idnits 2.17.1
draft-johnston-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 420 has weird spacing: '...ats and codes...'
-- The document date (September 16, 2010) is 4968 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 385, but not defined
== Unused Reference: 'ETSI' is defined on line 426, 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
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group A. Johnston, Ed.
3 Internet-Draft Avaya
4 Intended status: Standards Track J. McMillen
5 Expires: March 20, 2011 Unaffiliated
6 J. Rafferty
7 Dialogic
8 September 16, 2010
10 A Mechanism for Transporting User to User Call Control Information in
11 SIP
12 draft-johnston-cuss-sip-uui-00
14 Abstract
16 The need for applications using SIP to exchange User to User
17 Information (UUI) data during session establishment has been
18 discussed. Several approaches to transporting call control User to
19 User Information (UUI) data in SIP have been proposed. As networks
20 move to SIP it is important that applications requiring this data can
21 continue to function in SIP networks as well as the ability to
22 interwork with this ISDN service for end-to- end transparency. This
23 document discusses three mechanisms to meet the requirements defined
24 in the Requirements for SIP Call Control UUI document. A new SIP
25 header field which bests meets these requirements is proposed.
27 Status of this Memo
29 This Internet-Draft is submitted to IETF in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on March 20, 2011.
44 Copyright Notice
46 Copyright (c) 2010 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 3. Possible Mechanisms . . . . . . . . . . . . . . . . . . . . . 3
64 3.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 3
65 3.2. Why Other Protocol Encapsulation UUI Mechanisms are
66 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 3.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 4
68 3.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 5
69 3.5. Header Field Approach . . . . . . . . . . . . . . . . . . 5
70 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6
71 5. Syntax for UUI Header Field . . . . . . . . . . . . . . . . . 7
72 5.1. Definition of New Parameter Values . . . . . . . . . . . . 7
73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
74 6.1. Registration of Header Field . . . . . . . . . . . . . . . 8
75 6.2. Registration of Header Field Parameters . . . . . . . . . 8
76 6.3. Registration of SIP Option Tag . . . . . . . . . . . . . . 9
77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
80 9.1. Informative References . . . . . . . . . . . . . . . . . . 10
81 9.2. Normative References . . . . . . . . . . . . . . . . . . . 10
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
84 1. Overview
86 This document describes the transport of User to User Information
87 (UUI) using SIP [RFC3261]. Specifically, we discuss a mechanism for
88 the transport of general application UUI and also for the transport
89 of call control related ITU-T Q.931 User to User Information Element
90 (UU IE) [Q931] and ITU-T Q.763 User to User Information Parameter
91 [Q763] data in SIP. UUI is widely used in the PSTN today in contact
92 centers and call centers which are transitioning away from ISDN to
93 SIP. This extension will also be used for native SIP endpoints
94 implementing similar services and interworking with ISDN services.
96 The definition, use cases, requirements, and call flows for SIP call
97 control UUI is discussed in [johnston-cuss-sip-uui-reqs]. All
98 references to requirement numbers (REQ-N) and figure numbers refer to
99 this draft.
101 2. Terminology
103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
105 document are to be interpreted as described in BCP 14, RFC 2119
106 [RFC2119].
108 3. Possible Mechanisms
110 Three possible mechanisms for transporting UUI will be described:
111 MIME body, URI parameter, and header field transport.
113 3.1. Why INFO is Not Used
115 Since the INFO method [RFC2976], was developed for ISUP interworking
116 of user-to-user information, it might seem to be the logical choice
117 here. For non-call control user-to-user information, INFO can be
118 utilized for end to end transport. However, for transport of call
119 control user-to-user information, INFO can not be used. As the call
120 flows in the previous section show, the information is related to an
121 attempt to establish a session and must be passed with the session
122 setup request (INVITE), responses to that INVITE, or session
123 termination requests. As a result, it is not possible to use INFO in
124 these cases.
126 3.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used
128 Other protocols have the ability to transport UUI information. For
129 example, consider ITU-T Q.931 User to User Information Element (UU
130 IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763],
131 as discussed in the requirements draft. In addition, NSS (Narrowband
132 Signaling System) [Q1980] is also able to transport UUI information.
133 Should one of these protocols be in use, and present in both User
134 Agents, then utilizing these other protocols to transport UUI might
135 make a lot of sense. Essentially, this is just adding an additional
136 layer in the protocol stack. SIP is not transporting the UUI, it is
137 encapsulating another protocol, and that protocol is transporting the
138 UUI. Once there is a mechanism to transport that other protocol
139 using SIP, the UUI transport function is essentially obtained without
140 any additional effort or work.
142 However, the authors believe that SIP needs to have its own native
143 UUI transport mechanism. It is not reasonable for a SIP UA to have
144 to implement another entire protocol (either ISDN or NSS, for
145 example) just to get the very simple UUI transport service. Of
146 course, this work does not preclude anyone from using other protocols
147 with SIP to transport UUI information.
149 3.3. MIME body Approach
151 One method of transport is to transport the UUI information as a MIME
152 body. This is in keeping with the SIP-T architecture [RFC3372] in
153 which MIME bodies are used to transport ISUP information. Since the
154 INVITE will normally have an SDP message body, the resulting INVITE
155 with SDP and UUI will be multipart MIME. This is not ideal as many
156 SIP UAs do not support multipart MIME INVITEs.
158 A bigger problem is the insertion of a UUI message body by a redirect
159 server or in a REFER. The body would need to be encoded in the
160 Contact URI of the 3xx response or the Refer-To URI of a REFER.
161 Currently, no UAs support this capability today, and even defining
162 this is problematic. For example, do all the Content-* header fields
163 have to be escaped as well? What if the escaped Content-Length does
164 not agree with the escaped body?
166 An example:
168
169 Contact:
171
173 Note that the tag convention from SIP Torture Test
174 Messages [RFC4475] is used to show that there are no line breaks in
175 the actual message syntax.
177 The MIME body approach meets REQs 1-5. However, it does not meet
178 REQ-6 as support for Multipart MIME and escaped bodies in URIs is
179 uncommon in SIP UAs.
181 3.4. URI Parameter
183 Another proposed approach is to encode the UUI as a URI parameter
184 into the Contact or Refer-To URI.
186
187 Contact:
189
191 An INVITE sent to this Contact URI would contain UUI in the Request-
192 URI of the INVITE. The URI parameter has a drawback in that a URI
193 parameter carried in a Request-URI will not survive retargeting by a
194 proxy as shown in Figure 2 of [johnston-cuss-sip-uui-reqs]. That is,
195 if the URI is included with an Address of Record instead of a Contact
196 URI, the URI parameter in the Reqeuest-URI will not be copied over to
197 the Contact URI, resulting in the loss of the information. As a
198 result, this approach does not meet REQ-4. Note that if this same
199 URI was present in a Refer-To header field, the same loss of
200 information would occur.
202 3.5. Header Field Approach
204 Another approach that has been proposed is to use a header field to
205 transport the UUI information. The header field would be included in
206 INVITE requests and responses and BYE requests and responses, and
207 would pass transparently through proxies. For redirection, the
208 header field would be escaped into the Contact or Refer-To URI. This
209 is commonly supported in UAs due to call transfer use cases. As a
210 result, the header field approach supports REQs 1-7. In order to
211 meet REQ- 8, a SIP feature tag is needed which can be included in
212 Supported and Require header fields.
214 The Call-Info header field is related to the UUI information.
215 However, there are a number of important differences:
217 o Call-Info is typically used for rendering to the user. While some
218 of the UUI information may ultimately be rendered to the user,
219 most of the UUI information will be consumed by the end device or
220 by an application server.
221 o Call-Info usually contains a URI pointer to the information
222 instead of the actual information itself which does not meet
223 REQ-5. It could be possible to use a data URI to carry the UUI
224 directly in this header field.
226 o The use of Call-Info for interworking to and from ISDN networks
227 seems problematic.
229 Overall, the overloading of the Call-Info header field for carrying
230 interworked UUI does not seem like a good idea. A separate header
231 field allows for clear policy and authorization rules to be used.
232 For these reasons, a separate header field needs to be defined,
233 described here as User-to-User. For example, here is an example
234 User-to-User header field from message F1 in Figure 1 of
235 [johnston-cuss-sip-uui-reqs]:
237 User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
238 ;content=isdn-uui
240 For example, here is an escaped User-to-User header field from the
241 redirection response F2 of Figure 3:
243
244 Contact:
247
249 The resulting INVITE F5 would contain:
251 User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
252 ;content=isdn-uui
254 An escaped User-to-User header field from the REFER message response
255 F1 of Figure 4:
257
258 Refer-To:
261
263 This would result in the INVITE F4 containing:
265 User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
266 ;content=isdn-uui
268 4. Recommendation
270 The recommendation is to define a new SIP header field "User-to-User"
271 to transport call control UUI since this mechanism best supports the
272 requirements in [johnston-cuss-sip-uui-reqs]. There are also
273 existing implementations and running code for this header field
274 approach. A SIP feature tag "uui" also needs to be defined so that
275 it can be used in Supported and Require header fields to meet REQ-8.
277 To help tag and identify the UUI used with this header field,
278 "purpose", "content", and "encoding" parameters are defined. This
279 specification only defines encodings of hex and IA5. Other
280 specifications can define other purposes and contents for this header
281 field per the requirements of this document.
283 5. Syntax for UUI Header Field
285 The User-to-User header field can be present in INVITE requests and
286 responses only and in BYE requests and responses.
288 The following syntax specification uses the augmented Backus-Naur
289 Form (BNF) as described in RFC 2234 and extends RFC 3261.
291 UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param)
292 uui-data = token
293 uui-param = enc-param | cont-param | purp-param | generic-param
294 enc-param = "encoding=" ("hex" | "IA5" | token)
295 cont-param = "content=" token
296 purp-param = "purpose=" token
298 The parameter "encoding=hex" means hexadecimal encoding. The
299 parameter "encoding=IA5" means Internet Alphabet Number 5 encoding,
300 also known as ITU-T T.50 [ia5]. If the encoding parameter is not
301 present, the default value of "hex" MUST be assumed. Other encoding
302 methods of encoding MAY also be standardized.
304 User-to-User header fields with different purpose parameters may be
305 present in a request or response. The number of User-to-User header
306 fields which may be present in a request or response is defined for a
307 particular purpose (application). Any size limitations on the UUI
308 for a particular purpose must be defined by that purpose.
310 5.1. Definition of New Parameter Values
312 This specification defines only the values of "hex", "IA5", and for
313 the "encoding" parameter. New values can be defined and added to the
314 IANA registry with a standards track RFC, which needs to discuss the
315 issues in this section.
317 New "encoding" values must reference a common encoding scheme or
318 define the exact new encoding scheme.
320 New "content" values must describe the content of the UUI and give
321 some example use cases. The default "encoding" and other allowed
322 encoding methods must be defined for this new content.
324 New "purpose" values must describe the new purpose and give some
325 example use cases. The default "content" value and other allowed
326 contents must be defined for this new purpose. Any restrictions on
327 the size of the UUI data must be described for the new purpose.
329 6. IANA Considerations
331 6.1. Registration of Header Field
333 This document defines a new SIP header field named "User-to-User".
335 The following row shall be added to the "Header Fields" section of
336 the SIP parameter registry:
338 +------------------+--------------+-----------+
339 | Header Name | Compact Form | Reference |
340 +------------------+--------------+-----------+
341 | User-to-User | | [RFCXXXX] |
342 +------------------+--------------+-----------+
344 Editor's Note: [RFCXXXX] should be replaced with the designation of
345 this document.
347 6.2. Registration of Header Field Parameters
349 This document defines the parameters for the header field defined in
350 the preceding section. The header field "User-to-User" can contain
351 the parameters "encoding", "content", and "purpose".
353 The following rows shall be added to the "Header Field Parameters and
354 Parameter Values" section of the SIP parameter registry:
356 +------------------+----------------+-------------------+-----------+
357 | Header Field | Parameter Name | Predefined Values | Reference |
358 +------------------+----------------+-------------------+-----------+
359 | User-to-User | encoding | hex | [RFCXXXX] |
360 +------------------+----------------+-------------------+-----------+
361 | User-to-User | encoding | IA5 | [RFCXXXX] |
362 +------------------+----------------+-------------------+-----------+
364 Editor's Note: [RFCXXXX] should be replaced with the designation of
365 this document.
367 6.3. Registration of SIP Option Tag
369 This specification registers a new SIP option tag, as per the
370 guidelines in Section 27.1 of [RFC3261].
372 This document defines the SIP option tag "uui".
374 The following row has been added to the "Option Tags" section of the
375 SIP Parameter Registry:
377 +------------+------------------------------------------+-----------+
378 | Name | Description | Reference |
379 +------------+------------------------------------------+-----------+
380 | uui | This option tag is used to indicate that | [RFCXXXX] |
381 | | a UA supports and understands the | |
382 | | User-to-User header field. | |
383 +------------+------------------------------------------+-----------+
385 Editor's Note: [RFCXXXX] should be replaced with the designation of
386 this document.
388 7. Security Considerations
390 User to user information can be exchanged over SIP on a hop-by-hop or
391 end-to-end basis. In some cases, UUI may carry privacy information
392 that would require confidentiality and message integrity. Standard
393 SIP security mechanisms, viz., based on TLS, offer these properties
394 per-hop. To preserve multi-hop or end-end confidentiality and
395 integrity, S/MIME profile MUST be utilized. Since the security
396 requirements and key management of the UUI information are likely to
397 be quite different from the SIP signaling transport, another approach
398 would be for the UUI information to be encrypted before being passed
399 to SIP for transport.
401 Received User-to-User information should only be trusted if it is
402 authenticated or if it is received within a trust domain. For
403 example, Spec-T, defined in [RFC3324] could be used to define a trust
404 domain. When utilized by a gateway to map information to or from
405 ISDN Q.931 and ISUP Q.763, appropriate policy should be applied based
406 on the PSTN trust domain.
408 8. Acknowledgements
410 Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura
411 Liess for their review of the document. The authors wish to thank
412 Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and
413 Mahalingam Mani for their comments.
415 9. References
417 9.1. Informative References
419 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
420 formats and codes",
421 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
423 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
424 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
426 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
427 Digital Network (ISDN); Diversion supplementary
428 services".
430 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
431 for Telephones (SIP-T): Context and Architectures",
432 BCP 63, RFC 3372, September 2002.
434 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
435 October 2000.
437 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
438 and H. Schulzrinne, "Session Initiation Protocol (SIP)
439 Torture Test Messages", RFC 4475, May 2006.
441 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -
442 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/
443 sg11aap/history/q1980.1/q1980.1.html .
445 9.2. Normative References
447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
448 Requirement Levels", BCP 14, RFC 2119, March 1997.
450 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
451 A., Peterson, J., Sparks, R., Handley, M., and E.
452 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
453 June 2002.
455 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
456 Identity", RFC 3324, November 2002.
458 [johnston-cuss-sip-uui-reqs]
459 Johnston, A., McMillen, J., and L. Liess, "Problem
460 Statement and Requirements for Transporting User to User
461 Call Control Information in SIP",
462 draft-johnston-cuss-sip-uui-reqs-00 .
464 [ia5] "T.50 : International Reference Alphabet (IRA) (Formerly
465 International Alphabet No. 5 or IA5) - Information
466 technology - 7-bit coded character set for information
467 interchange",
468 http://www.itu.int/rec/T-REC-T.50-199209-I/en .
470 Authors' Addresses
472 Alan Johnston (editor)
473 Avaya
474 St. Louis, MO 63124
476 Email: alan.b.johnston@gmail.com
478 Joanne McMillen
479 Unaffiliated
481 Email: c.joanne.mcmillen@gmail.com
483 James Rafferty
484 Dialogic
486 Email: james.rafferty@dialogic.com