idnits 2.17.1 draft-ietf-cuss-sip-uui-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 2, 2012) is 4134 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 572, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-cuss-sip-uui-isdn-04 ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-12) exists of draft-ietf-sipcore-rfc4244bis-10 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: June 5, 2013 Dialogic 6 December 2, 2012 8 A Mechanism for Transporting User to User Call Control Information in 9 SIP 10 draft-ietf-cuss-sip-uui-08 12 Abstract 14 There is a class of applications which benefit from using SIP to 15 exchange User to User Information (UUI) data during session 16 establishment. This information, known as call control UUI data, is 17 a small piece of data inserted by an application initiating the 18 session, and utilized by an application accepting the session. The 19 rules which apply for a specific application are defined by a UUI 20 package. This UUI data is opaque to SIP and its function is 21 unrelated to any basic SIP function. This document defines a new SIP 22 header field, User-to-User, to transport UUI data, along with an 23 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 June 5, 2013. 42 Copyright Notice 44 Copyright (c) 2012 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 . . . . . . . . . . . . . . . 6 64 4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7 65 4.3. Source Identity of UUI data . . . . . . . . . . . . . . . 7 66 5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 8 67 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Registration of User-to-User Header Field . . . . . . . . 11 70 6.2. Registration of User-to-User Header Field Parameters . . . 11 71 6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 11 72 6.4. Registration of UUI Content Parameters . . . . . . . . . . 12 73 6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12 74 6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 13 77 8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 13 78 8.2. Why Other Protocol Encapsulation UUI Mechanisms are 79 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 14 81 8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 15 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 10.1. Informative References . . . . . . . . . . . . . . . . . . 16 85 10.2. Normative References . . . . . . . . . . . . . . . . . . . 17 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Overview 90 This document describes the transport of User to User Information 91 (UUI) data using SIP [RFC3261]. A mechanism is defined for the 92 transport of general application UUI data and for the transport of 93 call control related ITU-T Q.931 User to User Information Element (UU 94 IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763] 95 data in SIP. UUI data is widely used in the PSTN today for contact 96 centers and call centers. There is also a trend for the related 97 applications to transition from ISDN to SIP. The UUI extension for 98 SIP may also be used for native SIP UAs implementing similar services 99 and to interwork with ISDN services. Note that in most cases, there 100 is an a priori understanding between the UAs in regard to what to do 101 with received UUI data. 103 This mechanism was designed to meet the use cases, requirements, and 104 call flows for SIP call control UUI detailed in [RFC6567]. All 105 references to requirement numbers (REQ-N) and figure numbers refer to 106 this document. 108 The mechanism is a new SIP header field, along with a new SIP option 109 tag. The header field carries the UUI data, along with parameters 110 indicating the encoding of the UUI data, the UUI package, and 111 optionally the content of the UUI data. The package definition 112 contains details about how a particular application can utilize the 113 UUI mechanism. The header field can be included (sometimes called 114 "escaped") into URIs supporting referral and redirection scenarios. 115 In these scenarios, History-Info is used to indicate the inserter of 116 the UUI data. The SIP option tag can be used to indicate support for 117 the header field. Support for the UUI header field indicates that a 118 UA is able to extract the information in the UUI data and pass it up 119 the protocol stack. Individual packages using the UUI mechanism can 120 utlize SIP media feature tags to indicate that a UA supports a 121 particular UUI package. Guidelines for defining UUI packages are 122 provided. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14, RFC 2119 [RFC2119]. 131 3. Requirements Discussion 133 This section describes how the User-to-User header field meets the 134 requirements in [RFC6567]. The header field can be included in 135 INVITE requests and responses and BYE requests and responses, meeting 136 REQ-1 and REQ-2. 138 For redirection and referral use cases and REQ-3, the header field 139 shall be included (escaped) into the Contact or Refer-To URI. 140 Currently, UAs that support attended transfer support the ability to 141 include a Replaces header field [RFC3891] into a Refer-To URI, and 142 when acting upon this URI add the Replaces header field to the 143 triggered INVITE. This logic and behavior is identical for the UUI 144 header field. The UA processing the REFER or the 3xx to the INVITE 145 will need to support the UUI mechanism, as UAs in general do not 146 process unknown included header fields. 148 Since SIP proxy forwarding and retargeting does not affect header 149 fields, the header field meets REQ-4. 151 The UUI header field will carry the UUI data and not a pointer to the 152 data, so REQ-5 is met. 154 Since the basic design of the UUI header field is similar to the ISDN 155 UUI service, interworking with PSTN protocols is straightforward and 156 is documented in a separate specification 157 [I-D.ietf-cuss-sip-uui-isdn], meeting REQ-6. 159 Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the 160 mechanism and supported packages, and hence applications. REQ-7 161 relates to support of the UUI header field, while REQ-8 relates to 162 routing based on support of the UUI header field. REQ-7 is met by 163 defining a new SIP option tag 'uui'. The use of a Require:uui in a 164 request, or Supported:uui in an OPTIONS response could be used to 165 require or discover support of the mechanism. The presence of a 166 Supported:uui or Require:uui header field can be used by proxies to 167 route to an appropriate UA, meeting REQ-8. However, note that only 168 UAs are expected to understand the UUI data - proxies and other 169 intermediaries do not. REQ-10 is met by utlizing SIP feature tags 170 [RFC3840]. For example, the feature tag 'sip.uui-isdn' could be used 171 to indicate support of the ISDN UUI package, or 'sip.uui-pk1' could 172 be used to indicate support for a particular package, pk1. 174 Proxies commonly apply policy to the presence of certain SIP header 175 fields in requests by either passing them or removing them from 176 requests. REQ-9 is met by allowing proxies and other intermediaries 177 to remove UUI header fields in a request or response based on policy. 179 Carrying UUI data elements of at least 129 octets is trivial in the 180 UUI header field, meeting REQ-11. Note that very large UUI data 181 elements should be avoided, as SIP header fields have traditionally 182 not been large. 184 To meet REQ-12 for the redirection and referral use cases, History- 185 Info [I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting 186 cases, the changed Request-URI will be recorded in the History-Info 187 header field along with the identity of the element that performed 188 the retargeting. 190 The requirement for integrity protection in REQ-13 could be met by 191 the use of an S/MIME signature over a subset of header fields, as 192 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity 193 using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to- 194 end privacy could be met using S/MIME or using encryption at the 195 application layer. Note that the use of S/MIME to secure the UUI 196 data will result in an additional body being added to the request. 197 Hop-wise Transport Layer Security (TLS) [RFC5246] allows the header 198 field to meet REQ-15 for hop-by-hop security. 200 4. Normative Definition 202 This document defines a new SIP header field "User-to-User" to 203 transport call control UUI data to meet the requirements in 204 [RFC6567]. 206 To help tag and identify the UUI data used with this header field, 207 "purpose", "content", and "encoding" header field parameters are 208 defined. The "purpose" header field parameter identifies the package 209 which defines the generation and usage of the UUI data for a 210 particular application. For the case of interworking with the ISDN 211 UUI Service, the ISDN UUI Service interworking package is used. If 212 the "purpose" header field parameter is not present, interworking 213 with the ISDN UUI Service MUST be assumed. The "content" header 214 field parameter identifies the actual content of the UUI data. If 215 not present, the content MUST be assumed to be the default defined 216 for the package. Newly defined UUI packages MUST define or reference 217 at least a default "content" value. The "encoding" header field 218 parameter indicates the method of encoding the information in the UUI 219 data associated with a particular "content" value. This 220 specification only defines "encoding=hex". If the "encoding" header 221 field parameter is not present, the encoding MUST be assumed to be 222 the default defined for the package. 224 UUI data is considered an opaque series of octets. This mechanism 225 SHOULD NOT be used to convey a URL or URI; the Call-Info header field 226 [RFC3261] is used for this purpose. 228 4.1. Syntax for UUI Header Field 230 The User-to-User (UUI) header field can be present in INVITE requests 231 and responses only and in BYE requests and responses. Note that when 232 the UUI header is used in responses, it can only be utilized in end- 233 to-end responses, e.g. 1xx (excluding 100), 2xx, and 3xx responses. 235 The following syntax specification uses the augmented Backus-Naur 236 Form (BNF) as described in RFC 5234 and extends RFC 3261 (where token 237 and quoted-string are defined). 239 UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value) 240 uui-value = uui-data *(SEMI uui-param) 241 uui-data = token / quoted-string 242 uui-param = pkg-param / cont-param / enc-param / generic-param 243 pkg-param = "purpose" EQUAL token 244 cont-param = "content" EQUAL token 245 enc-param = "encoding" EQUAL ("hex" / token) 247 The rules for how many User-to-User header fields of each package may 248 be present in a request or a response are defined for each package. 249 Multiple User-to-User header fields MAY be present in a request or 250 response. Consistent with the rules of SIP syntax, the syntax 251 defined in this document allows any combination of individual User- 252 to-User header fields or User-to-User header fields with multiple 253 comma separated UUI data elements. Any size limitations on the UUI 254 data for a particular purpose must be defined by the related UUI 255 package. 257 UAs SHOULD ignore UUI data from packages or encoding that they do not 258 understand. 260 If an element supports this specification, it SHOULD include any UUI 261 data included in a redirection URI (if the UUI data and encoding is 262 understood). Note that redirection can occur multiple times to a 263 request. 265 Here is an example of an included User-to-User header field from the 266 redirection response F2 of Figure 2: 268 269 Contact: 272 274 The resulting INVITE F4 would contain: 276 User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar 278 4.2. Hex Encoding Definition 280 This specification defines hex encoding of UUI data. The value of 281 "hex" for the "encoding" header field parameter is normatively 282 defined in this section. It is used to encode binary UUI data with a 283 length that terminates at an octet boundary. Each octet of binary 284 data to be represented in the hex encoding MUST be mapped to two 285 hexadecimal digits (represented by ASCII characters 0-9, A-F and 286 a-f), each representing four bits within the octet. The four bits 287 appearing first in the binary UUI data MUST be mapped to the first 288 hexadecimal digit and the four subsequent bits in the binary UUI data 289 MUST be mapped to the second hexadecimal digit. When mapping 4 bits 290 to a hexadecimal digit, the bit appearing first in the binary UUI 291 data shall be most significant. Thus, Hex encoded UUI data must have 292 an even number of hexadecimal digits, and MUST be considered invalid 293 if it has an odd number. Hex encoding is normally done as a token, 294 although quoted-string is permitted, in which case the quotes MUST be 295 ignored. 297 4.3. Source Identity of UUI data 299 It is important for the recipient of UUI data to know the identity of 300 the UA that inserted the UUI data. In a request without a History- 301 Info [I-D.ietf-sipcore-rfc4244bis] header field, the identity of the 302 entity which inserted the UUI data will be assumed to be the source 303 of the SIP message. For a SIP request, typically this is the UA 304 identified by the URI in the From header field or a P-Asserted- 305 Identity [RFC3325] header field. In a request with a History-Info 306 header field, the recipient needs to parse the Targeted-to-URIs 307 present (hi-targeted-to-uri) to see if any included User-to-User 308 header fields are present. If an included User-to-User header field 309 is present and matches the UUI data in the request, this indicates 310 that redirection has taken place, resulting in the inclusion of UUI 311 data in the request. The inserter of the UUI data will be the UA 312 identified by the Targeted-to-URI of the History-Info element prior 313 to the element with the included UUI data. In a response, the 314 inserter of the UUI data will be the identity of the UA that 315 generated the response. Typically, this is the UA identified in the 316 To header field of the response. Note that any updates to this 317 identity by use of the SIP Connected Identity extension [RFC4916] or 318 others will update this information. 320 For an example of History-Info and redirection, consider Figure 2 321 from [RFC6567] where the Originating UA is Carol, the Redirector Bob, 322 and the Terminating UA Alice. The INVITE F4 containing UUI data 323 could be: 325 INVITE sips:alice@example.com SIP/2.0 326 Via: SIP/2.0/TLS lab.example.com:5061 327 ;branch=z9hG4bKnashds9 328 To: Bob 329 From: Carol ;tag=323sf33k2 330 Call-ID: dfaosidfoiwe83ifkdf 331 Max-Forwards: 70 332 Contact: 333 Supported: histinfo 334 User-to-User: 342342ef34;encoding=hex 335 History-Info: ;index=1 336 337 History-Info: ;index=1.1;rc=1 339 341 Without the redirection captured in the History-Info, Alice would 342 conclude the UUI data was inserted by Carol. However, the History- 343 Info containing UUI data (index=1.1) indicates that the inserter was 344 Bob (index=1). 346 Note that the tag convention from SIP Torture Test 347 Messages [RFC4475] is used to show that there are no line breaks in 348 the actual message syntax. 350 To enable maintaining a record of the inserter identity of UUI data, 351 UAs supporting this mechanism SHOULD support History-Info 352 [I-D.ietf-sipcore-rfc4244bis] and include Supported: histinfo in all 353 requests and responses. 355 Border elements such as proxies or Back-to-Back User Agents (B2BUAs) 356 which anonymize a SIP URI in a History-Info header field SHOULD leave 357 the corresponding User-to-User parameter, if present, and the 358 corresponding User-to-User header field unchanged. Border elements 359 removing a History-Info header containing a User-to-User parameter 360 SHOULD NOT drop the corresponding User-to-User header. Otherwise, 361 the UA consuming the UUI data may not be able at SIP level to 362 identify the source of the UUI data. 364 5. Guidelines for UUI Packages 366 UUI packages defined using this SIP UUI mechanism MUST follow the 367 "RFC Required" guideline as defined in [RFC5226] and publish a 368 standards track RFC which describes the usage. Note that this 369 mechanism is not suitable for the transport of arbitrary data between 370 UAs. The following guidelines are provided to help determine if this 371 mechanism is appropriate or some other SIP mechanism should be used. 373 The SIP UUI mechanism is applicable when all of the following 374 conditions be met: 376 1. The information is generated and consumed by an application 377 during session setup using SIP, but the application is not 378 necessarily SIP aware. 380 2. The behavior of SIP entities that support it is not 381 significantly changed (as discussed in Section 4 of [RFC5727]). 383 3. User Agents (UAs) are the generators and consumers of the UUI 384 data. Proxies and other intermediaries may route based on the 385 presence of a User-to-User header field or a particular package 386 tag but do not otherwise consume or generate the UUI data. 388 4. There are no overriding privacy issues associated with the 389 information being transported (e.g., geolocation or emergency- 390 related information are examples of inappropriate UUI data). 392 5. The UUI data is not being utilized for user-to-user Remote 393 Procedure Call (RPC) calls. 395 UUI packages define the semantics for a particular application usage 396 of UUI data. The content defines the syntax of the UUI data, while 397 the encoding defines the encoding of the UUI data for the content. 398 Each content is defined as a stream of octets, which allows multiple 399 encodings of that content. For example, packages may define: 401 1. The SIP methods and responses in which the UUI data may be 402 present. 404 2. The maximum number of UUI data elements that may be inserted 405 into a request or response. (The default is one per encoding.) 406 Note that a UA may still receive a request with more than this 407 maximum number due to redirection. The package must define how to 408 handle this situation. 410 3. The default values for content and encoding if they are not 411 present. If the same UUI data may be inserted multiple times with 412 different encodings, the packages must state this. A package may 413 support and define multiple contents and their associated 414 encodings, and reuse contents defined by other packages. 416 4. Any size limitations on the UUI data. Size should be 417 specified in terms of the octet stream output of the content, 418 since the size of the resulting uui-data element will vary 419 depending on the encoding scheme. 421 A package MUST define a "purpose" header field value to identify the 422 package in the coding. A package MUST describe the new application 423 which is utilizing the UUI data and provide some use case examples. 424 The default "content" value MUST be defined or referenced in another 425 document for the package. Additional allowed contents MAY also be 426 defined or referenced. Any restrictions on the size of the UUI data 427 MUST be described. In addition, a package MAY define a Media Feature 428 tag per RFC 3840 [RFC3840] to indicate support for this UUI package. 429 For example, the media feature tag sip.uui-pk1 could be defined to 430 indicate support for a UUI package named pk1. The definition of a 431 new SIP option tag solely to identify support for a UUI package is 432 NOT RECOMMENDED unless there are additional SIP behaviors needed to 433 implement this feature. 435 For an example UUI package definition, see 436 [I-D.ietf-cuss-sip-uui-isdn]. 438 5.1. Extensibility 440 New "content" values MUST describe the semantics of the UUI data, 441 valid encodings, and give some example use cases. A previously 442 defined UUI content value can be used in a new package. In this 443 case, the semantics and usage of the content by the new package is 444 defined within the new package. New UUI content types cannot be 445 added to existing packages - instead, a new package would need to be 446 defined. New content values defined are added to the IANA registry 447 with a standards track RFC, which needs to discuss the issues in this 448 section. If no new encoding value is defined for a content, the 449 encoding defaults to "hex" as defined in this document. In this 450 case, the "hex" value will be explicitly stated via the encoding 451 parameter as the encoding for the content. 453 New "encoding" values associated with a new content MUST reference a 454 specific encoding scheme (such as "hex" which is defined in this 455 specification) or define the new encoding scheme. A previously 456 defined UUI encoding value can be used with a newly defined content. 457 In this case, the usage of the encoding is defined by the content 458 definition. New UUI encodings cannot be added to existing contents - 459 instead, a new content would need to be defined. Newly defined 460 encoding values are added to the IANA registry with a standards track 461 RFC, which needs to discuss the issues in this section. 463 6. IANA Considerations 464 6.1. Registration of User-to-User Header Field 466 This document defines a new SIP header field named "User-to-User". 468 The following row shall be added to the "Header Fields" section of 469 the SIP parameter registry: 471 +------------------+--------------+-----------+ 472 | Header Name | Compact Form | Reference | 473 +------------------+--------------+-----------+ 474 | User-to-User | | [RFCXXXX] | 475 +------------------+--------------+-----------+ 477 Editor's Note: [RFCXXXX] should be replaced with the designation of 478 this document. 480 6.2. Registration of User-to-User Header Field Parameters 482 This document defines the parameters for the header field defined in 483 the preceding section. The header field "User-to-User" can contain 484 the parameters "encoding", "content", and "purpose". 486 The following rows shall be added to the "Header Field Parameters and 487 Parameter Values" section of the SIP parameter registry: 489 +------------------+----------------+-------------------+-----------+ 490 | Header Field | Parameter Name | Predefined Values | Reference | 491 +------------------+----------------+-------------------+-----------+ 492 | User-to-User | encoding | hex | [RFCXXXX] | 493 +------------------+----------------+-------------------+-----------+ 494 | User-to-User | content | | [RFCXXXX] | 495 +------------------+----------------+-------------------+-----------+ 496 | User-to-User | purpose | | [RFCXXXX] | 497 +------------------+----------------+-------------------+-----------+ 499 Editor's Note: [RFCXXXX] should be replaced with the designation of 500 this document. 502 6.3. Registration of UUI Packages 504 This specification establishes the uui-packages sub-registry under 505 http://www.iana.org/assignments/sip-parameters. New uui-packages 506 MUST follow the "RFC Required" guideline as defined in [RFC5226] and 507 shall be registered as a result of a standards track RFC. 509 The descriptive text for the table of uui-content is: 511 UUI Packages provides information about the usage of the UUI data in 512 a User-to-User header field [RFCXXXX]. 514 +------------+------------------------------------------+-----------+ 515 | Package | Description | Reference | 516 +------------+------------------------------------------+-----------+ 518 6.4. Registration of UUI Content Parameters 520 This specification establishes the uui-content sub-registry under 521 http://www.iana.org/assignments/sip-parameters. New uui-content 522 values MUST follow the "RFC Required" guideline as defined in 523 [RFC5226] and shall be registered as a result of a standards track 524 RFC. 526 The descriptive text for the table of uui-content is: 528 UUI Content provides information about the content of the UUI data in 529 a User-to-User header field [RFCXXXX]. 531 +------------+------------------------------------------+-----------+ 532 | Content | Description | Reference | 533 +------------+------------------------------------------+-----------+ 535 6.5. Registration of UUI Encoding Parameters 537 This specification establishes the uui-encoding sub-registry under 538 http://www.iana.org/assignments/sip-parameters and initiates its 539 population with the table below. Additional uui-encoding values MUST 540 follow the "RFC Required" guideline as defined in [RFC5226] and shall 541 be registered as a result of a standards track RFC. 543 The descriptive text for the table of uui-encoding is: 545 UUI Encoding provides information about the encoding of the UUI data 546 in a User-to-User header field [RFCXXXX]. 548 +-----------+-------------------------------------------+-----------+ 549 | Encoding | Description | Reference | 550 +-----------+-------------------------------------------+-----------+ 551 | hex | The UUI data is encoded using hexadecimal | [RFCXXXX] | 552 +-----------+-------------------------------------------+-----------+ 554 6.6. Registration of SIP Option Tag 556 This specification registers a new SIP option tag, as per the 557 guidelines in Section 27.1 of [RFC3261]. 559 This document defines the SIP option tag "uui". 561 The following row has been added to the "Option Tags" section of the 562 SIP Parameter Registry: 564 +------------+------------------------------------------+-----------+ 565 | Name | Description | Reference | 566 +------------+------------------------------------------+-----------+ 567 | uui | This option tag is used to indicate that | [RFCXXXX] | 568 | | a UA supports and understands the | | 569 | | User-to-User header field. | | 570 +------------+------------------------------------------+-----------+ 572 Editor's Note: [RFCXXXX] should be replaced with the designation of 573 this document. 575 7. Security Considerations 577 User to user information can potentially carry sensitive information 578 that might require privacy or integrity protection. Standard 579 deployed SIP security mechanisms such as TLS transport, offer these 580 properties on a hop-by-hop basis. To preserve multi-hop or end-to- 581 end confidentiality and integrity of UUI data, approaches using 582 S/MIME or IPSec can be used, as discussed in the draft. However, the 583 lack of deployment of these mechanisms means that applications can 584 not in general rely on them. As such, applications are encouraged to 585 utilize their own security mechanisms. 587 If the UUI data was included by the UA originator of the SIP request 588 or response, normal SIP mechanisms can be used to determine the 589 identity of the inserter of the UUI data. If the UUI data was 590 included by a UA that was not the originator of the request, History- 591 Info can be used to determine the identity of the inserter of the UUI 592 data. UAs can apply policy based on the origin of the UUI data using 593 this information. 595 8. Appendix - Other Possible Mechanisms 597 Two other possible mechanisms for transporting UUI data will be 598 described: MIME body and URI parameter transport. 600 8.1. Why INFO is Not Used 602 Since the INFO method [RFC6086], was developed for ISUP interworking 603 of user-to-user information, it might seem to be the logical choice 604 here. For non-call control user-to-user information, INFO can be 605 utilized for end to end transport. However, for transport of call 606 control user-to-user information, INFO can not be used. As the call 607 flows in [RFC6567] show, the information is related to an attempt to 608 establish a session and must be passed with the session setup request 609 (INVITE), responses to that INVITE, or session termination requests. 610 As a result, it is not possible to use INFO in these cases. 612 8.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used 614 Other protocols have the ability to transport UUI data. For example, 615 consider the ITU-T Q.931 User to User Information Element (UU IE) 616 [Q931] and the ITU-T Q.763 User to User Information Parameter [Q763]. 617 In addition, NSS (Narrowband Signaling System) [Q1980] is also able 618 to transport UUI data. Should one of these protocols be in use, and 619 present in both User Agents, then utilizing these other protocols to 620 transport UUI data might be a logical solution. Essentially, this is 621 just adding an additional layer in the protocol stack. In these 622 cases, SIP is not transporting the UUI data; it is encapsulating 623 another protocol, and that protocol is transporting the UUI data. 624 Once a mechanism to transport that other protocol using SIP exists, 625 the UUI data transport function is essentially obtained without any 626 additional effort or work. 628 However, the authors believe that SIP needs to have its own native 629 UUI data transport mechanism. It is not reasonable for a SIP UA to 630 have to implement another entire protocol (either ISDN or NSS, for 631 example) just to get the very simple UUI data transport service. Of 632 course, this work does not preclude anyone from using other protocols 633 with SIP to transport UUI data. 635 8.3. MIME body Approach 637 One method of transport is to use a MIME body. This is in keeping 638 with the SIP-T architecture [RFC3372] in which MIME bodies are used 639 to transport ISUP information. Since the INVITE will normally have 640 an SDP message body, the resulting INVITE with SDP and UUI data will 641 be multipart MIME. This is not ideal as many SIP UAs do not support 642 multipart MIME INVITEs. 644 A bigger problem is the insertion of a UUI message body by a redirect 645 server or in a REFER. The body would need to be encoded in the 646 Contact URI of the 3xx response or the Refer-To URI of a REFER. 647 Currently, the authors are not aware of any UAs that support this 648 capability today for any body type. As such, the complete set of 649 semantics for this operation would need to be determined and defined. 650 Some issues will need to be resolved, such as, do all the Content-* 651 header fields have to be included as well? And, what if the included 652 Content-Length does not agree with the included body? 653 Since proxies cannot remove a body from a request or response, it is 654 not clear how this mechanism could meet REQ-9. 656 The requirement for integrity protection could be met by the use of 657 an S/MIME signature over the body, as defined in Section 23.3 of RFC 658 3261 "Securing MIME bodies". Alternatively, this could be achieved 659 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy 660 could be met using S/MIME encryption or using encryption at the 661 application layer. However, note that neither S/MIME or RFC 4474 662 enjoys deployment in SIP today. 664 An example: 666 667 Contact: 669 671 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, 672 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, 673 although the authors do not have a specific mechanism to propose. 674 Meeting REQ-3 is problematic, but not impossible for this mechanism. 675 However, this mechanism does not seem to be able to meet REQ-9. 677 8.4. URI Parameter 679 Another proposed approach is to encode the UUI data as a URI 680 parameter. This UUI parameter could be included in a Request-URI or 681 in the Contact URI or Refer-To URI. It is not clear how it could be 682 transported in a responses which does not have a Request-URI, or in 683 BYE requests or responses. 685 686 Contact: 688 690 An INVITE sent to this Contact URI would contain UUI data in the 691 Request-URI of the INVITE. The URI parameter has a drawback in that 692 a URI parameter carried in a Request-URI will not survive retargeting 693 by a proxy as shown in Figure 2 of [RFC6567]. That is, if the URI is 694 included with an Address of Record instead of a Contact URI, the URI 695 parameter in the Reqeuest-URI will not be copied over to the Contact 696 URI, resulting in the loss of the information. Note that if this 697 same URI was present in a Refer-To header field, the same loss of 698 information would occur. 700 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and 701 REQ-11. It is possible the approach could meet REQ-12 and REQ-13. 702 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and 703 REQ-14. 705 9. Acknowledgements 707 Joanne McMillen was a major contributor and co-author of earlier 708 versions of this document. Thanks to Paul Kyzivat for his 709 contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith 710 Drage, Vijay Gurbani, and Laura Liess for their review of the 711 document. The authors wish to thank Roland Jesske, Celine Serrut- 712 Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen 713 Jennings, and Mahalingam Mani for their comments. 715 10. References 717 10.1. Informative References 719 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 720 formats and codes", 721 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 723 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 724 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 726 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 727 for Telephones (SIP-T): Context and Architectures", 728 BCP 63, RFC 3372, September 2002. 730 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 731 Initiation Protocol (SIP) INFO Method and Package 732 Framework", RFC 6086, January 2011. 734 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 735 and H. Schulzrinne, "Session Initiation Protocol (SIP) 736 Torture Test Messages", RFC 4475, May 2006. 738 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 739 for the Session Initiation Protocol (SIP) and the Real- 740 time Applications and Infrastructure Area", BCP 67, 741 RFC 5727, March 2010. 743 [I-D.ietf-cuss-sip-uui-isdn] 744 Drage, K. and A. Johnston, "Interworking ISDN Call Control 745 User Information with SIP", 746 draft-ietf-cuss-sip-uui-isdn-04 (work in progress), 747 May 2012. 749 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) - 750 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/ 751 sg11aap/history/q1980.1/q1980.1.html . 753 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 754 Extensions to the Session Initiation Protocol (SIP) for 755 Asserted Identity within Trusted Networks", RFC 3325, 756 November 2002. 758 [RFC6567] Johnston, A. and L. Liess, "Problem Statement and 759 Requirements for Transporting User-to-User Call Control 760 Information in SIP", RFC 6567, April 2012. 762 10.2. Normative References 764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 765 Requirement Levels", BCP 14, RFC 2119, March 1997. 767 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 768 A., Peterson, J., Sparks, R., Handley, M., and E. 769 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 770 June 2002. 772 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 773 Authenticated Identity Management in the Session 774 Initiation Protocol (SIP)", RFC 4474, August 2006. 776 [I-D.ietf-sipcore-rfc4244bis] 777 Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. 778 Holmberg, "An Extension to the Session Initiation Protocol 779 (SIP) for Request History Information", 780 draft-ietf-sipcore-rfc4244bis-10 (work in progress), 781 September 2012. 783 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 784 Protocol (SIP)", RFC 4916, June 2007. 786 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 787 "Indicating User Agent Capabilities in the Session 788 Initiation Protocol (SIP)", RFC 3840, August 2004. 790 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 791 Protocol (SIP) "Replaces" Header", RFC 3891, 792 September 2004. 794 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 795 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 797 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 798 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 799 May 2008. 801 Authors' Addresses 803 Alan Johnston 804 Avaya 805 St. Louis, MO 63124 807 Email: alan.b.johnston@gmail.com 809 James Rafferty 810 Dialogic 811 Needham, MA 02494 813 Email: james.rafferty@dialogic.com