All, In the MLA design team, we have come up with two non-PUBLISH/NOTIFY mechanisms for this feature.
The first is a floor control approach described in this email. The other is an INVITE approach discussed in a separate email. We are looking to get feedback on which of these approaches to develop further, and also revisit the PUBLISH/NOTIFY issues raised in Philadelphia. Comments are most welcome! Thanks, Alan - - - - Elements: Standard SIP Event State Compositor (ESC) Standard BFCP Floor Control Server that uses Appearance Agent as Moderator Registrar/Forking Proxy Server that talks to Appearance Agent about incoming calls Appearance Agent: software that acts as Moderator for floor control server and tells forking proxy to insert Alert-Info header field in incoming requests. Operations: UAs in the appearance group would subscribe to the dialog state of the AOR (to the ESC) and would publish their dialog state to the AOR. The dialog package would be extended to include the <appearance> attribute. Appearance numbers are allocated/selected/reserved in two ways: 1. For incoming calls, the Forking Proxy interacts with the Appearance Agent. The Appearance Agent selects an appearance by taking a particular floor and marking it "moderator controlled". This appearance number is then included by the Forking Proxy in INVITEs. When a UA answers the call, it takes the appearance number from the Alert-Info and includes it in the dialog state publication. It then requests the floor associated with the appearance number from the floor control server, which forwards the request to the Appearance Agent (moderator). The Appearance Agent correlates the floor control request with the dialog state notification with the dialog ID from the INVITE with the Alert-Info. If they match, the floor is granted. If they do not match, it means the floor request is not an answer of the call but is a random appearance selection by the UA and will be rejected. 2. For outgoing calls, the UA sends an INVITE and requests a particular floor from the floor control server. Depending on the User Interface requirements, the floor request can be done before or after sending the INVITE. The floor grant policy for most appearances is set to "first come first serve". Once the floor has been granted and the call answered, the dialog state publication by the UA will include the appearance number. When a call has ended, the UA releases the floor to the floor control server and this appearance is now available for incoming and outgoing calls. When a UA in the group which does not support BFCP is in a call, the Appearance Agent will grant the floor associated with that appearance to that UA. When that call is over, the Appearance Agent will release the floor. Since the UA will not publish the appearance number to the ESC, the Appearance Agent will need to do that on their behalf. If the UA does publish dialog state but without the appearance number, the Appearance Agent will still need to re-publish the dialog state including the appearance number. UAs in the group will be able to recognize these two dialogs as one since they will have the same SIP dialog ID. Alternate Approach: The previous approach requires all UAs to support BFCP and interact with the floor control server. It would be nice to come up with an approach that meant that only UAs who needed to seize a particular appearance number. One way of doing this would be to do away with the standard ESC and have the Appearance Agent get all the publication information (with or without appearance information) and the send notifies including the appearance number. In this case, a UA who does not care what appearance number is selected for an outgoing call would just make the call and would learn the appearance number in a NOTIFY from the Appearance Agent. A UA which does care (due to UI issues) would still be forced to use BFCP to get the floor. _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
