Internet Engineering Task Force
Internet Draft Koskelainen/Schulzrinne
draft-koskelainen-mmusic-floor-req-00.txt Columbia U.
August 9, 2002
Expires: Dec 2002
Requirements for 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
This document defines the requirements for floor control.
1 Introduction
Conference applications often have shared resources such as the right
to talk, input access to a limited-bandwidth video channel, or a
pointer or input focus in a shared application.
In many cases, it is desirable to be able to control who can provide
input (send/write/control, depending on the application) to the
shared resource.
Floor control enables applications or users to gain safe and mutually
exclusive or non-exclusive input access to the shared object or
Koskelainen/Schulzrinne [Page 1]
Internet Draft Floor control reqs. August 9, 2002
resource. Floor is an individual temporary access or manipulation
permission for a specific shared resource (or group of resources)
[2].
Floor control is an optional feature for conferencing applications.
SIP [7] conferencing applications may also decide not to support this
feature at all. Two-party applications may use floor control outside
conferencing, although the usefulness in this kind of scenario is
limited.
Floor control has been studied extensively over the years (e.g. [5],
[1], [6], [2]) therefore earlier work can be utilized here.
This work supports on-going SIPPING conferencing work [4].
2 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].
3 Definitions
Focus: The central point of signaling for conferences. It handles the
subscriptions, invitations and other management functions for the SIP
URI identifying the conference.
Focus owner: A user role that sets policies for the whole focus (e.g.
number of conferences that can be supported by that focus etc.)
Floor: A permission to temporarily access or manipulate a specific
shared resource or set of resources.
Conference owner: A privileged user who controls the conference,
creates floors and assigns and deassigns floor chairs. Conference
owner does not have to be a member in a conference.
Floor chair: A user (or an entity) who manages one floor (grants,
denies or revokes a floor). Floor chair does not have to be a member
in a conference.
Floor control: A mechanism that enables applications or users to gain
safe and mutually exclusive or non-exclusive input access to the
shared object or resource.
4 Model
A floor control protocol is used to convey the floor control messages
Koskelainen/Schulzrinne [Page 2]
Internet Draft Floor control reqs. August 9, 2002
among the floor chairs (moderators) of the conference, the focus
(such as conference server) and the participants of the conference.
Centralized architecture is assumed in which all messages go via one
focus point.
The centralized conference server controls the floors at least in the
signaling level. Controlling also the actual (physical) media
resources (e.g. audio mixer) is highly recommended, but beyond the
scope of this document.
Note that the floor is a concept coupled with one or more media
sessions. The creation of the media session itself is defined
elsewhere. A participant with appropriate privileges may create a
floor by defining that existing media session(s) is now floor-
controlled, and apppoint a floor chair.
5 Integration with Conferencing
Floor control itself does not support privileges such as handing over
chair privileges to another users (or taking them away). Instead,
some external mechanism, such as conference management, is used for
that.
Conference policy (and conference owner or creator) decides whether
floor control is in use or not, and if it is, whether it is mandatory
or optional. It is also conference policy about what media streams
can be in a conference, and which ones are floor controlled.
Typically, conference owner creates the floor(s) using floor control
mechanism (protocol) and appoints the floor chair. Conference owner
can remove the floor anytime (so that media is not floor controlled
anymore), or change floor chair or floor parameters.
Floor chair just controls the access to the floor(s), according to
the conference policy.
6 Requirements
REQ-1: It MUST be possible to announce that one or more conference's
media sessions are floor-controlled. This means that, unless
otherwise defined, all floor participants are in passive receive-
only mode.
REQ-2: It MUST also be possible to group more than one media sessions
together so that one floor applies to the group of media sessions.
Editor's note: This grouping can be done e.g. via SDP "fid"
extensions.
Koskelainen/Schulzrinne [Page 3]
Internet Draft Floor control reqs. August 9, 2002
REQ-3: It MUST be possible to define who is allowed to create a (and
change/terminate) floor in a conference.
Editor's note: This may be a conference chair, or a participant
authorized by conference chair.
REQ-4: It MUST be possible for a participant with appropriate
privileges to create a floor with specific parameters, such as how
many simultaneous users are allowed. Similarly, floor modification
and termination MUST be supported.
Example: The conference owner creates a floor (for existing
audio session), defines that max two users are allowed to
hold the floor at the same time and assigns floor chair.
REQ-5: It MUST be possible to use chair controlled floor policy in
which the server notifies the floor chair and waits for the chair to
make decisions. This enables the chair to fully control who has the
floor. The server MAY forward all requests immediately to chair, or
it may do filtering and send only occasional notifications to chair.
REQ-6: Participants MUST be able to request (claim) a floor and give
additional information about the request, such as the topic of the
question in audio floor.
REQ-7: It MUST be possible (for a floor holder) to release a floor.
REQ-8: It MUST be possible (for a server or participant with
appropriate privileges) to revoke a floor from its current holder.
REQ-9: It MUST be possible to grant a floor to a participant.
REQ-10: It MUST be possible to manipulate or set at least the
following floor parameters:
- who is floor control chair (this does not have to be the conference
owner)
- floor control policy (such as chair-controlled, FCFS, Random)
- number of simultaneous floor holders
Floor control related parameters are defined when the controlled
floor is created, or modified.
REQ-11: It MAY be possible to manipulate additional parameters, such
as time limits.
REQ-12: It MUST be possible for a user with appropriate conference
privileges to give (and take away) chair privileges to (from) other
Koskelainen/Schulzrinne [Page 4]
Internet Draft Floor control reqs. August 9, 2002
users.
REQ-13: It MAY be possible for a user to request that media is floor
controlled.
Editor's note: This may be useful especially if the chair is a
robot.
REQ-14: It MAY be possible to support multiple chairs.
REQ-15: Bandwidth and terminal limitations MUST be taken into account
in order to ensure that floor control can be efficiently used in
mobile environments.
7 Open Issues
- support for more than one floor chair?
8 Acknowledgements
The authors would like to thank Xiaotao Wu, Sanjoy Sen, Jonathan
Rosenberg, Brian Rosen, Nermeen Ismail, Rohan Mahy, and Orit Levin
for their comments.
9 Authors' Addresses
Petri Koskelainen
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
electronic mail: petkos@cs.columbia.edu
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
electronic mail: hgs@cs.columbia.edu
10 Bibliography
[1] Bormann, C., Kutscher, D., Ott, J., and Trossen, D., Simple
conference control protocol service specification. Internet Draft,
Internet Engineering Task Force, Mar. 2001. Work in progress.
Koskelainen/Schulzrinne [Page 5]
Internet Draft Floor control reqs. August 9, 2002
[2] Dommel, H.-P., and Garcia-Luna-Aceves, J., "Floor control for
activity coordination in networked multimedia applications.," In
Proc. of 2nd Asian-Pacific Conference on Communications (APCC (Osaka,
Japan, June 1995).
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[4] O. Levin, A. Zmolek, R. Even, D. Petrie, and P. Koskelainen,
"Conferencing requirements for sip based systems," Internet Draft,
Internet Engineering Task Force, April 2002. Work in progress.
[5] P. Koskelainen, H. Schulzrinne, and X. Wu, "A sip-based
conference control framework," in The 12nd International Workshop on
Network and Operating System Support for Digital Audio and Video
(NOSSDAV) , (Miami Beach, Florida), May 2002.
[6] Wu, X., Koskelainen P., Schulzrinne H., Chen C. Use SIP and SOAP
for conference floor control. Internet Draft, Internet Engineering
Task Force, Feb. 2002. Work in progress.
[7] 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
Koskelainen/Schulzrinne [Page 6]
Internet Draft Floor control reqs. August 9, 2002
"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
2 Conventions of This Document ........................ 2
3 Definitions ......................................... 2
4 Model ............................................... 2
5 Integration with Conferencing ....................... 3
6 Requirements ........................................ 3
7 Open Issues ......................................... 5
8 Acknowledgements .................................... 5
9 Authors' Addresses .................................. 5
10 Bibliography ........................................ 5
Koskelainen/Schulzrinne [Page 7]