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]