Internet Engineering Task Force Internet Draft Koskelainen,Schulzrinne,Wu draft-koskelainen-sipping-conf-requirements-00.txt Nokia,Columbia U. April 29, 2002 Expires: October 2002 Additional Requirements to Conferencing 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 focuses on advanced media-independent conferencing and conference control requirements, especially on user management related requirements. Media control and floor control are out of scope. 1 Introduction This document is an input document to the IETF SIPPING WG. This document complements other conferencing requirements such as [1] and focuses more on advanced user management issues. Floor control and media control are totally out of scope. This document focuses only on centralized (star-based) conferences in Koskelainen,Schulzrinne,Wu [Page 1] Internet Draft Additional Conferencing Requirements April 29, 2002 which the server hosts the conference. Scalable solutions to support large conferences are out of scope. Later standardization may define how star-based conference topology can be extended to support really large conferences. Work on scalable solutions can be found e.g. in [2], which defines a mechanism that can be used to distribute the conference across several conference servers using hierarchical, distributed server tree (DST) or single source multicast. Management functions identified in this document may be utilized for other services as well. For example, creating a group list at a server (without intension to do conferencing) may utilize same operations, such as creating a group list and adding new users into it. 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 Overview We define conference as a set of members that exchange one or more media streams or share some other state, such as an application. Conferencing includes two main parts. First part enables participants to join and leave a conference. Signaling protocols, such as SIP, can generally support these operations if conferences are addressed like regular endpoints. The second conferencing part, conference control, can be considered as consisting three components: - conference management (creating, modifying and deleting conferences as a whole), - user management (adding and deleting conference participants and modifying their properties), and - resource contention management, also known as floor control. The main function of floor control is to provide safe access to shared resources. Controlling permissions to talk is the most typical example of floor control. However, as said earlier, floor control is out of scope. Conferences are addressed like regular endpoints so conference has an identifier such as sip:conf34@server.com. The conference server has a point-to-point relationship with each conference member. SIP can control application sessions only between one user and the conference server. It cannot change the conference state or the Koskelainen,Schulzrinne,Wu [Page 2] Internet Draft Additional Conferencing Requirements April 29, 2002 conference-wide media settings at the server so additional management operations are needed [2]. 3 Example Use Cases Use Case 1: (Conference creation and conference control) A conference is created at a server, and it is managed during the conference lifetime. Conference may have a lot of properties such as member list, access control list (ACL), user privileges, and media channels. Use Case 2: (Creating and managing user list without actual conference) A group name such as sip:myfriends@server.com is created. Creator can add and remove users. This group name can be used e.g. as an alias for multiparty one-shot messaging, or it can be used later for conferecing (no need to create new user list for each conference, instead, user can utilize existing user lists). 4 General Requirements * Tight conference control (in contrast to loose conference control) * Centralized architecture (in contrast to fully meshed or multicast) * Simplicity: Conferencing framework must balance being poweful enough for most practical scenarios, yet avoid being too complex to be widely accepted and implemented on devices with limited computational resources and user interfaces. * Mobile-friendliness Solution MUST be mobile-friendly, since mobile low-bandwidth devices represent large portion of user base. Bandwidth consumption on the access link is the most important mobile requirement. It means that unnecessary (frequent) communication SHOULD be minimized. For example, pre-defined definitions (access lists) eliminate the need to consult human moderator for every join attempt. Moreover, the notification frequency SHOULD be configurable by the user. Similarly, partial modifications MUST be supported. This means that there is no need to send all parameters if you change only one. In addition, changes in the member lists should be distributed as additions and removals (instead of distributing whole list). Moreover, the solution MUST NOT assume IP multicast since it is not widely available in mobile networks or in residential environments (such as PPPoE). * Component based Koskelainen,Schulzrinne,Wu [Page 3] Internet Draft Additional Conferencing Requirements April 29, 2002 The solutions MUST be component-based (in contrast to monolithic). This allows clients to implement only relevant components. It also allows more advanced components to be added later (such as floor control), or existing components may be changed. * Asynchronous commands The execution of commands may take a long time, especially if human intervention is required so asynchronous commands MUST be supported. * Asynchronous notifications There MUST be a support for asynchronous notifications (e.g. network-initiated notifications without client pull). * Media-independency: The solution MUST be media-independent since in many cases there is no (RTP) media at all. 5 Component Specific Requirements 5.1 Conference Management requirements Conference management may include several optional sub-components, but it has also a few mandatory top-level requirements: * Conference creation: This creates a conference at a server. It may have parameters which describe basic conference-wide properties such as conference name and subject. Conference may be created for one- time use only, or as a permanent conference or group (conference name remains reserved). * Conference termination: This terminates the conference. The conference name may still be left to the server so same conference name and parameters may be utilized for later conferences. * Modification of conference parameters: This modifies conference parameters (e.g. adds video channel). * Fetching conference description from the server: User may fetch the conference description even before joining the conference. * Finding out the status of the conference: Solution MUST NOT be based on RTCP. * Search conferences at the server (e.g. search all conferences which are public and subject line or keywords includes word "soccer") * User SHOULD be able to define the level of details it want to receive as conference notifications or announcements (e.g. user may Koskelainen,Schulzrinne,Wu [Page 4] Internet Draft Additional Conferencing Requirements April 29, 2002 not want to receive informational notifications at all) It must be possible to create a simple conference using these top- level functions. More advanced features can be provided by optional sub-components. 5.2 User Management component This is an optional component. It must enable at least the following operations or features: * Managing user right levels: Manage user right levels, such as audience, guru, moderator. It must be possible to create and delete a user level, and add (remove) a user to (from) a user level. Default user levels may be defined (e.g. all new users are audience). * Managing privileges for user levels: This sets the user level privileges in a conference and defines what is allowed for each user level. Managing privileges can be an arbitrarily complex, expressible only in a full programming language. However, the majority of cases can be handled by defining a few simple privileges that are directly tied to conference management and giving users rights to those privileges. The privileges are at least invite users, expel members, make real-time authorizations (such as accept or deny a join attempt), manage access control list (ACL), manage media sessions (e.g. change a user to receive only mode, or add video channel into a conference), and manage general parameters such as subject, authentication, visibility or start-time. Typically, moderator user level has all privileges. * Managing ACL: Manage ACL and sets allow/block definitions for a list of users. Wildcards must be supported (e.g. block sip:*@spam.com). Add/remove operations must be supported. * Expelling users: This expels list of users from the conference. * Mass-invitation: Invites a list of users into the conference * Real-time authorization operations: For unexpected decisions during the conference. For example, "allow user X to join the conference". * Finding out conference members: It SHOULD be possible to find out the identities of current conference members at any given time. Must Koskelainen,Schulzrinne,Wu [Page 5] Internet Draft Additional Conferencing Requirements April 29, 2002 not assume RTCP. * Anonymous participation: It must be possible to participate anonymously to the conference (e.g. by creating an anonymous user name into the server) 5.3 Other components The solution must allow other sub-components to be introduced later into the framework (such as SIP/SOAP floor control [4]). 5.4 Group Operations * Group name creation, modifications, termination: Create/Modify/Terminate a group name which can be later used e.g. for conferencing or one-shots. In many cases, this group name includes just a list of users and is used only for one-shot messaging. (this overlaps partly with conference creation..) 6 Notifications Following notifications or announcements are required: - Occasional user related notifications, such as "Bob and Tom have joined", or "Dear moderator, user X wants to join the conference. Accept or Deny?", or other general conference notifyications. - result for the asynchronous command (e.g. moderator decided - after thinking for a while - not to allow Bob to join). 7 Denial-of-Service attacks DoS attacks are possible. For example, a large number of join attempts may be created. Human moderator should not be automatically consulted about each join attempt. Instead, access lists are checked first. Rate-control must be applied in the server so notifications are not sent too often. Moreover, this often allows the server to include several notification into one message (e.g. 3 join attempts are reported in one notification). 8 Examples At least the following parameters should be supported: - conference name (such as sip:conf34@server.com) - conference subject (such as "IETF interim SIMPLE WG meeting") - conference time (e.g. it starts tomorrow 12:00 EST) - store conference parameters or not for later use - whether conference is public or not (can it be seen/searched) Koskelainen,Schulzrinne,Wu [Page 6] Internet Draft Additional Conferencing Requirements April 29, 2002 - authentication information - application information (such as conference-wide media codecs) - list of users to be invited by the server (for mass-invitation) - user right levels (such as guru, moderator, audience) - user level access rights (such as guru-members are allowed to expel members) - ACL Following is a concrete example of the conference creation, and conference control during the conference. User A creates a conference at a server with following parameters: - conference name: sip:conf34@server.com - subject: Interim Sipping meeting - authentication: digest, passwd=''x243DHEDw'' - media: video channel:H.261.., audio channel:PCM.. - user levels: default groups (moderator, audience) moderator list: user A audience list: (default for all new members) - user level rights: audience: none moderator:expel members, authorize joins, manage ACL, terminate conference) - invite users: Tom, Alice, John - ACL: block list=Bob, *.spam.com. The conference server sends an acknowledgement. It means that the command was accepted without an immediate failure. The server process the command and makes invitations. The server sends occasional notifications to the creator, such as "Conference created successfully. Members in a conference: Tom, Alice". New members try to join the conference. ACL does not include any hint how to act so moderator action is required. The server waits for a while, and sends a notification to the moderator. The notification includes information about 3 join attempts. The moderator accepts one of them, and denies two of them. The decision is sent to the server in a one message. 9 Conclusions There are two kinds of operations needed for conference control and Koskelainen,Schulzrinne,Wu [Page 7] Internet Draft Additional Conferencing Requirements April 29, 2002 management: - commands (sent to the server) - informative notifications aka announcements 10 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 electronic mail: petri.koskelainen@nokia.com Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: xiaotaow@cs.columbia.edu Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu 11 Bibliography [1] 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. [2] 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. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [4] X. Wu, P. Koskelainen, H. Schulzrinne, and C. Chen, "Use SIP and SOAP for conference floor control," Internet Draft, Internet Engineering Task Force, April 2002. Work in progress. Koskelainen,Schulzrinne,Wu [Page 8] Internet Draft Additional Conferencing Requirements April 29, 2002 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 Overview ............................................ 2 3 Example Use Cases ................................... 3 4 General Requirements ................................ 3 5 Component Specific Requirements ..................... 4 5.1 Conference Management requirements .................. 4 5.2 User Management component ........................... 5 5.3 Other components .................................... 6 5.4 Group Operations .................................... 6 6 Notifications ....................................... 6 7 Denial-of-Service attacks ........................... 6 8 Examples ............................................ 6 Koskelainen,Schulzrinne,Wu [Page 9] Internet Draft Additional Conferencing Requirements April 29, 2002 9 Conclusions ......................................... 7 10 Authors' Addresses .................................. 8 11 Bibliography ........................................ 8 Koskelainen,Schulzrinne,Wu [Page 10]