idnits 2.17.1
draft-ietf-cuss-sip-uui-01.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
== Line 447 has weird spacing: '...ats and codes...'
-- The document date (July 11, 2011) is 4672 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)
== Missing Reference: 'RFCXXXX' is mentioned on line 301, but not defined
== Unused Reference: 'ETSI' is defined on line 453, but no explicit
reference was found in the text
== Unused Reference: 'RFC3324' is defined on line 482, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 2976
(Obsoleted by RFC 6086)
** Downref: Normative reference to an Informational RFC: RFC 3324
== Outdated reference: A later version (-09) exists of
draft-ietf-cuss-sip-uui-reqs-02
** Downref: Normative reference to an Informational draft:
draft-ietf-cuss-sip-uui-reqs (ref. 'I-D.ietf-cuss-sip-uui-reqs')
** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224)
== Outdated reference: A later version (-12) exists of
draft-ietf-sipcore-rfc4244bis-05
Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group A. Johnston
3 Internet-Draft Avaya
4 Intended status: Standards Track J. Rafferty
5 Expires: January 12, 2012 Dialogic
6 July 11, 2011
8 A Mechanism for Transporting User to User Call Control Information in
9 SIP
10 draft-ietf-cuss-sip-uui-01
12 Abstract
14 There is a need for applications using SIP to exchange User to User
15 Information (UUI) data during session establishment. This
16 information, known as call control UUI, is a small piece of data
17 inserted by an application initiating the session, and utilized by an
18 application accepting the session. This data is opaque to SIP and
19 its function is unrelated to any basic SIP function. This document
20 defines a new SIP header field, User-to-User, to transport UUI, along
21 with an extension mechanism.
23 Status of this Memo
25 This Internet-Draft is submitted to IETF in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on January 12, 2012.
40 Copyright Notice
42 Copyright (c) 2011 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3
60 4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5
61 4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 5
62 4.2. Definition of New Parameter Values . . . . . . . . . . . . 6
63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
64 5.1. Registration of Header Field . . . . . . . . . . . . . . . 6
65 5.2. Registration of Header Field Parameters . . . . . . . . . 7
66 5.3. Registration of SIP Option Tag . . . . . . . . . . . . . . 7
67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
68 7. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 8
69 7.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 8
70 7.2. Why Other Protocol Encapsulation UUI Mechanisms are
71 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 8
72 7.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 9
73 7.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 10
74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
76 9.1. Informative References . . . . . . . . . . . . . . . . . . 10
77 9.2. Normative References . . . . . . . . . . . . . . . . . . . 11
78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
80 1. Overview
82 This document describes the transport of User to User Information
83 (UUI) using SIP [RFC3261]. Specifically, we discuss a mechanism for
84 the transport of general application UUI and also for the transport
85 of call control related ITU-T Q.931 User to User Information Element
86 (UU IE) [Q931] and ITU-T Q.763 User to User Information Parameter
87 [Q763] data in SIP. UUI is widely used in the PSTN today in contact
88 centers and call centers which are transitioning away from ISDN to
89 SIP. This extension will also be used for native SIP endpoints
90 implementing similar services and interworking with ISDN services.
92 This mechanism was designed to meet the use cases, requirements, and
93 call flows for SIP call control UUI detailed in
94 [I-D.ietf-cuss-sip-uui-reqs]. All references to requirement numbers
95 (REQ-N) and figure numbers refer to this document.
97 The mechanism chosen is a new SIP header field, along with a new SIP
98 option tag and media feature tag. The header field carries the UUI
99 information, along with parameters indicating the encoding of the
100 UUI, the application user of the UUI, and optionally the content of
101 the UUI. The header field can be escaped into URIs supporting
102 referral and redirection scenarios. In these scenarios, History-Info
103 is used to indicate the inserter of the UUI. The SIP option tag is
104 used to indicate support for the header field. Support for the
105 header field indicates that a UA is able to extract the information
106 in the UUI and pass it up the protocol stack. The media feature tag
107 is used to indicate that a UA supports a particular application user
108 of UUI.
110 2. Terminology
112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
114 document are to be interpreted as described in BCP 14, RFC 2119
115 [RFC2119].
117 3. Requirements Discussion
119 This section describes how the User-to-User header field meets the
120 requirements in [I-D.ietf-cuss-sip-uui-reqs]. The header field can
121 be included in INVITE requests and responses and BYE requests and
122 responses, meeting REQ-1 and REQ-2.
124 For redirection and referral use cases and REQ-3, the header field
125 would be escaped into the Contact or Refer-To URI. Currently, UAs
126 that support attended transfer support the ability to escape a
127 Replaces header field into a Refer-To URI, and when acting upon this
128 URI add the Replaces header field to the triggered INVITE. This
129 logic and behavior is identical for the UUI header field. The UA
130 processing the REFER or the 3xx to the INVITE will need to support
131 the UUI mechanism, as UAs in general do not process unknown escaped
132 header fields.
134 Since SIP proxy forwarding and retargeting does not affect header
135 fields, the header field meets REQ-4.
137 The UUI header field will carry the UUI data and not a pointer to the
138 data, so REQ-5 is met.
140 Since the basic design of the UUI header field is similar to the ISDN
141 UUI service, interworking with PSTN protocols will be straightforward
142 and will be documented in a separate specification, meeting REQ-6
144 Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the
145 mechanism and supported applications. REQ-7 relates to support of
146 the UUI header field, while REQ-8 relates to routing based on support
147 of the UUI header field. REQ-7 is met by defining a new SIP option
148 tag 'uui'. The use of a 'Require: uui' in a request, or 'Supported:
149 uui' in an OPTIONS response could be used to require or discover
150 support of the mechanism. The presence of a Supported:uui or
151 Require:uui header field can be used by proxies to route to an
152 appropriate UA, meeting REQ-8. REQ-10 is met by creating a new class
153 of SIP feature tags. For example, the feature tag 'sip.uui.isdn'
154 could be used to indicate support of the ISDN UUI service, or
155 'sip.uui.app1' could be used to indicate support for a particular
156 application, app1.
158 Proxies commonly apply policy to the presence of certain SIP header
159 fields in requests by either passing them or removing them from
160 requests. REQ-9 is met by allowing proxies and other intermediaries
161 to remove UUI header fields in a request or response based on policy.
163 Carrying UUI data elements of at least 129 octets is trivial in the
164 UUI header field, meeting REQ-11. Note that very large UUI elements
165 should be avoided, as SIP header fields have traditionally not been
166 large.
168 To meet REQ-12 in redirection and referral use cases, History-Info
169 [I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting
170 cases, the changed Request-URI will be recorded in the History-Info
171 header field along with the identity of the element that performed
172 the retargeting.
174 The requirement for integrity protection in REQ-13 could be met by
175 the use of an S/MIME signature over a subset of header fields, as
176 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity
177 using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to-
178 end privacy could be met using S/MIME or using encryption at the
179 application layer. Note that the use of S/MIME to secure the UUI
180 will result in an additional body being added to the request.
181 Hopwise TLS allows the header field to meet REQ-15 for hop-by-hop
182 security.
184 4. Normative Definition
186 This document defines a new SIP header field "User-to-User" to
187 transport call control UUI to meet the requirements in
188 [I-D.ietf-cuss-sip-uui-reqs].
190 To help tag and identify the UUI used with this header field, "app",
191 "content", and "encoding" parameters are defined. The "app"
192 parameter identifies the application which generates and consumes the
193 UUI information. For the case of interworking with the ISDN UUI
194 Service, the application is unknown, so a value to indicate ISDN UUI
195 Service interworking will be defined. If the "app" parameter is not
196 present, interworking with the ISDN UUI Service MUST be assumed. The
197 "content" parameter identifies the actual content of the UUI data.
198 If not present, the content MUST be assumed to be unknown as it is in
199 the ISDN UUI Service. For newly defined applications using the SIP
200 UUI service, a "content" value MUST be defined and SHOULD be used.
201 The "encoding" parameter indicates the method of encoding the
202 information in the UUI. This specification only defines
203 "encoding=hex". If the "encoding" parameter is not present, "hex"
204 MUST be assumed.
206 4.1. Syntax for UUI Header Field
208 The User-to-User header field can be present in INVITE requests and
209 responses only and in BYE requests and responses.
211 The following syntax specification uses the augmented Backus-Naur
212 Form (BNF) as described in RFC 2234 and extends RFC 3261.
214 UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param)
215 uui-data = token
216 uui-param = enc-param | cont-param | app-param | generic-param
217 enc-param = "encoding="("hex" | token)
218 cont-param = "content=" token
219 app-param = "app=" token
221 User-to-User header fields with different "app" parameters MAY be
222 present in a request or response. The number of User-to-User header
223 fields which may be present in a request or response is defined for a
224 particular application. Any size limitations on the UUI for a
225 particular purpose must be defined by that application.
227 4.2. Definition of New Parameter Values
229 This specification defines only the value of "hex" for the "encoding"
230 parameter. New values can be defined and added to the IANA registry
231 with a standards track RFC, which needs to discuss the issues in this
232 section.
234 New "encoding" values must reference a common encoding scheme or
235 define the exact new encoding scheme.
237 New "content" values must describe the content of the UUI and give
238 some example use cases. The default "encoding" and other allowed
239 encoding methods must be defined for this new content.
241 New "app" values must describe the new application which is utilizing
242 the UUI data and give some example use cases. The default "content"
243 value and other allowed contents must be defined for this new
244 purpose. Any restrictions on the size of the UUI data must be
245 described for the new application.
247 5. IANA Considerations
249 5.1. Registration of Header Field
251 This document defines a new SIP header field named "User-to-User".
253 The following row shall be added to the "Header Fields" section of
254 the SIP parameter registry:
256 +------------------+--------------+-----------+
257 | Header Name | Compact Form | Reference |
258 +------------------+--------------+-----------+
259 | User-to-User | | [RFCXXXX] |
260 +------------------+--------------+-----------+
262 Editor's Note: [RFCXXXX] should be replaced with the designation of
263 this document.
265 5.2. Registration of Header Field Parameters
267 This document defines the parameters for the header field defined in
268 the preceding section. The header field "User-to-User" can contain
269 the parameters "encoding", "content", and "purpose".
271 The following rows shall be added to the "Header Field Parameters and
272 Parameter Values" section of the SIP parameter registry:
274 +------------------+----------------+-------------------+-----------+
275 | Header Field | Parameter Name | Predefined Values | Reference |
276 +------------------+----------------+-------------------+-----------+
277 | User-to-User | encoding | hex | [RFCXXXX] |
278 +------------------+----------------+-------------------+-----------+
280 Editor's Note: [RFCXXXX] should be replaced with the designation of
281 this document.
283 5.3. Registration of SIP Option Tag
285 This specification registers a new SIP option tag, as per the
286 guidelines in Section 27.1 of [RFC3261].
288 This document defines the SIP option tag "uui".
290 The following row has been added to the "Option Tags" section of the
291 SIP Parameter Registry:
293 +------------+------------------------------------------+-----------+
294 | Name | Description | Reference |
295 +------------+------------------------------------------+-----------+
296 | uui | This option tag is used to indicate that | [RFCXXXX] |
297 | | a UA supports and understands the | |
298 | | User-to-User header field. | |
299 +------------+------------------------------------------+-----------+
301 Editor's Note: [RFCXXXX] should be replaced with the designation of
302 this document.
304 Registration of SIP media feature tag is TBD.
306 6. Security Considerations
308 User to user information can potentially carry sensitive information
309 that might require privacy or integrity protection. Standard
310 deployed SIP security mechanisms such as TLS transport, offer these
311 properties on a hop-by-hop basis. To preserve multi-hop or end-to-
312 end confidentiality and integrity of UUI, approaches using S/MIME can
313 be used, as discussed in the draft. However, the lack of deployment
314 of these mechanisms means that applications can not in general rely
315 on them. As such, applications are encouraged to utilize their own
316 security mechanisms.
318 7. Appendix - Other Possible Mechanisms
320 Two other possible mechanisms for transporting UUI will be described:
321 MIME body and URI parameter transport.
323 7.1. Why INFO is Not Used
325 Since the INFO method [RFC2976], was developed for ISUP interworking
326 of user-to-user information, it might seem to be the logical choice
327 here. For non-call control user-to-user information, INFO can be
328 utilized for end to end transport. However, for transport of call
329 control user-to-user information, INFO can not be used. As the call
330 flows in [I-D.ietf-cuss-sip-uui-reqs] show, the information is
331 related to an attempt to establish a session and must be passed with
332 the session setup request (INVITE), responses to that INVITE, or
333 session termination requests. As a result, it is not possible to use
334 INFO in these cases.
336 7.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used
338 Other protocols have the ability to transport UUI information. For
339 example, consider the ITU-T Q.931 User to User Information Element
340 (UU IE) [Q931] and the ITU-T Q.763 User to User Information Parameter
341 [Q763]. In addition, NSS (Narrowband Signaling System) [Q1980] is
342 also able to transport UUI information. Should one of these
343 protocols be in use, and present in both User Agents, then utilizing
344 these other protocols to transport UUI might be a logical solution.
345 Essentially, this is just adding an additional layer in the protocol
346 stack. In these cases, SIP is not transporting the UUI; it is
347 encapsulating another protocol, and that protocol is transporting the
348 UUI. Once a mechanism to transport that other protocol using SIP
349 exists, the UUI transport function is essentially obtained without
350 any additional effort or work.
352 However, the authors believe that SIP needs to have its own native
353 UUI transport mechanism. It is not reasonable for a SIP UA to have
354 to implement another entire protocol (either ISDN or NSS, for
355 example) just to get the very simple UUI transport service. Of
356 course, this work does not preclude anyone from using other protocols
357 with SIP to transport UUI information.
359 7.3. MIME body Approach
361 One method of transport is to use a MIME body. This is in keeping
362 with the SIP-T architecture [RFC3372] in which MIME bodies are used
363 to transport ISUP information. Since the INVITE will normally have
364 an SDP message body, the resulting INVITE with SDP and UUI will be
365 multipart MIME. This is not ideal as many SIP UAs do not support
366 multipart MIME INVITEs.
368 A bigger problem is the insertion of a UUI message body by a redirect
369 server or in a REFER. The body would need to be encoded in the
370 Contact URI of the 3xx response or the Refer-To URI of a REFER.
371 Currently, the authors are not aware of any UAs that support this
372 capability today for any body type. As such, the complete set of
373 semantics for this operation would need to be determined and defined.
374 Some issues will need to be resolved, such as, do all the Content-*
375 header fields have to be escaped as well? And, what if the escaped
376 Content-Length does not agree with the escaped body?
378 Since proxies cannot remove a body from a request or response, it is
379 not at all clear how this mechanism could meet REQ-9.
381 The requirement for integrity protection could be met by the use of
382 an S/MIME signature over the body, as defined in Section 23.3 of RFC
383 3261 "Securing MIME bodies". Alternatively, this could be achieved
384 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy
385 could be met using S/MIME encryption or using encryption at the
386 application layer. However, note that neither S/MIME or RFC 4474
387 enjoys deployment in SIP today.
389 An example:
391
392 Contact:
394
396 Note that the tag convention from SIP Torture Test
397 Messages [RFC4475] is used to show that there are no line breaks in
398 the actual message syntax.
400 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5,
401 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible,
402 although the authors do not have a specific mechanism to propose.
403 Meeting REQ-3 is problematic, but not impossible for this mechanism.
404 However, this mechanism does not seem to be able to meet REQ-9.
406 7.4. URI Parameter
408 Another proposed approach is to encode the UUI as a URI parameter.
409 This UUI parameter could be included in a Request-URI or in the
410 Contact URI or Refer-To URI. It is not clear how it could be
411 transported in a responses which does not have a Request-URI, or in
412 BYE requests or responses.
414
415 Contact:
417
419 An INVITE sent to this Contact URI would contain UUI in the Request-
420 URI of the INVITE. The URI parameter has a drawback in that a URI
421 parameter carried in a Request-URI will not survive retargeting by a
422 proxy as shown in Figure 2 of [I-D.ietf-cuss-sip-uui-reqs]. That is,
423 if the URI is included with an Address of Record instead of a Contact
424 URI, the URI parameter in the Reqeuest-URI will not be copied over to
425 the Contact URI, resulting in the loss of the information. Note that
426 if this same URI was present in a Refer-To header field, the same
427 loss of information would occur.
429 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and
430 REQ-11. It is possible the approach could meet REQ-12 and REQ-13.
431 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and
432 REQ-14.
434 8. Acknowledgements
436 Joanne McMillen was a major contributor and co-author of earlier
437 versions of this document. Thanks to Spencer Dawkins, Keith Drage,
438 Vijay Gurbani, and Laura Liess for their review of the document. The
439 authors wish to thank Francois Audet, Denis Alexeitsev, Paul Kyzivat,
440 Cullen Jennings, and Mahalingam Mani for their comments.
442 9. References
444 9.1. Informative References
446 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
447 formats and codes",
448 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
450 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
451 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
453 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
454 Digital Network (ISDN); Diversion supplementary
455 services".
457 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
458 for Telephones (SIP-T): Context and Architectures",
459 BCP 63, RFC 3372, September 2002.
461 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
462 October 2000.
464 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
465 and H. Schulzrinne, "Session Initiation Protocol (SIP)
466 Torture Test Messages", RFC 4475, May 2006.
468 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -
469 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/
470 sg11aap/history/q1980.1/q1980.1.html .
472 9.2. Normative References
474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
475 Requirement Levels", BCP 14, RFC 2119, March 1997.
477 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
478 A., Peterson, J., Sparks, R., Handley, M., and E.
479 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
480 June 2002.
482 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
483 Identity", RFC 3324, November 2002.
485 [I-D.ietf-cuss-sip-uui-reqs]
486 Johnston, A. and L. Liess, "Problem Statement and
487 Requirements for Transporting User to User Call Control
488 Information in SIP", draft-ietf-cuss-sip-uui-reqs-02 (work
489 in progress), May 2011.
491 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
492 Authenticated Identity Management in the Session
493 Initiation Protocol (SIP)", RFC 4474, August 2006.
495 [I-D.ietf-sipcore-rfc4244bis]
496 Barnes, M., Audet, F., Schubert, S., Gmbh, D., and C.
497 Holmberg, "An Extension to the Session Initiation Protocol
498 (SIP) for Request History Information",
499 draft-ietf-sipcore-rfc4244bis-05 (work in progress),
500 April 2011.
502 Authors' Addresses
504 Alan Johnston
505 Avaya
506 St. Louis, MO 63124
508 Email: alan.b.johnston@gmail.com
510 James Rafferty
511 Dialogic
513 Email: james.rafferty@dialogic.com