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
