Re: [BLISS] Multiple Session Appearances of an AOR using Floor Control

Hello,

Pub/Not is what we prefer.

Martin 

-----Original Message-----
From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf
Of Alan Johnston
Sent: Friday, May 30, 2008 3:52 PM
To: bliss@ietf.org
Subject: [BLISS] Multiple Session Appearances of an AOR using Floor
Control

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
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss