[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
   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