Internet Engineering Task Force
Internet Draft Wu/Koskelainen/Schulzrinne/Chen
wu-sipping-floor-control-02.txt Columbia University
November 4, 2002
Expires: April 2003
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 November 4, 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 November 4, 2002
2 Use SIP and SOAP for the floor control
2.1 Use SIP event notification architecture for floor status
notification
The user's UA MAY send a SUBSCRIBE with the Event header as 'floor-
control' to the conference server for 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.
2.2 Use SDP to establish control channel
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.
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 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 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:
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
Wu/Koskelainen/Schulzrinne/Chen [Page 3]
Internet Draft SIP-floor-control November 4, 2002
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.
2.3 Use 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
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 SHOULD be able to convey the
knowledge to the users.
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 floors, resources and
floor claims etc. The namespace URI for elements defined by this
specification is a URN [8], using the namespace identifier 'ietf'
defined by [9] and extended by [10]. This URN is:
urn:ietf:params:xml:ns:floor-control
To represent such information, the following defines several
datatypes and provides XML schema fragment for each datatype.
3.1 floorType
Wu/Koskelainen/Schulzrinne/Chen [Page 4]
Internet Draft SIP-floor-control November 4, 2002
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.
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
the element 'moderators' is not provided in a floor control command,
the user who creates the floor 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.
3.2 resourcesType
The resourcesType defines contains a sequence of elements with the
type resourceType. The following shows the XML schema fragment of the
resourceType and the resourcesType.
Wu/Koskelainen/Schulzrinne/Chen [Page 5]
Internet Draft SIP-floor-control November 4, 2002
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' line
(a=mid) provides the value.
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.
If the attribute 'url' is not provided, there MUST be at least one
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 there are two elements, the
Wu/Koskelainen/Schulzrinne/Chen [Page 6]
Internet Draft SIP-floor-control November 4, 2002
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 'users' is not provided, there is no user holding
the floor. The holdingType has two attributes, the timestamp gives
the time the users get the access right of the resources and the
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 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 'resources' defines what resources
the user claims for. If not provided, the user is claiming for all
the resources. The element 'subject' provides the reason for holding
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 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.
Wu/Koskelainen/Schulzrinne/Chen [Page 7]
Internet Draft SIP-floor-control November 4, 2002
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
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.
Wu/Koskelainen/Schulzrinne/Chen [Page 8]
Internet Draft SIP-floor-control November 4, 2002
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 [11].
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
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.
Wu/Koskelainen/Schulzrinne/Chen [Page 9]
Internet Draft SIP-floor-control November 4, 2002
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. 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 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 10]
Internet Draft SIP-floor-control November 4, 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.
If the 'url' attribute is not provided, there MUST be one or more
claims presented in the queueChanged tag. The following shows the
XML schema fragment of the queueChanged event.
Wu/Koskelainen/Schulzrinne/Chen [Page 11]
Internet Draft SIP-floor-control November 4, 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 12]
Internet Draft SIP-floor-control November 4, 2002
Figure 1 shows an example of using SOAP to carry the CreateFloor
command and the response of the CreateFloor command.
mid:1
mid:2
sip:foo@examples.com
true
Figure 1: Use SOAP to encapsulate CreateFloor command
5.2 RemoveFloor command
Wu/Koskelainen/Schulzrinne/Chen [Page 13]
Internet Draft SIP-floor-control November 4, 2002
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.
Figure 2 shows an example of using SOAP to carry the 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
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
Wu/Koskelainen/Schulzrinne/Chen [Page 14]
Internet Draft SIP-floor-control November 4, 2002
mid:1
mid:2
Figure 2: Use SOAP to encapsulate RemoveFloor command
the command.
Figure 3 shows an example of using SOAP to carry the ChangeConfig
command.
Wu/Koskelainen/Schulzrinne/Chen [Page 15]
Internet Draft SIP-floor-control November 4, 2002
mid:1
mid:2
sip:foo@examples.com
Figure 3: 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 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 16]
Internet Draft SIP-floor-control November 4, 2002
Figure 4 shows an example of using SOAP to carry the ClaimFloor
command.
sip:foo@example.com
mid:1
mid:2
Why SOAP
P30S
Figure 4: Use SOAP to encapsulate ClaimFloor command
5.5 ReleaseFloor event
Wu/Koskelainen/Schulzrinne/Chen [Page 17]
Internet Draft SIP-floor-control November 4, 2002
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)
The following shows the XML schema fragment of the ReleaseFloor
command.
Figure 5 shows an example of using SOAP to carry the 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.
Wu/Koskelainen/Schulzrinne/Chen [Page 18]
Internet Draft SIP-floor-control November 4, 2002
mid:1
mid:2
sip:foo@examples.com
Figure 5: Use SOAP to encapsulate ReleaseFloor command
boolean GrantFloor(holdingType holding, claimType claim)
The following shows the XML schema fragment of the GrantFloor
command.
Wu/Koskelainen/Schulzrinne/Chen [Page 19]
Internet Draft SIP-floor-control November 4, 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)
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.
Wu/Koskelainen/Schulzrinne/Chen [Page 20]
Internet Draft SIP-floor-control November 4, 2002
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 21]
Internet Draft SIP-floor-control November 4, 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
Wu/Koskelainen/Schulzrinne/Chen [Page 22]
Internet Draft SIP-floor-control November 4, 2002
sip:foo@example.com
Figure 8: Use SOAP to encapsulate RemoveClaims command
move. The parameter 'operation' defines how to move the claim.
boolean ReorderClaims(resourcesType resources,
claimType claim,
operationType operation)
The following shows the XML schema fragment of the RemoveClaims
command.
Wu/Koskelainen/Schulzrinne/Chen [Page 23]
Internet Draft SIP-floor-control November 4, 2002
Figure 9 shows an example of using SOAP to carry the RemoveClaims
command.
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
Wu/Koskelainen/Schulzrinne/Chen [Page 24]
Internet Draft SIP-floor-control November 4, 2002
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
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 [12].
8 Call flows
8.1 A user joins the conference and gets a floor
A Changes from Earlier Version
A.1 Changes from Draft -01
* Reorganize section 2 into three subsections for clearer description
of using SIP and SOAP for floor control
* Provide namespace definitation for the elements defined by this
specification
* 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
* Clarify that the whole string of the value in 'a=mid' line is used as
the value for 'resourceType'
* Clarify that for 'usersType', if the attribute 'url' is not provided,
the list of the users MUST be provided.
* 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'.
* Remove 'maxOccurs=1' in schema fragment because by default, maxOccurs
is 1
Wu/Koskelainen/Schulzrinne/Chen [Page 25]
Internet Draft SIP-floor-control November 4, 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
* In 'claimType', change the element 'resource' to 'resources', and the
type 'resourceType' to 'resourcesType'.
* Add an example of the SOAP response of CreateFloor command
* Fix typo 'floor_remove' to 'RemoveFloor' in Figure 2
B Authors' Addresses
Xiaotao Wu
Dept. of Computer Science
Wu/Koskelainen/Schulzrinne/Chen [Page 26]
Internet Draft SIP-floor-control November 4, 2002
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
C 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.
[3] W3C, "Simple object access protocol (soap) 1.1."
[4] H. S. P. Koskelainen 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," RFC 2119, Internet Engineering Task Force, Mar. 1997.
Wu/Koskelainen/Schulzrinne/Chen [Page 27]
Internet Draft SIP-floor-control November 4, 2002
[6] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 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] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task
Force, May 1997.
[9] R. Moats, "A URN namespace for IETF documents," RFC 2648,
Internet Engineering Task Force, Aug. 1999.
[10] M. Mealling, "The IETF XML registry," Internet Draft, Internet
Engineering Task Force, July 2002. Work in progress.
[11] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC
3023, Internet Engineering Task Force, Jan. 2001.
[12] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," RFC 2543, Internet Engineering Task
Force, Mar. 1999.
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
Wu/Koskelainen/Schulzrinne/Chen [Page 28]
Internet Draft SIP-floor-control November 4, 2002
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
2.1 Use SIP event notification architecture for floor
status notification ............................................ 3
2.2 Use SDP to establish control channel ................ 3
2.3 Use SOAP for floor control commands ................. 4
3 Datatypes in the floor control messages ............. 4
3.1 floorType ........................................... 4
3.2 resourcesType ....................................... 5
3.3 usersType ........................................... 6
3.4 moderatorsType ...................................... 6
3.5 holdingType ......................................... 6
3.6 claimType ........................................... 7
3.7 claimsType .......................................... 8
3.8 operationType ....................................... 8
4 Floor control events ................................ 9
4.1 floorCreated event .................................. 9
4.2 floorRemoved event .................................. 10
4.3 configChanged event ................................. 10
4.4 floorChanged event .................................. 11
4.5 queueChanged event .................................. 11
5 Floor control commands .............................. 12
5.1 CreateFloor command ................................. 12
5.2 RemoveFloor command ................................. 13
5.3 ChangeConfig command ................................ 14
5.4 ClaimFloor command .................................. 16
5.5 ReleaseFloor event .................................. 17
5.6 GrantFloor command .................................. 18
5.7 RevokeFloor command ................................. 20
5.8 RemoveClaims command ................................ 21
5.9 ReorderClaims command ............................... 22
6 The floor control policies .......................... 24
7 Security consideration .............................. 25
8 Call flows .......................................... 25
8.1 A user joins the conference and gets a floor ........ 25
A Changes from Earlier Version ........................ 25
Wu/Koskelainen/Schulzrinne/Chen [Page 29]
Internet Draft SIP-floor-control November 4, 2002
A.1 Changes from Draft -01 .............................. 25
B Authors' Addresses .................................. 26
C Bibliography ........................................ 27
Wu/Koskelainen/Schulzrinne/Chen [Page 30]