Internet DRAFT - draft-yusef-xcon-ccmp-indication
draft-yusef-xcon-ccmp-indication
INTERNET-DRAFT R. Shekh-Yusef
Intended Status: Standards Track Avaya
Expires: September 13, 2012 M. Barnes
Polycom
March 12, 2012
Conference Focus Indicating CCMP Support
draft-yusef-xcon-ccmp-indication-02.txt
Abstract
The Centralized Conferencing Manipulation Protocol document defines
away 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 few options to address the above limitation with
the pros and cons for each approach.
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 September 13, 2012 [Page 1]
INTERNET DRAFT Conference Focus CCMP Support March 12, 2012
Copyright and License Notice
Copyright (c) 2011 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 September 13, 2012 [Page 2]
INTERNET DRAFT Conference Focus CCMP Support March 12, 2012
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Possible Solutions . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Feature Tag . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Conference Event Package . . . . . . . . . . . . . . . . . . 6
2.3.1 Service URI purpose . . . . . . . . . . . . . . . . . . 6
2.3.2 Conference URI purpose . . . . . . . . . . . . . . . . 6
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Normative References . . . . . . . . . . . . . . . . . . . 7
5.2 Informative References . . . . . . . . . . . . . . . . . . 7
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Shekh-Yusef & Barnes Expires September 13, 2012 [Page 3]
INTERNET DRAFT Conference Focus CCMP Support March 12, 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 Centralized Conferencing Manipulation Protocol (CCMP) 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 Centralized Conferencing Manipulation Protocol (CCMP) draft
defines a way for a client to determine a conference control server
that supports CCMP, but it does not define a way for a client to
determine if a conference focus supports CCMP.
This draft describes few options to address the above limitation with
the pros and cons for each approach.
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 September 13, 2012 [Page 4]
INTERNET DRAFT Conference Focus CCMP Support March 12, 2012
2 Possible Solutions
2.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.
2.2 OPTIONS
This approach requires the client to send an OPTIONS request to the
conference focus to determine if the conference supports CCMP.
If the feature tag approach is used, then the 200 OK response to the
OPTIONS request MUST include the ccmp feature parameter in the
Contact header.
Another option is return the Call-Info header with an XCON-URI in the
200 OK .
The pros of this approach is that it is consistent with SIP in terms
of the mechanism by which a UA determines the capabilities of a SIP
intermediary, 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 that it requires an extra step to
determine that a conference focus supports CCMP.
Shekh-Yusef & Barnes Expires September 13, 2012 [Page 5]
INTERNET DRAFT Conference Focus CCMP Support March 12, 2012
2.3 Conference Event Package
There are two options that rely on the SIP conference event package
defined in RFC 4575:
2.3.1 Service URI purpose
Define 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>
2.3.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 September 13, 2012 [Page 6]
INTERNET DRAFT Conference Focus CCMP Support March 12, 2012
3 Security Considerations
These proposal introduce no additional security considerations beyond
those which are applicable to each of the mechanisms described
herein.
4 IANA Considerations
<IANA considerations text>
5 Acknowledgments
The authers would like to thanks Alan Johnston and Robert Sparks for
their careful review and feedback.
6 References
6.1 Normative References
[RFC2119] S. Bradner, "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, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[CCMP] Barnes M., Boulton, C., Romano S P., and Schulzrinne H.,
"Centralized Conferencing Manipulation Protocol", Work in
Progress, October 2010.
6.2 Informative References
Shekh-Yusef & Barnes Expires September 13, 2012 [Page 7]
INTERNET DRAFT Conference Focus CCMP Support March 12, 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 September 13, 2012 [Page 8]
