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: > 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. 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. > > 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. 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". > > 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. > It is unlikely a new overload of REGISTER could really work or gain consensus in the SIP Working Group. > -Derek > > ------------------------------------------------------------------------ > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
