Internet Engineering Task Force Internet Draft Wu/Koskelainen/Schulzrinne Columbia University draft-wu-sipping-floor-control-03.txt January 14, 2003 Expires: July 2003 Use of Session Initiation Protocol (SIP) and Simple Object Access Protocol (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 control coordinates simultaneous access to shared resource in multimedia conferences. Floor control allows applications and users to gain safe and mutually exclusive or non- exclusive access to the shared resources. This document defines an approach of using Session Initiation Protocol (SIP) event notification mechanism and Simple Object Access Protocol (SOAP) to perform floor control. Wu/Koskelainen/Schulzrinne [Page 1] Internet Draft sipping-floor-control January 14, 2003 1 Introduction Many existing conference management protocols, such as [11][12] have defined floor control functions. Floor control can be used to avoid or resolve conflicts among simultaneous media inputs. For example, at a given time, the moderator of a floor can ensure that only one person is heard by other participants or one person types into a shared document. The conference models can be centralized or non-centralized [13]. In a centralized model, we assume there is one conference server acting as the root of a conference. The root conference server receives all floor requests and can control the propagation of media in the conference directly or through sending requests to other conference servers in a tree topology. There is no such root conference server in the non-centralized model. The non-centralized model does not work well with the mechanism in this document. In the rest of this document, we simply use conference server referring to the root conference server. The conference server needs to be able to control the shared resources. For example, the mixer in a conference server 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 moderators and participants of changes. A floor control protocol is used to convey the floor control messages among the moderators 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 or how to add users to the conference. We divide the floor control messages into two categories: floor control events and floor control commands. The conference server sends floor control events to moderators or participants to report changes in the resource status. The SIP [1] events architecture [2] 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 the conference server to change the status of resources. Floor control commands are like remote-procedure 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 Wu/Koskelainen/Schulzrinne [Page 2] Internet Draft sipping-floor-control January 14, 2003 another RPC protocol, we consider of using SOAP to transmit floor control commands. SOAP messaging most commonly uses HTTP as the transport protocol. However, SIP can also be used to carry the SOAP content [14]. The same mechanism can be used for general conference control [15]. In the centralized conference model, floor claims are ordered in queues at the conference server. Floor moderators can assert priority or reorder the claims in the queues. 1.1 Conventions of This Document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4]. 2 Using SIP and SOAP for Floor Control 2.1 SIP Event Notification for Tracking Floor Status A new SIP event package 'floor-control' is introduced for floor status notification. The conference server can indicate that it supports the floor-control event package by including an 'Allow- Events: floor-control' header field. If a user wants to be informed of the floor status, the user's UA MUST send a SUBSCRIBE with the Event header set to 'floor-control' to the conference server. 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 this 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. 2.2 Using SDP to Establish Floor Control Channel We use Session Description Protocol (SDP) [5] to convey the floor control channel information since floor control channels and media channels are closely coupled. Any approach trying to convey floor control channel information must know the detail of the session description. When a user joins a conference, the conference server uses SDP's 'a' line to indicate that the conference is moderated. a=type:moderated Wu/Koskelainen/Schulzrinne [Page 3] Internet Draft sipping-floor-control January 14, 2003 The new participants joining the moderated conference SHOULD start media tools as 'mute' so that they do not send media. If only some of the media streams are moderated in a conference, the 'a=type:moderated' line MUST NOT be used because this attribute is a session level attribute, it indicates all the media streams in a session are moderated. As introduced later in this section, grouping media channels and a control channel can clearly indicate that the grouped media channels are moderated. For moderated media channels, the new participants SHOULD start the media tools as 'mute' accordingly. As indicated in RFC2327 [5], 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 However, the 'm' line does not provide the information of HTTP URL or SIP URI. A way of relaying the URI information is to use a session- level 'a=floorcontrol:' attribute. This is similar to how RTSP's 'a=control:' attribute [16] works. The following is an example: a=floorcontrol:sip:floorcontrol@foo.example.com Using m=control line cannot associate floor control channel with particular media channels. Thus, it cannot handle the case that a moderator can only control part 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 RFC3388 "Grouping of media lines in the Session Description Protocol (SDP) [6]. A new semantics named FL (floor control) is defined for this purpose. An example session description is shown below: v=0 o=Foo 289083124 289083124 IN IP4 foo.example.com s=SIP conferencing t=0 0 c=IN IP4 224.2.17.12/127 a=group:FL 1 2 4 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 Wu/Koskelainen/Schulzrinne [Page 4] Internet Draft sipping-floor-control January 14, 2003 m=control 5060 SIP SOAP a=floorcontrol:sip:floorcontrol@foo.example.com a=mid:4 In this example, the control channel can only control audio and video, but not the whiteboard. The SIP URI for the control channel is sip:floorcontrol@foo.example.com. The control line cannot indicate whether a user is a moderator or not. The conference server will use the floorCreated (Section 4.1) or configChanged (Section 4.3) event notification to indicate that. If a participant dials in the conference, the INVITE message will not contain the m=control line for floor control because the participant's user agent does not know how many floor control channels are needed. The m=control line can only be initiated from the conference server's INVITE message. If a participant's user agent cannot support floor control, in the SIP response, the user agent will set the port as 0 for the m=control line. 2.3 Use of SOAP for Floor Control Commands 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 carried either in 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 SHOULD be able to convey the knowledge to the users. 3 Datatypes in the floor control messages We use an XML-based data format for the floor control messages. A floor control message contains information about floors, resources and floor claims. The namespace URI for elements defined by this specification is a URN [7], using the namespace identifier 'ietf' defined by [8] and extended by [9]. This URN is: urn:ietf:params:xml:ns:floor-control To represent such information, the following sections define several datatypes and provides the XML schema fragment for each datatype. 3.1 floorType Wu/Koskelainen/Schulzrinne [Page 5] Internet Draft sipping-floor-control January 14, 2003 The floorType is used to define a floor. It 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 XML schema fragment defines the floorType. There are three sub-elements in the floorType. The element 'resources' has the type 'resourcesType'. It lists the resources the floor controls. If it is not provided, the floor controls all the resources of the conference. The element 'users' has the type 'usersType'. It defines who can hold the floor. If it is not provided, every user in the conference can hold the floor. The element 'moderators' has the type 'moderatorsType'. It defines who are the moderators of the floor. If it is not provided in the CreateFloor command, the user who sends the FloorCreate command will serve as the moderator. If the element 'moderators' is not provided in a floor control notification, it means this information is hidden by the conference server. The wildcard xs:any in the floorType is used to provide additional information of the floor, such as floor control policies. 3.2 resourcesType The resourcesType groups resources that can be controlled by one floor. It contains a sequence of elements with the type resourceType. The following XML schema fragment defines the resourceType and the resourcesType. Wu/Koskelainen/Schulzrinne [Page 6] Internet Draft sipping-floor-control January 14, 2003 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:' attribute provides the value. 3.3 usersType The usersType contains a list of users that can claim the floor or the URL of the user list. The following XML schema fragment defines the userType and the usersType. The string value in userType MUST be a valid SIP or SIPS URI. The attribute 'url' of usersType gives the web URL that contains the user list. If it is not provided, there MUST be at least one 'user' element presented. 3.4 moderatorsType The moderatorsType contains a floor moderator list. The following XML schema fragment defines the moderatorType and the moderatorsType. The string value in moderatorType MUST be a valid SIP or SIPS URI. 3.5 holdingType The holdingType defines the relationship between the floor holders and the resources. Within the holdingType there 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 the resources of the conference. The element 'users' has the type 'usersType'. If 'users' is not provided, there is no user holding the floor. The holdingType has two attributes, the required attribute timestamp gives the time the users get the access right of the resources and the optional attribute expiration defines when the holding will be expired. If the expiration is not provided, the holding will end until the users release the floor. The following XML schema fragment defines holdingType. 3.6 claimType The claimType contains the information sent by the participants to request a floor. Floor claims are put in a queue at the conference server. Generally, the order of the queue is based on the timestamp of floor claims. The required element 'user' defines who sends the claim. The optional element 'resources' defines what resources the user claims for. If not provided, the user wishes to claim for all the resources. The optional element 'subject' provides the reason for holding the floor. The optional element 'holdingTime' defines how long the user expects to hold the floor. The required attribute 'claimID' MUST be Wu/Koskelainen/Schulzrinne [Page 8] Internet Draft sipping-floor-control January 14, 2003 globally unique for the conference, generated by the combination of a random string and the claimer's SIP URI. The claimer can modify an existing claim by sending a new claim with the same claimID as the existing one. When a claim is granted, before the claimer releases the floor, the claim is considered as a granted claim. Granted claims MUST be removed from the claim queue. The conference server MUST keep track of the granted claims. The current floor holder can send a claim with the same claimID as his granted claim to ask for the extension of the holding time. The optional attribute 'timestamp' provides the time that the claim is generated. The optional attribute 'expiration' defines when a claim expires. The conference server MUST remove expired floor claims from the floor claim queue. The optional attribute 'priority' defines the priority of the claim. There are four possible priority values, "non-urgent", "normal", "urgent" and "emergency". By default, the priority is "normal". The following XML schema fragment defines the claimType. 3.7 claimsType The claimsType contains a list of claims. The following XML schema fragment defines the claimsType. Wu/Koskelainen/Schulzrinne [Page 9] Internet Draft sipping-floor-control January 14, 2003 3.8 operationType We defined several queue 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 have an argument. For 'up' and 'down', the argument means how many steps to move a claim. For 'top', the argument means to what position to move a claim counting down from the top of the queue. For 'bottom', the argument means to what position to move a claim 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 XML schema fragment defines the operatorType and the operationType. 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 Wu/Koskelainen/Schulzrinne [Page 10] Internet Draft sipping-floor-control January 14, 2003 type for the format is application/floor-control+xml, consistent with the recommendations provided in RFC 3023 [10]. 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 -> Moderator Table 1: Floor control events In Table 1, the 'Server' refers to 'Conference server' and the 'User' refers to either 'Moderator' or 'Participant'. 4.1 floorCreated event When a floor is created for some set of 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 XML schema fragment defines the floorCreated event. Figure 1 shows an example of the floorCreated event. Wu/Koskelainen/Schulzrinne [Page 11] Internet Draft sipping-floor-control January 14, 2003 mid:1 sip:user_a@foo.example.com sip:user_b@foo.example.com sip:user_c@foo.example.com sip:user_a@foo.example.com Figure 1: floorCreated event example 4.2 floorRemoved event When a floor is removed for some set of 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. Within the tag, there are zero or more 'resources' tag. If the resources tag is not provided, it means the floor for all the resources are removed. The following XML schema fragment defines the floorRemoved event. Figure 2 shows an example of the floorRemoved event. Wu/Koskelainen/Schulzrinne [Page 12] Internet Draft sipping-floor-control January 14, 2003 mid:1 Figure 2: floorRemoved event example 4.3 configChanged event When the configuration of the floor is changed, the conference server SHOULD send a notification to the parties interested in this event. The event contains the updated floor information. The following XML schema fragment defines the configChanged event. Figure 3 shows an example of the configChanged event. 4.4 floorChanged event If the holders of one or more floors have 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 sending of media. The UA SHOULD not send media until it has received a floorChanged event. The following XML schema fragment defines the floorChanged event. The element 'holding' contains the new holders' information. Wu/Koskelainen/Schulzrinne [Page 13] Internet Draft sipping-floor-control January 14, 2003 mid:1 sip:user_a@foo.example.com Figure 3: configChanged event example Figure 4 shows an example of the floorChanged event. mid:1 sip:user_a@foo.example.com Figure 4: floorChanged event example 4.5 queueChanged event The conference server SHOULD send a notification to the parties interested in the queueChanged event when the claim queue changes, e.g., a new claim is added in or an existing claim is removed, Wu/Koskelainen/Schulzrinne [Page 14] Internet Draft sipping-floor-control January 14, 2003 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. If the 'url' attribute is not provided, there MUST be one or more claims presented in the queueChanged tag. The following XML schema fragment defines the queueChanged event. Figure 5 shows an example of the queueChanged event. 5 Floor control commands Table 2 shows the floor control commands. Floor control commands are encapsulated in SOAP and are sent from the user to the conference server in order to change floor status. In Table 2, the 'Server' refers to 'Conference server' and the 'User' refers to either 'Moderator' or 'Participant'. 5.1 CreateFloor command The CreateFloor command creates a floor for some resources and users. Only moderators 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 XML schema fragment defines the CreateFloor command and the response of the command. Wu/Koskelainen/Schulzrinne [Page 15] Internet Draft sipping-floor-control January 14, 2003 sip:user_a@foo.example.com mid:1 SIP conferencing PT5M sip:user_b@foo.example.com mid:1 Floor control PT10M Figure 5: queueChanged event example Command name Description Issuer -> Receiver ________________________________________________________________________ CreateFloor Create a floor for some resources Moderator -> Server and participants. RemoveFloor Remove floors for some Moderator -> Server resources. ChangeConfig Change the configuration of a floor Moderator -> Server ClaimFloor Request a floor User -> Server ReleaseFloor Give up a floor User -> Server GrantFloor Grant a floor to some users Moderator -> Server RevokeFloor Force release floors from some users Moderator -> Server RemoveClaims Remove some existing floor claims User -> Server ReorderClaims Reorder some claims in the queue Moderator -> Server Table 2: Floor control commands Wu/Koskelainen/Schulzrinne [Page 16] Internet Draft sipping-floor-control January 14, 2003 Figure 6 shows an example of using SOAP to carry the CreateFloor command and the response of the CreateFloor command. 5.2 RemoveFloor command The RemoveFloor command deletes floors for several resources. Only moderators 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 has been successfully removed or not. The following XML schema fragment defines the RemoveFloor command and the response of the command. Wu/Koskelainen/Schulzrinne [Page 17] Internet Draft sipping-floor-control January 14, 2003 mid:1 mid:2 sip:foo@examples.com true Figure 6: Use SOAP to encapsulate CreateFloor command Figure 7 shows an example of using SOAP to carry the RemoveFloor command. 5.3 ChangeConfig command The ChangeConfig command changes a floor's configuration. Only Wu/Koskelainen/Schulzrinne [Page 18] Internet Draft sipping-floor-control January 14, 2003 mid:1 mid:2 Figure 7: Use SOAP to encapsulate RemoveFloor command moderators can execute this command. boolean ChangeConfig(floorType floor) The parameters for the ChangeConfig command is the same as that for the CreateFloor command. The response indicates whether the configuration is successfully changed or not. The following XML schema fragment defines the ChangeConfig command and the response of the command. Wu/Koskelainen/Schulzrinne [Page 19] Internet Draft sipping-floor-control January 14, 2003 Figure 8 shows an example of using SOAP to carry the ChangeConfig command. mid:1 mid:2 sip:foo@examples.com Figure 8: Use SOAP to encapsulate 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 new claim MUST have the same claimID as the granted claim which enables the current holding. boolean ClaimFloor(claimsType claims) For new claims, the response of the method is a boolean value indicating whether the claim has been successfully put into the claim queue. For updating an existing claim, the response indicates whether the existing claim get updated successfully. The following XML schema fragment defines the ClaimFloor command and the response of the command. Wu/Koskelainen/Schulzrinne [Page 20] Internet Draft sipping-floor-control January 14, 2003 Figure 9 shows an example of using SOAP to carry the ClaimFloor command. 5.5 ReleaseFloor event To release a floor, the user's UA can send a ReleaseFloor command to the conference server. 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) The following XML schema fragment defines the ReleaseFloor command. Wu/Koskelainen/Schulzrinne [Page 21] Internet Draft sipping-floor-control January 14, 2003 sip:foo@examples.com mid:1 mid:2 The auditorium is on fire! P30S Figure 9: Use SOAP to encapsulate ClaimFloor command Figure 10 shows an example of using SOAP to carry the ReleaseFloor command. 5.6 GrantFloor command The GrantFloor command grants floors to one or more 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 claim MUST be removed from the queue. If the 'claim' parameter is not provided, the GrantFloor command does not affect the claim queue. Only moderators can execute this command. Wu/Koskelainen/Schulzrinne [Page 22] Internet Draft sipping-floor-control January 14, 2003 mid:1 mid:2 sip:foo@examples.com Figure 10: Use SOAP to encapsulate ReleaseFloor command boolean GrantFloor(holdingType holding, claimType claim) The following XML schema fragment defines the GrantFloor command. Wu/Koskelainen/Schulzrinne [Page 23] Internet Draft sipping-floor-control January 14, 2003 Figure 11 shows an example of using SOAP to carry the GrantFloor command. mid:1 mid:2 sip:foo@examples.com Figure 11: Use SOAP to encapsulate GrantFloor command 5.7 RevokeFloor command The RevokeFloor command forces the release of a floor from the current holders. boolean RevokeFloor(holdingType holding) The parameter holding indicates which floor should be revoked. Only moderators can execute this command. The following XML schema fragment defines the RevokeFloor command. Wu/Koskelainen/Schulzrinne [Page 24] Internet Draft sipping-floor-control January 14, 2003 Figure 12 shows an example of using SOAP to carry the RevokeFloor command. mid:1 mid:2 sip:foo@examples.com Figure 12: Use SOAP to encapsulate RevokeFloor command 5.8 RemoveClaims command The RemoveClaims command removes several claims from the claim queue. Moderators can remove any claims. Participants can only remove their own claims. Wu/Koskelainen/Schulzrinne [Page 25] Internet Draft sipping-floor-control January 14, 2003 boolean RemoveClaims(claimsType claims) RemoveClaims command takes one parameter, claims. The return value indicates whether the claims have been removed successfully. The following XML schema fragment defines the RemoveClaims command. Figure 13 shows an example of using SOAP to carry the RemoveClaims command. 5.9 ReorderClaims command The ReorderClaims command changes the order of the claims in the queue. Only moderators can execute this command. This command supports some simple operations 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, operationType operation) Wu/Koskelainen/Schulzrinne [Page 26] Internet Draft sipping-floor-control January 14, 2003 sip:foo@examples.com Figure 13: Use SOAP to encapsulate RemoveClaims command The following XML schema fragment defines the RemoveClaims command. Figure 14 shows an example of using SOAP to carry the RemoveClaims command. Wu/Koskelainen/Schulzrinne [Page 27] Internet Draft sipping-floor-control January 14, 2003 sip:foo@examples.com up 2 Figure 14: Use SOAP to encapsulate ReorderClaims command 6 Floor Control Policies Each resource SHOULD 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 multiple resources need to be granted in atomic mode, e.g., access to all resources is granted or denied as a group, 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 applys. 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 releases the floor, 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 potential deadlock, the claims in different queues MUST be granted independently. When a conference server receives a GrantFloor command, the conference server SHOULD queue the grant until there is an available Wu/Koskelainen/Schulzrinne [Page 28] Internet Draft sipping-floor-control January 14, 2003 floor. Occupied floor can be released by ReleaseFloor and RevokeFloor commands. A floor creator can specify some complicated floor control policies, for example, "senior members get 5 minutes to talk, junior members 2 minutes and visitors 1 minute". There should be a floor control language to describe the policies and the wildcard 'xs:any' in the floorType can carry the policies to the conference server. 7 Security consideration Conference server SHOULD use appropriate authentication to ensure the commands and events originated from trusted parties. Other SIP considerations apply [1]. 8 Call flows 8.1 A user joins the conference and gets a floor Figure 15 shows the call flow when a user joins a moderated conference, claims for a floor and gets the floor. In the call flow, initially, the participant first sends an INVITE to the conference server to join the conference. Since the participant does not know whether the conference is moderated or not, there is no m=control line in the initial INVITE. In the 200 response from the conference server, the conference server uses a=moderated line to mute all the media tools of the participant. The conference server then sends a re-INVITE with m=control lines to establish floor control channels. The participants can then send SUBSCRIBE for floor control events and uses floor control channels for floor control commands. When the participant gets the floor, the conference server notifies all the users about the floor change and send a re-INVITE to unmute the media tools of the participant. 9 Changes from Earlier Version 9.1 Changes from Draft -02 o Change the title from "Use of SIP and SOAP for Conference Floor Control" to "Use of Session Initiation Protocol (SIP) and Simple Object Access Protocol (SOAP) for Conference Floor Control". o If only part of the media are moderated, the 'a=type:moderated' line MUST NOT be used. The grouping of media channels and control channels can indicate which media are moderated. o Fix the lost part at the bottom of page 5. o Add ACK to Figure 15. Wu/Koskelainen/Schulzrinne [Page 29] Internet Draft sipping-floor-control January 14, 2003 o Explicitly describe the floor claim queue model in section 1 and section 3.6 o Explain the reason to put floor control channel information in SDP. o Explain how to use Allow-Events header for floor status notification. o The m=control line can only be initiated from conference server's INVITE message. o Add the missing 's' line in the SDP example in Section 2.2. o Add "a=floorcontrol:" attribute in SDP for control URL information. o Add re-INVITE to Figure 15. o Add xs:any wildcard in floorType for additional information of a floor. o In claimType, the claimID MUST be globally unique. Define the way of updating an existing claim and extending the current floor holding time. o Add priority attribute to claimType. o Add floor control event examples. o Separate the references into normative and informative. o Clarified some wording. o Fixed some typographical errors. 9.2 Changes from Draft -01 o Reorganize section 2 into three subsections for clearer description of using SIP and SOAP for floor control o Provide namespace definitation for the elements defined by this specification o If the 'moderators' element is not provided in a floor, in floor control command, the person creates the floor will serve as the moderator, in floor control events, it means the information of moderators is hidden by conference server o Clarify that the whole string of the value in 'a=mid' line is used as the value for 'resourceType' o Clarify that for 'usersType', if the attribute 'url' is not provided, the list of the users MUST be provided. o For 'holdingType', if the 'users' element is not provided, it means no user is holding the floor. Previously, it defined as 'all users holding the floor'. o Remove 'maxOccurs=1' in schema fragment because by default, maxOccurs is 1 o In 'claimType', change the element 'resource' to 'resources', and the type 'resourceType' to 'resourcesType'. o Add an example of the SOAP response of CreateFloor command o Fix typo 'floor_remove' to 'RemoveFloor' in Figure 7 10 Authors' Addresses Wu/Koskelainen/Schulzrinne [Page 30] Internet Draft sipping-floor-control January 14, 2003 Conference server participant | | | | +<-------- INVITE --------------+ | (audio,video,whiteboard) | | (a=mid:1 a=mid:2 a=mid:3) | | | +--------- 200 -------------->+ | (moderated) | (mute) | | |<--------- ACK ----------------| | | +------- re-INVITE ------------>+ | (m=control 5060 SIP SOAP) | | (a=mid:4) | | (a=group:FL 1 2 4) | +<-------- 200 ---------------+ | | |---------- ACK --------------->| | | +<------- SUBSCRIBE ------------+ | (Event: floor-control) | | | +-------- NOTIFY -------------->+ | (configChanged) | | | +<------- HTTP/SOAP ------------+ | (ClaimFloor) | moderator <---- NOTIFY ----+ | (queueChanged) | | | | moderator --- HTTP/SOAP -->+ | (GrantFloor) | | +-------- re-INVITE ----------->+ | (a=sendrecv) | (unmute) | | +<-------- 200 ---------------+ | | +--------- ACK -------------->+ | | +--------- NOTIFY ------------->+ | (floorChanged) | other | | participants <---- NOTIFY ----+ | (floorChanged) Figure 15: A user send INVITE to join the conference Wu/Koskelainen/Schulzrinne [Page 31] Internet Draft sipping-floor-control January 14, 2003 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 11 Normative References [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session initiation protocol," RFC 3261, Internet Engineering Task Force, June 2002. [2] A. B. Roach, "Session initiation protocol (sip)-specific event notification," RFC 3265, Internet Engineering Task Force, June 2002. [3] W3C, "Simple object access protocol (soap) 1.1." [4] S. Bradner, "Key words for use in rfcs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [5] M. Handley and V. Jacobson, "SDP: session description protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998. [6] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, "Grouping of media lines in the session description protocol (SDP)," RFC 3388, Internet Engineering Task Force, Dec. 2002. [7] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task Wu/Koskelainen/Schulzrinne [Page 32] Internet Draft sipping-floor-control January 14, 2003 Force, May 1997. [8] R. Moats, "A URN namespace for IETF documents," RFC 2648, Internet Engineering Task Force, Aug. 1999. [9] M. Mealling, "The IETF XML registry," internet draft, Internet Engineering Task Force, July 2002. Work in progress. [10] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC 3023, Internet Engineering Task Force, Jan. 2001. 12 Informative References [11] 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. [12] R. Malpani and L. A. Rowe, "Floor control for large-scale mbone seminars," in ACM Multimedia, (Seattle, Washington), Nov. 1997. [13] J. Rosenberg and H. Schulzrinne, "Models for multi party conferencing in SIP," internet draft, Internet Engineering Task Force, July 2002. Work in progress. [14] N. Deason, "SIP for SOAP sessions," internet draft, Internet Engineering Task Force, Apr. 2002. Work in progress. [15] H. S. P. Koskelainen and X. Wu, "A sip-based conference control framework," in NOSSDAV, (Miami, Florida), May 2002. [16] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 1998. Full Copyright Statement Copyright (c) The Internet Society (2003). 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 Wu/Koskelainen/Schulzrinne [Page 33] Internet Draft sipping-floor-control January 14, 2003 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. Wu/Koskelainen/Schulzrinne [Page 34] Table of Contents 1 Introduction ........................................ 2 1.1 Conventions of This Document ........................ 3 2 Using SIP and SOAP for Floor Control ................ 3 2.1 SIP Event Notification for Tracking Floor Status .... 3 2.2 Using SDP to Establish Floor Control Channel ........ 3 2.3 Use of SOAP for Floor Control Commands .............. 5 3 Datatypes in the floor control messages ............. 5 3.1 floorType ........................................... 5 3.2 resourcesType ....................................... 6 3.3 usersType ........................................... 7 3.4 moderatorsType ...................................... 7 3.5 holdingType ......................................... 8 3.6 claimType ........................................... 8 3.7 claimsType .......................................... 9 3.8 operationType ....................................... 10 4 Floor control events ................................ 10 4.1 floorCreated event .................................. 11 4.2 floorRemoved event .................................. 12 4.3 configChanged event ................................. 13 4.4 floorChanged event .................................. 13 4.5 queueChanged event .................................. 14 5 Floor control commands .............................. 15 5.1 CreateFloor command ................................. 15 5.2 RemoveFloor command ................................. 17 5.3 ChangeConfig command ................................ 18 5.4 ClaimFloor command .................................. 20 5.5 ReleaseFloor event .................................. 21 5.6 GrantFloor command .................................. 22 5.7 RevokeFloor command ................................. 24 5.8 RemoveClaims command ................................ 25 5.9 ReorderClaims command ............................... 26 6 Floor Control Policies .............................. 28 7 Security consideration .............................. 29 8 Call flows .......................................... 29 8.1 A user joins the conference and gets a floor ........ 29 9 Changes from Earlier Version ........................ 29 9.1 Changes from Draft -02 .............................. 29 9.2 Changes from Draft -01 .............................. 30 10 Authors' Addresses .................................. 30 11 Normative References ................................ 32 12 Informative References .............................. 33 Wu/Koskelainen/Schulzrinne [Page 1] Internet Draft sipping-floor-control January 14, 2003 Wu/Koskelainen/Schulzrinne [Page 2]