idnits 2.17.1
draft-yusef-xcon-ccmp-indication-02.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 (March 12, 2012) is 4420 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'RFC3261' is defined on line 212, but no explicit
reference was found in the text
== Unused Reference: 'RFC5239' is defined on line 217, but no explicit
reference was found in the text
== Unused Reference: 'RFC4575' is defined on line 220, but no explicit
reference was found in the text
== Unused Reference: 'CCMP' is defined on line 224, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'CCMP'
Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET-DRAFT R. Shekh-Yusef
3 Intended Status: Standards Track Avaya
4 Expires: September 13, 2012 M. Barnes
5 Polycom
6 March 12, 2012
8 Conference Focus Indicating CCMP Support
9 draft-yusef-xcon-ccmp-indication-02.txt
11 Abstract
13 The Centralized Conferencing Manipulation Protocol document defines
14 away for a client to discover a conference control server that
15 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 XCON
19 conference event package and take advantage of CCMP operations on the
20 conference.
22 This draft describes few options to address the above limitation with
23 the pros and cons for each approach.
25 Status of this Memo
27 This Internet-Draft is submitted to IETF in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF), its areas, and its working groups. Note that
32 other groups may also distribute working documents as
33 Internet-Drafts.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 The list of current Internet-Drafts can be accessed at
41 http://www.ietf.org/1id-abstracts.html
43 The list of Internet-Draft Shadow Directories can be accessed at
44 http://www.ietf.org/shadow.html
46 Copyright and License Notice
48 Copyright (c) 2011 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
65 2 Possible Solutions . . . . . . . . . . . . . . . . . . . . . . . 5
66 2.1 Feature Tag . . . . . . . . . . . . . . . . . . . . . . . . 5
67 2.2 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 5
68 2.3 Conference Event Package . . . . . . . . . . . . . . . . . . 6
69 2.3.1 Service URI purpose . . . . . . . . . . . . . . . . . . 6
70 2.3.2 Conference URI purpose . . . . . . . . . . . . . . . . 6
71 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
72 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
73 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
74 5.1 Normative References . . . . . . . . . . . . . . . . . . . 7
75 5.2 Informative References . . . . . . . . . . . . . . . . . . 7
76 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
78 1 Introduction
80 RFC 5239 defines a framework for Centralized Conferencing, which
81 allows participants to exchange media in a centralized unicast
82 conference. The framework also outlines a set of conferencing
83 protocols for building advanced conferencing applications.
85 The Centralized Conferencing Manipulation Protocol (CCMP) allows
86 authenticated and authorized users to create, manipulate and delete
87 conference objects. Operations on conferences include adding and
88 removing participants, changing their roles, as well as adding and
89 removing media streams and associated end points.
91 The Centralized Conferencing Manipulation Protocol (CCMP) draft
92 defines a way for a client to determine a conference control server
93 that supports CCMP, but it does not define a way for a client to
94 determine if a conference focus supports CCMP.
96 This draft describes few options to address the above limitation with
97 the pros and cons for each approach.
99 1.1 Terminology
101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
103 document are to be interpreted as described in RFC 2119 [RFC2119].
105 2 Possible Solutions
107 2.1 Feature Tag
109 This approach defines a feature parameter 'ccmp' to express that a
110 SIP dialog belongs to a conference that supports CCMP. The use of
111 feature parameters in Contact header fields to describe the
112 characteristics and capabilities of a UA is described in the User
113 Agent Capabilities document.
115 The focus behavior regarding the handling of the 'ccmp' feature is
116 the same as the handling of the 'isfocus' feature parameter. In
117 session establishment, a focus MUST include the 'ccmp' feature
118 parameter in the Contact header field unless the focus wishes to hide
119 the fact that it is a focus.
121 The pros of this approach is a one step discovery of the focus and
122 its ccmp support, and the fact that it can be used in response to an
123 OPTIONS request, and that it enables the discovery of the ccmp
124 capability by any network element that does not need the conference
125 event package. The cons is the definition of a new feature parameter.
127 2.2 OPTIONS
129 This approach requires the client to send an OPTIONS request to the
130 conference focus to determine if the conference supports CCMP.
132 If the feature tag approach is used, then the 200 OK response to the
133 OPTIONS request MUST include the ccmp feature parameter in the
134 Contact header.
136 Another option is return the Call-Info header with an XCON-URI in the
137 200 OK .
139 The pros of this approach is that it is consistent with SIP in terms
140 of the mechanism by which a UA determines the capabilities of a SIP
141 intermediary, and that it enables the discovery of the ccmp
142 capability by any network element that does not need the conference
143 event package. The cons is that it requires an extra step to
144 determine that a conference focus supports CCMP.
146 2.3 Conference Event Package
148 There are two options that rely on the SIP conference event package
149 defined in RFC 4575:
151 2.3.1 Service URI purpose
153 Define an additional URI 'purpose' of 'ccmp' associated with a
154 'service-uris' element in the SIP conferencing event package. The
155 XCON-URI for the conference is included in the 'uri' element, per the
156 following example:
158
159
160 XCON:conf1@example.com
161 ccmp
162
163
165 2.3.2 Conference URI purpose
167 Define an additional URI 'purpose' of 'ccmp' associated with a
168 'confs-uris' element in the SIP conferencing event package.
170 ccmp: Indicates that the conference focus represented by this URI
171 supports ccmp, which allows a client to use the CCMP protocol to
172 manipulate the conference. This URI MUST be an XCON-URI as defined in
173 the xcon-data-model.
175
176
177 XCON:conf1@example.com
178 whatever
179 ccmp
180
181
183 The pro of the SIP conference event package options is the use of an
184 existing mechanism for extending the field of the or elements. The con is the requirement that the
186 client register for the conference event package. However, given
187 that clients that want to take advantage of CCMP would most likely
188 register for the conference event packages.
190 3 Security Considerations
192 These proposal introduce no additional security considerations beyond
193 those which are applicable to each of the mechanisms described
194 herein.
196 4 IANA Considerations
198
200 5 Acknowledgments
202 The authers would like to thanks Alan Johnston and Robert Sparks for
203 their careful review and feedback.
205 6 References
207 6.1 Normative References
209 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
210 Requirement Levels", BCP 14, RFC 2119, March 1997.
212 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
213 A., Peterson, J., Sparks, R., Handley, M., and E.
214 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
215 June 2002.
217 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
218 Centralized Conferencing", RFC 5239, June 2008.
220 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
221 Initiation Protocol (SIP) Event Package for Conference
222 State", RFC 4575, August 2006.
224 [CCMP] Barnes M., Boulton, C., Romano S P., and Schulzrinne H.,
225 "Centralized Conferencing Manipulation Protocol", Work in
226 Progress, October 2010.
228 6.2 Informative References
229 Author's Addresses
231 Rifaat Shekh-Yusef
232 Avaya
233 250 Sidney Street
234 Belleville, Ontario
235 Canada
237 Phone: +1-613-967-5267
238 Email: rifatyu@avaya.com
240 Mary Barnes
241 Polycom
242 TX
243 US
245 Email: mary.ietf.barnes@gmail.com