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
