Subject: [BLISS] MLA Open Issue-Appearance Acquisition

From: "Derek MacDonald" <[email-masked]>
Date: Tue, 11 Mar 2008 09:54:47 -0400

I believe that there is one open issue which we did not resolve during the
design team calls, mainly because I thought of it too late.

The approach to Appearance Acquisition using the Dialog Package Parameter
approach described in section 5 violates the semantics of NOTIFY and
PUBLISH. It
also requires that the resource acquisition request be performed in one
dialog,
while the response is received in another, which is rather strange.

Snipped from 11.2

Carol        Proxy           Alice     Appearance Agent         Bob
|              |               |              |                  |
|              |               |              |<------ NOTIFY F1<|
|              |               |              |                  |
|              |               |              |>F2 200 OK ------>|
|              |               |              |                  |
|              |               |<-- NOTIFY F3<|                  |
|              |               |              |                  |
|              |               |>F4 200 OK -->|                  |
|              |               |              |------- NOTIFY F5>|
|              |               |              |                  |
|              |               |              |<F6 200 OK ------<|
|              |               |              |                  |

F1 is a request for an appearance; it might be a particular appearance, or
it
could be a request for any available appearance.  The 200OK does not
indicate if
an appearance was acquired, or whic was acquired.

The appearance is returned in F5; which is a different dialog. This doesn't
match the 3265 NOTIFY semantics:

     Notification: Notification is the act of a notifier sending a NOTIFY
     message to a subscriber to inform the subscriber of the state of a
     resource.

I have discussed this style of resource acquisition should be performed with
a few people; 3
approaches have been considered.

1. SUBSCRIBE with a body as a filter--new event package used to retrieve
appearances.

I had this as a straw man; after talking to Adam I'm convinced that this is
also
an abuse of 3265, if not as egregious.

2. BFCP - Rohan Mahy

You have a floor for each named appearance.  If you want to sieze an
appearce
you request the floor for the next available appearance.  If it fails you
try
the next one.  The chance of one failure is small, the change of two
consequtive
failures is very, very low.  BCFP is lightweight and fast. This approach
allows
a commodity dialog event server to be used if it has the appropriate
composition policy.

3. GRUU-REG thing from Dean Willis after 3 drinks

A separate registrar controls the appearances.  Each appearance is a GRUU.
Appearances are requested using a REGISTER; a parameter specifies if a
specific
appearance is requested; otherwise the next available appearance is
returned.

-Derek
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Alan Johnston <[email-masked]>
Date: Tue, 11 Mar 2008 09:27:13 -0500

Derek,

I disagree that this is a resource acquisition problem across two 
dialogs - it is a distributed state synchronization problem.  When a UA 
selects an available appearance number and sends a NOTIFY to the 
Appearance Agent, it is sending its view of the state of the resource.  
However, since the state is distributed among several UAs, this state 
may not be accurate.  The only one with an accurate view of the state is 
the Appearance Agent.  The Appearance Agent then updates the state based 
on the NOTIFY and sends a NOTIFY to all the subscribed UAs indicating 
the new current state.  The UA may discover that the selected appearance 
number is in fact not available and the UA can then choose again based 
on this updated state.  Please point out in this description where the 
semantics of RFC 3265 are being violated.

Now, we have recently added some optimizations that allow a UA to 
provide some suggested preferences to the Appearance Agent in the event 
that the UA's view of the state was out of date.  These include the 
ability to allow the Appearance Agent to select any available 
appearance, or to select an appearance from a range or set.  Now, if 
this violates RFC 3265 then perhaps we can drop these enhancements.  We 
can replicate the functionality - it will just require multiple round 
trips.  I'm fine with this.  However, this doesn't require a complete 
U-turn in how we solve this problem.

See additional comments below.

Thanks,
Alan

Derek MacDonald wrote:
> also requires that the resource acquisition request be performed in 
> one dialog,
> F1 is a request for an appearance; it might be a particular 
> appearance, or it
> I have discussed this style of resource acquisition should be 
> performed with a few people; 3
> 1. SUBSCRIBE with a body as a filter--new event package used to 
> retrieve appearances.
>
> I had this as a straw man; after talking to Adam I'm convinced that 
> this is also

I think this is worse - an appearance selection does not change the 
state of the subscription nor what information the UA wishes to receive 
in NOTIFYs.  SUBSCRIBE is clearly not the right method here.

> you request the floor for the next available appearance.  If it fails 
> you try
> failures is very, very low.  BCFP is lightweight and fast. This 
> approach allows

Yes, this could work. We actually wouldn't use 90% of BFCP 
functionality.  It is quite ugly, though, as the floors would need to be 
mapped to the dialog package.  Multiple subscriptions would have to be 
maintained and the information in each synchronized.  I wouldn't be 
surprised if this introduces very complex race conditions. 

Also, BFCP would have to be extended in order to do any optimizations, 
as there is no way in BFCP to say "Give me any floor" or "Give me any of 
the first 5 floors".

> appearance is requested; otherwise the next available appearance is 

It is unlikely a new overload of REGISTER could really work or gain 
consensus in the SIP Working Group.

> -Derek
>
> ------------------------------------------------------------------------
>