Internet Draft O. Levin/RADVISION Document: R. Even/Polycom draft-levin-sipping-conferencing- A. Zmolek/Avaya requirements-01.txt D. Petrie/Pingtel July 2002 P. Koskelainen/Columbia U. Expires: January 2003 S. Sen/Nortel Requirements for Tightly Coupled SIP 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document examines a wide range of conferencing requirements being applied to a tightly coupled SIP Star conference. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols. Together, these documents would provide a guide for building interoperable SIP conferencing applications. O. Levin et al. Expires: January 2003 Page 1 Requirements for Tightly Coupled SIP Conferencing Table of Contents 1. SCOPE............................................................3 2. TIGHTLY COUPLED SIP CONFERENCING FRAMEWORK.......................3 3. GENERAL DESIGN GUIDELINES........................................4 4. DISCOVERY PHASE REQUIREMENTS.....................................4 SIP ENTITY CONFERENCING CAPABILITIES DISCOVERY......................4 A PARTICULAR CONFERENCE LOCATION AND INFORMATION DISCOVERY..........5 5. BASIC CONFERENCING REQUIREMENTS..................................5 PARTICIPATION OF RFC 3261 COMPLIANT ONLY USER AGENT.................5 CONFERENCE ESTABLISHMENT IN DIAL-OUT SCENARIOS (AS PER [3]).........5 CONFERENCE ESTABLISHMENT IN DIAL-IN SCENARIOS (AS PER [3])..........6 THIRD PARTY INVITATION TO A CONFERENCE..............................6 DISCONNECTION OF CONFERENCE MEMBERS AND CONFERENCE TERMINATION......6 CONFERENCE MEMBER PRIVACY...........................................7 6. CONFERENCE STATE DISSEMINATION REQUIREMENTS......................7 REPORT OF CHANGES...................................................7 ON-DEMAND DISSEMINATION.............................................8 7. MISCELLANEOUS REQUIREMENTS.......................................8 8. MEDIA CONTROL REQUIREMENTS.......................................9 9. CONFERENCE ACCESS CONTROL LIST (ACL).............................9 10. CONFERENCE PARTICIPANT PRIVILEGES..............................10 MODEL..............................................................10 REQUIREMENTS.......................................................10 11. FLOOR CONTROL..................................................10 DEFINITIONS........................................................10 REQUIREMENTS.......................................................11 12. REQUIREMENTS BEYOND MANAGEMENT OF A SINGLE CONFERENCE..........12 13. CONVENTIONS USED IN THIS DOCUMENT..............................13 14. SECURITY CONSIDERATIONS........................................13 15. AUTHOR'S ADDRESSES.............................................13 16. REFERENCES.....................................................14 O. Levin et al. Expires: January 2003 Page 2 Requirements for Tightly Coupled SIP Conferencing 1. Scope This document examines a wide range of conferencing requirements being applied to a tightly coupled SIP Star conference. The requirements are grouped according to their topics in order to define solutions to different topics in parallel. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols. Together, these documents would provide a guide for building interoperable SIP conferencing applications. 2. Tightly Coupled SIP Conferencing Framework SIP conference is an association of SIP User Agents (e.g. conference members) with a central member (e.g. a conference host), which has a direct peer-wise relationship with each other member by means of a SIP dialog. Each dialog can belong to a different SIP session. In this framework, the SIP conference graph is always a star. The conference host maintains the correlation among conference's dialogs internally. The conference state is defined by a set of information describing the conference in progress. This MAY include the following: all or some participant information such as dialog-ids, media sessions in progress, etc. A complete conference state definition can be found in [5]. The conference can be hosted either by a participating entity (e.g. terminal) or by a separate application server. Typically to the first case, a terminal is capable of hosing a limited ad hoc conference. Such conference is established using basic conferencing primitives. Editor's Note: This is similar to traditional offering from PSTN service providers in audio conferencing such as being able to join independent calls into a multiparty conference. Application server offers more robust options including reservation, large conferences, and managed conferences. In addition to the basic functionality, the conferencing server supports any subset of advanced conferencing features, presented in this document. In this case, the conference has a globally routable identifier, such as SIP URI. O. Levin et al. Expires: January 2003 Page 3 Requirements for Tightly Coupled SIP Conferencing The conference properties are defined by a list of configuration parameters (e.g., maximum number of ports/participants, needs chair- person supervision or not, password protected or not, duration, etc.) that a conference creator can request from the conference service. Conference properties are configured at the onset of a conference and, typically, need special privileges to be changed. Conference participants MAY have different roles or privileges in a conference. For example, a conference Chair MAY have the right to disconnect users from a conference, or terminate the conference. SIP conference MAY have media sessions similarly to standard two- party SIP calls. The conference media graph is constructed independently from the SIP star conference. For example, it can be centralized (e.g. following the star graph of the SIP conference) or it can be de-centralized (such as multicast mesh among the participating entities). As it can be seen from the examples, the function of the media processing can be performed either by the conference host alone or by each one of the participating entities. 3. General Design Guidelines GDG-1: Keep It Simple. GDG-2: Low Bandwidth Consumption. Mobile low-bandwidth devices represent large portion of user base. Bandwidth consumption on the access link is the most important mobile requirement. GDG-3: MUST NOT assume IP Multicast. The solution MUST NOT assume IP multicast since it is not widely available in mobile networks or in residential environments (such as PPPoE). GDG-4: The design MUST allow for scalable architecture in order to support large (but still tightly managed) conferences. GDG-5: Since the request processing may take long time at the server, the response mechanism SHOULD be asynchronous. Editor's note: For example, if a conference creation includes long list of dial-out participants, it may take a long time to have the final response to the request. 4. Discovery Phase Requirements SIP Entity Conferencing Capabilities Discovery O. Levin et al. Expires: January 2003 Page 4 Requirements for Tightly Coupled SIP Conferencing Editor's Note: The following requirements can always be achieved by configuration means or/and human agreement. Nevertheless, we feel that automatic means MUST be defined. CAPD-1: A standard means MUST be defined for automatic discovery of location of conferencing application server(s). CAPD-2: A standard format for expressing UA's conferencing capabilities MUST be defined. Each SIP entity MUST be able to independently express its capabilities as a conference member only and as a conference host. CAPD-3: A standard means MUST be defined for retrieving conferencing capabilities of a known SIP entity. In this regard, the SIP entity can be either a user device (e.g. a terminal) or a dedicated conferencing server. A Particular Conference Location and Information Discovery CNFD-1: Given a global identifier of a particular conference, a standard means MUST be defined for locating the hosting entity of this conference. CNFD-2: Given a global identifier of a particular conference, a standard means MUST be defined for obtaining the conference properties. CNFD-3: Given a global identifier of a particular conference, a standard means MUST be defined for obtaining the conference state information. 5. Basic Conferencing Requirements Participation of RFC 3261 compliant only User Agent BSC-1: A conference host MUST be able to invite and disconnect an RFC 3261 compliant only SIP UA to and from a SIP conference. BSC-2: RFC 3261 compliant only SIP UA's MUST be able to dial-in a particular SIP conference (as per [3]). In this case, only the user behind its UA knows that he dials into the conference. Editor's Note: In this case, the conference can be identified either by manually populating the Request-URI field with the conference identifier or, alternatively, by using an IVR service. Conference Establishment in Dial-Out Scenarios (as per [3]) DOUT-1: A means MUST be defined for a conference host to invite a User Agent to one of its active conferences (specified by a O. Levin et al. Expires: January 2003 Page 5 Requirements for Tightly Coupled SIP Conferencing conference identifier) over an existing SIP dialog between the two. As a result, the dialog becomes a part of the conference. DOUT -2: A means MUST be defined for a conference host to invite a User Agent by establishing a new SIP dialog between the two together with specifying the identifier of the conference. The dialog belongs to the conference. Conference Establishment in Dial-In Scenarios (as per [3]) DIN-1: Provided desired conference properties and the hosting entity location (as per DS-1 and DS-2), a means MUST be defined for a UA to create an ad-hoc conference [3] and to become its member. A means MUST be defined for creating a global conference identifier for this ad-hoc scenario. DIN-2: Provided a reserved conference identifier, a means MUST be defined for a UA to activate the conference and to become its member. DIN-3: Provided a reserved conference identifier, a means MUST be defined for a UA to dial-in an active conference and to become its member. DIN-4: Provided one of the dialogs ID, belonging to a particular active conference, a means MUST be defined for a UA to dial-in an active conference and to become its member. Third Party Invitation to a Conference THIP-1: Provided a conference identifier, a means MUST be defined for a UA to invite another UA to this conference. THIP-2: Provided one of the dialogs ID, belonging to a particular active conference, a means MUST be defined for a UA to invite another UA to this conference. THIP-3: Provided a conference identifier, a means MAY be defined for a UA to invite a list of UAs to this conference (a so-called "mass invitation"). Disconnection of Conference Members and Conference Termination TERM-1: A means MUST be defined for a conference host to disconnect a conference member from an active conference. TERM-2: A means MAY be defined for a conference host to revert a two-party conference to a basic SIP point-to-point session (and releasing internal conferencing resources). O. Levin et al. Expires: January 2003 Page 6 Requirements for Tightly Coupled SIP Conferencing TERM-3: Provided a conference identifier, a means MUST be defined for a UA to disconnect another UA from this conference. TERM-4: Provided one of the dialogs ID, belonging to a particular active conference, a means MAY be defined for a UA to disconnect another UA from this conference. TERM-5: Provided a conference identifier, a means MAY be defined for a UA to disconnect a list of UAs from this conference (a so-called "mass feature"). TERM-6: Provided a conference identifier, a means MUST be defined for a UA to disconnect all members from this conference. TERM-7: Provided a conference identifier, a means MAY be defined for a UA to terminate this conference by disconnection all the members, releasing conference resources together with the conference identifier. Editor's note: Some of the requirements above overlap with each other. Conference Member Privacy The following features depend both on host's capabilities and policies and on members' capabilities. A conference host SHOULD support these. A conference member MAY support these. PRV-1: A conference member participates in a conference "anonymously", meaning that its presence is known and can be announced but without disclosing its identity. PRV-2: A conference member requests anonymous participation from the host. PRV-3: A conference member participates in a conference "in a hidden mode", meaning that both its presence and its identity are not disclosed. PRV-4: A conference member requests participation in a hidden mode. 6. Conference State Dissemination Requirements Report of Changes CNG-1: It is expected that the set of events related a conference state and required to be reported would grow with time. Therefore, a mechanism for extensible definition/registration of new conference state changes MUST be defined. O. Levin et al. Expires: January 2003 Page 7 Requirements for Tightly Coupled SIP Conferencing CNG-2: A means MUST be defined for reporting the conference state changes to interested parties (including conference members) in a timely manner. The report MAY include more than one change. CNG-3: A means MUST be defined for a SIP UA to express its interest in selected state changes only. CNG-4: A means MUST be defined for a SIP UA to express the minimum interval between receiving state change reports. A means MUST be defined for reporting at least the following changes in a conference state: CNG-5: A new conference member joined the conference. CNG-6: A Particular conference member left the conference. On-demand Dissemination ODD-1: A means MUST be defined to disseminate any conference state information (as per [5]) to interested parties (i.e. SIP UAs) on- demand. ODD-2: A means MUST be defined for a SIP UA to request a conference state information of a particular conference defined by the conference identifier. ODD-3: A means MUST be defined for a SIP UA to specify the subset of the conference state information, it wants and capable to receive. 7. Miscellaneous Requirements MISC-1: A procedure for delegating of a host role by the current host to another member MUST be defined. MISC-2: A procedure for requesting a conference host to transfer its role to another conference member MUST be defined. MISC-3: A procedure for on-demand unconditional transfer of the host role to a different member MUST be defined. MISC-4: A detection procedure for a conference host failure condition MUST be defined. MISC-5: In case a conference host failure, a procedure for assigning a new conference host MUST be defined. Editor's Note: This is a difficult for standardization requirement. O. Levin et al. Expires: January 2003 Page 8 Requirements for Tightly Coupled SIP Conferencing 8. Media Control Requirements This section is left for future study. To this point, the listed below requirements have been identified: MEDI-1: Each media session between the conference Server and a participant in a conference MUST have a unique identity in the conference space MEDI-2: It MUST be possible for a user to participate in a sub-set of media sessions of a conference MEDI-3: It MUST be possible to modify media sessions of certain subset of the participants without impacting the sessions of other participants (e.g., introduce side-bar conversations between two participants). MEDI-4: It MUST be possible to modify a subset of the media sessions of a participant during the conference (e.g., swap in and out video). MEDI-5: A media session of a participant MUST be in one of the following states: - Inactive : SDP attribute=inactive - Active : opposite of inactive - On-hold : SDP attribute=sendonly - Disabled : media port = 0 MEDI-6: It MUST be possible for the conference server to mix a sub- set of the active media sessions in a conference (e.g., mix audio from two most audible speakers). MEDI-7: It SHOULD be possible for a participant with appropriate privileges to add (and delete) conference-wide media sessions into (from) the conference, or modify their properties. 9. Conference Access Control List (ACL) The purpose of the Access Control List is to define who is allowed (or not allowed) to join the conference. If there is user's join attempt, but user is not in the ACL then (depending on the conference policy), the conference chair MAY be consulted whether the user can be accepted to join the conference. ACL-1: There MUST be a mechanism to define Access Control List (ACL) so that user's joins can be pre-authorized (or denied). ACL-2: It MUST be possible to add and delete users to/from ACL. O. Levin et al. Expires: January 2003 Page 9 Requirements for Tightly Coupled SIP Conferencing ACL-3: It MUST be possible to consult a user with appropriate privileges (such as chair) when an unknown user tries to join the conference. The chair may accept or deny the join attempt. 10. Conference Participant Privileges Model Conference participants MAY have different privileges. In the simplest case, only two kinds of participants exist: the conference Chair (with all the privileges), and normal Participants (without any privileges). For example, following privileges MAY be supported: - Right to terminate a conference - Right to disconnect participants - Right to manage general conference properties - Right to manage conference access control list (ACL) - Right to manage conference-wide media sessions (e.g. add audio session into conference) - Right to manage other participant's session parameters (such as media) - Right to make real-time authorization (for join attempts) - Right to hand-off all (or some of) the above privileges to another participant Some conferences may utilize more complex privilege definition and hierarchy; such as guru-participants have the right to disconnect participants. Therefore, protocol mechanisms MUST be in place to translate these rights into actions. Requirements PRIV-1: It MUST be possible to define different privileges to different participants. PRIV-2: It MAY be possible that different participant levels are defined (e.g. senior-member, panelist). PRIV-3: Rules MUST be defined for special cases, such as if chair leaves suddenly, or chair tries to take privileges away from all privilege holders. 11. Floor Control Definitions O. Levin et al. Expires: January 2003 Page 10 Requirements for Tightly Coupled SIP Conferencing 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 resource. This is an optional feature for conferencing applications. SIP conferencing applications may decide not to implement this feature. Floor control has been studied extensively over the years (e.g. [8], [9], [10], [11], and [12]) therefore earlier work can be utilized here. A floor control protocol is used to convey the floor control messages among the floor chairs (moderators) of the conference, the conference server and the participants of the conference. 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. Requirements FLO-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. 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 announcement can be done e.g. via SDP "fid" extensions ([6] and [7]). FLO-2: It MUST be possible to define who is allowed to create a floor in a conference. Editor's note: This may be a conference chair, or a participant authorized by conference chair. O. Levin et al. Expires: January 2003 Page 11 Requirements for Tightly Coupled SIP Conferencing FLO-3: 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 of this is that chair creates a floor (for existing audio session) and defines that max two users are allowed to hold the floor at the same time. The server can then take care of this. FLO-4: It MUST be possible to use moderator-controlled floor policy in which the server notifies the floor moderator and waits for the moderator to make decisions. This enables the moderator to fully control who has the floor. The server MAY forward all requests immediately to moderator, or it may do filtering and send only occasional notifications to moderator. FLO-5: It MAY be possible that several users are acting as floor moderators. The centralized server may send floor request notifications either sequentially, or at the same time. FLO-6: The moderator actions (e.g. floor grant) MUST be atomic and the server MUST cope with "simultaneous write" problem in which many moderators try to make conflicting decisions at the same time. FLO-7: Participants MUST be able to request (claim) a floor. FLO-8: It MUST be possible (for a floor holder) to release a floor. FLO-9: It MUST be possible (for a server or participant with appropriate privileges) to revoke a floor from its current holder. FLO-10: It MUST be possible to grant a floor to a participant. Floor control related parameters are defined when the controlled floor is created, or modified. FLO-11: It MUST be possible to manipulate at least the following floor parameters: - Floor control chair (this does not have to be the conference chair) - Floor control policy (such as moderator-controlled, FCFS, Random) - Number of simultaneous floor holders FLO-12: it MAY be possible to manipulate additional parameters, such as time limits. 12. Requirements Beyond Management of a Single Conference O. Levin et al. Expires: January 2003 Page 12 Requirements for Tightly Coupled SIP Conferencing This section is left for future study. To this point, the listed below requirements have been identified: MET-1: It SHOULD be possible to merge two existing conferences to form a single conference. MET-2: It SHOULD be possible to split an active conference into two or more conferences. MET-3: It SHOULD be possible to daisy-chain multiple ongoing conferences. Editor's Note: In general, conferencing split and merge operations are extremely difficult. We may consider achieving this functionality by transferring individual participants to other conference using simple SIP means. 13. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 14. Security Considerations Security requirements will be addressed in the next version of this document. 15. Author's Addresses Orit Levin RADVISION Inc. 266 Harristown Road, Suite 201, Glen Rock, NJ 07452 Phone: +1-201-689-6330 USA Email: orit@radvision.com Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva Phone: +972-3-925-1200 Israel Email: roni.even@polycom.co.il Andy Zmolek Avaya 8740 Lucent Blvd. 403E273 Highlands Ranch, CO 80129 Phone: +1-720-444-4001 USA Email: zmolek@avaya.com O. Levin et al. Expires: January 2003 Page 13 Requirements for Tightly Coupled SIP Conferencing Daniel G. Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801 Phone: +1 781 938 5306 USA Email: dpetrie@pingtel.com Petri Koskelainen Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: petkos@cs.columbia.edu Sanjoy Sen Nortel Networks Email: sanjoy@nortelnetworks.com 16. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2 J. Rosenberg, H. Schulzrinne et al., "SIP: Session Initiation Protocol", RFC 3261. 3 J. Rosenberg, H. Schulzrinne, "Models for Multi Party Conferencing in SIP", draft-ietf-sipping-conferencing-models- 00.txt, Nov 2001, IETF Draft. Work in progress. 4 Mahy/Cambell/Johnston/Petrie/Rosenberg/Sparks, "A Multi-party Application Framework for SIP", draft-ietf-sipping-cc-framework- 00.txt, Feb 2002, IETF Draft. Work in progress. 5 J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping- conference-package-00.txt, June 2002, IETF Draft. Work in progress. 6 M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-08.txt, Apr 2002, IETF Draft. Work in progress. 7 Camarillo/Holler/Eriksson/Schulzrinne, "Grouping of m lines in SDP", draft-ietf-mmusic-fid-06.txt, Feb 2002, IETF Draft. Work in progress. 8 Dommel, H-P. and Garcia-Luna-Aceves, J., "Floor control for activity coordination in networked multimedia applications." In Proc. of 2nd Asian-Pacic Conference on Communications (APCC) (Osaka, Japan, June 1995). O. Levin et al. Expires: January 2003 Page 14 Requirements for Tightly Coupled SIP Conferencing 9 Dommel, H-P. and Garcia-Luna-Aceves J., "Efficacy of Floor Control Protocols in Distributed Multimedia Collaboration," Cluster Computing Journal, Special issue on Multimedia Collaborative Environments, Vol. 2, No.1, 1999. 10 Bormann, C., Kutscher, D., Ott, J., and Trossen, D. "Simple conference control protocol service specifation." Mar. 2001, IETF Draft,. Work in progress. 11 Koskelainen, P., Schulzrinne H., and Wu, X. "A SIP-based Conference Control Framework," in Proc. International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), (Miami Beach, Florida), May 2002. 12 Wu/Koskelainen/Schulzrinne/Chen, "Use SIP and SOAP for conference floor control", draft-wu-sipping-floor-control-01.txt, Apr 2002,IETF Draft. Work in progress. O. Levin et al. Expires: January 2003 Page 15