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
