idnits 2.17.1
draft-ietf-cuss-sip-uui-00.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 452 has weird spacing: '...ats and codes...'
-- The document date (February 7, 2011) is 4825 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 309, but not defined
== Unused Reference: 'ETSI' is defined on line 458, but no explicit
reference was found in the text
== Unused Reference: 'RFC3324' is defined on line 487, 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-01
** 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-02
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. McMillen
5 Expires: August 11, 2011 Unaffiliated
6 J. Rafferty
7 Dialogic
8 February 7, 2011
10 A Mechanism for Transporting User to User Call Control Information in
11 SIP
12 draft-ietf-cuss-sip-uui-00
14 Abstract
16 There is a need for applications using SIP to exchange User to User
17 Information (UUI) data during session establishment. This
18 information, known as call control UUI, is a small piece of data
19 inserted by an application initiating the session, and utilized by an
20 application accepting the session. This data is opaque to SIP and
21 its function is unrelated to any basic SIP function. This document
22 defines a new SIP header field, User-to-User, to transport UUI, along
23 with an extension mechanism.
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). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on August 11, 2011.
42 Copyright Notice
44 Copyright (c) 2011 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3
62 4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5
63 4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 5
64 4.2. Definition of New Parameter Values . . . . . . . . . . . . 6
65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
66 5.1. Registration of Header Field . . . . . . . . . . . . . . . 6
67 5.2. Registration of Header Field Parameters . . . . . . . . . 7
68 5.3. Registration of SIP Option Tag . . . . . . . . . . . . . . 7
69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
70 7. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 8
71 7.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 8
72 7.2. Why Other Protocol Encapsulation UUI Mechanisms are
73 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 8
74 7.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 9
75 7.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 10
76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
78 9.1. Informative References . . . . . . . . . . . . . . . . . . 10
79 9.2. Normative References . . . . . . . . . . . . . . . . . . . 11
80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
82 1. Overview
84 This document describes the transport of User to User Information
85 (UUI) using SIP [RFC3261]. Specifically, we discuss a mechanism for
86 the transport of general application UUI and also for the transport
87 of call control related ITU-T Q.931 User to User Information Element
88 (UU IE) [Q931] and ITU-T Q.763 User to User Information Parameter
89 [Q763] data in SIP. UUI is widely used in the PSTN today in contact
90 centers and call centers which are transitioning away from ISDN to
91 SIP. This extension will also be used for native SIP endpoints
92 implementing similar services and interworking with ISDN services.
94 This mechanism was designed to meet the use cases, requirements, and
95 call flows for SIP call control UUI detailed in
96 [I-D.ietf-cuss-sip-uui-reqs]. All references to requirement numbers
97 (REQ-N) and figure numbers refer to this document.
99 2. 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 BCP 14, RFC 2119
104 [RFC2119].
106 3. Requirements Discussion
108 This section describes how the User-to-User header field can meet the
109 requirements in [I-D.ietf-cuss-sip-uui-reqs]. The header field would
110 be included in INVITE requests and responses and BYE requests and
111 responses, and would pass transparently through proxies.
113 Requirements REQ-8 and REQ-10 relate to discovery of the mechanism
114 and supported applications. REQ-8 could be met by defining a new SIP
115 option tag 'uui'. The use of a 'Require: uui' in a request, or
116 'Supported: uui' in an OPTIONS response could be used to require or
117 discover support of the mechanism. REQ-10 could be met by creating a
118 new class of SIP feature tags. For example, the feature tag
119 'sip.uui.isdn' could be used to indicate support of the ISDN UUI
120 service, or 'sip.uui.app1' could be used to indicate support for a
121 particular application.
123 For redirection and referral use cases and REQ-3, the header field
124 would be escaped into the Contact or Refer-To URI. Currently, UAs
125 that support attended transfer support the ability to escape a
126 Replaces header field into a Refer-To URI, and when acting upon this
127 URI add the Replaces header field to the triggered INVITE. This
128 logic and behavior is identical for the proposed UUI header field.
130 To meet REQ-12 in redirection and referral use cases, a History-Info
131 [I-D.ietf-sipcore-rfc4244bis] extension could be used. During
132 redirection or retargeting, History-Info captures the history and the
133 identity of the entity performing the redirection or referral. A new
134 History-Info parameter could be defined to indicate that the UUI was
135 inserted during this operation. The source of UUI inserted during
136 redirection or referral could then be determined by examination of
137 the History-Info header field.
139 OPEN ISSUE: How important is it to meet this requirement? Is
140 History-Info the right way?
142 The requirement for integrity protection in REQ-13 could be met by
143 the use of an S/MIME signature over a subset of header fields, as
144 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity
145 using S/MIME: Tunneling SIP". It could not be achieved using RFC
146 4474 without some sort of extension. The requirement for end-to-end
147 privacy could be met using S/MIME or using encryption at the
148 application layer. Note that the use of S/MIME to secure the UUI
149 will result in an additional body being added to the request.
151 OPEN ISSUE: Is there interest in developing this mechanism?
153 For example, here is an example User-to-User header field from
154 message F1 in Figure 1 of [I-D.ietf-cuss-sip-uui-reqs]:
156 User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
157 ;content=isdn-uui
159 As another example, here is an escaped User-to-User header field from
160 the redirection response F2 of Figure 3:
162
163 Contact:
166
168 The resulting INVITE F5 would contain:
170 User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
171 ;content=isdn-uui
173 An escaped User-to-User header field from the REFER message response
174 F1 of Figure 4:
176
177 Refer-To:
180
182 This would result in the INVITE F4 containing:
184 User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
185 ;content=isdn-uui
187 The header field approach meets REQ-1, REQ-2, REQ-3, REQ-4, REQ-5,
188 REQ-7, REQ-9, REQ-11, REQ-13, and REQ-14. The mechanism can likely
189 meet REQ-12 with a History-Info extension.
191 4. Normative Definition
193 This document defines a new SIP header field "User-to-User" to
194 transport call control UUI to meet the requirements in
195 [I-D.ietf-cuss-sip-uui-reqs].
197 To help tag and identify the UUI used with this header field,
198 "purpose", "content", and "encoding" parameters are defined. This
199 specification only defines "encoding=hex". Other specifications can
200 define other purposes and contents for this header field per the
201 requirements of this document.
203 4.1. Syntax for UUI Header Field
205 The User-to-User header field can be present in INVITE requests and
206 responses only and in BYE requests and responses.
208 The following syntax specification uses the augmented Backus-Naur
209 Form (BNF) as described in RFC 2234 and extends RFC 3261.
211 UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param)
212 uui-data = token
213 uui-param = enc-param | cont-param | purp-param | generic-param
214 enc-param = "encoding="("hex" | token)
215 cont-param = "content=" token
216 purp-param = "purpose=" token
218 If the encoding parameter is not present, the default value of "hex"
219 MUST be assumed. Other encoding methods of encoding MAY also be
220 standardized.
222 OPEN ISSUE: Is this encoding the encoding used by SIP, or the
223 encoding used by the application? For interworking with ISDN, these
224 are not necessarily the same thing. For example, the data coming
225 from ISDN may be encoded as IA5. However, this data may then be
226 encoded in SIP as hex. Earlier versions have defined an
227 "encoding=ia5" parameter, but do we need this? Or do we actually
228 have UUI data that is encoded and transported over SIP using IA5?
230 User-to-User header fields with different purpose parameters may be
231 present in a request or response. The number of User-to-User header
232 fields which may be present in a request or response is defined for a
233 particular purpose (application). Any size limitations on the UUI
234 for a particular purpose must be defined by that purpose.
236 4.2. Definition of New Parameter Values
238 This specification defines only the values of "hex" for the
239 "encoding" parameter. New values can be defined and added to the
240 IANA registry with a standards track RFC, which needs to discuss the
241 issues in this section.
243 New "encoding" values must reference a common encoding scheme or
244 define the exact new encoding scheme.
246 New "content" values must describe the content of the UUI and give
247 some example use cases. The default "encoding" and other allowed
248 encoding methods must be defined for this new content.
250 New "purpose" values must describe the new purpose and give some
251 example use cases. The default "content" value and other allowed
252 contents must be defined for this new purpose. Any restrictions on
253 the size of the UUI data must be described for the new purpose.
255 5. IANA Considerations
257 5.1. Registration of Header Field
259 This document defines a new SIP header field named "User-to-User".
261 The following row shall be added to the "Header Fields" section of
262 the SIP parameter registry:
264 +------------------+--------------+-----------+
265 | Header Name | Compact Form | Reference |
266 +------------------+--------------+-----------+
267 | User-to-User | | [RFCXXXX] |
268 +------------------+--------------+-----------+
270 Editor's Note: [RFCXXXX] should be replaced with the designation of
271 this document.
273 5.2. Registration of Header Field Parameters
275 This document defines the parameters for the header field defined in
276 the preceding section. The header field "User-to-User" can contain
277 the parameters "encoding", "content", and "purpose".
279 The following rows shall be added to the "Header Field Parameters and
280 Parameter Values" section of the SIP parameter registry:
282 +------------------+----------------+-------------------+-----------+
283 | Header Field | Parameter Name | Predefined Values | Reference |
284 +------------------+----------------+-------------------+-----------+
285 | User-to-User | encoding | hex | [RFCXXXX] |
286 +------------------+----------------+-------------------+-----------+
288 Editor's Note: [RFCXXXX] should be replaced with the designation of
289 this document.
291 5.3. Registration of SIP Option Tag
293 This specification registers a new SIP option tag, as per the
294 guidelines in Section 27.1 of [RFC3261].
296 This document defines the SIP option tag "uui".
298 The following row has been added to the "Option Tags" section of the
299 SIP Parameter Registry:
301 +------------+------------------------------------------+-----------+
302 | Name | Description | Reference |
303 +------------+------------------------------------------+-----------+
304 | uui | This option tag is used to indicate that | [RFCXXXX] |
305 | | a UA supports and understands the | |
306 | | User-to-User header field. | |
307 +------------+------------------------------------------+-----------+
309 Editor's Note: [RFCXXXX] should be replaced with the designation of
310 this document.
312 6. Security Considerations
314 User to user information can potentially carry sensitive information
315 that might require privacy or integrity protection. Standard
316 deployed SIP security mechanisms such as TLS transport, offer these
317 properties on a hop-by-hop basis. To preserve multi-hop or end-to-
318 end confidentiality and integrity of UUI, approaches using S/MIME or
319 RFC 4474 can be used, as discussed in the draft. However, the lack
320 of deployment of these mechanisms means that applications can not in
321 general rely on them. As such, applications are encouraged to
322 utilize their own security mechanisms.
324 7. Appendix - Other Possible Mechanisms
326 Two other possible mechanisms for transporting UUI will be described:
327 MIME body and URI parameter transport.
329 7.1. Why INFO is Not Used
331 Since the INFO method [RFC2976], was developed for ISUP interworking
332 of user-to-user information, it might seem to be the logical choice
333 here. For non-call control user-to-user information, INFO can be
334 utilized for end to end transport. However, for transport of call
335 control user-to-user information, INFO can not be used. As the call
336 flows in [I-D.ietf-cuss-sip-uui-reqs] show, the information is
337 related to an attempt to establish a session and must be passed with
338 the session setup request (INVITE), responses to that INVITE, or
339 session termination requests. As a result, it is not possible to use
340 INFO in these cases.
342 7.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used
344 Other protocols have the ability to transport UUI information. For
345 example, consider the ITU-T Q.931 User to User Information Element
346 (UU IE) [Q931] and the ITU-T Q.763 User to User Information Parameter
347 [Q763]. In addition, NSS (Narrowband Signaling System) [Q1980] is
348 also able to transport UUI information. Should one of these
349 protocols be in use, and present in both User Agents, then utilizing
350 these other protocols to transport UUI might be a logical solution.
351 Essentially, this is just adding an additional layer in the protocol
352 stack. In these cases, SIP is not transporting the UUI; it is
353 encapsulating another protocol, and that protocol is transporting the
354 UUI. Once a mechanism to transport that other protocol using SIP
355 exists, the UUI transport function is essentially obtained without
356 any additional effort or work.
358 However, the authors believe that SIP needs to have its own native
359 UUI transport mechanism. It is not reasonable for a SIP UA to have
360 to implement another entire protocol (either ISDN or NSS, for
361 example) just to get the very simple UUI transport service. Of
362 course, this work does not preclude anyone from using other protocols
363 with SIP to transport UUI information.
365 7.3. MIME body Approach
367 One method of transport is to use a MIME body. This is in keeping
368 with the SIP-T architecture [RFC3372] in which MIME bodies are used
369 to transport ISUP information. Since the INVITE will normally have
370 an SDP message body, the resulting INVITE with SDP and UUI will be
371 multipart MIME. This is not ideal as many SIP UAs do not support
372 multipart MIME INVITEs.
374 A bigger problem is the insertion of a UUI message body by a redirect
375 server or in a REFER. The body would need to be encoded in the
376 Contact URI of the 3xx response or the Refer-To URI of a REFER.
377 Currently, the authors are not aware of any UAs that support this
378 capability today for any body type. As such, the complete set of
379 semantics for this operation would need to be determined and defined.
380 Some issues will need to be resolved, such as, do all the Content-*
381 header fields have to be escaped as well? And, what if the escaped
382 Content-Length does not agree with the escaped body?
384 Since proxies cannot remove a body from a request or response, it is
385 not at all clear how this mechanism could meet REQ-9.
387 The requirement for integrity protection could be met by the use of
388 an S/MIME signature over the body, as defined in Section 23.3 of RFC
389 3261 "Securing MIME bodies". Alternatively, this could be achieved
390 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy
391 could be met using S/MIME encryption or using encryption at the
392 application layer. However, note that neither S/MIME or RFC 4474
393 enjoys deployment in SIP today.
395 An example:
397
398 Contact:
400
402 Note that the tag convention from SIP Torture Test
403 Messages [RFC4475] is used to show that there are no line breaks in
404 the actual message syntax.
406 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5,
407 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible,
408 although the authors do not have a specific mechanism to propose.
409 Meeting REQ-3 is problematic, but not impossible for this mechanism.
410 However, this mechanism does not seem to be able to meet REQ-9.
412 7.4. URI Parameter
414 Another proposed approach is to encode the UUI as a URI parameter.
415 This UUI parameter could be included in a Request-URI or in the
416 Contact URI or Refer-To URI. It is not clear how it could be
417 transported in a responses which does not have a Request-URI, or in
418 BYE requests or responses.
420
421 Contact:
423
425 An INVITE sent to this Contact URI would contain UUI in the Request-
426 URI of the INVITE. The URI parameter has a drawback in that a URI
427 parameter carried in a Request-URI will not survive retargeting by a
428 proxy as shown in Figure 2 of [I-D.ietf-cuss-sip-uui-reqs]. That is,
429 if the URI is included with an Address of Record instead of a Contact
430 URI, the URI parameter in the Reqeuest-URI will not be copied over to
431 the Contact URI, resulting in the loss of the information. Note that
432 if this same URI was present in a Refer-To header field, the same
433 loss of information would occur.
435 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and
436 REQ-11. It is possible the approach could meet REQ-12 and REQ-13.
437 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and
438 REQ-14.
440 8. Acknowledgements
442 Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura
443 Liess for their review of the document. The authors wish to thank
444 Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and
445 Mahalingam Mani for their comments.
447 9. References
449 9.1. Informative References
451 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
452 formats and codes",
453 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
455 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
456 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
458 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
459 Digital Network (ISDN); Diversion supplementary
460 services".
462 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
463 for Telephones (SIP-T): Context and Architectures",
464 BCP 63, RFC 3372, September 2002.
466 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
467 October 2000.
469 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
470 and H. Schulzrinne, "Session Initiation Protocol (SIP)
471 Torture Test Messages", RFC 4475, May 2006.
473 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -
474 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/
475 sg11aap/history/q1980.1/q1980.1.html .
477 9.2. Normative References
479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
480 Requirement Levels", BCP 14, RFC 2119, March 1997.
482 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
483 A., Peterson, J., Sparks, R., Handley, M., and E.
484 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
485 June 2002.
487 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
488 Identity", RFC 3324, November 2002.
490 [I-D.ietf-cuss-sip-uui-reqs]
491 Johnston, A., McMillen, J., and L. Liess, "Problem
492 Statement and Requirements for Transporting User to User
493 Call Control Information in SIP",
494 draft-ietf-cuss-sip-uui-reqs-01 (work in progress),
495 December 2010.
497 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
498 Authenticated Identity Management in the Session
499 Initiation Protocol (SIP)", RFC 4474, August 2006.
501 [I-D.ietf-sipcore-rfc4244bis]
502 Barnes, M., Audet, F., Schubert, S., Netherlands, T., and
503 C. Holmberg, "An Extension to the Session Initiation
504 Protocol (SIP) for Request History Information",
505 draft-ietf-sipcore-rfc4244bis-02 (work in progress),
506 October 2010.
508 Authors' Addresses
510 Alan Johnston
511 Avaya
512 St. Louis, MO 63124
514 Email: alan.b.johnston@gmail.com
516 Joanne McMillen
517 Unaffiliated
519 Email: c.joanne.mcmillen@gmail.com
521 James Rafferty
522 Dialogic
524 Email: james.rafferty@dialogic.com