doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc7082.txt b/doc/rfc/rfc7082.txt
new file mode 100644
index 0000000..3a24862
--- /dev/null
+++ b/doc/rfc/rfc7082.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    R. Shekh-Yusef
+Request for Comments: 7082                                         Avaya
+Category: Informational                                        M. Barnes
+ISSN: 2070-1721                                                  Polycom
+                                                           December 2013
+
+
+                 Indication of Conference Focus Support
+     for the Centralized Conferencing Manipulation Protocol (CCMP)
+
+Abstract
+
+   The Centralized Conferencing Manipulation Protocol (CCMP) document
+   (RFC 6503) defines a way for a client to discover a conference
+   control server that supports CCMP.  However, it does not define a way
+   for a client involved in a conference to determine if the conference
+   focus supports CCMP.  This information would allow a CCMP-enabled
+   client that joins a conference using SIP to also register for the
+   Centralized Conferencing (XCON) conference event package and take
+   advantage of CCMP operations on the conference.
+
+   This document describes two mechanisms, depending upon the need of
+   the User Agent (UA), to address the above limitation.  The first
+   mechanism uses the Call-Info header field, and the second mechanism
+   defines a new value for the "purpose" header field parameter in the
+   <service-uris> element in the SIP conferencing event package.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7082.
+
+
+
+
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 1]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................3
+   2. Solutions .......................................................3
+      2.1. Call-Info ..................................................3
+      2.2. Service URI Purpose ........................................4
+   3. Overall Process .................................................5
+   4. Security Considerations .........................................5
+   5. IANA Considerations .............................................6
+      5.1. Call-Info Purpose Registration .............................6
+      5.2. URI Purpose Registration ...................................6
+   6. Acknowledgments .................................................6
+   7. Normative References ............................................7
+   Appendix A. Other Approaches Considered ............................9
+      A.1. Feature Tag ................................................9
+      A.2. Conference URI Purpose .....................................9
+
+1.  Introduction
+
+   RFC 5239 [RFC5239] defines a framework for Centralized Conferencing
+   (XCON), which allows participants to exchange media in a centralized
+   unicast conference.  The framework also outlines a set of
+   conferencing protocols for building advanced conferencing
+   applications.
+
+   The Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503]
+   allows authenticated and authorized users to create, manipulate, and
+   delete conference objects.  Operations on conferences include adding
+   and removing participants and changing their roles, as well as adding
+   and removing media streams and associated end points.
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 2]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+   CCMP defines a way for an XCON-aware client to discover whether a
+   conference control server supports CCMP.  However, it does not define
+   a way for a SIP client involved in a conference to determine if the
+   conference focus [RFC4353] supports CCMP.  Knowing that a focus
+   supports CCMP would allow a SIP client (that is also XCON aware) that
+   joins a conference using SIP-based conferencing [RFC4579] to also
+   register for the XCON conference event package [RFC6502] and take
+   advantage of CCMP operations on the conference.
+
+   This document describes two options to address the above limitation,
+   depending on the need of the User Agent (UA).  The first option uses
+   the Call-Info [RFC3261] header, which is suitable for application
+   servers that need to discover if a UA supports CCMP.  The second
+   option defines a new value for the "purpose" header field parameter
+   in the <service-uris> element in the SIP conferencing event package
+   [RFC4575] that is suitable for a UA that would typically subscribe to
+   the conference event package.
+
+   Appendix A has a brief description of other options that we
+   considered as possible solutions.  Those other options were not
+   selected, however, because the options described in this document
+   better address the problem we are trying to solve.
+
+1.1.  Terminology
+
+   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 [RFC2119].
+
+2.  Solutions
+
+   This section defines two mechanisms that can be used by a SIP UA to
+   discover whether the conference that a client has joined, per the SIP
+   signaling procedures defined in [RFC4579], supports CCMP.
+   Specifically, the mechanisms allow the client to know that the URI
+   representing the conference focus, as defined in [RFC4579], is an
+   XCON-URI as defined in [RFC6501].
+
+2.1.  Call-Info
+
+   This approach uses the Call-Info header in various requests and
+   responses.
+
+   The Call-Info header consists of two parts: a URI and a "purpose"
+   header field parameter.  The URI provides the XCON-URI of the
+   conference focus, and a new value for the "purpose" header field
+   parameter indicates that the conference focus supports CCMP.
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 3]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+   While the XCON-URI by itself should be enough to indicate that the
+   conference focus supports CCMP, the "purpose" header field parameter
+   with a value of 'ccmp' provides an easier way for a UA that does not
+   use the conference event package to discover that the conference
+   focus supports CCMP, without parsing the URI.
+
+   The Call-Info header, with the XCON-URI and the "purpose" header
+   field parameter with the 'ccmp' value, can be used with any INVITE
+   request or response and with a response to an OPTIONS request.
+
+   This approach would be suitable for a UA, e.g., an application server
+   that acts as a Back-to-Back User Agent (B2BUA), that is interested in
+   discovering that a conference focus supports CCMP but does not use
+   the XCON conference event package [RFC6502].  In this case, the
+   application could use the OPTIONS request and discover CCMP support
+   from the response.
+
+   This approach would also be suitable for a conference focus that
+   initiates an INVITE request to a SIP UA to add a participant to a
+   conference, as it would allow the conference focus to indicate that
+   it supports CCMP with the INVITE request sent to the UA.
+
+   The advantage of this approach is the ability to discover that a
+   conference focus supports CCMP, without subscribing to the XCON event
+   package [RFC6502].  The disadvantage is the need, in some cases, for
+   an extra request, i.e., an additional OPTIONS request, to discover
+   that a conference focus supports CCMP.
+
+2.2.  Service URI Purpose
+
+   This approach defines an additional URI 'purpose' of 'ccmp'
+   associated with a <service-uris> element in the SIP conferencing
+   event package.  The XCON-URI for the conference is included in the
+   'uri' element, per the following example:
+
+      <service-uris>
+        <entry>
+          <uri>XCON:conf1@example.com</uri>
+          <purpose>ccmp</purpose>
+        </entry>
+      </service-uris>
+
+   The advantage of this approach is that it uses an existing mechanism
+   for extending the <purpose> field of the <service-uris> element in
+   the conferencing event package [RFC4353].  The disadvantage is that
+   it requires the client to subscribe to the conference event package.
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 4]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+   This approach would be suitable for a SIP UA that would typically
+   subscribe to the conference event package.  Knowing that a conference
+   supports CCMP allows a SIP UA that is XCON aware to make use of the
+   CCMP operations and allows it to subscribe to the XCON event package
+   [RFC6502] to get additional information related to the conference.
+
+3.  Overall Process
+
+   CCMP capability is discovered using the two methods described in
+   Section 2.  The order in which the two methods are tried depends on
+   whether an implementation subscribes to the conference event package
+   by default.
+
+   A UA implementation that subscribes to the conference event package
+   can examine the conference description to see if a URI with
+   <purpose>ccmp</purpose> is specified (Section 2.2).  An
+   implementation that does not subscribe to the conference event
+   package can perform an OPTIONS query when connecting to the
+   conference server.  UAs MUST NOT attempt both methods with the same
+   server.
+
+   Conference servers MUST reflect the same information using both
+   discovery channels.  A server MUST indicate CCMP support through the
+   conference event package if and only if it indicates support through
+   the Call-Info header in OPTIONS responses.  This prevents the need
+   for UAs to try both methods.
+
+4.  Security Considerations
+
+   This document defines no new headers or data elements; it reuses
+   existing headers and data elements.  CCMP already allows a client the
+   ability to discover if a conference server supports CCMP, using a DNS
+   mechanism as defined in [RFC6503] Section 12.4.
+
+   Thus, the solution options defined in this document do not introduce
+   any new security threats.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 5]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+5.  IANA Considerations
+
+5.1.  Call-Info Purpose Registration
+
+   This specification adds a new predefined value "ccmp" for the
+   "purpose" header field parameter of the Call-Info header field.  This
+   modifies the registry header field parameters and parameter values by
+   adding this RFC as a reference to the line for header field
+   "Call-Info" and parameter name "purpose":
+
+      Header Field: Call-Info
+
+      Parameter Name: purpose
+
+      Predefined Values: yes
+
+      Reference: [RFC3261] [RFC5367] [RFC6910] [RFC6993] [RFC7082]
+
+5.2.  URI Purpose Registration
+
+   This specification adds a new predefined value "ccmp" to the "URI
+   Purposes" subregistry, which defines XML elements to be encoded in
+   the conference event package [RFC4575].
+
+   This modifies the registry as follows:
+
+      Value: ccmp
+
+      Description: The URI can be used to indicate that the conference
+                   focus supports CCMP.
+
+      Reference: [RFC7082]
+
+6.  Acknowledgments
+
+   The authors would like to thank Alan Johnston, Robert Sparks, Cullen
+   Jennings, Glenn Parsons, Ben Campbell, Barry Leiba, Spencer Dawkins,
+   Sean Turner, Pete Resnick, and Adrian Farrel for their careful review
+   and feedback.
+
+   Special thanks to Adam Roach for his thorough review, comments, and
+   suggestions.  Special thanks also to Richard Barnes for his review
+   and for the text he provided for Section 3 of this document.
+
+
+
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 6]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3261]  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.
+
+   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
+              "Indicating User Agent Capabilities in the Session
+              Initiation Protocol (SIP)", RFC 3840, August 2004.
+
+   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
+              Session Initiation Protocol (SIP)", RFC 4353,
+              February 2006.
+
+   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
+              Session Initiation Protocol (SIP) Event Package for
+              Conference State", RFC 4575, August 2006.
+
+   [RFC4579]  Johnston, A. and O. Levin, "Session Initiation Protocol
+              (SIP) Call Control - Conferencing for User Agents",
+              BCP 119, RFC 4579, August 2006.
+
+   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
+              Centralized Conferencing", RFC 5239, June 2008.
+
+   [RFC5367]  Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
+              Request-Contained Resource Lists in the Session Initiation
+              Protocol (SIP)", RFC 5367, October 2008.
+
+   [RFC6501]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
+              "Conference Information Data Model for Centralized
+              Conferencing (XCON)", RFC 6501, March 2012.
+
+   [RFC6502]  Camarillo, G., Srinivasan, S., Even, R., and J.
+              Urpalainen, "Conference Event Package Data Format
+              Extension for Centralized Conferencing (XCON)", RFC 6502,
+              March 2012.
+
+   [RFC6503]  Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
+              "Centralized Conferencing Manipulation Protocol",
+              RFC 6503, March 2012.
+
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 7]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+   [RFC6910]  Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev,
+              "Completion of Calls for the Session Initiation Protocol
+              (SIP)", RFC 6910, April 2013.
+
+   [RFC6993]  Saint-Andre, P., "Instant Messaging and Presence Purpose
+              for the Call-Info Header Field in the Session Initiation
+              Protocol (SIP)", RFC 6993, July 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 8]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+Appendix A.  Other Approaches Considered
+
+   The following two options were considered as possible solutions but
+   were not selected because the options described in this document
+   better address the problem we are trying to solve.
+
+A.1.  Feature Tag
+
+   This approach defines a feature parameter 'ccmp' to indicate that a
+   SIP dialog belongs to a conference that supports CCMP.  The use of
+   feature parameters in Contact header fields to describe the
+   characteristics and capabilities of a UA is described in the User
+   Agent Capabilities document [RFC3840].
+
+   The conference focus behavior regarding the handling of the 'ccmp'
+   feature is the same as the behavior for the handling of the 'isfocus'
+   feature parameter.  In session establishment, a conference focus MUST
+   include the 'ccmp' feature parameter in the Contact header field
+   unless the conference focus wishes to hide the fact that it is a
+   conference focus.
+
+   The advantages of this approach are a one-step discovery of the
+   conference focus and its support for the 'ccmp' feature and the fact
+   that it can be used in response to an OPTIONS request, and that it
+   enables the discovery of the 'ccmp' capability by any network element
+   that does not need the conference event package.  The disadvantage is
+   the definition of a new feature parameter.
+
+A.2.  Conference URI Purpose
+
+   This approach defines an additional URI 'purpose' of 'ccmp'
+   associated with a 'conf-uris' element in the SIP conferencing event
+   package.
+
+   ccmp: Indicates that the conference focus represented by this URI
+      supports 'ccmp'; this in turn allows a client to use CCMP to
+      manipulate the conference.  This URI MUST be an XCON-URI as
+      defined in the XCON data model specification [RFC6501].
+
+      <conf-uris>
+        <entry>
+          <uri>XCON:conf1@example.com</uri>
+          <display-text>whatever</display-text>
+          <purpose>ccmp</purpose>
+        </entry>
+      </conf-uris>
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                     [Page 9]
+
+RFC 7082            Conference Focus Support for CCMP      December 2013
+
+
+   The advantage of the SIP conference event package options is the use
+   of an existing mechanism for extending the <purpose> field of the
+   <service-uris> or <conf-uris> elements.  The disadvantage is the
+   requirement that the client register for the conference event
+   package.
+
+Authors' Addresses
+
+   Rifaat Shekh-Yusef
+   Avaya
+   250 Sidney Street
+   Belleville, Ontario
+   Canada
+
+   Phone: +1-613-967-5267
+   EMail: rifaat.ietf@gmail.com
+
+
+   Mary Barnes
+   Polycom
+   TX
+   US
+
+   EMail: mary.ietf.barnes@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shekh-Yusef & Barnes          Informational                    [Page 10]
+