Internet Draft O. Levin/RADVISION Document: R. Even/Polycom draft-levin-sipping-conferencing- P. Koskelainen/Columbia U. requirements-02.txt S. Sen/Nortel November 2002 Expires: May 2003 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: May 2003 Page 1 Requirements for Tightly Coupled SIP Conferencing Table of Contents 1. SCOPE............................................................3 2. TIGHTLY COUPLED SIP CONFERENCING FRAMEWORK.......................3 3. DISCOVERY PHASE REQUIREMENTS.....................................4 SIP ENTITY CONFERENCING CAPABILITIES DISCOVERY..............................4 A PARTICULAR CONFERENCE LOCATION AND INFORMATION DISCOVERY.....................4 4. BASIC CONFERENCING REQUIREMENTS..................................5 PARTICIPATION OF RFC 3261 COMPLIANT ONLY (I.E. BASIC) USER AGENT...............5 CONFERENCE ESTABLISHMENT IN DIAL-OUT SCENARIOS..............................5 CONFERENCE ESTABLISHMENT IN DIAL-IN SCENARIOS...............................5 THIRD PARTY INVITATION TO A CONFERENCE.....................................6 DISCONNECTION OF CONFERENCE MEMBERS AND CONFERENCE TERMINATION..................6 CONFERENCE MEMBER PRIVACY................................................7 5. CONFERENCE STATE DISSEMINATION REQUIREMENTS......................7 REPORT OF CHANGES......................................................7 ON-DEMAND DISSEMINATION.................................................7 6. MISCELLANEOUS REQUIREMENTS.......................................8 7. MEDIA CONTROL REQUIREMENTS.......................................8 8. CONFERENCE ACCESS CONTROL LIST (ACL).............................9 9. CONFERENCE PARTICIPANT PRIVILEGES................................9 MODEL................................................................9 REQUIREMENTS.........................................................10 10. FLOOR CONTROL..................................................10 11. CASCADING OF CONFERENCES.......................................10 12. SIDE-BAR CONFERENCES...........................................11 13. SIMPLE AND SIP CONFERENCING COORDINATION.......................11 14. CONVENTIONS USED IN THIS DOCUMENT..............................11 15. SECURITY CONSIDERATIONS........................................11 16. AUTHOR'S ADDRESSES.............................................11 17. REFERENCES.....................................................12 O. Levin et al. Expires: May 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 focus), 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. Focus is a SIP UA which has abilities to host SIP conferences including its creation, maintenance and manipulation using SIP call control means. In this framework, the SIP conference graph is always a star. The conference focus 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 hosting a limited ad hoc conference. Such conference may be established using basic call control 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 O. Levin et al. Expires: May 2003 Page 3 Requirements for Tightly Coupled SIP Conferencing functionality, the conferencing server supports any subset of advanced conferencing features, presented in this document. In this case, the focus is one of the logical entities comprising the conferencing application server. 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 focus alone or by each one of the participating entities. 3. Discovery Phase Requirements SIP Entity Conferencing Capabilities Discovery 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 focus. 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. O. Levin et al. Expires: May 2003 Page 4 Requirements for Tightly Coupled SIP Conferencing 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. 4. Basic Conferencing Requirements Participation of RFC 3261 compliant only (i.e. basic) User Agent BSC-1: A conference focus 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. 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 DOUT-1: A means MUST be defined for a conference focus to invite a User Agent to one of its active conferences (specified by a 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 focus 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 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 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. O. Levin et al. Expires: May 2003 Page 5 Requirements for Tightly Coupled SIP Conferencing 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 focus to disconnect a conference member from an active conference. TERM-2: A means MAY be defined for a conference focus to revert a two-party conference to a basic SIP point-to-point session (and releasing internal conferencing resources). 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. O. Levin et al. Expires: May 2003 Page 6 Requirements for Tightly Coupled SIP Conferencing Conference Member Privacy The following features depend both on focusÆs capabilities and policies and on membersÆ capabilities. A conference focus 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 focus. 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. 5. 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. 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 O. Levin et al. Expires: May 2003 Page 7 Requirements for Tightly Coupled SIP Conferencing 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. 6. Miscellaneous Requirements MISC-1: A procedure for delegating of a focus role by the current focus to another member MUST be defined. MISC-2: A procedure for requesting a conference focus to transfer its role to another conference member MUST be defined. MISC-3: A procedure for on-demand unconditional transfer of the focus role to a different member MUST be defined. MISC-4: A detection procedure for a conference focus failure condition MUST be defined. MISC-5: In case a conference focus failure, a procedure for assigning a new conference focus MUST be defined. EditorÆs Note: This is a difficult for standardization requirement. 7. 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). O. Levin et al. Expires: May 2003 Page 8 Requirements for Tightly Coupled SIP Conferencing 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. 8. 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. 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. 9. 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) O. Levin et al. Expires: May 2003 Page 9 Requirements for Tightly Coupled SIP Conferencing - 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. 10. Floor Control 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. For detailed floor control requirements refer to [8]. 11. Cascading of Conferences Cascading of conferences can be used for different purposes: - Peer-to-peer chaining of conferencing applications - Hierarchal relations among conferencing applications - Distribution of media "mixers" - Etc. O. Levin et al. Expires: May 2003 Page 10 Requirements for Tightly Coupled SIP Conferencing The three presented applications would result in conceptually different sets of requirements. Currently this work requires further study. 12. Side-bar Conferences The 00 version of this draft suggests that side-bar conversations within a conference are achieved as a part of Media Policy. Currently this work requires further study. 13. SIMPLE and SIP Conferencing Coordination SMPL-1: SIMPLE-based Presence and Instant Messaging architecture SHOULD fit into general SIP Conferencing architecture. SMPL-2: A scenario where a multimedia SIP conference and a multiparty IM conversation takes place among the same group of participants SHOULD be addressed. SMPL-3: A scenario where a side-bar or/and a sub-IM-conference is being held as a part of SIP conference SHOULD be addressed. 14. 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]. 15. Security Considerations Security requirements will be addressed in the next version of this document. 16. 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 O. Levin et al. Expires: May 2003 Page 11 Requirements for Tightly Coupled SIP Conferencing 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 17. 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, "A Framework for Conferencing with the Session Initiation Protocol", draft-rosenberg-sipping-conferencing- framework-00.txt, Oct 2002, 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 Koskelainen/Schulzrinne, "Requirements for Floor Control", draft- koskelainen-mmusic-floor-req-01.txt, Nov 2002. Work in progress. 9 Johnston/Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents,"draft-johnston-sipping-cc- conferencing-00.txt, IETF Draft, Internet Engineering Task Force, Oct. 2002. Work in progress. O. Levin et al. Expires: May 2003 Page 12