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