idnits 2.17.1
draft-yusef-dispatch-ccmp-indication-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 9, 2013) is 3851 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC XXXX' is mentioned on line 254, but not defined
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET-DRAFT R. Shekh-Yusef
3 Intended Status: Informational Avaya
4 Expires: April 12, 2014 M. Barnes
5 Polycom
6 October 9, 2013
8 Conference Focus Indicating CCMP Support
9 draft-yusef-dispatch-ccmp-indication-07
11 Abstract
13 The Centralized Conferencing Manipulation Protocol (CCMP) document
14 defines a way for a client to discover a conference control server
15 that supports CCMP. However, it does not define a way for a client
16 involved in a conference to determine if the conference focus
17 supports CCMP. This information would allow a CCMP-enabled client
18 that joins a conference using SIP to also register for the
19 centralized conferencing (XCON) conference event package and take
20 advantage of CCMP operations on the conference.
22 This document describes two mechanisms, depending upon the need of
23 the User Agent (UA), to address the above limitation. The first
24 mechanism uses the Call-Info header, and the second mechanism defines
25 a new value for the 'purpose' parameter in the 'service-uris' element
26 in the SIP conferencing event package.
28 Status of this Memo
30 This Internet-Draft is submitted to IETF in full conformance with the
31 provisions of BCP 78 and BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF), its areas, and its working groups. Note that
35 other groups may also distribute working documents as
36 Internet-Drafts.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 The list of current Internet-Drafts can be accessed at
44 http://www.ietf.org/1id-abstracts.html
46 The list of Internet-Draft Shadow Directories can be accessed at
47 http://www.ietf.org/shadow.html
49 Copyright and License Notice
51 Copyright (c) 2013 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (http://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 Table of Contents
66 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
67 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
68 2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
69 2.1 Call-Info . . . . . . . . . . . . . . . . . . . . . . . . . 5
70 2.2 Service URI purpose . . . . . . . . . . . . . . . . . . . . 6
71 3. Overall Process . . . . . . . . . . . . . . . . . . . . . . . . 6
72 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
73 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
74 5.1 Call-Info Purpose Registration . . . . . . . . . . . . . . . 7
75 5.2 URI Purpose Registration . . . . . . . . . . . . . . . . . . 7
76 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
77 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
78 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9
79 Appendix A. Other Approaches Considered . . . . . . . . . . . . . 11
80 A.1 Feature Tag . . . . . . . . . . . . . . . . . . . . . . . . 11
81 A.2 Conference URI purpose . . . . . . . . . . . . . . . . . . . 11
82 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
84 1 Introduction
86 RFC 5239 [RFC5239] defines a framework for Centralized Conferencing
87 (XCON), which allows participants to exchange media in a centralized
88 unicast conference. The framework also outlines a set of conferencing
89 protocols for building advanced conferencing applications.
91 The CCMP protocol RFC 6503 [RFC6503] allows authenticated and
92 authorized users to create, manipulate and delete conference objects.
93 Operations on conferences include adding and removing participants,
94 changing their roles, as well as adding and removing media streams
95 and associated end points.
97 The CCMP defines a way for an XCON-aware client to discover whether a
98 conference control server supports CCMP. However, it does not define
99 a way for a SIP client involved in a conference to determine if the
100 conference focus [RFC4353] supports CCMP. Knowing that a focus
101 supports CCMP would allow a SIP client (that is also XCON-aware) that
102 joins a conference using SIP based conferencing [RFC4579] to also
103 register for the XCON conference event package [RFC6502] and take
104 advantage of CCMP operations on the conference.
106 This document describes two options to address the above limitation,
107 depending on the need of the User Agent (UA). The first option uses
108 the Call-Info [RFC3261] header, which is suitable for application
109 servers that need to discover if a UA supports CCMP. The second
110 option defines a new value for the 'purpose' parameter in the
111 'service-uris' element in the SIP conferencing event package
112 [RFC4575], which is suitable to a UA that would typically subscribe
113 to the conference event package.
115 Appendix A has a brief description to other options that we
116 considered as possible solutions but were not selected because the
117 selected options better address the problem we are trying to solve.
119 1.1 Terminology
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123 document are to be interpreted as described in RFC 2119 [RFC2119].
125 2 Solutions
127 This section defines two mechanisms that can be used by a SIP UA to
128 discover whether the conference which a client has joined, per the
129 SIP signaling procedures defined in [RFC4579], supports CCMP.
130 Specifically, the mechanisms allow the client to know that the URI
131 representing the conference focus, as defined in [RFC4579], is an
132 XCON-URI as defined in [RFC6501].
134 2.1 Call-Info
136 This approach uses the Call-Info header in various requests and
137 responses.
139 The Call-Info header consists of two parts: a URI and a parameter.
140 The URI provides the XCON-URI of the conference focus, and the
141 parameter indicates that the conference focus supports CCMP.
143 While the XCON-URI by itself should be enough to indicate that the
144 conference focus supports CCMP, the purpose parameter with a value of
145 'ccmp' provides an easier way for a UA that does not use the
146 conference event package to discover that the conference focus
147 supports CCMP, without parsing the URI.
149 The Call-Info header, with the XCON-URI and the purpose parameter
150 with the 'ccmp' value, can be used with any INVITE request or
151 response and with a response to an OPTIONS request.
153 This approach would be suitable for a UA, like an application server
154 that acts as a B2BUA, that is interested in discovering that a
155 conference focus supports CCMP but does not use the XCON conference
156 event package [RFC6502]. In this case the application could use the
157 OPTIONS request and discover the CCMP support from the response.
159 This approach would also be suitable for a conference focus that
160 initiates an INVITE request to a SIP UA to add a participant to a
161 conference, as it would allow the conference focus to indicate that
162 it supports CCMP with the INVITE request sent to the UA.
164 The advantage of this approach is the ability to discover that a
165 conference focus supports CCMP without subscribing to the XCON event
166 package [RFC6502]. The disadvantage is the need, in some cases, for
167 an extra request, i.e. OPTIONS request, to discover that a conference
168 focus supports CCMP.
170 2.2 Service URI purpose
172 This approach defines an additional URI 'purpose' of 'ccmp'
173 associated with a 'service-uris' element in the SIP conferencing
174 event package. The XCON-URI for the conference is included in the
175 'uri' element, per the following example:
177
178
179 XCON:conf1@example.com
180 ccmp
181
182
184 The advantage of this approach is that it uses an existing mechanism
185 for extending the field of the element in
186 the conferencing event package [RFC4353]. The disadvantage is that it
187 requires the client to subscribe to the conference event package.
189 This approach would be suitable for a SIP UA that would typically
190 subscribe to the conference event package. Knowing that a conference
191 supports CCMP allows a SIP UA that is XCON-aware to make use of the
192 CCMP operations and allows them to subscribe to the XCON event
193 package [RFC6502] to get additional information related to the
194 conference.
196 3. Overall Process
198 CCMP capability is discovered using the two methods described in
199 Section 2. The order in which the two methods are tried depends on
200 whether an implementation subscribes to the conference event package
201 by default.
203 A UA implementation that subscribes to the conference event package
204 can examine the conference description to see if a URI with
205 ccmp is specified (Section 2.2). An
206 implementation that does not subscribe to the conference event
207 package can perform an OPTIONS query when connecting to the
208 conference server. UAs MUST NOT attempt both methods with the same
209 server.
211 Conference servers MUST reflect the same information using both
212 discovery channels. A server MUST indicate CCMP support through the
213 conference event package if and only if it indicates support through
214 the Call-Info header in OPTIONS responses. This prevents the need
215 for UAs to try both methods.
217 4 Security Considerations
219 This document defines no new headers or data elements and are reusing
220 existing headers and data elements. The CCMP protocol already allows
221 a client the ability to discover if a conference server supports
222 CCMP, using a DNS mechanism as defined in RFC 6503 [RFC6503] section
223 12.4.
225 For these reasons, we think that this document does not introduce any
226 new security risks.
228 5 IANA Considerations
230 5.1 Call-Info Purpose Registration
232 This specification adds a new predefined value "ccmp" for the
233 "purpose" header field parameter of the Call-Info header field. This
234 modifies the registry header field parameters and parameter values by
235 adding this RFC as a reference to the line for header field "Call-
236 Info" and parameter name "purpose":
238 Header Field: Call-Info
239 Parameter Name: purpose
240 Predefined Values: yes
241 Reference: [RFC3261][RFC5367][RFC6910][RFC6993][RFC XXXX]
243 5.2 URI Purpose Registration
245 This specification adds a new predefined value "ccmp" for the "URI
246 Purposes" sub-registry, which defines XML elements to be encoded in
247 the conference event package RFC 4575 [RFC4575].
249 This modifies the registry as follows:
251 Value: ccmp
252 Description: The URI can be used to indicate that the conference
253 focus supports CCMP.
254 Reference: [RFC XXXX]
256 (Note for RFC Editor: Please fill in XXXX with the RFC number of this
257 specification)
259 6 Acknowledgments
261 The authors would like to thank Alan Johnston, Robert Sparks, Cullen
262 Jennings, Glenn Parsons, Ben Campbell, Barry Leiba, Spencer Dawkins,
263 Sean Turner, Pete Resnick, and Adrian Farrel for their careful review
264 and feedback.
266 Special thanks to Adam Roach for his thorough review, comments, and
267 suggestions. Special thanks also to Richard Barnes for his review and
268 for the text he provided for section 3 of this document.
270 7 References
272 7.1 Normative References
274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
275 Requirement Levels", BCP 14, RFC 2119, March 1997.
277 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
278 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
279 Session Initiation Protocol", RFC 3261, June 2002.
281 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
282 Centralized Conferencing", RFC 5239, June 2008.
284 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
285 Session Initiation Protocol (SIP) Event Package for Conference
286 State", RFC 4575, August 2006.
288 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
289 Centralized Conferencing", RFC 5239, June 2008.
291 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
292 Session Initiation Protocol (SIP)", RFC 4353, February 2006.
294 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
295 (SIP) Call Control - Conferencing for User Agents", BCP 119,
296 RFC 4579, August 2006.
298 [RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
299 Request-Contained Resource Lists in the Session Initiation Protocol
300 (SIP)", RFC 5367, October 2008.
302 [RFC6503] Barnes M., Boulton, C., Romano S P., and Schulzrinne H.,
303 "Centralized Conferencing Manipulation Protocol", RFC6503, March
304 2012.
306 [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
307 "Conference Information Data Model for Centralized Conferencing
308 (XCON)", RFC 6501, March 2012.
310 [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J.
311 Urpalainen, "Conference Event Package Data Format Extension for
312 Centralized Conferencing (XCON)", RFC 6502, March 2012.
314 [RFC6910] Worley, D., Huelsemann, M., Jesske, R., Alexeitsev, D.,
315 "Completion of Calls for the Session Initiation Protocol (SIP)", RFC
316 6910, April 2013.
318 [RFC6993] Saint-Andre, P., "Instant Messaging and Presence Purpose
319 for the Call-Info Header Field in the Session Initiation Protocol
320 (SIP)", RFC 6993, July 2013.
322 7.2 Informative References
324 Appendix A. Other Approaches Considered
326 The following two options were considered as possible solutions but
327 were not selected because the selected options better address the
328 problem we are trying to solve.
330 A.1 Feature Tag
332 This approach defines a feature parameter 'ccmp' to express that a
333 SIP dialog belongs to a conference that supports CCMP. The use of
334 feature parameters in Contact header fields to describe the
335 characteristics and capabilities of a UA is described in the User
336 Agent Capabilities document.
338 The conference focus behavior regarding the handling of the 'ccmp'
339 feature is the same as the handling of the 'isfocus' feature
340 parameter. In session establishment, a conference focus MUST include
341 the 'ccmp' feature parameter in the Contact header field unless the
342 conference focus wishes to hide the fact that it is a conference
343 focus.
345 The advantages of this approach is a one step discovery of the
346 conference focus and its ccmp support, and the fact that it can be
347 used in response to an OPTIONS request, and that it enables the
348 discovery of the ccmp capability by any network element that does not
349 need the conference event package. The disadvantage is the definition
350 of a new feature parameter.
352 A.2 Conference URI purpose
354 Define an additional URI 'purpose' of 'ccmp' associated with a
355 'confs-uris' element in the SIP conferencing event package.
357 ccmp: Indicates that the conference focus represented by this URI
358 supports ccmp, which allows a client to use the CCMP protocol to
359 manipulate the conference. This URI MUST be an XCON-URI as defined in
360 the xcon-data-model.
362
363
364 XCON:conf1@example.com
365 whatever
366 ccmp
367
368
370 The advantage of the SIP conference event package options is the use
371 of an existing mechanism for extending the field of the
372 or elements. The disadvantage is the
373 requirement that the client register for the conference event
374 package.
376 Author's Addresses
378 Rifaat Shekh-Yusef
379 Avaya
380 250 Sidney Street
381 Belleville, Ontario
382 Canada
384 Phone: +1-613-967-5267
385 Email: rifaat.ietf@gmail.com
387 Mary Barnes
388 Polycom
389 TX
390 US
392 Email: mary.ietf.barnes@gmail.com