summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4245.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4245.txt')
-rw-r--r--doc/rfc/rfc4245.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc4245.txt b/doc/rfc/rfc4245.txt
new file mode 100644
index 0000000..6126931
--- /dev/null
+++ b/doc/rfc/rfc4245.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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:
+
+ - Peer-to-peer chaining of signaling. (Many ways exist to
+ build the media graph in this case.)
+
+ - Conferences have hierarchal signaling relations. (Many ways
+ exists to build the media graph in this case.)
+
+ - "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]
+