Internet Engineering Task Force
Internet Draft Wu/Koskelainen/Schulzrinne
Columbia University
draft-wu-sipping-floor-control-04.txt
March 2, 2003
Expires: September 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 March 2, 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 March 2, 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 March 2, 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 March 2, 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 March 2, 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.
<xs:complexType name="floorType">
<xs:sequence>
<xs:element name="resources" type="resourcesType" minOccurs="0"/>
<xs:element name="users" type="usersType" minOccurs="0"/>
<xs:element name="moderators" type="moderatorsType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="maxHolders" type="xs:int" default="1"/>
</xs:complexType>
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.
<xs:simpleType name="resourceType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:complexType name="resourcesType">
Wu/Koskelainen/Schulzrinne [Page 6]
Internet Draft sipping-floor-control March 2, 2003
<xs:sequence>
<xs:element name="resource" type="resourceType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs: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:'
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.
<xs:simpleType name="userType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="usersType">
<xs:sequence>
<xs:element name="user" type="userType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="url" type="xs:anyURI"/>
</xs:complexType>
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.
<xs:simpleType name="moderatorType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="moderatorsType">
<xs:sequence>
<xs:element name="moderator" type="moderatorType"
Wu/Koskelainen/Schulzrinne [Page 7]
Internet Draft sipping-floor-control March 2, 2003
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
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.
<xs:complexType name="holdingType">
<xs:sequence>
<xs:element name="resources" type="resourcesType" minOccurs="0"/>
<xs:element name="users" type="usersType"/>
</xs:sequence>
<xs:attribute name="expiration" type="xs:dateTime"/>
<xs:attribute name="timestamp" type="xs:dateTime" use="required"/>
</xs:complexType>
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 March 2, 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.
<xs:simpleType name="PriorityType">
<xs:restriction base="xs:string">
<xs:enumeration value="non-urgent"/>
<xs:enumeration value="normal"/>
<xs:enumeration value="urgent"/>
<xs:enumeration value="emergency"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="claimType">
<xs:sequence>
<xs:element name="user" type="userType"/>
<xs:element name="resources" type="resourcesType" minOccurs="0"/>
<xs:element name="subject" type="xs:string" minOccurs="0"/>
<xs:element name="holdingTime" type="xs:duration" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="claimID" type="xs:string" use="required"/>
<xs:attribute name="timestamp" type="xs:dateTime" use="optional"/>
<xs:attribute name="expiration" type="xs:dateTime" use="optional"/>
<xs:attribute name="priority" type="PriorityType"
default="normal" use="optional"/>
</xs:complexType>
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 March 2, 2003
<xs:complexType name="claimsType">
<xs:sequence>
<xs:element name="claim" type="claimType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
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.
<xs:simpleType name="operatorType">
<xs:restriction base="xs:string">
<xs:enumeration value="up"/>
<xs:enumeration value="down"/>
<xs:enumeration value="top"/>
<xs:enumeration value="bottom"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="operationType">
<xs:sequence>
<xs:element name="operator" type="operatorType"/>
<xs:element name="argument" type="xs:int" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="timestamp" type="xs:dateTime"/>
</xs: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
Wu/Koskelainen/Schulzrinne [Page 10]
Internet Draft sipping-floor-control March 2, 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.
<xs:element name="floorCreated">
<xs:complexType>
<xs:sequence>
<xs:element name="floor" type="floorType" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
Figure 1 shows an example of the floorCreated event.
Wu/Koskelainen/Schulzrinne [Page 11]
Internet Draft sipping-floor-control March 2, 2003
<floorCreated>
<floor maxHolders="1">
<resources>
<resource>mid:1</resource>
</resources>
<users>
<user>sip:user_a@foo.example.com</user>
<user>sip:user_b@foo.example.com</user>
<user>sip:user_c@foo.example.com</user>
</users>
<moderators>
<moderator>sip:user_a@foo.example.com</moderator>
</moderators>
</floor>
</floorCreated>
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.
<xs:element name="floorRemoved">
<xs:complexType>
<xs:sequence>
<xs:element name="resources" type="resourcesType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Figure 2 shows an example of the floorRemoved event.
Wu/Koskelainen/Schulzrinne [Page 12]
Internet Draft sipping-floor-control March 2, 2003
<floorRemoved>
<resources>
<resource>mid:1</resource>
</resources>
</floorRemoved>
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.
<xs:element name="configChanged">
<xs:complexType>
<xs:sequence>
<xs:element name="floor" type="floorType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
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.
<xs:element name="floorChanged">
<xs:complexType>
<xs:sequence>
<xs:element name="holding" type="holdingType" maxOccurs="unbounded"/>
Wu/Koskelainen/Schulzrinne [Page 13]
Internet Draft sipping-floor-control March 2, 2003
<configChanged>
<floor maxHolders="1">
<resources>
<resource>mid:1</resource>
</resources>
<users url="http://foo.example.com/conference1/user.html" />
<moderators>
<moderator>sip:user_a@foo.example.com</moderator>
</moderators>
</floor>
</configChanged>
Figure 3: configChanged event example
</xs:sequence>
</xs:complexType>
</xs:element>
Figure 4 shows an example of the floorChanged event.
<?xml version="1.0" encoding="UTF-8"?>
<floorChanged>
<holding expiration="2003-01-12T09:40:47-05:00" timestamp="2003-01-12T09:30:47-05:00">
<resources>
<resource>mid:1</resource>
</resources>
<users>
<user>sip:user_a@foo.example.com</user>
</users>
</holding>
</floorChanged>
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 March 2, 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.
<xs:element name="queueChanged">
<xs:complexType>
<xs:sequence>
<xs:element name="claims" type="claimsType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="timestamp" type="xsd:dateTime"/>
<xs:attribute name="url" type="xsd:string"/>
</xs:complexType>
</xs:element>
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 March 2, 2003
<queueChanged timestamp="2003-01-17T09:40:00-05:00">
<claims>
<claim claimID="1:sip:user_a@foo.example.com"
timestamp="2003-01-12T09:30:00-05:00">
<user>sip:user_a@foo.example.com</user>
<resources>
<resource>mid:1</resource>
</resources>
<subject>SIP conferencing</subject>
<holdingTime>PT5M</holdingTime>
</claim>
<claim claimID="1:sip:user_b@foo.example.com"
timestamp="2003-01-12T09:35:00-05:00">
<user>sip:user_b@foo.example.com</user>
<resources>
<resource>mid:1</resource>
</resources>
<subject>Floor control</subject>
<holdingTime>PT10M</holdingTime>
</claim>
</claims>
</queueChanged>
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 March 2, 2003
<xs:element name="CreateFloor">
<xs:complexType name="CreateFloor">
<xs:sequence>
<xs:element name="floor" type="floorType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CreateFloorResponse">
<xs:simpleType>
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
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.
<xs:element name="RemoveFloor">
<xs:complexType name="RemoveFloor">
<xs:sequence>
<xs:element name="resources" type="resourcesType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Wu/Koskelainen/Schulzrinne [Page 17]
Internet Draft sipping-floor-control March 2, 2003
<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>
<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:CreateFloorResponse xmlns:m="Some-URI">
true
</m:CreateFloorResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 6: Use SOAP to encapsulate CreateFloor command
<xs:element name="RemoveFloorResponse">
<xs:simpleType name="RemoveFloorRespones">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
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 March 2, 2003
<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:RemoveFloor xmlns:m="Some-URI">
<resources>
<resource>mid:1</resource>
<resource>mid:2</resource>
</resources>
</m:RemoveFloor>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
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.
<xs:element name="ChangeConfig">
<xs:complexType name="ChangeConfig">
<xs:sequence>
<xs:element name="floor" type="floorType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ChangeConfigResponse">
<xs:simpleType name="ChangeConfigResponse">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
Wu/Koskelainen/Schulzrinne [Page 19]
Internet Draft sipping-floor-control March 2, 2003
Figure 8 shows an example of using SOAP to carry the ChangeConfig
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: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 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.
<xs:element name="ClaimFloor">
Wu/Koskelainen/Schulzrinne [Page 20]
Internet Draft sipping-floor-control March 2, 2003
<xs:complexType name="ClaimFloor">
<xs:sequence>
<xs:element name="claims" type="claimsType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ClaimFloorResponse">
<xs:simpleType name="ClaimFloorResponse">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
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.
<xs:element name="ReleaseFloor">
<xs:complexType name="ReleaseFloor">
<xs:sequence>
<xs:element name="holding" type="holdingType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ReleaseFloorResponse">
<xs:simpleType name="ReleaseFloorResponse">
Wu/Koskelainen/Schulzrinne [Page 21]
Internet Draft sipping-floor-control March 2, 2003
<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:sip:foo@examples.com"
timestamp="2003-01-14T09:30:47-05:00"
expiration="2003-01-14T09:40:47-05:00"
priority=emergency>
<user>sip:foo@examples.com</user>
<resources>
<resource>mid:1</resource>
<resource>mid:2</resource>
</resources>
<subject>The auditorium is on fire!</subject>
<holdingTime>P30S</holdingTime>
</claim>
</claims>
</m:ClaimFloor>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 9: Use SOAP to encapsulate ClaimFloor command
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
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 March 2, 2003
<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 10: Use SOAP to encapsulate ReleaseFloor command
boolean GrantFloor(holdingType holding, claimType claim)
The following XML schema fragment defines the GrantFloor command.
<xs:element name="GrantFloor">
<xs:complexType name="GrantFloor">
<xs:sequence>
<xs:element name="holding" type="holdingType"/>
<xs:element name="claim" type="claimType" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="GrantFloorResponse">
<xs:simpleType name="GrantFloorResponse">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
Wu/Koskelainen/Schulzrinne [Page 23]
Internet Draft sipping-floor-control March 2, 2003
Figure 11 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 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.
<xs:element name="RevokeFloor">
<xs:complexType name="RevokeFloor">
<xs:sequence>
<xs:element name="holding" type="holdingType"/>
</xs:sequence>
</xs:complexType>
Wu/Koskelainen/Schulzrinne [Page 24]
Internet Draft sipping-floor-control March 2, 2003
</xs:element>
<xs:element name="RevokeFloorResponse">
<xs:simpleType name="RevokeFloorResponse">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
Figure 12 shows an example of using SOAP to carry the RevokeFloor
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: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 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 March 2, 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.
<xs:element name="RemoveClaims">
<xs:complexType name="RemoveClaims">
<xs:sequence>
<xs:element name="claims" type="claimsType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="RemoveClaimsResponse">
<xs:simpleType name="RemoveClaimsResponse">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
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 March 2, 2003
<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:sip:foo@examples.com">
<user>sip:foo@examples.com</user>
</claim>
</claims>
</m:RemoveClaims>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 13: Use SOAP to encapsulate RemoveClaims command
The following XML schema fragment defines the RemoveClaims command.
<xs:element name="ReorderClaims">
<xs:complexType name="ReorderClaims">
<xs:sequence>
<xs:element name="resources" type="resourcesType"/>
<xs:element name="claim" type="claimType"/>
<xs:element name="operation" type="operationType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ReorderClaimsResponse">
<xs:simpleType name="ReorderClaimsResponse">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
</xs:element>
Figure 14 shows an example of using SOAP to carry the RemoveClaims
command.
Wu/Koskelainen/Schulzrinne [Page 27]
Internet Draft sipping-floor-control March 2, 2003
<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:sip:foo@examples.com">
<user>sip:foo@examples.com</user>
</claim>
<operation timestamp="2003-01-14T09:30:47-05:00">
<operator>up</operator>
<argument>2</argument>
</operation>
</m:ReorderClaims>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
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 March 2, 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 IANA considerations
8.1 New semantics for the "group" SDP Attribute
Name being registered: FL
Long-form name in English: Floor Control
Type of name: Semantics for the "group" SDP Attribute
Purpose: Group medias for floor control
Reference: RFCxxxx (this document)
Contact: Xiaotao Wu <xiaotaow@cs.columbia.edu>
8.2 URN Sub-Namespace Registration
This section registers a new XML namespace, as per the guidelines in
[9]
URI: urn:ietf:params:xml:ns:floor-control
Registrant Contact: Xiaotao Wu <xiaotaow@cs.columbia.edu>
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
Wu/Koskelainen/Schulzrinne [Page 29]
Internet Draft sipping-floor-control March 2, 2003
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Conference Floor Control Namespace</title>
</head>
<body>
<h1>Namespace for Conference Floor Control</h1>
<h2>application/floorcontrol+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
9 Call flows
9.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=type: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.
10 Changes from Earlier Version
10.1 Changes from Draft -03
o Add IANA considerations for new semantics for "group" SDP attribute
and URN Sub-Namespace registration
10.2 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
Wu/Koskelainen/Schulzrinne [Page 30]
Internet Draft sipping-floor-control March 2, 2003
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.
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.
10.3 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'.
Wu/Koskelainen/Schulzrinne [Page 31]
Internet Draft sipping-floor-control March 2, 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 32]
Internet Draft sipping-floor-control March 2, 2003
o Add an example of the SOAP response of CreateFloor command
o Fix typo 'floor_remove' to 'RemoveFloor' in Figure 7
11 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
12 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.
Wu/Koskelainen/Schulzrinne [Page 33]
Internet Draft sipping-floor-control March 2, 2003
[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
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.
13 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
Wu/Koskelainen/Schulzrinne [Page 34]
Internet Draft sipping-floor-control March 2, 2003
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.
Wu/Koskelainen/Schulzrinne [Page 35]
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 IANA considerations ................................. 29
8.1 New semantics for the "group" SDP Attribute ......... 29
8.2 URN Sub-Namespace Registration ...................... 29
9 Call flows .......................................... 30
9.1 A user joins the conference and gets a floor ........ 30
10 Changes from Earlier Version ........................ 30
10.1 Changes from Draft -03 .............................. 30
10.2 Changes from Draft -02 .............................. 30
Wu/Koskelainen/Schulzrinne [Page 1]
Internet Draft sipping-floor-control March 2, 2003
10.3 Changes from Draft -01 .............................. 31
11 Authors' Addresses .................................. 33
12 Normative References ................................ 33
13 Informative References .............................. 34
Wu/Koskelainen/Schulzrinne [Page 2]