[-Internet Draft-] {+SIPPING Working Group+} O. [-Levin/RADVISION Document: R. Even/Polycom draft-levin-sipping-conferencing- P. Koskelainen/Columbia U. requirements-02.txt S. Sen/Nortel November 2002-] {+Levin Internet-Draft RADVISION+} Expires: [-May-] {+August 31, 2003 R. Even Polycom March 2,+} 2003 {+High Level+} Requirements for Tightly Coupled SIP Conferencing {+draft-levin-sipping-conferencing-requirements-03+} 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.+} 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".-] {+progress."+} The list of current Internet-Drafts can be accessed at [-http://www.ietf.org/ietf/1id-abstracts.txt-] {+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. {+This Internet-Draft will expire on August 31, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.+} Abstract This document examines a wide range of conferencing requirements [-being applied to a-] {+for+} tightly coupled SIP [-Star conference.-] {+conferences.+} Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new [-protocols.-] {+protocols as needed.+} Together, these documents [-would-] {+will+} provide a guide for building interoperable SIP conferencing applications. [-O.-] Levin [-et al. Expires: May-] {+& Even Expires August 31,+} 2003 [-Page 1-] {+[Page 1] Internet-Draft HL+} Requirements for [-Tightly Coupled-] SIP Conferencing {+March 2003+} Table of Contents 1. [-SCOPE............................................................3-] {+Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3+} 2. [-TIGHTLY COUPLED SIP CONFERENCING FRAMEWORK.......................3-] {+An Overview . . . . . . . . . . . . . . . . . . . . . . . . 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.-] {+High Level Requirements . . . . . . . . . . . . . . . . . . 4 3.1 Discovery Phase . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Conference Creation . . . . . . . . . . . . . . . . . . . . 5 3.3 Conference Termination . . . . . . . . . . . . . . . . . . . 5 3.4 Participants’ Manipulations . . . . . . . . . . . . . . . . 5 3.4.1 Participation of a Conference-unaware User Agent . . . . . . 5 3.4.2 Dial-Out Scenarios . . . . . . . . . . . . . . . . . . . . . 6 3.4.3 Dial-In Scenarios . . . . . . . . . . . . . . . . . . . . . 6 3.4.4 Third Party Invitation to a Conference . . . . . . . . . . . 6 3.4.5 Participants’ Removal . . . . . . . . . . . . . . . . . . . 7 3.4.6 Participants’ Privacy . . . . . . . . . . . . . . . . . . . 7 3.5 Conference State Information . . . . . . . . . . . . . . . . 7 3.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5.2 Dissemination of Changes . . . . . . . . . . . . . . . . . . 8 3.5.3 On-demand Information Dissemination . . . . . . . . . . . . 8 3.6 Focus Role Migration . . . . . . . . . . . . . . . . . . . . 9 3.7 Side-bar Conferences . . . . . . . . . . . . . . . . . . . . 9 3.8 Cascading of Conferences . . . . . . . . . . . . . . . . . . 10 3.9+} SIMPLE [-AND-] {+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.-] {+Conferencing Coordination . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . 10 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . 12+} Levin [-et al. Expires: May-] {+& Even Expires August 31,+} 2003 [-Page 2-] {+[Page 2] Internet-Draft HL+} Requirements for [-Tightly Coupled-] SIP Conferencing {+March 2003+} 1. Scope This document examines a wide range of conferencing requirements [-being applied to a-] {+for+} tightly coupled SIP [-Star conference.-] {+(RFC 3261 [2]) conferencing.+} The requirements are grouped [-according to their topics-] {+by subjects+} in [-order to define-] {+various areas allowing+} solutions to [-different topics-] {+progress+} in parallel. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new [-protocols.-] {+protocols as needed.+} Together, these documents [-would-] {+will+} provide a guide for building interoperable SIP conferencing applications. 2. [-Tightly Coupled SIP Conferencing Framework-] {+An Overview A+} SIP conference is an association of SIP [-User Agents (e.g.-] {+user agents (i.e.+} conference [-members)-] {+participants)+} with a central [-member (e.g.-] {+point (i.e.+} a conference [-focus), which-] {+focus) where the focus+} has a direct peer-wise relationship with each [-other member-] {+participant+} by means of a SIP dialog. Each dialog can belong to a different SIP session. [-Focus-] {+The focus+} is a SIP [-UA-] {+user agent+} which has abilities to host SIP conferences including [-its-] {+their+} creation, [-maintenance-] {+maintenance,+} and manipulation using SIP call control {+means and potentially other non-SIP+} means. In this [-framework,-] {+tightly coupled model,+} 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-] {+focus+} can be [-hosted-] {+implemented+} either by a [-participating entity (e.g. terminal)-] {+participant+} or by a separate application server. [-Typically to-] {+In+} the first case, a [-terminal-] {+focus+} is {+typically+} capable of hosting a [-limited ad hoc conference. Such-] {+simple ad-hoc+} conference [-may-] {+only. We envision that such basic conference can+} be established using [-basic-] {+SIP+} call control [-primitives. EditorÆs Note: This is similar to traditional offering from PSTN service providers-] {+primitives only. A dedicated conference server,+} in [-audio conferencing such as being able-] {+addition+} to [-join independent calls into a multiparty conference. Application server-] {+the basic features,+} offers [-more robust options-] {+richer functionality+} including [-reservation,-] {+simultaneous conferences,+} large {+scalable conferences, reserved+} 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-] {+A+} conferencing server [-supports-] {+can support+} any subset of {+the+} advanced conferencing [-features,-] {+functions+} presented in this document. {+The media graph of a SIP conference can be centralized, de-centralized, or any combination of both and potentially differ per media type.+} In [-this-] {+centralized+} case, the {+media sessions are established between the+} focus [-is-] {+and each+} one of the [-logical entities comprising-] {+participants. In de-centralized Levin & Even Expires August 31, 2003 [Page 3] Internet-Draft HL Requirements for SIP Conferencing March 2003 (i.e. distributed) case, the media graph is a (multicast or multi-unicast) mesh among the participants. Consequently, the media processing (e.g. mixing) can be performed either by the focus alone or by+} the {+participants. Conference participants and third parties can have different roles and privileges in a certain conference. For example,+} conferencing [-application server. The-] {+policy can state that the rights to disconnect from and to invite to a+} conference [-properties-] are [-defined-] {+limited to the conference chair only. Throughout the document,+} by {+conference policies we mean+} a [-list-] {+set+} of [-configuration-] parameters [-(e.g.,-] {+and rules (e.g.+} maximum number of [-ports/participants,-] {+participants,+} needs [-chair- person-] {+chair-person+} supervision or not, password protected or not, duration, {+a way of media mixing,+} etc.) that [-a conference creator can request from the conference service. Conference properties-] are [-configured-] {+defined+} at the onset of a {+conference. Typically, conference policies would be specified by a+} conference [-and, typically,-] {+creator and+} need special privileges to be [-changed. Conference participants MAY have different roles or privileges in a conference. For example,-] {+manipulated. Throughout the document, by+} a conference [-Chair MAY have the right to disconnect users from-] {+state we mean+} a [-conference, or terminate-] {+set of information describing+} the [-conference. SIP-] conference [-MAY have-] {+in progress. This includes participants’ information (such as dialog identifiers),+} 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-] {+in progress,+} the [-star graph of-] {+current loudest speaker,+} 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-] {+current chair, etc. 3. High Level Requirements In addition to+} the {+requirements presented in this document, supplementary requirements for conferencing policy,+} media [-processing can-] {+mixing and other manipulations, floor control, privileges control, etc. will+} be [-performed either by the conference focus alone or by each one of the participating entities. 3.-] {+discussed in separate documents. 3.1+} Discovery Phase [-Requirements SIP Entity Conferencing Capabilities Discovery EditorÆs Note: The following-] {+Some of the+} requirements {+presented in this section+} can [-always-] be [-achieved-] {+met either+} by configuration means [-or/and human agreement.-] {+or by using proprietary conventions.+} Nevertheless, we feel that [-automatic means MUST be defined. CAPD-1: A-] standard means {+for implementing these functions by automata+} MUST be [-defined for automatic discovery-] {+defined. REQ -1: Discovery+} of {+a+} location of {+an arbitrary SIP+} 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-] {+Editor’s Note: No solution currently exists. REQ -2: Given+} a [-conference focus. CAPD-3: A standard means MUST be defined for retrieving conferencing capabilities-] {+SIP AOR+} of a [-known SIP entity. In this regard,-] {+certain entity, resolution whether+} 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:-] {+has focus capabilities. Editor’s Note: No solution currently exists. REQ -3:+} 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-] {+& Even Expires August 31,+} 2003 [-Page 4-] {+[Page 4] Internet-Draft HL+} Requirements for [-Tightly Coupled-] SIP Conferencing [-CNFD-2:-] {+March 2003 locating the conference focus. REQ -4:+} Given a global identifier of a particular conference, [-a standard means MUST be defined for-] obtaining the conference properties. [-CNFD-3:-] {+REQ -5:+} 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-] {+3.2 Conference Creation Given a+} focus [-MUST be able to invite and disconnect an RFC 3261 compliant only SIP UA to and from-] {+location,+} a [-SIP conference. BSC-2: RFC 3261 compliant only SIP UAÆs-] {+means+} MUST be [-able to dial-in-] {+defined for an interested entity (including+} a [-particular SIP conference. In this case, only the-] user [-behind its UA knows that he dials into-] {+agent) to implement+} the [-conference. EditorÆs Note: In this case,-] {+procedures below: REQ -1: Creation of an ad-hoc conference identifier and+} the conference [-can be identified either by manually populating the Request-URI field-] with {+default properties. REQ -2: Creation of an ad-hoc conference identifier and+} the conference {+with particular properties. REQ -3: Creation of a reserved conference+} identifier [-or, alternatively, by using an IVR service.-] {+for a conference with default properties. REQ -4: Creation of a reserved conference identifier for a conference with particular properties. 3.3+} Conference [-Establishment in Dial-Out Scenarios DOUT-1: A-] {+Termination REQ -1: Given a conference identifier, a+} means MUST be defined for a [-conference focus to invite a User Agent-] {+user agent+} to [-one of its active conferences (specified by a-] {+disconnect all participants from the+} conference [-identifier) over an existing SIP dialog between-] {+and terminate+} the [-two. As a result,-] {+conference including+} the [-dialog becomes a part-] {+release+} of the [-conference. DOUT-2:-] {+associated resources. REQ -2:+} A means [-MUST-] {+MAY+} be defined for {+requesting+} a [-conference-] focus to [-invite-] {+revert+} a [-User Agent by establishing-] {+two-party conference to+} a [-new-] {+basic+} SIP [-dialog between the two together with specifying-] {+point-to-point session including+} the [-identifier-] {+release+} of the [-conference. The dialog belongs to-] {+associated conferencing resources. 3.4 Participants’ Manipulations Some of+} the [-conference. Conference Establishment-] {+requirements presented+} 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-] {+this section can+} be [-defined for a UA to create an ad-hoc conference and to become its member. A-] {+met by human intervention, configuration means, or by using proprietary conventions. Nevertheless, we feel that standard+} means {+for implementing these functions by automata+} MUST be [-defined for creating a global conference identifier for this ad- hoc scenario. DIN-2: Provided a reserved conference identifier,-] {+defined. 3.4.1 Participation of+} a [-means-] {+Conference-unaware User Agent REQ -1: Focus+} MUST be [-defined for a UA-] {+able+} to [-activate the conference-] {+invite+} and {+disconnect an RFC 3261 compliant only SIP user agent+} to [-become its member. O.-] {+and from a SIP conference.+} Levin [-et al. Expires: May-] {+& Even Expires August 31,+} 2003 [-Page 5-] {+[Page 5] Internet-Draft HL+} Requirements for [-Tightly Coupled-] SIP Conferencing [-DIN-3: Provided a reserved conference identifier,-] {+March 2003 REQ -2: RFC 3261 compliant only SIP user agent MUST be able to dial-in+} a {+particular SIP conference. In this case, only the human knows that he/she is connected to the conference. 3.4.2 Dial-Out Scenarios REQ -1: A+} means MUST be defined for a [-UA-] {+focus+} to [-dial-in an active conference and-] {+invite another user agent+} to [-become its member. DIN-4: Provided-] one of the [-dialogs ID, belonging-] {+focus’ conferences. This procedure MUST result in establishing of a single SIP dialog between the two. REQ -2: Given an existent SIP dialog between two user agents, where at least one with focus capabilities, a means MUST be defined for the conference focus to invite the other user agent to one of the focus’ conferences without additional SIP dialog establishment. REQ -3: An invitation+} to a [-particular-] {+user agent to join a conference MUST include a standard indication that it is "a conference" and the conference identifier. 3.4.3 Dial-In Scenarios REQ -1: A means MUST be defined for a user agent to create an ad-hoc conference with default properties (as per "Conference Creation" REQ -1 above) and to become its participant using a single SIP dialog. REQ -2: Given a reserved conference identifier, a means MUST be defined for a user agent to activate the conference and to become its participant using a single SIP dialog. REQ -3: Given a conference identifier of an+} active conference, a means MUST be defined for a [-UA-] {+user agent+} to dial-in {+the conference and to become its participant using a single SIP dialog between the two. REQ -4: Given+} an {+identifier of one of the dialogs of a particular+} active {+conference, a means MUST be defined for a user agent to dial-in the+} conference and to become its [-member.-] {+participant. 3.4.4+} Third Party Invitation to a Conference [-THIP-1: Provided-] {+REQ -1: Given+} a conference identifier, a means MUST be defined for a [-UA-] {+user agent+} to invite another [-UA-] {+user agent+} to this conference. [-THIP-2: Provided-] {+REQ -2: Given an identifier of+} one of the dialogs [-ID, belonging to-] {+of+} a particular active conference, a means MUST be defined for a [-UA-] {+user agent+} to invite another [-UA-] {+user agent+} to this conference. [-THIP-3: Provided-] {+REQ -3: Given+} a conference identifier, a means [-MAY-] {+SHOULD+} be defined for a [-UA-] {+user agent+} to invite a list of [-UAs-] {+user agents+} to this conference (a {+Levin & Even Expires August 31, 2003 [Page 6] Internet-Draft HL Requirements for SIP Conferencing March 2003+} so-called "mass invitation"). [-Disconnection of Conference Members and Conference Termination TERM-1:-] {+3.4.5 Participants’ Removal REQ -1:+} A means MUST be defined for a conference focus to [-disconnect-] {+remove+} a conference [-member-] {+participant+} from [-an active-] {+the+} 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-] {+REQ -2: Given+} a conference identifier, a means MUST be defined for a [-UA-] {+user agent+} to [-disconnect another UA-] {+remove a participant+} from [-this-] {+the+} conference. [-TERM-4: Provided-] {+REQ -3: Given an identifier of+} one of the dialogs [-ID, belonging to-] {+of+} a particular active conference, a means [-MAY-] {+MUST+} be defined for a [-UA-] {+user agent+} to [-disconnect another UA-] {+remove a participant+} from [-this-] {+the+} conference. [-TERM-5: Provided-] {+REQ -4: Given+} a conference identifier, a means [-MAY-] {+MUST+} be defined for a [-UA-] {+user agent+} to [-disconnect a list of UAs-] {+remove all the participants+} 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-] {+the+} conference. [-TERM-7: Provided-] {+REQ -5: Given+} a conference [-identifier,-] {+identifier and a sub-list of participants,+} a means MAY be defined for a [-UA-] {+user agent+} to [-terminate this conference by disconnection all-] {+remove+} the [-members, releasing conference resources together with-] {+specified participants from+} 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-] {+(a so-called "mass ejection"). 3.4.6 Participants’+} Privacy [-The following features depend both on focusÆs capabilities and policies and on membersÆ capabilities.-] A conference focus SHOULD support [-these.-] {+the procedures described in this section.+} A conference [-member-] {+participant+} MAY support [-these. PRV-1:-] {+the procedures described in this section. REQ -1:+} A conference [-member participates in a-] {+participant joins the+} conference "anonymously", [-meaning that its-] {+i.e. his/her+} presence [-is known and-] can be announced but without disclosing [-its-] {+his/her+} identity. [-PRV-2:-] {+REQ -2:+} A conference [-member-] {+participant+} requests {+a focus for+} anonymous participation [-from-] {+in+} the [-focus. PRV-3:-] {+conference. REQ -3:+} A conference [-member participates in-] {+participant joins+} a conference [-"in-] {+in+} a [-hidden-] {+"hidden+} mode", [-meaning that-] {+i.e. his/her+} both [-its-] presence and [-its-] identity are not [-disclosed. PRV-4:-] {+to be disclosed to other participants. REQ -4:+} A conference [-member-] {+participant+} requests {+a focus for+} participation in {+the conference in+} a hidden mode. [-5.-] {+3.5+} Conference State [-Dissemination-] {+Information 3.5.1 Description By a conference state we mean a virtual database describing the conference in progress. This includes different conference aspects - participants’ information (such as dialog identifiers and state), Levin & Even Expires August 31, 2003 [Page 7] Internet-Draft HL+} Requirements [-Report of Changes CNG-1: It-] {+for SIP Conferencing March 2003 media sessions in progress (such as current stream contributing sources and encoding schemes), the current loudest speaker, the current chair, etc. Conference state+} is [-expected that-] the [-set of events related a-] {+latest conference snapshot triggered by changes in participants’ state,+} conference {+policy changes, etc. REQ -1: Conference+} state [-and required-] {+virtual database MUST have a modular definition, i.e. it MUST be possible+} to {+access different conference aspects independently. REQ -2: It MUST+} be [-reported would grow with time. Therefore,-] {+possible to aggregate information relating to different conference aspects in+} a {+single report. REQ -3: A+} mechanism for extensible [-definition/registration-] {+definition and registration+} of [-new-] conference state [-changes-] {+elements MUST be present. REQ -4: A default minimal conference state+} MUST be defined. [-CNG-2:-] {+It SHOULD include a list of current conference participants only. 3.5.2 Dissemination of Changes REQ -1:+} A means MUST be defined for reporting the conference state changes to interested parties (including conference [-members)-] {+participants)+} in a timely manner. [-The report MAY include more than one change. CNG-3:-] {+REQ -2:+} A means MUST be defined for a SIP [-UA-] {+user agent+} to express its interest in selected state changes only. [-CNG-4:-] {+REQ -3:+} A means MUST be defined for a SIP [-UA-] {+user agent+} to express the minimum interval between receiving state change reports. [-A means-] {+REQ -4: It+} MUST be [-defined for reporting at least the following-] {+possible to aggregate recent+} changes in a [-conference state: CNG-5:-] {+single reporting event. REQ -5:+} A [-new-] {+default minimal+} conference [-member joined-] {+state changes MUST be defined. They SHOULD include events about participants’ joining and leaving+} the [-conference. CNG-6: A Particular-] conference [-member left the conference.-] {+only. 3.5.3+} On-demand {+Information+} Dissemination [-O. Levin et al. Expires: May 2003 Page 7 Requirements for Tightly Coupled SIP Conferencing ODD-1:-] {+REQ -1:+} A means MUST be defined to disseminate any conference state information [-(as per [5])-] to interested parties [-(i.e.-] {+(including+} SIP [-UAs) on- demand. ODD-2:-] {+user agents) on-demand. REQ -2:+} A means MUST be defined for [-a-] {+an interested party (including+} SIP [-UA-] {+user agents)+} to request [-a-] conference state information of a particular conference defined by the conference identifier. [-ODD-3:-] {+Levin & Even Expires August 31, 2003 [Page 8] Internet-Draft HL Requirements for SIP Conferencing March 2003 REQ -3:+} A means MUST be defined for [-a-] {+an interested party (including+} SIP [-UA-] {+user agents)+} to specify the subset of the conference state information, it wants and capable to receive. [-6. Miscellaneous Requirements MISC-1:-] {+3.6 Focus Role Migration Editor’s Note: We should decide whether the requirements below can be met by using SIP or non-SIP means. REQ -1:+} A procedure for delegating [-of-] a focus role by the current focus to another [-member-] {+participant+} MUST be defined. [-MISC-2:-] {+REQ -2:+} A procedure for requesting a conference focus to transfer its role to another [-conference member-] {+participant+} MUST be defined. [-MISC-3:-] {+REQ -3:+} A procedure for on-demand unconditional transfer of the focus role to a different [-member-] {+participant+} MUST be defined. [-MISC-4:-] {+REQ -4:+} A detection procedure for a [-conference-] focus failure condition MUST be defined. [-MISC-5: In case-] {+3.7 Side-bar Conferences A standard means MUST be defined in order to implement the operations defined in this section below. REQ -1: A user agent (not+} a conference [-focus failure,-] {+participant) joins+} a [-procedure for assigning-] {+side-bar within the conference by SIP means. REQ -2: A user agent (not+} a [-new-] conference [-focus MUST be defined. EditorÆs Note: This-] {+participant)+} is {+invited to+} 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-] {+side-bar within+} the conference [-Server and a-] {+by SIP means. REQ -3: A conference+} participant {+creates a side-bar conference with one or more participants+} in a conference [-MUST have-] {+by SIP means. REQ -4: A conference participant joins+} a [-unique identity in-] {+side-bar within+} the conference [-space MEDI-2: It MUST be possible for a user-] {+by SIP means. REQ -5: A conference participant is invited+} to [-participate in a sub-set of media sessions of-] a {+side-bar within the+} conference [-MEDI-3:-] {+by SIP means. REQ -6: A conference-unaware user agent (a participant or not) creates and participates in side-bar conferences.+} It [-MUST-] {+MAY+} be [-possible to modify media sessions of certain subset of-] {+achieved by non-SIP means. REQ -7: A conference participant creates side-bar conferences within+} the [-participants-] {+conference+} without [-impacting-] {+establishing any additional SIP dialogs with+} the [-sessions of other participants (e.g., introduce side-bar conversations between two participants). MEDI-4:-] {+focus.+} It [-MUST-] {+MAY+} be [-possible to modify a subset of the media sessions of a participant during the conference (e.g., swap in and out video). O.-] {+achieved by non-SIP means.+} Levin [-et al. Expires: May-] {+& Even Expires August 31,+} 2003 [-Page 8-] {+[Page 9] Internet-Draft HL+} Requirements for [-Tightly Coupled-] SIP Conferencing [-MEDI-5:-] {+March 2003 REQ -8:+} A [-media session of a-] {+conference+} participant [-MUST be in one-] {+joins any number+} of {+side-bars within+} the [-following states: - Inactive : SDP attribute=inactive - Active : opposite of inactive - On-hold : SDP attribute=sendonly - Disabled : media port = 0 MEDI-6:-] {+conference without establishing any additional SIP dialogs with the focus.+} It [-MUST-] {+MAY+} be [-possible for the-] {+achieved by non-SIP means. REQ -9: A+} conference [-server-] {+participant is invited+} to [-mix a sub- set-] {+any number+} of {+side-bars within+} the [-active media sessions in a-] conference [-(e.g., mix audio from two most audible speakers). MEDI-7:-] {+without establishing any additional SIP dialogs with the focus.+} It [-SHOULD-] {+MAY+} be [-possible for-] {+achieved by non-SIP means. 3.8 Cascading of Conferences "Cascading of Conferences" is+} 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-] {+term that has different meanings in different contexts. Some examples are listed below: - Peer-to-peer chaining+} of {+signaling. (Many ways exist to build+} the [-Access Control List is-] {+media graph in this case.) - Conferences have hierarchal signaling relations. (Many ways exists+} to [-define who-] {+build the media graph in this case.) - "Cascading"+} is [-allowed (or not allowed)-] {+used+} to [-join-] {+distribute+} the [-conference. If there is userÆs join attempt, but user-] {+media "mixing" only. The distribution of signaling+} is not [-in the ACL then (depending on the conference policy), the conference chair MAY be consulted whether the user-] {+required. As it+} can be [-accepted to join-] {+seen from+} the [-conference. ACL-1: There MUST be a mechanism to-] {+examples, each will+} 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-] {+set of requirements. Editor’s Note: We need to discuss which+} of [-participants exist:-] the [-conference Chair (with all-] {+architectures require our attention as a part of+} the [-privileges),-] {+SIP conferencing force. 3.9 SIMPLE+} 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-] {+SIP Conferencing Coordination REQ -1: SIMPLE-based Presence and Instant Messaging architecture SHOULD fit into the+} 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-] {+SIP Conferencing architecture. REQ -2: A scenario where a multimedia SIP+} conference and a multiparty IM conversation [-takes-] {+take+} place among the same group of participants [-SHOULD-] {+MUST+} be addressed. [-SMPL-3:-] {+REQ -3:+} A scenario where a side-bar or/and a sub-IM-conference is being held as a part of SIP conference [-SHOULD-] {+MUST+} 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.-] {+4.+} Security Considerations [-Security requirements will-] {+Editor’s Note: Will+} be [-addressed-] {+provided+} in the next version of [-this-] {+the+} 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-] {+5. Contributors This work is based on the discussions among the members of the+} 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.-] {+design team. Normative+} References [-1-] {+[1]+} Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [-2 J.-] {+Levin & Even Expires August 31, 2003 [Page 10] Internet-Draft HL Requirements for SIP Conferencing March 2003 [2]+} Rosenberg, [-H. Schulzrinne et al.,-] {+J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,+} "SIP: Session Initiation Protocol", RFC [-3261. 3 J. Rosenberg, "A Framework-] {+3261, June 2002. Informative References Authors' Addresses Orit Levin RADVISION 266 Harristown Road Glen Rock, NJ 75024 EMail: orit@radvision.com Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva, Israel EMail: roni.even@polycom.co.il Levin & Even Expires August 31, 2003 [Page 11] Internet-Draft HL Requirements+} for {+SIP+} Conferencing [-with the Session Initiation Protocol", draft-rosenberg-sipping-conferencing- framework-00.txt, Oct 2002,-] {+March 2003 Intellectual Property Statement The+} IETF [-Draft. Work-] {+takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described+} 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-] {+this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights+} in [-progress. 5 J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package-] {+standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available+} for [-Conference State", draft-ietf-sipping- conference-package-00.txt, June 2002,-] {+publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the+} 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,-] {+Secretariat. The+} IETF [-Draft. Work-] {+invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 [-progress. 7 Camarillo/Holler/Eriksson/Schulzrinne, "Grouping-] {+its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction+} of [-m lines-] {+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 [-SDP", draft-ietf-mmusic-fid-06.txt, Feb 2002, IETF Draft. Work-] {+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 [-progress. 8 Koskelainen/Schulzrinne, "Requirements-] {+which case the procedures+} for [-Floor Control", draft-