doc: Add RFC documents

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]
+