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