Skip to main content

Conference Focus Indicating CCMP Support
draft-yusef-dispatch-ccmp-indication-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7082.
Authors Rifaat Shekh-Yusef , Mary Barnes
Last updated 2013-09-27
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources
Stream WG state (None)
Document shepherd Alan Johnston
Shepherd write-up Show Last changed 2013-06-18
IESG IESG state Became RFC 7082 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Gonzalo Camarillo
Send notices to rifatyu@avaya.com, mary.ietf.barnes@gmail.com, draft-yusef-dispatch-ccmp-indication@tools.ietf.org, alan.johnston@mci.com
IANA IANA review state IANA OK - Actions Needed
draft-yusef-dispatch-ccmp-indication-06
INTERNET-DRAFT                                            R. Shekh-Yusef
Intended Status: Informational                                     Avaya
Expires: March 31, 2014                                        M. Barnes
                                                                 Polycom
                                                      September 27, 2013

                Conference Focus Indicating CCMP Support
                draft-yusef-dispatch-ccmp-indication-06

Abstract

   The Centralized Conferencing Manipulation Protocol document 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 XCON
   conference event package and take advantage of CCMP operations on the
   conference.

   This document describes two mechanisms, depending upon the need of
   the UA, to address the above limitation. The first mechanism uses the
   Call-Info header, and the second mechanism defines a new value for
   the 'purpose' parameter in the 'service-uris' element in the SIP
   conferencing event package.

Status of this Memo

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

   Internet-Drafts are working documents 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 of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
 

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 1]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

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.

 

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 2]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   2  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1 Call-Info  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2 Service URI purpose  . . . . . . . . . . . . . . . . . . . .  6
   3  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
     4.1 Call-Info Purpose Registration . . . . . . . . . . . . . . .  7
     4.2 URI Purpose Registration . . . . . . . . . . . . . . . . . .  7
   5  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .  8
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1  Normative References  . . . . . . . . . . . . . . . . . . .  8
   Appendix A. Other Approaches Considered  . . . . . . . . . . . . .  9
     A.1 Feature Tag  . . . . . . . . . . . . . . . . . . . . . . . .  9
     A.2 Conference URI purpose . . . . . . . . . . . . . . . . . . .  9
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

 

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 3]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

1  Introduction

   RFC 5239 [RFC5239] defines a framework for Centralized Conferencing,
   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 [RFC6503] allows authenticated and
   authorized users to create, manipulate and delete conference objects.
   Operations on conferences include adding and removing participants,
   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) 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 UA. The first option uses the Call-Info [RFC3261]
   header, and the second option defines a new value for the 'purpose'
   parameter in the 'service-uris' element in the SIP conferencing event
   package [RFC4575].

   Other options considered are described in Appendix A.

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

 

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 4]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

2  Solutions

   This section defines two mechanisms that can be used by a SIP UA to
   discover whether the conference which 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 parameter.
   The purpose of the URI is to provide the XCON-URI of the conference
   focus, and the purpose of the parameter is to indicate 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 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 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 an application server
   that acts as a 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 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 pros of this approach is the ability to discover that a
   conference focus supports CCMP without subscribing to the XCON event
   package [RFC6502]. The cons is the need, in some cases, for an extra
   request, i.e. OPTIONS request, to discover that a conference focus
   supports CCMP.

 

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 5]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

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 pros of this approach is the use of an existing mechanism for
   extending the <purpose> field of the <service-uris> element in the 
   conferencing event package [RFC4353]. The con is the requirement that
   the client subscribe for 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 to make use of the 
   CCMP operations and allows them to subscribe to the XCON event 
   package [RFC6502] to get additional information related to the
   conference.  

3  Security Considerations

   The solution options described in this document introduce no
   additional security considerations, as they define no new headers or
   data elements and are reusing existing headers and data elements and
   thus no new security threats are introduced.

 

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 6]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

4  IANA Considerations

4.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][RFC XXXX]

4.2 URI Purpose Registration

   This specification adds a new predefined value "ccmp" for the "URI
   Purposes" sub-registry, 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)

 

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 7]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

5  Acknowledgments

   The authors would like to thank Alan Johnston, Robert Sparks, Cullen
   Jennings, Glenn Parsons, and Ben Campbell for their careful review
   and feedback.

   Special thanks to Adam Roach for his thorough review, comments, and
   suggestions.

6  References
6.1  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., and O. Levin, "A Framework for
   Centralized Conferencing", RFC 5239, June 2008.

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

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

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 8]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

Appendix A. Other Approaches Considered

A.1 Feature Tag

   This approach defines a feature parameter 'ccmp' to express 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.

   The conference focus behavior regarding the handling of the 'ccmp'
   feature is the same as 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 pros of this approach is a one step discovery of the conference
   focus and its ccmp support, 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 cons is the definition of a new feature
   parameter.

A.2 Conference URI purpose

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

   ccmp: Indicates that the conference focus represented by this URI
   supports ccmp, which 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.

         <conf-uris>
           <entry>
             <uri>XCON:conf1@example.com</uri>
             <display-text>whatever</display-text>
             <purpose>ccmp</purpose>
           </entry>
         </conf-uris>

   The pro 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 con is the requirement that the
   client register for the conference event package.  

 

Shekh-Yusef & Barnes     Expires March 31, 2014                 [Page 9]
INTERNET DRAFT       Conference Focus CCMP Support    September 27, 2013

Author's 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     Expires March 31, 2014                [Page 10]