rfc:rfc7082
Internet Engineering Task Force (IETF) R. Shekh-Yusef Request for Comments: 7082 Avaya Category: Informational M. Barnes ISSN: 2070-1721 Polycom
December 2013
Indication of Conference Focus Support
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 (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 field, and the second mechanism defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7082.
Shekh-Yusef & Barnes Informational [Page 1] RFC 7082 Conference Focus Support for CCMP December 2013
Copyright 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. Introduction ....................................................2
1.1. Terminology ................................................3
2. Solutions .......................................................3
2.1. Call-Info ..................................................3
2.2. Service URI Purpose ........................................4
3. Overall Process .................................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
5.1. Call-Info Purpose Registration .............................6
5.2. URI Purpose Registration ...................................6
6. Acknowledgments .................................................6
7. Normative References ............................................7
Appendix A. Other Approaches Considered ............................9
A.1. Feature Tag ................................................9
A.2. Conference URI 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 Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503] allows authenticated and authorized users to create, manipulate, and delete conference objects. Operations on conferences include adding and removing participants and changing their roles, as well as adding and removing media streams and associated end points.
Shekh-Yusef & Barnes Informational [Page 2] RFC 7082 Conference Focus Support for CCMP December 2013
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" header field parameter in the <service-uris> element in the SIP conferencing event package [RFC4575] that is suitable for a UA that would typically subscribe to the conference event package.
Appendix A has a brief description of other options that we considered as possible solutions. Those other options were not selected, however, because the options described in this document 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].
2. Solutions
This section defines two mechanisms that can be used by a SIP UA to discover whether the conference 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. 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.
Shekh-Yusef & Barnes Informational [Page 3] RFC 7082 Conference Focus Support for CCMP December 2013
While the XCON-URI by itself should be enough to indicate that the conference focus supports CCMP, the "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" 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, e.g., an application server
that acts as a 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, the
application could use the OPTIONS request and discover 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., an additional OPTIONS request, to discover that a conference focus supports CCMP.
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.
Shekh-Yusef & Barnes Informational [Page 4] RFC 7082 Conference Focus Support for CCMP December 2013
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 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. Security Considerations
This document defines no new headers or data elements; it reuses existing headers and data elements. CCMP already allows a client the ability to discover if a conference server supports CCMP, using a DNS mechanism as defined in [RFC6503] Section 12.4.
Thus, the solution options defined in this document do not introduce any new security threats.
Shekh-Yusef & Barnes Informational [Page 5] RFC 7082 Conference Focus Support for CCMP December 2013
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] [RFC7082]
5.2. URI Purpose Registration
This specification adds a new predefined value "ccmp" to the "URI Purposes" subregistry, which defines XML elements to be encoded in the conference event package [RFC4575].
This modifies the registry as follows:
Value: ccmp
Description: The URI can be used to indicate that the conference
focus supports CCMP.
Reference: [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 3 of this document.
Shekh-Yusef & Barnes Informational [Page 6] RFC 7082 Conference Focus Support for CCMP December 2013
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.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 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.
[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.
[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.
Shekh-Yusef & Barnes Informational [Page 7] RFC 7082 Conference Focus Support for CCMP December 2013
[RFC6910] Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev,
"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.
Shekh-Yusef & Barnes Informational [Page 8] RFC 7082 Conference Focus Support for CCMP December 2013
Appendix A. Other Approaches Considered
The following two options were considered as possible solutions but were not selected because the options described in this document better address the problem we are trying to solve.
A.1. Feature Tag
This approach defines a feature parameter 'ccmp' to 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 [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 are a one-step discovery of the
conference focus and its 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' 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
This approach defines an additional URI 'purpose' of 'ccmp' associated with a 'conf-uris' element in the SIP conferencing event package.
ccmp: Indicates that the conference focus represented by this URI
supports 'ccmp'; this in turn allows a client to use CCMP to
manipulate the conference. This URI MUST be an XCON-URI as
defined in the 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>
Shekh-Yusef & Barnes Informational [Page 9] RFC 7082 Conference Focus Support for CCMP December 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.
Authors' 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 Informational [Page 10]
/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc7082.txt · Last modified: 2013/12/05 01:54 by 127.0.0.1