Internet Engineering Task Force Internet Draft Wu/Koskelainen/Schulzrinne/Chen draft-wu-sipping-floor-control-01.txt Columbia University April 19, 2002 Expires: October 2002 Use of SIP and SOAP for Conference Floor Control STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract During a conference, floor means the right to access some shared resources such as audio or video channel. Floor control controls such right so as to enable applications or users to gain safe and mutually exclusive or non-exclusive access to the shared resources. This document defines an approach of using SIP event notification mechanism and SOAP to perform floor control. 1 Introduction Many existing conference management protocols [1] [2] have defined floor control functions. Floor control to a conference is like the traffic control to a transportation system. It can be used to avoid or resolve conflicts among simultaneous media inputs. For example, at Wu/Koskelainen/Schulzrinne/Chen [Page 1]
Internet Draft SIP-floor-control April 19, 2002 a given time, the moderator of a floor can ensure that only one person talks. The conference server needs to be able to control the shared resources. For example, the mixer in a conference bridge can selectively choose the media sources for mixing. The moderators and participants of the conference should be able to send the floor control commands to the conference server to change floor status, and the conference server should notify the changes to the moderators and the participants. A floor control protocol is used to convey the floor control messages among the moderator of the conference, the conference server and the participants of the conference. The floor control protocol does not deal with the conference management such as how to elect the moderator of the conference. Neither does it deal with the policy in the conference server such as who can join the conference. We divide the floor control messages into two categories. One is a set of floor control events and the other is a set of floor control commands. Conference server sends floor control events to moderators or participants to report changes in the resource status. The SIP Events architecture is well fitted for conveying floor control events. This document defines a new event package named floor-control for the floor control events. Moderators or participants send floor control commands to conference server to change the resource status. Floor control commands are like RPC calls from the moderators or the participants to the conference server. Since one of SOAP's [3] design goals is to encapsulate and exchange RPC calls, instead of creating a new XML schema, we consider to use SOAP for transmitting floor control commands. Either HTTP or SIP can be used to carry the SOAP content. The same mechanism can be used for general conference control [4]. The conference models can be centralized or non-centralized. In a centralized model, there is an entity (usually the conference server) acting as the root of the conference topology. There is no such root for the non-centralized model. The non-centralized model does not work well with the mechanism in this document. 1.1 Conventions of This Document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [5]. Wu/Koskelainen/Schulzrinne/Chen [Page 2]
Internet Draft SIP-floor-control April 19, 2002 2 Use SIP and SOAP for the floor control When a user joins a conference, the conference server uses SDP's 'a' line to indicate that the conference is moderated. a=type:moderated The new participants joining the moderated conference SHOULD start the media tool as 'mute' so as to not send media streams. The user's UA MAY send a SUBSCRIBE to the conference server to be notified of the changes of the resource status. The events in the floor-control package will be described in detail in section 4. If the user's UA cannot understand the 'floor-control' package, the user may use web based floor control approach. To convey the URL for the web based floor control, the conference server MAY use the 'Call-Info' header to bring the URL. And a new value, named 'floor- control', SHOULD be used for the Call-Info header's purpose parameter. If a user wants to change the floor control status, the user's UA MAY use SOAP to carry the floor control commands. The SOAP message can be either within HTTP or SIP. The name and the parameters of the commands will be described in detail in section 5. Both the moderator and the participants can have control over the conference. However, they have different control command set. The conference server SHOULD have knowledge of the moderated resources (e.g. who can control the resources and who are the moderators) and SHOULD convey the knowledge to the users. As indicated in RFC2327 [6], the 'm' line can specify the conference control tools, the port and protocol used for control. The following is an example: m=control 5060 SIP SOAP The shortage of this approach is that it does not associate floor control with each particular media. Thus, it cannot handle the case that a moderator cannot control all of the resources, e.g., a moderator can control the cameras but not the microphones. To solve this problem, we can group the control lines with the other media lines as described in the Internet Draft "Grouping of media lines in SDP [7]. A new semantics named FL (floor control) is defined for this purpose. The SDP will look like: Wu/Koskelainen/Schulzrinne/Chen [Page 3]
Internet Draft SIP-floor-control April 19, 2002 v=0 o=Foo 289083124 289083124 IN IP4 foo.example.com t=0 0 c=IN IP4 224.2.17.12/127 a=type:moderated a=group:FL 1 2 4 a=group:FL 3 5 m=audio 10000 RTP/AVP 0 a=mid:1 m=video 20000 RTP/AVP 31 a=mid:2 m=application 30000 udp wb a=mid:3 m=control 80 HTTP SOAP a=mid:4 m=control 5060 SIP SOAP a=mid:5 In this example, there are two floor control channels, one is for audio and video, the other is for whiteboard. The control line cannot indicate whether a user is a moderator or not. The conference server will use the floorCreated or configChanged event notification to indicate that. 3 Datatypes in the floor control messages We use XML-based data format for the floor control messages. A floor control message contains information about floor, resource and floor claims etc. To represent such information, the following defines several datatypes and provides XML schema fragment for each datatype. 3.1 floorType The floorType contains an optional attribute and several sub- elements. The optional attribute 'maxHolders' defines how many users can hold the floor simultanuously. The default value of the 'maxHolders' is 1. The following shows the XML schema fragment of the floorType. <xsd:complexType name="floorType"> <xsd:sequence> <xsd:element name="resources" type="resourcesType" minOccurs="0"/> <xsd:element name="users" type="usersType" minOccurs="0"/> <xsd:element name="moderators" type="moderatorsType" minOccurs="0"/> </xsd:sequence> Wu/Koskelainen/Schulzrinne/Chen [Page 4]
Internet Draft SIP-floor-control April 19, 2002 <xsd:attribute name="maxHolders" type="xsd:int" default="1"/> </xsd:complexType> There are three sub-elements in the floorType. The element 'resources' defines what are the resources the floor applied. If it is not provided, the floor is applied to all the resources of the conference. The element 'users' defines who can hold the floor. If it is not provided, every user in the conference can hold the floor. The element 'moderators' defines who are the moderators of the floor, if it is not provided, there is no moderator for the floor. In the case of no moderator, the conference server will base on its internal policy to grant floors. 3.2 resourcesType The resourcesType defines what are the resources the floor applied for. It contains a sequence of elements with the type resourceType. The following shows the XML schema fragment of the resourceType and the resourcesType. <xsd:simpleType name="resourceType"> <xsd:restriction base="xsd:string"/> </xsd:simpleType> <xsd:complexType name="resourcesType"> <xsd:sequence> <xsd:element name="resource" type="resourceType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> The value of the 'resource' element MUST be one of the mids defined in the SDP of the conference server's message. The SDP's a=mid line provides the value of the mid. 3.3 usersType The usersType contains a list of users or the URL of the web page that has the list of users that can claim the floor. The following shows the XML schema fragment of the userType and the usersType. <xsd:simpleType name="userType"> <xsd:restriction base="xsd:string"/> </xsd:simpleType> <xsd:complexType name="usersType"> <xsd:sequence> <xsd:element name="user" type="userType" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> Wu/Koskelainen/Schulzrinne/Chen [Page 5]
Internet Draft SIP-floor-control April 19, 2002 <xsd:attribute name="url" type="xsd:string"/> </xsd:complexType> 3.4 moderatorsType The moderatorsType contains a list the moderators for the floor. The following shows the XML schema fragment of the moderatorType and the moderatorsType. <xsd:simpleType name="moderatorType"> <xsd:restriction base="xsd:string"/> </xsd:simpleType> <xsd:complexType name="moderatorsType"> <xsd:sequence> <xsd:element name="moderator" type="moderatorType" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> 3.5 holdingType The holdingType defines the relationship between the holders and the resources. Within the holdingType are two elements, the resources and the users. The element 'resources' has the type 'resourcesType'. If it is not provided, the holding is for all resources of the conference. The element 'users' has the type 'usersType'. If it is not provided, the holding is for all users. The holdingType has two optional attributes, the timestamp gives when the users get the access right of the resources and the expiration defines when the holding will be expired. The following shows the XML schema fragment of the holdingType. <xsd:complexType name="holdingType"> <xsd:sequence> <xsd:element name="resources" type="resourcesType" minOccurs="0"/> <xsd:element name="users" type="usersType" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="expiration" type="xsd:dateTime"/> <xsd:attribute name="timestamp" type="xsd:dateTime"/> </xsd:complexType> 3.6 claimType The claimType contains the information sent by the participants to request a floor. The element 'user' defines who sends the claim. This element is required. The element 'resource' defines what the user claims for. The element 'subject' provides the reason for holding Wu/Koskelainen/Schulzrinne/Chen [Page 6]
Internet Draft SIP-floor-control April 19, 2002 the floor. The element 'holdingTime' defines how long the user expect to hold the floor. The required attribute 'claimID' and the element 'user' can uniquely identify a claim. The attribute 'timestamp' provides the time that the claim is generated. The attribute 'expiration' defines when the claim will be expired. The conference server MUST remove the expired floor claims from the queue. If the expiration value is 0, it indicates that the claim MUST be removed from the queue immediately. It is used to ask for immediate grant of the floor. For example, when the holder wants to extend the holding time, he/she can send a claim with expiration as 0 for the extension. The following shows the XML schema fragment of the claimType. <xsd:complexType name="claimType"> <xsd:sequence> <xsd:element name="user" type="userType" minOccurs="1" maxOccurs="1"/> <xsd:element name="resource" type="resourceType" minOccurs="0" maxOccurs="1"/> <xsd:element name="subject" type="xsd:string" minOccurs="0" maxOccurs="1"/> <xsd:element name="holdingTime" type="xsd:duration" minOccurs="0" maxOccurs="1"/> </xsd:sequence> <xsd:attribute name="claimID" type="xsd:string" use="required"/> <xsd:attribute name="timestamp" type="xsd:dateTime" use="optional"/> <xsd:attribute name="expiration" type="xsd:dateTime" use="optional"/> </xsd:complexType> 3.7 claimsType The claimsType contains a list of claims. The following shows the XML schema fragment of the claimsType. <xsd:complexType name="claimsType"> <xsd:sequence> <xsd:element name="claim" type="claimType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> 3.8 operationType We defined several operations such as move up, move down, move to the top and move to the bottom to manipulate the floor claim queue. The 'up', 'down', 'top' and 'bottom' are the operators. The operation MAY Wu/Koskelainen/Schulzrinne/Chen [Page 7]
Internet Draft SIP-floor-control April 19, 2002 have an argument. For 'up' and 'down', the argument indicates how far to move a claim. For 'top', the argument indicates the position counting down from the top of the queue. For 'bottom', the argument indicates the position counting up from the bottom of the queue. If the argument is not presented, the operation 'up' will move the claim up one position in the queue; the operation 'down' will move the claim down one position in the queue; the operation 'top' will move a claim at the top of the queue and the operation 'bottom' will move a claim to the bottom of the queue. The following shows the XML schema fragment of the operatorType and the operationType. <xsd:simpleType name="operatorType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="up"/> <xsd:enumeration value="down"/> <xsd:enumeration value="top"/> <xsd:enumeration value="bottom"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="operationType"> <xsd:sequence> <xsd:element name="operator" type="operatorType"/> <xsd:element name="argument" type="xsd:int" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="timestamp" type="xsd:dateTime"/> </xsd:complexType> 4 Floor control events Table 1 shows the events for the floor control package. We specify an XML-based data format for the parameters of each event. The MIME type for the format is application/floor-control+xml, consistent with the recommendations provided in RFC 3023 [8]. Event name Description Issuer -> Receiver ____________________________________________________________________ floorCreated A floor has been created for some Server -> User resources and participants. floorRemoved A floor has been removed for some Server -> User resources configChanged Floor configuration changed Server -> User floorChanged Floor changed to different users Server -> User queueChanged Floor claim queue changed Server -> Chair Table 1: Floor control events Wu/Koskelainen/Schulzrinne/Chen [Page 8]
Internet Draft SIP-floor-control April 19, 2002 4.1 floorCreated event When a floor is created for some resources, the conference server SHOULD send a notification to the parties interested in this event. The floorCreated event contains the information about what are the resources being controlled and who can access the floor. The XML document for the floorCreated event starts with a 'floorCreated' tag. Within the tag are one or more 'floor' elements. The floor element has the type floorType. The following shows the XML schema fragment of the floorCreated event. <xsd:element name="floorCreated"> <xsd:complexType> <xsd:sequence> <xsd:element name="floor" type="floorType" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> </xsd:element> 4.2 floorRemoved event When a floor is removed for some resources, the conference server SHOULD send a notification to the parties interested in this event. The XML document for floorRemoved event starts with a 'floorRemoved' tag. The following shows the XML schema fragment of the floorRemoved event. <xsd:element name="floorRemoved"> <xsd:complexType> <xsd:sequence> <xsd:element name="resources" type="resourcesType" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> 4.3 configChanged event When the configuration of the floor changed, the conference server SHOULD send a notification to the parties interested in this event. The event contains the updated floor information. The following shows the XML schema fragment of the configChanged event. <xsd:element name="configChanged"> Wu/Koskelainen/Schulzrinne/Chen [Page 9]
Internet Draft SIP-floor-control April 19, 2002 <xsd:complexType> <xsd:sequence> <xsd:element name="floor" type="floorType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> 4.4 floorChanged event If the holders of one or more floors has been changed, the conference server SHOULD send a notification to the parties interested in this event. At the same time, the conference server SHOULD send a re- INVITE to the new holders to enable the media sending. Before getting the floor, a participant SHOULD mute the moderated media tools. The following shows the XML schema fragment of the floorChanged event. The element 'holding' contains the new holders' information. <xsd:element name="floorChanged"> <xsd:complexType> <xsd:sequence> <xsd:element name="holding" type="holdingType"/> </xsd:sequence> </xsd:complexType> </xsd:element> 4.5 queueChanged event When the claim queue is changed, for example, a new claim is added in or a claim is removed, the conference server SHOULD send a notification to the parties interested in the queueChanged event. The queueChanged event contains the updated claim queue. The required attribute 'timestamp' defines when the event happens. The optional attribute 'url' provides the web URL having the updated claim queue. The following shows the XML schema fragment of the queueChanged event. <xsd:element name="queueChanged"> <xsd:complexType> <xsd:sequence> <xsd:element name="claims" type="claimsType" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="timestamp" type="xsd:dateTime"/> <xsd:attribute name="url" type="xsd:string"/> </xsd:complexType> </xsd:element> Wu/Koskelainen/Schulzrinne/Chen [Page 10]
Internet Draft SIP-floor-control April 19, 2002 5 Floor control commands Table 2 shows the floor control commands. The floor control command will be encapsulated in SOAP and sent from the user to the conference server for changing the floor status. Command name Description Issuer -> Receiver _______________________________________________________________________ CreateFloor Create a floor for some resources Moderator -> Server and participants. RemoveFloor Remove the floor for some Moderator -> Server resources. ChangeConfig Change the configuration of a floor Moderator -> Server ClaimFloor Request a floor User -> Server ReleaseFloor Give up the floor User -> Server GrantFloor Grant floor to some users Moderator -> Server RevokeFloor Force release floor from some users Moderator -> Server RemoveClaims Remove the existing floor claims User -> Server ReorderClaims Reorder the claims in the queue Moderator -> Server Table 2: Floor control commands 5.1 CreateFloor command CreateFloor command will create a floor for some resources and users. Only the moderator can execute this command. boolean CreateFloor(floorType floor) The CreateFloor command takes one parameter, floor, to create a new floor for some resources. The parameter 'floor' has the type 'floorType'. The response of the method is a boolean value indicating whether the floor is successfully created or not. The following shows the XML schema fragment of the CreateFloor command and the response of the command. <xsd:element name="CreateFloor"> <xsd:complexType name="CreateFloor"> <xsd:sequence> <xsd:element name="floor" type="floorType"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="CreateFloorResponse"> <xsd:complexType name="CreateFloorResponse"> Wu/Koskelainen/Schulzrinne/Chen [Page 11]
Internet Draft SIP-floor-control April 19, 2002 <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 1 shows an example of using SOAP to carry the CreateFloor command. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:CreateFloor xmlns:m="Some-URI"> <floor max_holders=2> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <moderators> <moderator>sip:foo@examples.com</moderator> </moderators> </floor> </m:CreateFloor> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 1: Use SOAP to encapsulate CreateFloor command 5.2 RemoveFloor command RemoveFloor command will delete the floors for several resources. Only the moderator can execute this command. boolean RemoveFloor(resourcesType resources) The RemoveFloor command takes one parameter, resources, which has the type resoursesType. The response of the method is a boolean value indicating whether the floor is successfully removed or not. The following shows the XML schema fragment of the RemoveFloor command and the response of the command. Wu/Koskelainen/Schulzrinne/Chen [Page 12]
Internet Draft SIP-floor-control April 19, 2002 <xsd:element name="RemoveFloor"> <xsd:complexType name="RemoveFloor"> <xsd:sequence> <xsd:element name="resources" type="resourcesType"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="RemoveFloorResponse"> <xsd:complexType name="RemoveFloorRespones"> <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 2 shows an example of using SOAP to carry the RemoveFloor command. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:floor_remove xmlns:m="Some-URI"> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> </m:floor_remove> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 2: Use SOAP to encapsulate RemoveFloor command 5.3 ChangeConfig command The ChangeConfig command will change a floor's configuration. Only the moderator can execute this command. boolean ChangeConfig(floorType floor) The parameters for the ChangeConfig command is the same as that for Wu/Koskelainen/Schulzrinne/Chen [Page 13]
Internet Draft SIP-floor-control April 19, 2002 the CreateFloor command. The response indicates whether the configuration is successfully changed or not. The following shows the XML schema fragment of the ChangeConfig command and the response of the command. <xsd:element name="ChangeConfig"> <xsd:complexType name="ChangeConfig"> <xsd:sequence> <xsd:element name="floor" type="floorType"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="ChangeConfigResponse"> <xsd:complexType name="ChangeConfigResponse"> <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 3 shows an example of using SOAP to carry the ChangeConfig command. 5.4 ClaimFloor command When a user wants to request a floor, the user's UA SHOULD send a ClaimFloor command to the conference server. The holder of a floor can also use ClaimFloor command to extend the holding time. To ask for the extension, the holder MUST set the expiration time of the claim as 0. The moderator SHOULD immmediately process the claim with expiration as 0. boolean ClaimFloor(claimsType claims) The response of the method is a boolean value indicating whether the claims has been successfully put into the claim queue. The following shows the XML schema fragment of the ClaimFloor command and the response of the command. <xsd:element name="ClaimFloor"> <xsd:complexType name="ClaimFloor"> <xsd:sequence> <xsd:element name="claims" type="claimsType"/> </xsd:sequence> </xsd:complexType> </xsd:element> Wu/Koskelainen/Schulzrinne/Chen [Page 14]
Internet Draft SIP-floor-control April 19, 2002 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:ChangeConfig xmlns:m="Some-URI"> <floor max_holders=2> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <moderators> <moderator>sip:foo@examples.com</moderator> </moderators> </floor> </m:ChangeConfig> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 3: Use SOAP to encapsulate ChangeConfig command <xsd:element name="ClaimFloorResponse"> <xsd:complexType name="ClaimFloorResponse"> <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 4 shows an example of using SOAP to carry the ClaimFloor command. 5.5 ReleaseFloor event When a user finishes input, the user SHOULD release the floor so that the other user can get the floor. The user's UA SHOULD send a ReleaseFloor command to the conference server to release the floor. The ReleaseFloor command takes one parameter, holding, which has the type holdingType. The sender of the command SHOULD be the same as the sub-element 'user' of the holding parameter. boolean ReleaseFloor (holdingType holding) Wu/Koskelainen/Schulzrinne/Chen [Page 15]
Internet Draft SIP-floor-control April 19, 2002 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:ClaimFloor xmlns:m="Some-URI"> <claims> <claim claimID="1" timestamp="Sun Apr 7 12:05:45 EDT 2002" expiration="Sun Apr 7 13:05:45 EDT 2002"> <user>sip:foo@example.com</user> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <subject>Why SOAP</subject> <holdingTime>P30S</holdingTime> </claim> </claims> </m:ClaimFloor> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 4: Use SOAP to encapsulate ClaimFloor command The following shows the XML schema fragment of the ReleaseFloor command. <xsd:element name="ReleaseFloor"> <xsd:complexType name="ReleaseFloor"> <xsd:sequence> <xsd:element name="holding" type="holdingType"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="ReleaseFloorResponse"> <xsd:complexType name="ReleaseFloorResponse"> <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 5 shows an example of using SOAP to carry the ReleaseFloor command. Wu/Koskelainen/Schulzrinne/Chen [Page 16]
Internet Draft SIP-floor-control April 19, 2002 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:floor_release xmlns:m="Some-URI"> <holding> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <users> <user>sip:foo@examples.com</user> </users> </holding> </m:floor_release> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 5: Use SOAP to encapsulate ReleaseFloor command 5.6 GrantFloor command The GrantFloor command will grant one or more floors to several users. The parameter 'holding', which has the type 'holdingType', defines the relationship between the floors and the holders. The parameter 'claim', which has the type 'claimType', specifies the claim that the floor is granted for. The specified claim MUST be removed from the queue. If the 'claim' parameter is not provided, the GrantFloor command will not affect the claim queue. Only the moderator can execute this command. boolean GrantFloor(holdingType holding, claimType claim) The following shows the XML schema fragment of the GrantFloor command. <xsd:element name="GrantFloor"> <xsd:complexType name="GrantFloor"> <xsd:sequence> <xsd:element name="holding" type="holdingType"/> <xsd:element name="claim" type="claimType" minOccurs="0" maxOccurs="1"/> Wu/Koskelainen/Schulzrinne/Chen [Page 17]
Internet Draft SIP-floor-control April 19, 2002 </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="GrantFloorResponse"> <xsd:complexType name="GrantFloorResponse"> <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 6 shows an example of using SOAP to carry the GrantFloor command. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GrantFloor xmlns:m="Some-URI"> <holding expiration="Sat Apr 6 11:53:24 EST 2002"> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <users> <user>sip:foo@examples.com</user> </users> </holding> </m:GrantFloor> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 6: Use SOAP to encapsulate GrantFloor command 5.7 RevokeFloor command The RevokeFloor command will force the release of a floor from the current holders. boolean RevokeFloor(holdingType holding) Wu/Koskelainen/Schulzrinne/Chen [Page 18]
Internet Draft SIP-floor-control April 19, 2002 RevokeFloor command takes the same parameter as that for the GrantFloor command. Only the moderator can execute this command. The following shows the XML schema fragment of the RevokeFloor command. <xsd:element name="RevokeFloor"> <xsd:complexType name="RevokeFloor"> <xsd:sequence> <xsd:element name="holding" type="holdingType"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="RevokeFloorResponse"> <xsd:complexType name="RevokeFloorResponse"> <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 7 shows an example of using SOAP to carry the RevokeFloor command. 5.8 RemoveClaims command The RemoveClaims command will remove several claims from the claim queue. The moderator can remove any claims. The participants can only remove his/her own claims. boolean RemoveClaims(claimsType claims) RemoveClaims command takes one parameter, claims. The return value indicates whether the claims have been removed successfully. The following shows the XML schema fragment of the RemoveClaims command. <xsd:element name="RemoveClaims"> <xsd:complexType name="RemoveClaims"> <xsd:sequence> <xsd:element name="claims" type="claimsType"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="RemoveClaimsResponse"> <xsd:complexType name="RemoveClaimsResponse"> Wu/Koskelainen/Schulzrinne/Chen [Page 19]
Internet Draft SIP-floor-control April 19, 2002 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:RevokeFloor xmlns:m="Some-URI"> <holding> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <users> <user>sip:foo@examples.com</user> </users> </holding> </m:RevokeFloor> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 7: Use SOAP to encapsulate RevokeFloor command <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 8 shows an example of using SOAP to carry the RemoveClaims command. 5.9 ReorderClaims command The ReorderClaims command will change the order of the claims in the queue. Only the moderator can execute this command. This command will use some simple operations such as move a claim to the top, move a claim up, to change a single claim's position. It takes three parameters. The parameter 'resources' indicates the claim queue to operate. The parameter 'claim' indicates which claim to move. The parameter 'operation' defines how to move the claim. boolean ReorderClaims(resourcesType resources, claimType claim, Wu/Koskelainen/Schulzrinne/Chen [Page 20]
Internet Draft SIP-floor-control April 19, 2002 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:RemoveClaims xmlns:m="Some-URI"> <claims> <claim claimID="1"> <user>sip:foo@example.com</user> </claim> </claims> </m:RemoveClaims> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 8: Use SOAP to encapsulate RemoveClaims command operationType operation) The following shows the XML schema fragment of the RemoveClaims command. <xsd:element name="ReorderClaims"> <xsd:complexType name="ReorderClaims"> <xsd:sequence> <xsd:element name="resources" type="resourcesType"/> <xsd:element name="claim" type="claimType"/> <xsd:element name="operation" type="operationType"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="ReorderClaimsResponse"> <xsd:complexType name="ReorderClaimsResponse"> <xsd:simpleContent> <xsd:restriction base="xsd:boolean"/> </xsd:simpleContent> </xsd:complexType> </xsd:element> Figure 9 shows an example of using SOAP to carry the RemoveClaims command. Wu/Koskelainen/Schulzrinne/Chen [Page 21]
Internet Draft SIP-floor-control April 19, 2002 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:ReorderClaims xmlns:m="Some-URI"> <claim claimID="1"> <user>sip:foo@example.com</user> </claim> <operation timestamp="Sun Apr 7 12:15:55 EDT 2002"> <operator>up</operator> <argument>2</argument> </operation> </m:ReorderClaims> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 9: Use SOAP to encapsulate ReorderClaims command 6 The floor control policies By default, each resource may have its own floor claim queue so that people interested in one resource will not get notified by the other resource's claim. However, if one moderator can control multiple resources, and the resources will be granted in all or none mode, the conference server MUST use one floor claim queue for all the resources. The floor claim queue is created when executing the CreateFloor command. The parameter of the command defines the resources the floor will apply. When a conference server receives a ClaimFloor command, the conference server SHOULD append the new claims at the end of the queue. If the current floor holder is done, the claim at the front of the queue SHOULD automatically get the floor. The fulfilled claims MUST be removed from the claim queue. In one claim request, a user may claim multiple resources in different floor claim queues. The claim will be appended to all the applicable queues. To avoid the potential deadlock, the claim in different queue MUST be independent with each other. The floor will be granted separately for the claims in different queue. When a conference server receives a GrantFloor command, by default, the conference server SHOULD queue the grant until there is an Wu/Koskelainen/Schulzrinne/Chen [Page 22]
Internet Draft SIP-floor-control April 19, 2002 available floor. Occupied floor can be released by ReleaseFloor and RevokeFloor commands. 7 Security consideration Conference server SHOULD use appropriate authentication to ensure the commands and events originated from trusted parties. Other SIP considerations apply [9]. 8 Call flows 8.1 A user joins the conference and gets a floor 9 Authors' Addresses Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: xiaotaow@cs.columbia.edu Petri Koskelainen Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: petkos@cs.columbia.edu electronic mail: petri.koskelainen@nokia.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu Clayton C. Chen Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: ccc57@cs.columbia.edu Wu/Koskelainen/Schulzrinne/Chen [Page 23]
Internet Draft SIP-floor-control April 19, 2002 Conference server participant | | | | +<-------- INVITE --------------+ | | | | +--------- 200 -------------->+ | (moderated) | | | +<------- SUBSCRIBE ------------+ | (Event: floor-control) | | | +-------- NOTIFY -------------->+ | (configChanged) | | | +<------- HTTP/SOAP ------------+ | (ClaimFloor) | | | moderator <---- NOTIFY ----+ | (queueChanged) | | | | moderator --- HTTP/SOAP -->+ | (GrantFloor) | | | | +--------- NOTIFY ------------->+ | (floorChanged) | | | +-------- re-INVITE ----------->+ | (a=sendrecv) | other | | participants <---- NOTIFY ----+ | (floorChanged) Figure 10: A user send INVITE to join the conference 10 Bibliography [1] C. Bormann, D. Kutscher, J. Ott, and D. Trossen, "Simple conference control protocol service specification," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. [2] R. Malpani and L. A. Rowe, "Floor control for large-scale Mbone seminars," in Proc. of ACM Multimedia , (Seattle, Washington), Nov. 1997. Wu/Koskelainen/Schulzrinne/Chen [Page 24]
Internet Draft SIP-floor-control April 19, 2002 [3] W3C, "Simple object access protocol (soap) 1.1." [4] P. Koskelainen, H. Schulzrinne and X. Wu, "A sip-based conference control framework," in NOSSDAV , (Miami, Florida), May 2002. [5] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [6] M. Handley and V. Jacobson, "SDP: session description protocol," Request for Comments 2327, Internet Engineering Task Force, Apr. 1998. [7] G. Camarillo, J. Holler, G. Eriksson, and H. Schulzrinne, "Grouping of m lines in SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [8] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request for Comments 3023, Internet Engineering Task Force, Jan. 2001. [9] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. Full Copyright Statement Copyright (c) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Wu/Koskelainen/Schulzrinne/Chen [Page 25]
Internet Draft SIP-floor-control April 19, 2002 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Table of Contents 1 Introduction ........................................ 1 1.1 Conventions of This Document ........................ 2 2 Use SIP and SOAP for the floor control .............. 3 3 Datatypes in the floor control messages ............. 4 3.1 floorType ........................................... 4 3.2 resourcesType ....................................... 5 3.3 usersType ........................................... 5 3.4 moderatorsType ...................................... 6 3.5 holdingType ......................................... 6 3.6 claimType ........................................... 6 3.7 claimsType .......................................... 7 3.8 operationType ....................................... 7 4 Floor control events ................................ 8 4.1 floorCreated event .................................. 9 4.2 floorRemoved event .................................. 9 4.3 configChanged event ................................. 9 4.4 floorChanged event .................................. 10 4.5 queueChanged event .................................. 10 5 Floor control commands .............................. 11 5.1 CreateFloor command ................................. 11 5.2 RemoveFloor command ................................. 12 5.3 ChangeConfig command ................................ 13 5.4 ClaimFloor command .................................. 14 5.5 ReleaseFloor event .................................. 15 5.6 GrantFloor command .................................. 17 5.7 RevokeFloor command ................................. 18 5.8 RemoveClaims command ................................ 19 5.9 ReorderClaims command ............................... 20 6 The floor control policies .......................... 22 7 Security consideration .............................. 23 8 Call flows .......................................... 23 8.1 A user joins the conference and gets a floor ........ 23 9 Authors' Addresses .................................. 23 10 Bibliography ........................................ 24 Wu/Koskelainen/Schulzrinne/Chen [Page 26]