Internet Engineering Task Force
Internet Draft Wu/Koskelainen/Schulzrinne/Chen
draft-wu-sipping-floor-control-00.txt Columbia University
February 22, 2002
Expires: August 2002
Use SIP and SOAP for conference floor control
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
Floor control is used to control who can input for the media
applications during a conference. This document defines an approach
of using SIP event notification mechanism and SOAP to perform the
floor control functions.
1 Introduction
Many existing conference management protocols [1] [2] have defined
floor control functions. Floor control to a conference is like the
traffic control to a transportation system. It can be used to avoid
or resolve the conflicts of simultaneous media inputs. For example,
at a given time, the moderator of a conference can ensure that only
one person can talk to avoid confusion.
Wu/Koskelainen/Schulzrinne/Chen [Page 1]
Internet Draft SIP-floor-control February 22, 2002
To perform floor control requires the conference server be able to
control the floor, for example, the mixer of the conference server
can selectively choose the media input for mixing. It also requires
the moderator and the participants of the conference can send the
floor control messages to the conference server for changing floor
status, and the conference server can notify the changes to the
moderator and the participants.
The floor control protocol is used to convey the floor control
messages among the moderator of the conference, the conference server
and the participants of the conference. The floor control protocol
does not deal with the conference management such as how to elect the
moderator of the conference. Neither does it deal with the policy in
the conference server such as who can join the conference.
The floor control messages can be divided into two categories. One is
a set of floor control events and the other is a set of floor control
commands.
The floor control events are used to report the changes of the floor
control status. The SIP Events architecture is well fitted for
conveying the floor control events. This document defines a new event
package named floor-control for the floor control events.
The floor control commands are used to change the floor control
status. The floor control commands are in fact RPC calls from the
moderator or the participants to the conference server. Since one of
SOAP's design goals is to encapsulate and exchange RPC calls, instead
of creating a new XML schema, we consider to use SOAP for
transmitting the floor control commands. Either HTTP or SIP can be
used to carry SOAP content.
The conference models can be centralized or non-centralized. In a
centralized model, there is an entity (usually the conference server)
acting as the root of the conference topology. There is no such root
for the non-centralized model. The non-centralized model does not
work well with the mechanism in this document.
1.1 Conventions of This Document
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3].
2 Use SIP and SOAP for the floor control
When a user joins a conference, the conference server MAY use SDP's
'a' line to indicate a media is moderated.
Wu/Koskelainen/Schulzrinne/Chen [Page 2]
Internet Draft SIP-floor-control February 22, 2002
a=type:moderated
The new participants joining the moderated conference SHOULD start
the media tool as 'mute'.
The user's UA MAY send a SUBSCRIBE to the conference server for the
floor control status changes on the moderated media. The events in
the floor-control package will be described in detail in section 3.
If the user's UA cannot understand the 'floor-control' package, the
user may use web based floor control approach. To convey the URL for
the web based floor control, the conference server MAY use the
'Call-Info' header to bring the URL. And a new value, named 'floor-
control', SHOULD be used for the Call-Info header's purpose
parameter.
If a user wants to change the floor control status, the user's UA MAY
use SOAP to carry the floor control commands. The SOAP message can be
either within HTTP or SIP. The name and the parameters of the
commands will be described in detail in section 4.
Both the moderator and the participants can have control over the
conference. However, they have different control command set. The
conference server SHOULD have knowledge of the moderated resources
(e.g. who can control the resources and who are the moderators) and
SHOULD convey the the knowledge to the users.
As indicated in the RFC2327 [4], the 'm' line can specify the
conference control tools and the port and protocol used by the
conference control tools. The following is an example:
m=control 5060 SIP SOAP
The shortage of this approach is that it does not associate floor
control with each particular media. Thus, it cannot handle the case
that a user cannot control all of the resources, e.g., a user can
control the cameras but not the microphones.
To solve this problem, we can group the control line with the other
media lines as described in the Internet Draft "Grouping of media
lines in SDP"[5]. A new semantics named FL (floor control) is defined
for this purpose. And the SDP will look like:
v=0
o=Foo 289083124 289083124 IN IP4 foo.example.com
t=0 0
c=IN IP4 224.2.17.12/127
a=group:FL 1 2 4
Wu/Koskelainen/Schulzrinne/Chen [Page 3]
Internet Draft SIP-floor-control February 22, 2002
a=group:FL 3 5
m=audio 10000 RTP/AVP 0
a=type:moderated
a=mid:1
m=video 20000 RTP/AVP 31
a=type:moderated
a=mid:2
m=application 30000 udp wb
a=type:moderated
a=mid:3
m=control 80 HTTP SOAP
a=mid:4
m=control 5060 SIP SOAP
a=mid:5
In this example, there are two floors, one is for audio and video
inputs and the other is for whiteboard input. The user can control
both floors.
The control line cannot indicate whether a user is a moderator or
not. The conference server will use the floor_created event
notification to indicate that. Section 3.1 describes the
floor_created event in detail.
3 Floor control events
Table 1 shows the events for the floor control package. We specify
an XML-based data format for the parameters of each event. The MIME
type for the format is application/floor-control+xml, consistent with
the recommendations provided in RFC 3023 [6].
Event name Description Issuer -> Reciever
_____________________________________________________________________
floor_created A floor has been created for some Server -> User
resources and participants.
floor_removed A floor has been removed for some Server -> User
resources and participants.
config_changed Floor configuration changed Server -> User
floor_changed Floor changed to different users Server -> User
queue_changed Floor claim queue changed Server -> Chair
Table 1: Floor control events
3.1 floor_created event
Wu/Koskelainen/Schulzrinne/Chen [Page 4]
Internet Draft SIP-floor-control February 22, 2002
When a floor is created for some resources, the conference server
SHOULD send a notification to the parties interested in this event.
The floor_created event contains the information about what are the
resources being controlled and who can access the floor.
The XML document for floor_created event starts with a
'floor_created' tag. Within the tag are one or more 'floor' tags.
The floor tag contains several optional tags that describe the
configuration information of the new created floor. The optional
attribute 'max_holders' defines how many users can hold the floor at
the same time. The default value of the 'max_holders' attribute is
1.
There are three subtags defined for the floor tag.
3.1.1 Resources
Resources subtag defines what's the resources the floor applied.
If the resources tag is not provided, the floor is for all the
resources of the conference. The value of 'resource' tag MUST be one
of the mids in the SDP of the conference server's message.
3.1.2 Users
Users subtag provides a list of users or the URL of the web page that
contains the list of users that can claim the floor. If not provided,
all the users can claim the floor.
3.1.3 Moderators
Moderators subtag list the moderators for the new created floor.
Wu/Koskelainen/Schulzrinne/Chen [Page 5]
Internet Draft SIP-floor-control February 22, 2002
3.2 floor_removed event
When a floor is removed for some resources, the conference server
SHOULD send a notification to the parties interested in this event.
The XML document for floor_removed event starts with a
'floor_removed' tag.
The resources tag is the same as that defined in the section 3.1.
3.3 config_changed event
When the configuration of the floor changed, the conference server
SHOULD send a notification to the parties interested in this event.
The XML document for config_changed event starts with a
'config_changed' tag.
Within the tag are one or more floor tags. The floor tag is the same
as that defined in the floor_created event. The floor tag carries the
updated configuration information of a floor.
3.4 floor_changed event
If the holders of one or more floors has been changed, the conference
server SHOULD send a notification to the parties interested in this
event. At the same time, the conference server SHOULD send re-INVITE
to the new holders to enable the media sending. Before getting the
floor, a participant SHOULD mute the moderated media tools.
The XML document for floor_changed event starts with a
'floor_changed' tag. Within the floor_changed tag are one or more
holding tags.
The holding tag defines the relationship between the holders and the
resources. Within holding tag are two required tags, the resources
and the holders. The holding tag has one optional attribute that
gives the timestamp of when the holders get the floor of the
resources.
Wu/Koskelainen/Schulzrinne/Chen [Page 6]
Internet Draft SIP-floor-control February 22, 2002
The resources subtag is the same as that defined in the section 3.1.
If it's not provided, the holding is for all the resources of the
conference. The 'holders' subtag gives the list of users that
currently holding the floor of the resources.
3.4.1 Holders
Holders subtag provides a list of users or the URL of the web page
that contains the list of users that holding the floor. The attribute
'expiration' defines how long the holders can hold the floor.
The holder subtag is within the holders tag. It provides the
information of the holder. The expiration value in the 'holder'
subtag will override the 'expiration' value in the 'holders' tag.
3.5 queue_changed event
When the claim queue is changed, for example, a new claim is added in
or an expired claim is removed out, the conference server SHOULD send
a notification to the parties interested in this event.
The XML document for queue_changed event starts with a
'queue_changed' tag. The required attribute timestamp defines when
the event happens. The optional attribute url provides the web URL
that contains the updated claim queue.
The claims subtag contains one or more claims for the updated claim
queue.
The resources subtag defines what's the resources for the claim
queue. It's the same as that defined in the section 3.1.
Wu/Koskelainen/Schulzrinne/Chen [Page 7]
Internet Draft SIP-floor-control February 22, 2002
The claim tag contains several attributes. The required attribute
'user' defines who sends the claim. The attribute 'expiration'
defines how long the claim will be expired. The conference server
MUST remove the expired floor claims from the queue. The attribute
'timestamp' defines when the claim is generated. The attribute
'holding_time' defines how long the user expect to hold the floor and
the attribute 'subject' provides the reason for holding the floor.
4 Floor control commands
Table 2 shows the floor control commands. The floor control command
will be encapsulated in SOAP and sent from the user to the conference
server for changing the floor status.
Command name Description Issuer -> Reciever
________________________________________________________________________
floor_create Create a floor for some resources Moderator -> Server
and participants.
floor_remove Remove the floor for some Moderator -> Server
resources and participants.
change_config Change the configuration of a floor Moderator -> Server
floor_claim Request a floor User -> Server
floor_release Give up the floor User -> Server
floor_grant Grant floor to users Moderator -> Server
floor_revoke Force release of floor from users Moderator -> Server
remove_claims Remove the existing floor claim User -> Server
reorder_claims Reorder the floor claim queue Moderator -> Server
Table 2: Floor control commands
4.1 floor_create command
Floor_create command will create a floor for some resources and
users.
boolean floor_create(resources, max_holders, users, moderators)
The floor_create command takes four parameters, the resources, the
max_holders, the users and the moderators. The definition of these
Wu/Koskelainen/Schulzrinne/Chen [Page 8]
Internet Draft SIP-floor-control February 22, 2002
parameters are the same as those defined in the section 3.1. The
response of the method is a boolean value indicating whether the
floor is successfully created or not.
Figure 1 shows an example of using SOAP to carry the floor_create
command.
mid:1
mid:2
2
sip:foo@examples.com
Figure 1: Use SOAP to encapsulate floor_create command
4.2 floor_remove command
Floor_remove command will remove a floor for some resources.
boolean floor_remove(resources)
The floor_remove command takes one parameter, resources. The
definition of resources are the same as that defined in the section
3.1. The response of the method is a boolean value indicates whether
the floor is successfully removed or not.
Figure 2 shows an example of using SOAP to carry the floor_remove
command.
4.3 change_config command
Wu/Koskelainen/Schulzrinne/Chen [Page 9]
Internet Draft SIP-floor-control February 22, 2002
mid:1
mid:2
Figure 2: Use SOAP to encapsulate floor_remove command
The change_config command will change a floor's configuration.
boolean change_config(resources, max_holders, users, moderators)
The parameters for the change_config command are the same as those
for the floor_create command. The response indicates whether the
configuration is successfully changed or not.
Figure 3 shows an example of using SOAP to carry the change_config
command.
4.4 floor_claim command
When a user wants to request a floor, the user's UA SHOULD send a
floor_claim command to the conference server.
boolean floor_claim(claims)
The claims is the same as that defined in the section 3.5. The
response of the method is a boolean value indicating whether the
claims has been successfully put into the claim queue.
Figure 4 shows an example of using SOAP to carry the floor_claim
command.
4.5 floor_release event
Wu/Koskelainen/Schulzrinne/Chen [Page 10]
Internet Draft SIP-floor-control February 22, 2002
mid:1
mid:2
2
sip:foo@examples.com
Figure 3: Use SOAP to encapsulate change_config command
When a user finishes input, the user SHOULD release the floor so that
the other user can get the floor. The user's UA SHOULD send a
floor_release command to the conference server to release the floor.
boolean floor_release (resources, holders)
The resources is the same as that defined in the section 3.1. If the
resources subtag is not provided, all the resources related to the
user are released.
Figure 5 shows an example of using SOAP to carry the floor_release
command.
4.6 floor_grant command
The floor_grant command will grant one or more floors to some users.
boolean floor_grant(resources,holders)
Floor_grant command takes two parameters. The resources is the same
as that defined in the section 3.1. The holders is the same as that
defined in the section 3.4.
Wu/Koskelainen/Schulzrinne/Chen [Page 11]
Internet Draft SIP-floor-control February 22, 2002
mid:1
mid:2
Figure 4: Use SOAP to encapsulate floor_claim command
Figure 6 shows an example of using SOAP to carry the floor_grant
command.
4.7 floor_revoke command
The floor_revoke command will force the release of a floor from the
current holders.
boolean floor_revoke(resources, holders)
Floor_revoke command takes the same parameters as those for the
floor_grant command.
Figure 7 shows an example of using SOAP to carry the floor_revoke
command.
Wu/Koskelainen/Schulzrinne/Chen [Page 12]
Internet Draft SIP-floor-control February 22, 2002
mid:1
mid:2
sip:foo@examples.com
Figure 5: Use SOAP to encapsulate floor_release command
mid:1
mid:2
sip:foo@examples.com
Figure 6: Use SOAP to encapsulate floor_grant command
Wu/Koskelainen/Schulzrinne/Chen [Page 13]
Internet Draft SIP-floor-control February 22, 2002
mid:1
mid:2
sip:foo@examples.com
Figure 7: Use SOAP to encapsulate floor_revoke command
4.8 remove_claims command
The remove_claims command will remove some claims from the claim
queue.
int remove_claims(claims)
Remove_claims command takes one parameter, claims. The claims is the
same as that defined in the section 3.5. The return value indicates
how many claims have been removed.
Figure 8 shows an example of using SOAP to carry the remove_claims
command.
4.9 reorder_claims command
The reorder_claims command will change the order of the claims in the
queue. This command will use some simple operations such as move a
claim to the top, move a claim up, to change a single claim's
position.
boolean reorder_claims(resources, claim, operation)
The resources is the same as that defined in the section 3.1. The
Wu/Koskelainen/Schulzrinne/Chen [Page 14]
Internet Draft SIP-floor-control February 22, 2002
mid:1
mid:2
Figure 8: Use SOAP to encapsulate remove_claims command
claim is the same as that defined in the section 3.5. The operation
is defined as the following:
operator (top|bottom|up|down) #REQUIRED>
Figure 9 shows an example of using SOAP to carry the remove_claims
command.
5 Security consideration
Conference server SHOULD use appropriate authentication to ensure the
commands and events originated from trusted parties. Other SIP
considerations apply [7].
6 Call flows
6.1 A user joins the conference and gets a floor
Wu/Koskelainen/Schulzrinne/Chen [Page 15]
Internet Draft SIP-floor-control February 22, 2002
mid:1
mid:2
2
Figure 9: Use SOAP to encapsulate reorder_claims command
6.2 A moderator joins the conference and grants a floor
7 Authors' Addresses
Xiaotao Wu
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
electronic mail: xiaotaow@cs.columbia.edu
Petri Koskelainen
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
electronic mail: petkos@cs.columbia.edu electronic mail:
petri.koskelainen@nokia.com
Wu/Koskelainen/Schulzrinne/Chen [Page 16]
Internet Draft SIP-floor-control February 22, 2002
Conference server participant
| |
| |
+<-------- INVITE --------------+
| |
| |
+--------- 200 -------------->+
| (audio moderated) |
| |
+<------- SUBSCRIBE ------------+
| (floor_ctrl events) |
| |
+-------- NOTIFY -------------->+
| (floor_created) |
| |
+--------- NOTIFY ------------->+
| (floor grant) |
| |
+-------- re-INVITE ----------->+
| (a=sendrecv) |
| |
<---- NOTIFY ----+ |
(floor_changed)
Figure 10: A user send INVITE to join the conference
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
electronic mail: schulzrinne@cs.columbia.edu
Clayton C. Chen
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
electronic mail: ccc57@cs.columbia.edu
8 Bibliography
Wu/Koskelainen/Schulzrinne/Chen [Page 17]
Internet Draft SIP-floor-control February 22, 2002
Moderator Conference server participant A
+---------- INVITE ----------->+ |
| | |
| +<-------- INVITE --------------+
| | |
| | |
| +<-------- SOAP/HTTP or SIP ----+
| | (floor_claim) |
| | |
+<--------- NOTIFY ------------+ |
| (queue_changed) | |
| | |
+-------- SOAP/HTTP or SIP --->+ |
| (floor_grant) | |
| | |
| +--------- NOTIFY ------------->+
| | (floor_changed) |
| | |
| +-------- re-INVITE ----------->+
| | (a=sendrecv) |
| | |
Figure 11: The conference chair join the conference
[1] C. Bormann, "Simple conference control protocol service
specofocation," Internet Draft, Internet Engineering Task Force, Mar.
2001. Work in progress.
[2] R. Malpani and L. A. Rowe, "Floor control for large-scale Mbone
seminars," in Proc. of ACM Multimedia , (Seattle, Washington), Nov.
1997.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997.
[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments 2327, Internet Engineering Task Force, Apr.
1998.
[5] G. Camarillo, J. Holler, G. Eriksson, and H. Schulzrinne,
"Grouping of m lines in SDP," Internet Draft, Internet Engineering
Task Force, Oct. 2001. Work in progress.
Wu/Koskelainen/Schulzrinne/Chen [Page 18]
Internet Draft SIP-floor-control February 22, 2002
[6] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request
for Comments 3023, Internet Engineering Task Force, Jan. 2001.
[7] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Introduction ........................................ 1
1.1 Conventions of This Document ........................ 2
2 Use SIP and SOAP for the floor control .............. 2
3 Floor control events ................................ 4
3.1 floor_created event ................................. 4
Wu/Koskelainen/Schulzrinne/Chen [Page 19]
Internet Draft SIP-floor-control February 22, 2002
3.1.1 Resources ........................................... 5
3.1.2 Users ............................................... 5
3.1.3 Moderators .......................................... 5
3.2 floor_removed event ................................. 6
3.3 config_changed event ................................ 6
3.4 floor_changed event ................................. 6
3.4.1 Holders ............................................. 7
3.5 queue_changed event ................................. 7
4 Floor control commands .............................. 8
4.1 floor_create command ................................ 8
4.2 floor_remove command ................................ 9
4.3 change_config command ............................... 9
4.4 floor_claim command ................................. 10
4.5 floor_release event ................................. 10
4.6 floor_grant command ................................. 11
4.7 floor_revoke command ................................ 12
4.8 remove_claims command ............................... 14
4.9 reorder_claims command .............................. 14
5 Security consideration .............................. 15
6 Call flows .......................................... 15
6.1 A user joins the conference and gets a floor ........ 15
6.2 A moderator joins the conference and grants a
floor .......................................................... 16
7 Authors' Addresses .................................. 16
8 Bibliography ........................................ 17
Wu/Koskelainen/Schulzrinne/Chen [Page 20]