Internet Engineering Task Force Internet Draft Wu/Koskelainen/Schulzrinne/Chen draft-wu-sipping-floor-control-00.txt Columbia University February 22, 2002 Expires: August 2002 Use 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 Floor control is used to control who can input for the media applications during a conference. This document defines an approach of using SIP event notification mechanism and SOAP to perform the floor control functions. 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 the conflicts of simultaneous media inputs. For example, at a given time, the moderator of a conference can ensure that only one person can talk to avoid confusion. Wu/Koskelainen/Schulzrinne/Chen [Page 1]
Internet Draft SIP-floor-control February 22, 2002 To perform floor control requires the conference server be able to control the floor, for example, the mixer of the conference server can selectively choose the media input for mixing. It also requires the moderator and the participants of the conference can send the floor control messages to the conference server for changing floor status, and the conference server can notify the changes to the moderator and the participants. The 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. The floor control messages can be divided into two categories. One is a set of floor control events and the other is a set of floor control commands. The floor control events are used to report the changes of the floor control status. The SIP Events architecture is well fitted for conveying the floor control events. This document defines a new event package named floor-control for the floor control events. The floor control commands are used to change the floor control status. The floor control commands are in fact RPC calls from the moderator or the participants to the conference server. Since one of SOAP's design goals is to encapsulate and exchange RPC calls, instead of creating a new XML schema, we consider to use SOAP for transmitting the floor control commands. Either HTTP or SIP can be used to carry SOAP content. 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 [3]. 2 Use SIP and SOAP for the floor control When a user joins a conference, the conference server MAY use SDP's 'a' line to indicate a media is moderated. Wu/Koskelainen/Schulzrinne/Chen [Page 2]
Internet Draft SIP-floor-control February 22, 2002 a=type:moderated The new participants joining the moderated conference SHOULD start the media tool as 'mute'. The user's UA MAY send a SUBSCRIBE to the conference server for the floor control status changes on the moderated media. The events in the floor-control package will be described in detail in section 3. 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 4. 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 the knowledge to the users. As indicated in the RFC2327 [4], the 'm' line can specify the conference control tools and the port and protocol used by the conference control tools. 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 user cannot control all of the resources, e.g., a user can control the cameras but not the microphones. To solve this problem, we can group the control line with the other media lines as described in the Internet Draft "Grouping of media lines in SDP"[5]. A new semantics named FL (floor control) is defined for this purpose. And the SDP will look like: v=0 o=Foo 289083124 289083124 IN IP4 foo.example.com t=0 0 c=IN IP4 224.2.17.12/127 a=group:FL 1 2 4 Wu/Koskelainen/Schulzrinne/Chen [Page 3]
Internet Draft SIP-floor-control February 22, 2002 a=group:FL 3 5 m=audio 10000 RTP/AVP 0 a=type:moderated a=mid:1 m=video 20000 RTP/AVP 31 a=type:moderated a=mid:2 m=application 30000 udp wb a=type:moderated 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 floors, one is for audio and video inputs and the other is for whiteboard input. The user can control both floors. The control line cannot indicate whether a user is a moderator or not. The conference server will use the floor_created event notification to indicate that. Section 3.1 describes the floor_created event in detail. 3 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 [6]. Event name Description Issuer -> Reciever _____________________________________________________________________ floor_created A floor has been created for some Server -> User resources and participants. floor_removed A floor has been removed for some Server -> User resources and participants. config_changed Floor configuration changed Server -> User floor_changed Floor changed to different users Server -> User queue_changed Floor claim queue changed Server -> Chair Table 1: Floor control events 3.1 floor_created event Wu/Koskelainen/Schulzrinne/Chen [Page 4]
Internet Draft SIP-floor-control February 22, 2002 When a floor is created for some resources, the conference server SHOULD send a notification to the parties interested in this event. The floor_created event contains the information about what are the resources being controlled and who can access the floor. The XML document for floor_created event starts with a 'floor_created' tag. Within the tag are one or more 'floor' tags. <!ELEMENT floor_created (floor+)> The floor tag contains several optional tags that describe the configuration information of the new created floor. The optional attribute 'max_holders' defines how many users can hold the floor at the same time. The default value of the 'max_holders' attribute is 1. <!ELEMENT floor (resources?,users?,moderators?)> <!ATTLIST floor max_holders CDATA #DEFAULT "1"> There are three subtags defined for the floor tag. 3.1.1 Resources Resources subtag defines what's the resources the floor applied. <!ELEMENT resources (resource+)> <!ELEMENT resource CDATA> If the resources tag is not provided, the floor is for all the resources of the conference. The value of 'resource' tag MUST be one of the mids in the SDP of the conference server's message. 3.1.2 Users Users subtag provides a list of users or the URL of the web page that contains the list of users that can claim the floor. If not provided, all the users can claim the floor. <!ELEMENT users (user*)> <!ATTLIST users url CDATA #IMPLIED> <!ELEMENT user CDATA> 3.1.3 Moderators Moderators subtag list the moderators for the new created floor. <!ELEMENT moderators (moderator+)> Wu/Koskelainen/Schulzrinne/Chen [Page 5]
Internet Draft SIP-floor-control February 22, 2002 <!ELEMENT moderator CDATA> 3.2 floor_removed 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 floor_removed event starts with a 'floor_removed' tag. <!ELEMENT floor_removed (resources?)> The resources tag is the same as that defined in the section 3.1. 3.3 config_changed event When the configuration of the floor changed, the conference server SHOULD send a notification to the parties interested in this event. The XML document for config_changed event starts with a 'config_changed' tag. <!ELEMENT config_changed (floor+)> Within the tag are one or more floor tags. The floor tag is the same as that defined in the floor_created event. The floor tag carries the updated configuration information of a floor. 3.4 floor_changed 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 re-INVITE to the new holders to enable the media sending. Before getting the floor, a participant SHOULD mute the moderated media tools. The XML document for floor_changed event starts with a 'floor_changed' tag. Within the floor_changed tag are one or more holding tags. <!ELEMENT floor_changed (holding+)> The holding tag defines the relationship between the holders and the resources. Within holding tag are two required tags, the resources and the holders. The holding tag has one optional attribute that gives the timestamp of when the holders get the floor of the resources. Wu/Koskelainen/Schulzrinne/Chen [Page 6]
Internet Draft SIP-floor-control February 22, 2002 <!ELEMENT holding (resources?,holders)> <!ATTLIST holding timestamp CDATA #IMPLIED> The resources subtag is the same as that defined in the section 3.1. If it's not provided, the holding is for all the resources of the conference. The 'holders' subtag gives the list of users that currently holding the floor of the resources. 3.4.1 Holders Holders subtag provides a list of users or the URL of the web page that contains the list of users that holding the floor. The attribute 'expiration' defines how long the holders can hold the floor. <!ELEMENT holders (holder*)> <!ATTLIST holders expiration CDATA #IMPLIED url CDATA #IMPLIED> The holder subtag is within the holders tag. It provides the information of the holder. The expiration value in the 'holder' subtag will override the 'expiration' value in the 'holders' tag. <!ELEMENT holder CDATA> <!ATTLIST holder expiration CDATA #IMPLIED> 3.5 queue_changed event When the claim queue is changed, for example, a new claim is added in or an expired claim is removed out, the conference server SHOULD send a notification to the parties interested in this event. The XML document for queue_changed event starts with a 'queue_changed' tag. The required attribute timestamp defines when the event happens. The optional attribute url provides the web URL that contains the updated claim queue. <!ELEMENT queue_changed (claims?)> <!ATTLIST queue_changed timestamp CDATA #REQUIRED url CDATA #IMPLIED> The claims subtag contains one or more claims for the updated claim queue. <!ELEMENT claims (resources?,claim+)> The resources subtag defines what's the resources for the claim queue. It's the same as that defined in the section 3.1. Wu/Koskelainen/Schulzrinne/Chen [Page 7]
Internet Draft SIP-floor-control February 22, 2002 <!ELEMENT claim> <!ATTLIST claim user CDATA #REQUIRED timestamp CDATA #IMPLIED expiration CDATA #IMPLIED subject CDATA #IMPLIED holding_time CDATA #IMPLIED> The claim tag contains several attributes. The required attribute 'user' defines who sends the claim. The attribute 'expiration' defines how long the claim will be expired. The conference server MUST remove the expired floor claims from the queue. The attribute 'timestamp' defines when the claim is generated. The attribute 'holding_time' defines how long the user expect to hold the floor and the attribute 'subject' provides the reason for holding the floor. 4 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 -> Reciever ________________________________________________________________________ floor_create Create a floor for some resources Moderator -> Server and participants. floor_remove Remove the floor for some Moderator -> Server resources and participants. change_config Change the configuration of a floor Moderator -> Server floor_claim Request a floor User -> Server floor_release Give up the floor User -> Server floor_grant Grant floor to users Moderator -> Server floor_revoke Force release of floor from users Moderator -> Server remove_claims Remove the existing floor claim User -> Server reorder_claims Reorder the floor claim queue Moderator -> Server Table 2: Floor control commands 4.1 floor_create command Floor_create command will create a floor for some resources and users. boolean floor_create(resources, max_holders, users, moderators) The floor_create command takes four parameters, the resources, the max_holders, the users and the moderators. The definition of these Wu/Koskelainen/Schulzrinne/Chen [Page 8]
Internet Draft SIP-floor-control February 22, 2002 parameters are the same as those defined in the section 3.1. The response of the method is a boolean value indicating whether the floor is successfully created or not. Figure 1 shows an example of using SOAP to carry the floor_create 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_create xmlns:m="Some-URI"> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <max_holders>2</max_holders> <moderators> <moderator>sip:foo@examples.com</moderator> </moderators> </m:floor_create> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 1: Use SOAP to encapsulate floor_create command 4.2 floor_remove command Floor_remove command will remove a floor for some resources. boolean floor_remove(resources) The floor_remove command takes one parameter, resources. The definition of resources are the same as that defined in the section 3.1. The response of the method is a boolean value indicates whether the floor is successfully removed or not. Figure 2 shows an example of using SOAP to carry the floor_remove command. 4.3 change_config command Wu/Koskelainen/Schulzrinne/Chen [Page 9]
Internet Draft SIP-floor-control February 22, 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_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 floor_remove command The change_config command will change a floor's configuration. boolean change_config(resources, max_holders, users, moderators) The parameters for the change_config command are the same as those for the floor_create command. The response indicates whether the configuration is successfully changed or not. Figure 3 shows an example of using SOAP to carry the change_config command. 4.4 floor_claim command When a user wants to request a floor, the user's UA SHOULD send a floor_claim command to the conference server. boolean floor_claim(claims) The claims is the same as that defined in the section 3.5. The response of the method is a boolean value indicating whether the claims has been successfully put into the claim queue. Figure 4 shows an example of using SOAP to carry the floor_claim command. 4.5 floor_release event Wu/Koskelainen/Schulzrinne/Chen [Page 10]
Internet Draft SIP-floor-control February 22, 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:change_config xmlns:m="Some-URI"> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <max_holders>2</max_holders> <moderators> <moderator>sip:foo@examples.com</moderator> </moderators> </m:change_config> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 3: Use SOAP to encapsulate change_config command 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 floor_release command to the conference server to release the floor. boolean floor_release (resources, holders) The resources is the same as that defined in the section 3.1. If the resources subtag is not provided, all the resources related to the user are released. Figure 5 shows an example of using SOAP to carry the floor_release command. 4.6 floor_grant command The floor_grant command will grant one or more floors to some users. boolean floor_grant(resources,holders) Floor_grant command takes two parameters. The resources is the same as that defined in the section 3.1. The holders is the same as that defined in the section 3.4. Wu/Koskelainen/Schulzrinne/Chen [Page 11]
Internet Draft SIP-floor-control February 22, 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_claim xmlns:m="Some-URI"> <claims> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <claim user="sip:foo@example.com" timestamp="1014185030" expiration="180" subject="Why SOAP" holding_time="120"/> <claim user="sip:foo@example.com" timestamp="1014185030" expiration="360" subject="How to use SIP for floor control" holding_time="120"/> </claims> </m:floor_claim> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 4: Use SOAP to encapsulate floor_claim command Figure 6 shows an example of using SOAP to carry the floor_grant command. 4.7 floor_revoke command The floor_revoke command will force the release of a floor from the current holders. boolean floor_revoke(resources, holders) Floor_revoke command takes the same parameters as those for the floor_grant command. Figure 7 shows an example of using SOAP to carry the floor_revoke command. Wu/Koskelainen/Schulzrinne/Chen [Page 12]
Internet Draft SIP-floor-control February 22, 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"> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <holders> <holder>sip:foo@examples.com</holder> </holders> </m:floor_release> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 5: Use SOAP to encapsulate floor_release 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_grant xmlns:m="Some-URI"> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <holders expiration=600> <holder>sip:foo@examples.com</holder> </holders> </m:floor_grant> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 6: Use SOAP to encapsulate floor_grant command Wu/Koskelainen/Schulzrinne/Chen [Page 13]
Internet Draft SIP-floor-control February 22, 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_revoke xmlns:m="Some-URI"> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <holders> <holder>sip:foo@examples.com</holder> </holders> </m:floor_revoke> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 7: Use SOAP to encapsulate floor_revoke command 4.8 remove_claims command The remove_claims command will remove some claims from the claim queue. int remove_claims(claims) Remove_claims command takes one parameter, claims. The claims is the same as that defined in the section 3.5. The return value indicates how many claims have been removed. Figure 8 shows an example of using SOAP to carry the remove_claims command. 4.9 reorder_claims command The reorder_claims command will change the order of the claims in the queue. 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. boolean reorder_claims(resources, claim, operation) The resources is the same as that defined in the section 3.1. The Wu/Koskelainen/Schulzrinne/Chen [Page 14]
Internet Draft SIP-floor-control February 22, 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:remove_claims xmlns:m="Some-URI"> <claims> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <claim user="foo@examples.com" timestamp="1014185030" subject="Why SOAP"/> </claims> </m:remove_claims> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 8: Use SOAP to encapsulate remove_claims command claim is the same as that defined in the section 3.5. The operation is defined as the following: <!ELEMENT operation (argument*)> <!ATTLIST operation timestamp CDATA #IMPLIED> operator (top|bottom|up|down) #REQUIRED> <!ELEMENT argument CDATA> Figure 9 shows an example of using SOAP to carry the remove_claims command. 5 Security consideration Conference server SHOULD use appropriate authentication to ensure the commands and events originated from trusted parties. Other SIP considerations apply [7]. 6 Call flows 6.1 A user joins the conference and gets a floor Wu/Koskelainen/Schulzrinne/Chen [Page 15]
Internet Draft SIP-floor-control February 22, 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:reorder_claims xmlns:m="Some-URI"> <resources> <resource>mid:1</resource> <resource>mid:2</resource> </resources> <claim user="foo@examples.com" timestamp="1014185030" subject="Why SOAP"/> <operation timestamp="1014185130" operator="up"> <argument>2</argument> </operation> </m:reorder_claims> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 9: Use SOAP to encapsulate reorder_claims command 6.2 A moderator joins the conference and grants a floor 7 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 Wu/Koskelainen/Schulzrinne/Chen [Page 16]
Internet Draft SIP-floor-control February 22, 2002 Conference server participant | | | | +<-------- INVITE --------------+ | | | | +--------- 200 -------------->+ | (audio moderated) | | | +<------- SUBSCRIBE ------------+ | (floor_ctrl events) | | | +-------- NOTIFY -------------->+ | (floor_created) | | | +--------- NOTIFY ------------->+ | (floor grant) | | | +-------- re-INVITE ----------->+ | (a=sendrecv) | | | <---- NOTIFY ----+ | (floor_changed) Figure 10: A user send INVITE to join the conference 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 8 Bibliography Wu/Koskelainen/Schulzrinne/Chen [Page 17]
Internet Draft SIP-floor-control February 22, 2002 Moderator Conference server participant A +---------- INVITE ----------->+ | | | | | +<-------- INVITE --------------+ | | | | | | | +<-------- SOAP/HTTP or SIP ----+ | | (floor_claim) | | | | +<--------- NOTIFY ------------+ | | (queue_changed) | | | | | +-------- SOAP/HTTP or SIP --->+ | | (floor_grant) | | | | | | +--------- NOTIFY ------------->+ | | (floor_changed) | | | | | +-------- re-INVITE ----------->+ | | (a=sendrecv) | | | | Figure 11: The conference chair join the conference [1] C. Bormann, "Simple conference control protocol service specofocation," 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. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [4] M. Handley and V. Jacobson, "SDP: session description protocol," Request for Comments 2327, Internet Engineering Task Force, Apr. 1998. [5] G. Camarillo, J. Holler, G. Eriksson, and H. Schulzrinne, "Grouping of m lines in SDP," Internet Draft, Internet Engineering Task Force, Oct. 2001. Work in progress. Wu/Koskelainen/Schulzrinne/Chen [Page 18]
Internet Draft SIP-floor-control February 22, 2002 [6] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request for Comments 3023, Internet Engineering Task Force, Jan. 2001. [7] 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 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 .............. 2 3 Floor control events ................................ 4 3.1 floor_created event ................................. 4 Wu/Koskelainen/Schulzrinne/Chen [Page 19]
Internet Draft SIP-floor-control February 22, 2002 3.1.1 Resources ........................................... 5 3.1.2 Users ............................................... 5 3.1.3 Moderators .......................................... 5 3.2 floor_removed event ................................. 6 3.3 config_changed event ................................ 6 3.4 floor_changed event ................................. 6 3.4.1 Holders ............................................. 7 3.5 queue_changed event ................................. 7 4 Floor control commands .............................. 8 4.1 floor_create command ................................ 8 4.2 floor_remove command ................................ 9 4.3 change_config command ............................... 9 4.4 floor_claim command ................................. 10 4.5 floor_release event ................................. 10 4.6 floor_grant command ................................. 11 4.7 floor_revoke command ................................ 12 4.8 remove_claims command ............................... 14 4.9 reorder_claims command .............................. 14 5 Security consideration .............................. 15 6 Call flows .......................................... 15 6.1 A user joins the conference and gets a floor ........ 15 6.2 A moderator joins the conference and grants a floor .......................................................... 16 7 Authors' Addresses .................................. 16 8 Bibliography ........................................ 17 Wu/Koskelainen/Schulzrinne/Chen [Page 20]