Internet DRAFT - draft-yusef-dispatch-ccmp-indication
draft-yusef-dispatch-ccmp-indication
INTERNET-DRAFT R. Shekh-Yusef
Intended Status: Informational Avaya
Expires: April 12, 2014 M. Barnes
Polycom
October 9, 2013
Conference Focus Indicating CCMP Support
draft-yusef-dispatch-ccmp-indication-07
Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) 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
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, 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 April 12, 2014 [Page 1]
INTERNET DRAFT Conference Focus CCMP Support October 9, 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 April 12, 2014 [Page 2]
INTERNET DRAFT Conference Focus CCMP Support October 9, 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. Overall Process . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Call-Info Purpose Registration . . . . . . . . . . . . . . . 7
5.2 URI Purpose Registration . . . . . . . . . . . . . . . . . . 7
6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 Normative References . . . . . . . . . . . . . . . . . . . 9
Appendix A. Other Approaches Considered . . . . . . . . . . . . . 11
A.1 Feature Tag . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2 Conference URI purpose . . . . . . . . . . . . . . . . . . . 11
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Shekh-Yusef & Barnes Expires April 12, 2014 [Page 3]
INTERNET DRAFT Conference Focus CCMP Support October 9, 2013
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 [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 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' parameter in the
'service-uris' element in the SIP conferencing event package
[RFC4575], which is suitable to a UA that would typically subscribe
to the conference event package.
Appendix A has a brief description to other options that we
considered as possible solutions but were not selected because the
selected options 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].
Shekh-Yusef & Barnes Expires April 12, 2014 [Page 4]
INTERNET DRAFT Conference Focus CCMP Support October 9, 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 URI provides the XCON-URI of the conference focus, and the
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 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 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. OPTIONS request, to discover that a conference
focus supports CCMP.
Shekh-Yusef & Barnes Expires April 12, 2014 [Page 5]
INTERNET DRAFT Conference Focus CCMP Support October 9, 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 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 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. 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.
Shekh-Yusef & Barnes Expires April 12, 2014 [Page 6]
INTERNET DRAFT Conference Focus CCMP Support October 9, 2013
4 Security Considerations
This document defines no new headers or data elements and are reusing
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
12.4.
For these reasons, we think that this document does not introduce any
new security risks.
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][RFC XXXX]
5.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 April 12, 2014 [Page 7]
INTERNET DRAFT Conference Focus CCMP Support October 9, 2013
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 Expires April 12, 2014 [Page 8]
INTERNET DRAFT Conference Focus CCMP Support October 9, 2013
7 References
7.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.
[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.
[RFC6910] Worley, D., Huelsemann, M., Jesske, R., Alexeitsev, D.,
"Completion of Calls for the Session Initiation Protocol (SIP)", RFC
6910, April 2013.
Shekh-Yusef & Barnes Expires April 12, 2014 [Page 9]
INTERNET DRAFT Conference Focus CCMP Support October 9, 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
Shekh-Yusef & Barnes Expires April 12, 2014 [Page 10]
INTERNET DRAFT Conference Focus CCMP Support October 9, 2013
Appendix A. Other Approaches Considered
The following two options were considered as possible solutions but
were not selected because the selected options better address the
problem we are trying to solve.
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 advantages 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 disadvantage 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>
Shekh-Yusef & Barnes Expires April 12, 2014 [Page 11]
INTERNET DRAFT Conference Focus CCMP Support October 9, 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.
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 April 12, 2014 [Page 12]
