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

INTERNET-DRAFT                                            R. Shekh-Yusef
Intended Status: Standards Track                                   Avaya
Expires: March 30, 2013                                        M. Barnes
                                                                 Polycom
                                                      September 26, 2012

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

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 draft describes a few options to address the above limitation
   with the pros and cons for each approach, and recommends two to be
   used depending on the need of the UA.

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 30, 2013                 [Page 1]
INTERNET DRAFT       Conference Focus CCMP Support    September 26, 2012

Copyright and License Notice

   Copyright (c) 2012 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 30, 2013                 [Page 2]
INTERNET DRAFT       Conference Focus CCMP Support    September 26, 2012

Table of Contents

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

 

Shekh-Yusef & Barnes     Expires March 30, 2013                 [Page 3]
INTERNET DRAFT       Conference Focus CCMP Support    September 26, 2012

1  Introduction

   RFC 5239 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] 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 protocol defines a way for a client to determine if a
   conference control server supports CCMP, but it does not define a way
   for a client to determine if a conference focus supports CCMP.

   This document defines two mechanisms to address the above limitation.
   Other mechanisms that we considered are listed 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 30, 2013                 [Page 4]
INTERNET DRAFT       Conference Focus CCMP Support    September 26, 2012

2  Solutions

   This section defines the mechanisms that can be used to discover that
   a focus supports CCMP.

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 focus, and
   the purpose of the parameter is to indicate that the focus supports
   CCMP.

   While the XCON-URI by itself should be enough to indicate that the
   focus supports CCMP, the purpose with a value of 'ccmp' provides an
   easier way for a UA that is not interested in the URI to discover
   that the 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.

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>

 

Shekh-Yusef & Barnes     Expires March 30, 2013                 [Page 5]
INTERNET DRAFT       Conference Focus CCMP Support    September 26, 2012

3  Security Considerations

   These proposals introduce no additional security considerations
   beyond those which are applicable to each of the mechanisms described
   herein.

4  IANA Considerations

   This document defines the 'ccmp' value for the "purpose" parameter of
   the Call-Info header field.  A reference to this RFC (in double
   brackets) needs to be added to the existing "purpose" Call-Info
   parameter entry in the SIP Parameters registry, which currently looks
   as follows:

   Header Field     Parameter Name     Values     Reference
   ---------------  ---------------   ---------   ---------
   Call-Info        purpose             Yes       [RFC3261] [RFC5367]

5  Acknowledgments

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

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

 

Shekh-Yusef & Barnes     Expires March 30, 2013                 [Page 6]
INTERNET DRAFT       Conference Focus CCMP Support    September 26, 2012

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.

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

 

Shekh-Yusef & Barnes     Expires March 30, 2013                 [Page 7]
INTERNET DRAFT       Conference Focus CCMP Support    September 26, 2012

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 focus behavior regarding the handling of the 'ccmp' feature is
   the same as the handling of the 'isfocus' feature parameter. In
   session establishment, a focus MUST include the 'ccmp' feature
   parameter in the Contact header field unless the focus wishes to hide
   the fact that it is a focus.

   The pros of this approach is a one step discovery of the 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.  However, given
   that clients that want to take advantage of CCMP would most likely
   register for the conference event packages.

 

Shekh-Yusef & Barnes     Expires March 30, 2013                 [Page 8]
INTERNET DRAFT       Conference Focus CCMP Support    September 26, 2012

Author's Addresses

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

   Phone: +1-613-967-5267
   Email: rifatyu@avaya.com

   Mary Barnes
   Polycom
   TX
   US

   Email: mary.ietf.barnes@gmail.com

Shekh-Yusef & Barnes     Expires March 30, 2013                 [Page 9]