INTERNET-DRAFT
Internet Engineering Task Force (IETF)                    R. Shekh-Yusef
Intended Status: Informational
Request for Comments: 7082                                         Avaya
Expires: April 12, 2014
Category: Informational                                        M. Barnes
ISSN: 2070-1721                                                  Polycom
                                                         October 9,
                                                           December 2013

                 Indication of Conference Focus Indicating CCMP Support
                draft-yusef-dispatch-ccmp-indication-07
     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
   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, header field, and the second mechanism
   defines a new value for the 'purpose' "purpose" header field parameter in the 'service-uris'
   <service-uris> element in the SIP conferencing event package.

Status of this This Memo

   This Internet-Draft document is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product 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
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents at
   approved by the IESG are a candidate for any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html
   http://www.rfc-editor.org/info/rfc7082.

Copyright and License 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

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1 ....................................................2
      1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   2 ................................................3
   2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1 .......................................................3
      2.1. Call-Info  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2 ..................................................3
      2.2. Service URI purpose  . . . . . . . . . . . . . . . . . . . .  6 Purpose ........................................4
   3. Overall Process . . . . . . . . . . . . . . . . . . . . . . . .  6
   4 .................................................5
   4. Security Considerations . . . . . . . . . . . . . . . . . . . .  7
   5 .........................................5
   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
     5.1 .............................................6
      5.1. Call-Info Purpose Registration . . . . . . . . . . . . . . .  7
     5.2 .............................6
      5.2. URI Purpose Registration . . . . . . . . . . . . . . . . . .  7
   6 ...................................6
   6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .  8
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1 .................................................6
   7. Normative References  . . . . . . . . . . . . . . . . . . .  9 ............................................7
   Appendix A. Other Approaches Considered  . . . . . . . . . . . . . 11
     A.1 ............................9
      A.1. Feature Tag  . . . . . . . . . . . . . . . . . . . . . . . . 11
     A.2 ................................................9
      A.2. Conference URI purpose . . . . . . . . . . . . . . . . . . . 11
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

1 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 CCMP protocol RFC 6503 Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503]
   allows authenticated and authorized users to create, manipulate manipulate, and
   delete conference objects.  Operations on conferences include adding
   and removing participants, participants and changing their roles, as well as adding
   and removing media streams and associated end points.

   The

   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) XCON aware) that
   joins a conference using SIP based 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' "purpose" header field parameter
   in the
   'service-uris' <service-uris> element in the SIP conferencing event package
   [RFC4575], which
   [RFC4575] that is suitable to for a UA that would typically subscribe to
   the conference event package.

   Appendix A has a brief description to of other options that we
   considered as possible solutions but solutions.  Those other options were not selected
   selected, however, because the
   selected options described in this document
   better address the problem we are trying to solve.

1.1

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

2.  Solutions

   This section defines two mechanisms that can be used by a SIP UA to
   discover whether the conference which 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

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.

   While the XCON-URI by itself should be enough to indicate that the
   conference focus supports CCMP, the purpose "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 "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, like e.g., an application server
   that acts as a B2BUA, 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 case, the
   application could use the OPTIONS request and discover the 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 CCMP, without subscribing to the XCON event
   package [RFC6502].  The disadvantage is the need, in some cases, for
   an extra request, i.e. i.e., an additional OPTIONS request, to discover
   that a conference focus supports CCMP.

2.2

2.2.  Service URI purpose Purpose

   This approach defines an additional URI 'purpose' of 'ccmp'
   associated with a 'service-uris' <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.

   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 XCON aware to make use of the
   CCMP operations and allows them 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

4.  Security Considerations

   This document defines no new headers or data elements and are reusing elements; it reuses
   existing headers and data elements. The  CCMP protocol already allows a client the
   ability to discover if a conference server supports CCMP, using a DNS
   mechanism as defined in RFC 6503 [RFC6503] section Section 12.4.

   For these reasons, we think that

   Thus, the solution options defined in this document does do not introduce
   any new security risks.

5 threats.

5.  IANA Considerations

5.1

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"
   "Call-Info" and parameter name "purpose":

      Header Field: Call-Info

      Parameter Name: purpose

      Predefined Values: yes

      Reference: [RFC3261][RFC5367][RFC6910][RFC6993][RFC XXXX]

5.2 [RFC3261] [RFC5367] [RFC6910] [RFC6993] [RFC7082]

5.2.  URI Purpose Registration

   This specification adds a new predefined value "ccmp" for to the "URI
   Purposes" sub-registry, subregistry, which defines XML elements to be encoded in
   the conference event package RFC 4575 [RFC4575].

   This modifies the registry as follows:

      Value: ccmp

      Description: The URI can be used to indicate that the conference
                   focus supports CCMP.

      Reference: [RFC XXXX]

   (Note for RFC Editor: Please fill in XXXX with the RFC number of this
   specification)

6 [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 Section 3 of this document.

7  References

7.1

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.

   [RFC5239]  Barnes, M., Boulton, C.,

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and O. Levin, P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [RFC4353]  Rosenberg, J., "A Framework for
   Centralized Conferencing", Conferencing with the
              Session Initiation Protocol (SIP)", RFC 5239, June 2008. 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.

   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
   Centralized Conferencing", RFC 5239, June 2008.

   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
   Session Initiation Protocol (SIP)", RFC 4353, February 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.

   [RFC6503]  Barnes M., Boulton, C., Romano S P., and Schulzrinne H.,
   "Centralized Conferencing Manipulation Protocol", RFC6503, March
   2012.

   [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.

   [RFC6910]  Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, D.,
              "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.

   7.2  Informative References

Appendix A.  Other Approaches Considered

   The following two options were considered as possible solutions but
   were not selected because the selected options described in this document
   better address the problem we are trying to solve.

A.1

A.1.  Feature Tag

   This approach defines a feature parameter 'ccmp' to express 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. 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 is are a one step one-step discovery of the
   conference focus and its ccmp support, 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 '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

A.2.  Conference URI purpose

   Define Purpose

   This approach defines an additional URI 'purpose' of 'ccmp'
   associated with a
   'confs-uris' 'conf-uris' element in the SIP conferencing event
   package.

   ccmp: Indicates that the conference focus represented by this URI
      supports ccmp, which 'ccmp'; this in turn allows a client to use the CCMP protocol to
      manipulate the conference.  This URI MUST be an XCON-URI as
      defined in the xcon-data-model. 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>
   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.

Author's

Authors' Addresses

   Rifaat Shekh-Yusef
   Avaya
   250 Sidney Street
   Belleville, Ontario
   Canada

   Phone: +1-613-967-5267
   Email:
   EMail: rifaat.ietf@gmail.com

   Mary Barnes
   Polycom
   TX
   US

   Email:

   EMail: mary.ietf.barnes@gmail.com