GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4245

Network Working Group O. Levin Request for Comments: 4245 Microsoft Corporation Category: Informational R. Even

                                                               Polycom
                                                         November 2005
    High-Level Requirements for Tightly Coupled SIP Conferencing

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document examines a wide range of conferencing requirements for
 tightly coupled SIP conferences.  Separate documents will map the
 requirements to existing protocol primitives, define new protocol
 extensions, and introduce new protocols as needed.  Together, these
 documents will provide a guide for building interoperable SIP
 conferencing applications.

Table of Contents

 1. Introduction ....................................................2
 2. An Overview .....................................................2
 3. High-Level Requirements .........................................3
    3.1. Discovery Phase ............................................3
    3.2. Conference Creation ........................................4
    3.3. Conference Termination .....................................4
    3.4. Participants' Manipulations ................................4
       3.4.1. Participation of a Conference-Unaware User Agent ......5
       3.4.2. Dial-Out Scenarios ....................................5
       3.4.3. Dial-In Scenarios .....................................5
       3.4.4. Third-Party Invitation to a Conference ................6
       3.4.5. Participants' Removal .................................6
       3.4.6. Participants' Privacy .................................6
    3.5. Conference State Information ...............................7
       3.5.1. Description ...........................................7
       3.5.2. Dissemination of Changes ..............................7
       3.5.3. On-demand Information Dissemination ...................8
    3.6. Focus Role Migration .......................................8

Levin & Even Informational [Page 1] RFC 4245 Conferencing Requirements November 2005

    3.7. Side-bar Conferences .......................................8
    3.8. Cascading of Conferences ...................................9
    3.9. SIMPLE and SIP Conferencing Coordination ...................9
 4. Security Considerations ........................................10
 5. Contributors ...................................................10
 6. References .....................................................10
    6.1. Normative References ......................................10

1. Introduction

 This document examines a wide range of conferencing requirements for
 tightly coupled SIP (RFC 3261 [2]) conferencing.
 The requirements are grouped by subjects in various areas allowing
 solutions to progress in parallel.
 Separate documents will map the requirements to existing protocol
 primitives, define new protocol extensions, and introduce new
 protocols as needed.
 Together, these documents will provide a guide for building
 interoperable SIP conferencing applications.
 The terms "MAY", "SHOULD", and "MUST" are to be interpreted as
 described in RFC 2119 [1].

2. An Overview

 A SIP conference is an association of SIP user agents (i.e.,
 conference participants) with a central point (i.e., a conference
 focus), where the focus has direct peer-wise relationships with the
 participants by maintaining a separate SIP dialog with each.
 The focus is a SIP user agent that has abilities to host SIP
 conferences including their creation, maintenance, and manipulation
 using SIP call control means and potentially other non-SIP means.
 In this tightly coupled model, the SIP conference graph is always a
 star.  The conference focus maintains the correlation among
 conference's dialogs internally.
 The conference focus can be implemented either by a participant or by
 a separate application server.
 In the first case, a focus is typically capable of hosting a simple
 ad hoc conference only.  We envision that such basic conference can
 be established using SIP call control primitives only.

Levin & Even Informational [Page 2] RFC 4245 Conferencing Requirements November 2005

 A dedicated conference server, in addition to the basic features,
 offers richer functionality including simultaneous conferences, large
 scalable conferences, reserved conferences, and managed conferences.
 A conferencing server can support any subset of the advanced
 conferencing functions presented in this document.
 The media graph of a SIP conference can be centralized,
 decentralized, or any combination of both, and potentially differ per
 media type.  In the centralized case, the media sessions are
 established between the focus and each one of the participants.  In
 the de-centralized (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
 policy can state that the rights to disconnect from and to invite to
 a conference are limited to the conference chair only.
 Throughout the document, by conference policies we mean a set of
 parameters and rules (e.g., maximum number of participants, needs
 chair-person supervision or not, password protected or not, duration,
 or a way of media mixing) that are defined at the onset of a
 conference.  Typically, conference policies would be specified by a
 conference creator and need special privileges to be manipulated.
 Throughout the document, by a conference state we mean a set of
 information describing the conference in progress.  This includes
 participants' information (such as dialog identifiers), media
 sessions in progress, the current loudest speaker, the current chair,
 etc.

3. High-Level Requirements

 In addition to the requirements presented in this document,
 supplementary requirements for conferencing policy, media mixing and
 other manipulations, floor control, privilege control, etc. will be
 discussed in separate documents.

3.1. Discovery Phase

 Some of the requirements presented in this section can be met either
 by configuration means or by using proprietary conventions.
 Nevertheless, there is consensus that standard means for implementing
 these functions by automata MUST be defined.

Levin & Even Informational [Page 3] RFC 4245 Conferencing Requirements November 2005

 REQ-1: Discovery of a location of an arbitrary SIP conferencing
      server(s).
 REQ-2: Given a SIP Address-of-Record (AOR) of a certain entity,
      resolution whether the SIP entity has focus capabilities.
 REQ-3: Given a global identifier of a particular conference, locating
      the conference focus.
 REQ-4: Given a global identifier of a particular conference,
      obtaining the conference properties.
 REQ-5: Given a global identifier of a particular conference,
      obtaining the conference state information.

3.2. Conference Creation

 Given a focus location, a means MUST be defined for an interested
 entity (including a user agent) to implement the procedures below:
 REQ-1: Creation of an ad-hoc conference identifier and the conference
      with specified properties.
 REQ-2: Creation of a reserved conference identifier for a conference
      with specified properties.
 REQ-3:  Specifying properties upon conference creation in any of the
      following ways: default, profiles, and explicitly.

3.3. Conference Termination

 REQ-1: Given a conference identifier, a means MUST be defined for a
      user agent to disconnect all participants from the conference
      and terminate the conference including the release of the
      associated resources.
 REQ-2: A means MAY be defined for requesting a focus to revert a
      two-party conference to a basic SIP point-to-point session
      including the release of the associated conferencing resources.

3.4. Participants' Manipulations

      Some of the requirements presented in this section can be met by
      human intervention, configuration means, or proprietary
      conventions.  Nevertheless, there is consensus that standard
      means for implementing these functions by automata MUST be
      defined.

Levin & Even Informational [Page 4] RFC 4245 Conferencing Requirements November 2005

3.4.1. Participation of a Conference-Unaware User Agent

 REQ-1: Focus MUST be able to invite and disconnect an RFC 3261
      compliant only SIP user agent to and from a SIP conference.
 REQ-2: An RFC 3261 compliant only SIP user agent MUST be able to
      dial-in to 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 focus to invite another user
      agent to one of the focus' conferences.  This procedure MUST
      result in the establishment of a single SIP dialog between the
      two.
 REQ-2: Given an existing SIP dialog between two user agents, if at
      least one user agent has 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 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 a 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 a participant using a single SIP dialog.
 REQ-3: Given a conference identifier of an active conference, a means
      MUST be defined for a user agent to dial-in the conference and
      to become a 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 a participant.

Levin & Even Informational [Page 5] RFC 4245 Conferencing Requirements November 2005

3.4.4. Third-Party Invitation to a Conference

 REQ-1: Given a conference identifier, a means MUST be defined for a
      user agent to invite another user agent to this conference.
 REQ-2: Given an identifier of one of the dialogs of a particular
      active conference, a means MUST be defined for a user agent to
      invite another user agent to this conference.
 EQ-3: Given a conference identifier, a means SHOULD be defined for a
      user agent to invite a list of user agents to this conference (a
      so-called "mass invitation").

3.4.5. Participants' Removal

 REQ-1: A means MUST be defined for a conference focus to remove a
      conference participant from the conference.
 REQ-2: Given a conference identifier, a means MUST be defined for a
      user agent to remove a participant from the conference.
 REQ-3: Given an identifier of one of the dialogs of a particular
      active conference, a means MUST be defined for a user agent to
      remove a participant from the conference.
 REQ-4: Given a conference identifier, a means MUST be defined for a
      user agent to remove all the participants from the conference.
 REQ-5: Given a conference identifier and a sub-list of participants,
      a means MAY be defined for a user agent to remove the specified
      participants from the conference (a so-called "mass ejection").

3.4.6. Participants' Privacy

 A conference focus SHOULD support the procedures described in this
 section.  A conference participant MAY support the procedures
 described in this section.  The requirements imply that "anonymizing"
 operations MUST be performed on all: the call control, the media
 control, and the media content when appropriate.
 REQ-1: A conference participant joins the conference "anonymously";
      that is, his/her presence can be announced but without
      disclosing his/her identity.
 REQ-2: A conference participant requests a focus for anonymous
      participation in the conference.

Levin & Even Informational [Page 6] RFC 4245 Conferencing Requirements November 2005

 REQ-3: A conference participant joins a conference in a "hidden
      mode"; that is, his/her presence and identity are not to be
      disclosed to other participants.
 REQ-4: A conference participant requests a focus for participation in
      the conference in a hidden mode.

3.5 Conference State 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),
 media sessions in progress (such as current stream contributing
 sources and encoding schemes), the current loudest speaker, the
 current chair, etc.  Conference state is the latest conference
 snapshot triggered by changes in participants' state, conference
 policy changes, etc.
 REQ-1: A conference state virtual database MUST have a modular
      definition that is, it MUST be possible to access different
      conference aspects independently.
 REQ-2: It MUST be possible to aggregate information relating to
      different conference aspects in a single report.
 REQ-3: A mechanism for extensible definition and registration of
      conference state evolving aspects MUST be present.
 REQ-4: A default conference state report MUST be defined.  It SHOULD
      contain a minimal useful set of information (e.g., a list of
      current conference participants).

3.5.2. Dissemination of Changes

 REQ-1: A means MUST be defined for reporting the conference state
      changes to interested parties (including non-conference
      participants) in a timely manner.
 REQ-2: A means MUST be defined for a SIP user agent to express its
      interest in selected state changes only.
 REQ-3: A means MUST be defined for a SIP user agent to express the
      minimum interval between receiving state change reports.
 REQ-4: It MUST be possible to aggregate recent changes in a single
      reporting event.

Levin & Even Informational [Page 7] RFC 4245 Conferencing Requirements November 2005

 REQ-5: Default conference state change reports MUST be defined.  They
      SHOULD contain minimal useful to the participants information
      (e.g., participants' joining and leaving the conference).

3.5.3. On-demand Information Dissemination

 REQ-1: A means MUST be defined to disseminate any conference state
      information to interested parties (including SIP user agents)
      on-demand.
 REQ-2: A means MUST be defined for an interested party (including a
      SIP user agent) to request conference state information of a
      particular conference defined by the conference identifier.
 REQ-3: A means MUST be defined for an interested party (including a
      SIP user agent) to specify the subset of the conference state
      information it wants and is capable of receiving.

3.6. Focus Role Migration

 REQ-1: A procedure for delegating a focus role by the current focus
      to another participant MUST be defined.
 REQ-2: A procedure for requesting a conference focus to transfer its
      role to another participant MUST be defined.
 REQ-3: A procedure for on-demand unconditional transfer of the focus
      role to a different participant MUST be defined.
 REQ-4: A detection procedure for a focus failure condition MUST be
      defined.

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 participant) joins a side-bar
      within the conference by SIP means.
 REQ-2: A user agent (not a conference participant) is invited to a
      side-bar within the conference by SIP means.
 REQ-3: A conference participant creates a side-bar conference with
      one or more participants in a conference by SIP means.
 REQ-4: A conference participant joins a side-bar within the
      conference by SIP means.

Levin & Even Informational [Page 8] RFC 4245 Conferencing Requirements November 2005

 REQ-5: A conference participant is invited to a side-bar within the
      conference by SIP means.
 REQ-6: A conference-unaware user agent (a participant or not) creates
      and participates in side-bar conferences.  It MAY be achieved by
      non-SIP means.
 REQ-7: A conference participant creates side-bar conferences within
      the conference without establishing any additional SIP dialogs
      with the focus.  It MAY be achieved by non-SIP means.
 REQ-8: A conference participant joins any number of side-bars within
      the conference without establishing any additional SIP dialogs
      with the focus.  It MAY be achieved by non-SIP means.
 REQ-9: A conference participant is invited to any number of side-bars
      within the conference without establishing any additional SIP
      dialogs with the focus.  It MAY be achieved by non-SIP means.

3.8. Cascading of Conferences

 "Cascading of Conferences" is a term that has different meanings in
 different contexts.  Some examples are listed below:
  1. Peer-to-peer chaining of signaling. (Many ways exist to

build the media graph in this case.)

  1. Conferences have hierarchal signaling relations. (Many ways

exists to build the media graph in this case.)

  1. "Cascading" is used to distribute the media "mixing" only.

The distribution of signaling is not required.

 As it can be seen from the examples, each will define a different set
 of requirements.

3.9. SIMPLE and SIP Conferencing Coordination

 REQ-1: SIMPLE-based Presence and Instant Messaging architecture
      SHOULD fit into the general SIP Conferencing architecture.
 REQ-2: A scenario where a multimedia SIP conference and a multiparty
      instant messaging conversation take place among the same group
      of participants MUST be addressed.
 REQ-3: A scenario where a side-bar and/or a sub-IM-conference is
      being held as a part of SIP conference MUST be addressed.

Levin & Even Informational [Page 9] RFC 4245 Conferencing Requirements November 2005

4. Security Considerations

 This document discusses high-level requirements for SIP conferencing.
 Conferencing has some specific security requirements, which will be
 summarized here at a very high level.
 All of the operations and functions described in this document need
 to be authorized by a focus or a participant.  It is expected that
 conferences will be governed by a set of authorization rules defined
 as a part of the conference policy.  In order for the conference
 policy to be implemented, the focus needs to be able to authenticate
 potential participants.  Normal SIP mechanisms including Digest
 authentication and certificates can be used [2].  These conference-
 specific security requirements will be discussed in detail in the
 protocol documents.
 Conferencing also has privacy implications.  Some of these are
 discussed in this document.  Standard SIP mechanisms for a user agent
 to request privacy should be utilized by a focus and will be detailed
 in the protocol documents.

5. Contributors

 This work is based on the discussions among the members of the SIP
 Conferencing design team.

6. References

6.1. Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.

Levin & Even Informational [Page 10] RFC 4245 Conferencing Requirements November 2005

Authors' Addresses

 Orit Levin
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA  98052
 EMail: oritl@microsoft.com
 Roni Even
 Polycom
 94 Derech Em Hamoshavot
 Petach Tikva, Israel
 EMail: roni.even@polycom.co.il

Levin & Even Informational [Page 11] RFC 4245 Conferencing Requirements November 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Levin & Even Informational [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4245.txt · Last modified: 2005/11/18 21:48 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki