Mutating the semantics of NOTIFY/PUBLISH to make them close enough will require a document in the SIP working group and will likely take as much or more time to be deployed than an entirely new protocol.
If you have a 3265 engine that properly does etags, composition-plug-ins etc. is is highly optimized to those semantics; changing the semantics will require a lot of effort. It will also require a client to support different semantic for the same SIP primitive. It would be better to add a new primitive for SIP for this type of resource acquisition/allocation. This sounds scary, but it's really what people are proposing when they talk about 'extending the semantics a little.' Its just disguised as an extension to an existing mechanism. In this case I think adding a new protocol is easier/cleaner than modifying the semantics of the existing SIP mechanisms. BFCP and REST seem like good candidates here. BFCP has closer semantics built in(timers), REST has broader applicability for endpoints. That said, I agree with Francois that we may have gone overboard with requirements; we might be able to use SIP cleanly with reduced requirements. -Derek On Thu, Mar 13, 2008 at 10:34 PM, Venkatesh <[EMAIL PROTECTED]> wrote: > Alan, Rohan, et al: > > I second Mohsen's suggestion. I think it makes sense to find out what the > disagreements were with using either using NOTIFY's or PUBLISH. If either of > them violates the RFC, what would it take to augment the RFC to accomodate > these flows assuming that the changes being requested are reasonable enough > and does not drastically break anything else? Finally, the proposal below > looks like an overkill to me in terms of what it is trying to achieve and is > probably going to be left with little implementations. > > Thanks > Venkatesh > > > On Thu, Mar 13, 2008 at 10:24 PM, Mohsen Soroushnejad <[EMAIL PROTECTED]> > wrote: > > > Hi Alan - > > > > > > Thanks for leading the discussion on this draft. > > > > >>In this week's WG meeting, a number of people expressed concern about > > the use of PUBLISH to select appearance numbers as was proposed. Others > > also object to the use of NOTIFY as well.<< > > If you don't mind, please provide a synopsis of what these concerns were > > at the meeting w.r.t PUBLISH and NOTIFY usage. > > > > In addition to BFCP discussion, I like to see discussions on: > > > > - Extending NOTIFY usage (why not a NOTIFY 2.0?) > > - Extending PUBLISH usage (why not a PUBLISH 2.0?) > > - Hey, let's use INFO -- I know I get shot for saying this....;-) > > > > My initial reaction w.r.t. goal of BLISS (i.e., interoperability on > > running code) is that by adding yet another protocol that a SIP UA must > > support (i.e., BFCP), we're pushing it to the next decade, if not > > further. Is this a necessary price to pay? > > > > I look forward to discussions on the list. > > > > Best Regards, > > Mohsen > > > > > > On Thu, Mar 13, 2008 at 7:18 AM, Alan Johnston <[EMAIL PROTECTED]> > > wrote: > > > > > All, > > > > > > In this week's WG meeting, a number of people expressed concern about > > > the use of PUBLISH to select appearance numbers as was proposed. > > > Others > > > also object to the use of NOTIFY as well. Rohan made the suggestion > > > to > > > treat an appearance number as a shared resource and use floor control > > > and the Binary Floor Control Protocol (BFCP) to do selection. > > > > > > I have done some preliminary thinking about how we could manage > > > appearance numbers as a floor and utilize BFCP (RFC 4582) to request > > > and > > > learn appearance numbers. We should discuss these options on the > > > list > > > and use the resulting consensus in the next version of the document. > > > I > > > will leave my opinions out of this initial email but will express them > > > in the resulting followup discussion. > > > > > > This design would not modify the dialog event package - it would > > > remain > > > as is and would contain dialog identifiers. Normal dialog state > > > information would be published to an event state compositor (ESC) and > > > notifications would be sent by the ESC - none of this would be > > > appearance aware. > > > > > > Each floor would have a floor ID associated with it. A simple > > > solution > > > would be for the floor ID to be the appearance number, so in this > > > usage > > > of BFCP, only non-negative integers would be used as floor IDs. > > > > > > A UA in the group wishing to learn the holder of an appearance number > > > would query the floor control server and receive a response from the > > > floor control server. Each floor would contain the owner which would > > > be the GRUU of the dialog to which the floor is associated with. This > > > GRUU could be used be used to lookup the dialog identifiers in the > > > dialog package notification so that UAs could perform call control > > > operations such as INVITE Join, INVITE Replaces, etc. > > > > > > A UA in the group making a call would first request a floor from the > > > floor control server. If the floor was unavailable, the UA would try > > > again. The floor control server would be configured to not do floor > > > request queuing. Once a floor was obtained, an INVITE could be sent > > > and the dialog information published. > > > > > > An incoming call to the AOR would somehow be known to a moderator > > > client. The moderator client would use some predetermined logic > > > (first > > > available, for example) and request an available floor from the floor > > > control server. The INVITE would then be forked to the UAs in the > > > group. The INVITE would need to carry the appearance number, such as > > > an > > > appearance parameter on an Alert-Info header field as defined in the > > > current draft. (I don't know of any way a UA could learn the floor > > > number from the floor control server unless there is a command to list > > > all floors in use and find the one that is not associated with any > > > dialog.) > > > > > > With this design, UAs would implement a BFCP client and a SIP UA. The > > > ESC would not need any extensions. The BFCP server would not need any > > > extensions. The moderator client would be a special piece of software > > > that could coordinate with the forking proxy to learn of incoming > > > calls > > > and provide an appearance number to insert into the Alert-Info header > > > field. > > > > > > When a call ended, the UA would release the appearance number to the > > > floor control server which would then be free to assign the appearance > > > number for future incoming or outgoing calls. > > > > > > UAs would need to publish their dialog state to the ESC and subscribe > > > to > > > the ESC to learn dialog IDs of other UAs. UAs would also need to > > > establish a BFCP connection over TCP (by sending an INVITE to the > > > floor > > > control server using RFC 4583). We would need to define how the UA > > > learns the SIP URI of the floor control server. > > > > > > Of course, this needs further analysis but it would be useful to get > > > feedback before more work is put into this approach. > > > > > > Thanks, > > > Alan > > > > > > > > > > > > _______________________________________________ > > > BLISS mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/bliss > > > > > > > > > _______________________________________________ > > BLISS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/bliss > > > > > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > >
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
