idnits 2.17.1 draft-ietf-cuss-sip-uui-13.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 (March 3, 2014) is 3707 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 582, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-cuss-sip-uui-isdn-07 ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 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: September 4, 2014 Human Communications 6 March 3, 2014 8 A Mechanism for Transporting User to User Call Control Information in 9 SIP 10 draft-ietf-cuss-sip-uui-13 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 September 4, 2014. 42 Copyright Notice 44 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 9 67 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 14 77 8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 14 78 8.2. Why Other Protocol Encapsulation UUI Mechanisms are 79 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 15 81 8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 16 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 10.1. Informative References . . . . . . . . . . . . . . . . . . 17 85 10.2. Normative References . . . . . . . . . . . . . . . . . . . 18 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, the History-Info header field is used to indicate 116 the inserter of the UUI data. The SIP option tag can be used to 117 indicate support for the header field. Support for the UUI header 118 field indicates that a UA is able to extract the information in the 119 UUI data and pass it up the protocol stack. Individual packages 120 using the UUI mechanism can utilize SIP media feature tags to 121 indicate that a UA supports a particular UUI package. Guidelines for 122 defining UUI packages are 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 Note that the tag convention from SIP Torture Test 132 Messages [RFC4475] is used to show that there are no line breaks in 133 the actual message syntax. 135 3. Requirements Discussion 137 This section describes how the User-to-User header field meets the 138 requirements in [RFC6567]. The header field can be included in 139 INVITE requests and responses and BYE requests and responses, meeting 140 REQ-1 and REQ-2. 142 For redirection and referral use cases and REQ-3, the header field is 143 included (escaped) within the Contact or Refer-To URI. The details 144 of this mechanism as it applies for redirection and referral use 145 cases are covered in Section 4.1. 147 Since SIP proxy forwarding and retargeting does not affect header 148 fields, the header field meets REQ-4. 150 The UUI header field will carry the UUI data and not a pointer to the 151 data, so REQ-5 is met. 153 Since the basic design of the UUI header field is similar to the ISDN 154 UUI service, interworking with PSTN protocols is straightforward and 155 is documented in a separate specification 156 [I-D.ietf-cuss-sip-uui-isdn], meeting REQ-6. 158 Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the 159 mechanism and supported packages, and hence applications. REQ-7 160 relates to support of the UUI header field, while REQ-8 relates to 161 routing based on support of the UUI header field. REQ-7 is met by 162 defining a new SIP option tag 'uui'. The use of a Require:uui in a 163 request, or Supported:uui in an OPTIONS response could be used to 164 require or discover support of the mechanism. The presence of a 165 Supported:uui or Require:uui header field can be used by proxies to 166 route to an appropriate UA, meeting REQ-8. However, note that only 167 UAs are expected to understand the UUI data - proxies and other 168 intermediaries do not. REQ-10 is met by utilizing SIP feature tags 169 [RFC3840]. For example, the feature tag 'sip.uui-isdn' could be used 170 to indicate support of the ISDN UUI package, or 'sip.uui-pk1' could 171 be used to indicate support for a particular package, pk1. 173 Proxies commonly apply policy to the presence of certain SIP header 174 fields in requests by either passing them or removing them from 175 requests. REQ-9 is met by allowing proxies and other intermediaries 176 to remove UUI header fields in a request or response based on policy. 178 Carrying UUI data elements of at least 129 octets is trivial in the 179 UUI header field, meeting REQ-11. Note that very large UUI data 180 elements should be avoided, as SIP header fields have traditionally 181 not been large. 183 To meet REQ-12 for the redirection and referral use cases, the 184 History-Info header field [RFC7044] can be used. In these 185 retargeting cases, the changed Request-URI will be recorded in the 186 History-Info header field along with the identity of the element that 187 performed the retargeting. 189 The requirement for integrity protection in REQ-13 could be met by 190 the use of an S/MIME signature over a subset of header fields, as 191 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity 192 using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to- 193 end privacy could be met using S/MIME or using encryption at the 194 application layer. Note that the use of S/MIME to secure the UUI 195 data will result in an additional body being added to the request. 196 Hop-wise Transport Layer Security (TLS) [RFC5246] allows the header 197 field to meet REQ-15 for hop-by-hop security. 199 4. Normative Definition 201 This document defines a new SIP header field "User-to-User" to 202 transport call control UUI data to meet the requirements in 203 [RFC6567]. 205 To help tag and identify the UUI data used with this header field, 206 "purpose", "content", and "encoding" header field parameters are 207 defined. The "purpose" header field parameter identifies the package 208 which defines the generation and usage of the UUI data for a 209 particular application. For the case of interworking with the ISDN 210 UUI Service, the ISDN UUI Service interworking package is used. If 211 the "purpose" header field parameter is not present, interworking 212 with the ISDN UUI Service MUST be assumed. The "content" header 213 field parameter identifies the actual content of the UUI data. If 214 not present, the content MUST be assumed to be the default defined 215 for the package. Newly defined UUI packages MUST define or reference 216 at least a default "content" value. The "encoding" header field 217 parameter indicates the method of encoding the information in the UUI 218 data associated with a particular "content" value. This 219 specification only defines "encoding=hex". If the "encoding" header 220 field parameter is not present, the encoding MUST be assumed to be 221 the default defined for the package. 223 UUI data is considered an opaque series of octets. This mechanism 224 SHOULD NOT be used to convey a URL or URI; the Call-Info header field 225 [RFC3261] is used for this purpose. 227 4.1. Syntax for UUI Header Field 229 The User-to-User (UUI) header field can be present in INVITE requests 230 and responses and in BYE requests and responses. Note that when the 231 UUI header is used in responses, it can only be utilized in end-to- 232 end responses, e.g. 1xx (excluding 100), 2xx, and 3xx responses. 234 The following syntax specification uses the augmented Backus-Naur 235 Form (BNF) as described in RFC 5234 and extends RFC 3261 (where token 236 and quoted-string are defined). 238 UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value) 239 uui-value = uui-data *(SEMI uui-param) 240 uui-data = token / quoted-string 241 uui-param = pkg-param / cont-param / enc-param / generic-param 242 pkg-param = "purpose" EQUAL pkg-param-value 243 pkg-param-value = token 244 cont-param = "content" EQUAL cont-param-value 245 cont-param-value = token 246 enc-param = "content" EQUAL enc-param-value 247 enc-param-value = token / "hex" 249 The rules for how many User-to-User header fields of each package may 250 be present in a request or a response are defined for each package. 251 Multiple User-to-User header fields MAY be present in a request or 252 response. Consistent with the rules of SIP syntax, the syntax 253 defined in this document allows any combination of individual User- 254 to-User header fields or User-to-User header fields with multiple 255 comma separated UUI data elements. Any size limitations on the UUI 256 data for a particular purpose must be defined by the related UUI 257 package. 259 UAs SHOULD ignore UUI data from packages or encoding that they do not 260 understand. 262 For redirection use cases, the header field is included (escaped) 263 within the Contact URI. For referral use cases, the header field is 264 included (escaped) within the Refer-To URI. For example, if a UA 265 supports this specification, it SHOULD include any UUI data included 266 in a redirection URI (if the UUI data and encoding is understood). 267 Note that redirection can occur multiple times to a request. 268 Currently, UAs that support attended transfer support the ability to 269 include a Replaces header field [RFC3891] into a Refer-To URI, and 270 when acting upon this URI, add the Replaces header field to the 271 triggered INVITE. This sort of logic and behavior shall also be 272 utilized for the UUI header field (that is, the UUI header field is 273 included in the triggered INVITE). The UA processing the REFER 275 [RFC3515] or the 3xx to the INVITE SHOULD support the UUI mechanism. 276 If the REFER or redirect target does not support UUI, the UUI header 277 will be discarded as per [RFC3261]. However, this may limit the 278 utility of use cases which depend upon the UUI being supported by all 279 elements. 281 Here is an example of an included User-to-User header field from the 282 redirection response F2 of Figure 2: 284 285 Contact: 288 290 The resulting INVITE F4 would contain: 292 User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar 294 4.2. Hex Encoding Definition 296 This specification defines hex encoding of UUI data. The value of 297 "hex" for the "encoding" header field parameter is normatively 298 defined in this section. It is used to encode binary UUI data with a 299 length that terminates at an octet boundary. Each octet of binary 300 data to be represented in the hex encoding MUST be mapped to two 301 hexadecimal digits (represented by ASCII characters 0-9, A-F and 302 a-f), each representing four bits within the octet. The four bits 303 appearing first in the binary UUI data MUST be mapped to the first 304 hexadecimal digit and the four subsequent bits in the binary UUI data 305 MUST be mapped to the second hexadecimal digit. When mapping 4 bits 306 to a hexadecimal digit, the bit appearing first in the binary UUI 307 data shall be most significant. Thus, Hex encoded UUI data must have 308 an even number of hexadecimal digits, and MUST be considered invalid 309 if it has an odd number. The hex-encoded value is normally 310 represented using the 'token' construction from RFC 3261, although 311 the 'quoted-string' construction is permitted, in which case the 312 quotes MUST be ignored. 314 4.3. Source Identity of UUI data 316 It is important for the recipient of UUI data to know the identity of 317 the UA that inserted the UUI data. In a request without a History- 318 Info header field, the identity of the entity which inserted the UUI 319 data will be assumed to be the source of the SIP message. For a SIP 320 request, typically this is the UA identified by the URI in the From 321 header field or a P-Asserted-Identity [RFC3325] header field. In a 322 request with a History-Info header field, the recipient needs to 323 parse the Targeted-to-URIs present (hi-targeted-to-uri defined in 324 [RFC7044]) to see if any included User-to-User header fields are 325 present. If an included User-to-User header field is present and 326 matches the UUI data in the request, this indicates that redirection 327 has taken place, resulting in the inclusion of UUI data in the 328 request. The inserter of the UUI data will be the UA identified by 329 the Targeted-to-URI of the History-Info element prior to the element 330 with the included UUI data. In a response, the inserter of the UUI 331 data will be the identity of the UA that generated the response. 332 Typically, this is the UA identified in the To header field of the 333 response. Note that any updates to this identity by use of the SIP 334 Connected Identity extension [RFC4916] or others will update this 335 information. 337 For an example of History-Info and redirection, consider Figure 2 338 from [RFC6567] where the Originating UA is Carol, the Redirector Bob, 339 and the Terminating UA Alice. The INVITE F4 containing UUI data 340 could be: 342 INVITE sips:alice@example.com SIP/2.0 343 Via: SIP/2.0/TLS lab.example.com:5061 344 ;branch=z9hG4bKnashds9 345 To: Bob 346 From: Carol ;tag=323sf33k2 347 Call-ID: dfaosidfoiwe83ifkdf 348 Max-Forwards: 70 349 Contact: 350 Supported: histinfo 351 User-to-User: 342342ef34;encoding=hex 352 History-Info: ;index=1 353 354 History-Info: ;index=1.1;rc=1 356 358 Without the redirection captured in the History-Info header field, 359 Alice would conclude the UUI data was inserted by Carol. However, 360 the History-Info containing UUI data (index=1.1) indicates that the 361 inserter was Bob (index=1). 363 To enable maintaining a record of the inserter identity of UUI data, 364 UAs supporting this mechanism SHOULD support History-Info [RFC7044] 365 and include Supported: histinfo in all requests and responses. 367 Border elements such as proxies or Back-to-Back User Agents (B2BUAs) 368 which anonymize a SIP URI in a History-Info header field SHOULD leave 369 the corresponding User-to-User parameter, if present, and the 370 corresponding User-to-User header field unchanged. Border elements 371 removing a History-Info header containing a User-to-User parameter 372 SHOULD NOT drop the corresponding User-to-User header. Otherwise, 373 the UA consuming the UUI data may not be able at SIP level to 374 identify the source of the UUI data. 376 5. Guidelines for UUI Packages 378 UUI packages defined using this SIP UUI mechanism MUST follow the 379 "Standards Action" guideline as defined in [RFC5226] and publish a 380 standards track RFC which describes the usage. Note that this 381 mechanism is not suitable for the transport of arbitrary data between 382 UAs. The following guidelines are provided to help determine if this 383 mechanism is appropriate or some other SIP mechanism should be used. 384 The SIP UUI mechanism is applicable when all of the following 385 conditions be met: 387 1. The information is generated and consumed by an application 388 during session setup using SIP, but the application is not 389 necessarily SIP aware. 391 2. The behavior of SIP entities that support it is not 392 significantly changed (as discussed in Section 4 of [RFC5727]). 394 3. User Agents (UAs) are the generators and consumers of the UUI 395 data. Proxies and other intermediaries may route based on the 396 presence of a User-to-User header field or a particular package 397 tag but do not otherwise consume or generate the UUI data. 399 4. There are no overriding privacy issues associated with the 400 information being transported (e.g., geolocation or emergency- 401 related information are examples of inappropriate UUI data). 403 5. The UUI data is not being utilized for user-to-user Remote 404 Procedure Call (RPC) calls. 406 UUI packages define the semantics for a particular application usage 407 of UUI data. The content defines the syntax of the UUI data, while 408 the encoding defines the encoding of the UUI data for the content. 409 Each content is defined as a stream of octets, which allows multiple 410 encodings of that content. For example, packages may define: 412 1. The SIP methods and responses in which the UUI data may be 413 present. 415 2. The maximum number of UUI data elements that may be inserted 416 into a request or response. (The default is one per encoding.) 417 Note that a UA may still receive a request with more than this 418 maximum number due to redirection. The package must define how to 419 handle this situation. 421 3. The default values for content and encoding if they are not 422 present. If the same UUI data may be inserted multiple times with 423 different encodings, the packages must state this. A package may 424 support and define multiple contents and their associated 425 encodings, and reuse contents defined by other packages. 427 4. Any size limitations on the UUI data. Size should be 428 specified in terms of the octet stream output of the content, 429 since the size of the resulting uui-data element will vary 430 depending on the encoding scheme. 432 A package MUST define a "purpose" header field value to identify the 433 package in the coding. A package MUST describe the new application 434 which is utilizing the UUI data and provide some use case examples. 435 The default "content" value MUST be defined or referenced in another 436 document for the package. Additional allowed contents MAY also be 437 defined or referenced. Any restrictions on the size of the UUI data 438 MUST be described. In addition, a package MAY define a Media Feature 439 tag per RFC 3840 [RFC3840] to indicate support for this UUI package. 440 For example, the media feature tag sip.uui-pk1 could be defined to 441 indicate support for a UUI package named pk1. The definition of a 442 new SIP option tag solely to identify support for a UUI package is 443 NOT RECOMMENDED unless there are additional SIP behaviors needed to 444 implement this feature. 446 For an example UUI package definition, see 447 [I-D.ietf-cuss-sip-uui-isdn]. 449 5.1. Extensibility 451 New "content" values MUST describe the semantics of the UUI data, 452 valid encodings, and give some example use cases. A previously 453 defined UUI content value can be used in a new package. In this 454 case, the semantics and usage of the content by the new package is 455 defined within the new package. New UUI content types cannot be 456 added to existing packages - instead, a new package would need to be 457 defined. New content values defined are added to the IANA registry 458 with a standards track RFC, which needs to discuss the issues in this 459 section. If no new encoding value is defined for a content, the 460 encoding defaults to "hex" as defined in this document. In this 461 case, the "hex" value will be explicitly stated via the encoding 462 parameter as the encoding for the content. 464 New "encoding" values associated with a new content MUST reference a 465 specific encoding scheme (such as "hex" which is defined in this 466 specification) or define the new encoding scheme. A previously 467 defined UUI encoding value can be used with a newly defined content. 468 In this case, the usage of the encoding is defined by the content 469 definition. New UUI encodings cannot be added to existing contents - 470 instead, a new content would need to be defined. Newly defined 471 encoding values are added to the IANA registry with a standards track 472 RFC, which needs to discuss the issues in this section. 474 6. IANA Considerations 476 6.1. Registration of User-to-User Header Field 478 This document defines a new SIP header field named "User-to-User". 480 The following row shall be added to the "Header Fields" section of 481 the SIP parameter registry: 483 +------------------+--------------+-----------+ 484 | Header Name | Compact Form | Reference | 485 +------------------+--------------+-----------+ 486 | User-to-User | | [RFCXXXX] | 487 +------------------+--------------+-----------+ 489 Editor's Note: [RFCXXXX] should be replaced with the designation of 490 this document. 492 6.2. Registration of User-to-User Header Field Parameters 494 This document defines the parameters for the header field defined in 495 the preceding section. The header field "User-to-User" can contain 496 the parameters "encoding", "content", and "purpose". 498 The following rows shall be added to the "Header Field Parameters and 499 Parameter Values" section of the SIP parameter registry: 501 +------------------+----------------+-------------------+-----------+ 502 | Header Field | Parameter Name | Predefined Values | Reference | 503 +------------------+----------------+-------------------+-----------+ 504 | User-to-User | encoding | hex | [RFCXXXX] | 505 +------------------+----------------+-------------------+-----------+ 506 | User-to-User | content | | [RFCXXXX] | 507 +------------------+----------------+-------------------+-----------+ 508 | User-to-User | purpose | | [RFCXXXX] | 509 +------------------+----------------+-------------------+-----------+ 511 Editor's Note: [RFCXXXX] should be replaced with the designation of 512 this document. 514 6.3. Registration of UUI Packages 516 This specification establishes the uui-packages sub-registry under 517 http://www.iana.org/assignments/sip-parameters. New uui-packages 518 MUST follow the "Standards Action" guideline as defined in [RFC5226]. 520 The descriptive text for the table of uui-content is: 522 UUI Packages provides information about the usage of the UUI data in 523 a User-to-User header field [RFCXXXX]. 525 +------------+------------------------------------------+-----------+ 526 | Package | Description | Reference | 527 +------------+------------------------------------------+-----------+ 529 6.4. Registration of UUI Content Parameters 531 This specification establishes the uui-content sub-registry under 532 http://www.iana.org/assignments/sip-parameters. New uui-content 533 values MUST follow the "Specification Required" guideline as defined 534 in [RFC5226]. 536 The descriptive text for the table of uui-content is: 538 UUI Content provides information about the content of the UUI data in 539 a User-to-User header field [RFCXXXX]. 541 +------------+------------------------------------------+-----------+ 542 | Content | Description | Reference | 543 +------------+------------------------------------------+-----------+ 545 6.5. Registration of UUI Encoding Parameters 547 This specification establishes the uui-encoding sub-registry under 548 http://www.iana.org/assignments/sip-parameters and initiates its 549 population with the table below. Additional uui-encoding values MUST 550 follow the "Specification Required" guideline as defined in 551 [RFC5226]. 553 The descriptive text for the table of uui-encoding is: 555 UUI Encoding provides information about the encoding of the UUI data 556 in a User-to-User header field [RFCXXXX]. 558 +-----------+-------------------------------------------+-----------+ 559 | Encoding | Description | Reference | 560 +-----------+-------------------------------------------+-----------+ 561 | hex | The UUI data is encoded using hexadecimal | [RFCXXXX] | 562 +-----------+-------------------------------------------+-----------+ 564 6.6. Registration of SIP Option Tag 566 This specification registers a new SIP option tag, as per the 567 guidelines in Section 27.1 of [RFC3261]. 569 This document defines the SIP option tag "uui". 571 The following row has been added to the "Option Tags" section of the 572 SIP Parameter Registry: 574 +------------+------------------------------------------+-----------+ 575 | Name | Description | Reference | 576 +------------+------------------------------------------+-----------+ 577 | uui | This option tag is used to indicate that | [RFCXXXX] | 578 | | a UA supports and understands the | | 579 | | User-to-User header field. | | 580 +------------+------------------------------------------+-----------+ 582 Editor's Note: [RFCXXXX] should be replaced with the designation of 583 this document. 585 7. Security Considerations 587 User to user information can potentially carry sensitive information 588 that might require privacy or integrity protection from third parties 589 that may wish to read or modify the UUI data. [RFC6567] describes 590 three security models which may be applicable for the UUI mechanism. 592 One model treats the SIP layer as untrusted and requires end-to-end 593 integrity protection and/or encryption. This model can be achieved 594 by providing these security services at a layer above SIP. In this 595 case, applications are encouraged to use their own integrity and/or 596 encryption mechanisms before passing it to the SIP layer. 598 The second approach is for the application to pass the UUI without 599 any protection to the SIP layer and require the SIP layer to provide 600 this security. This approach is possible in theory, although its 601 practical use would be extremely limited. To preserve multi-hop or 602 end-to-end confidentiality and integrity of UUI data, approaches 603 using S/MIME or IPSec can be used, as discussed in the review of 604 REQ-13 and REQ-14 in section 3 of this document. However, the lack 605 of deployment of these mechanisms means that applications cannot in 606 general rely on them being present. 608 The third model utilizes a trust domain and relies on perimeter 609 security at the SIP layer. This is the security model of the PSTN 610 and ISDN where UUI is commonly used today. This approach uses hop- 611 by-hop security mechanisms and relies on border elements for 612 filtering and application of policy. Standard deployed SIP security 613 mechanisms such as TLS transport, offer privacy and integrity 614 protection properties on a hop-by-hop basis at the SIP layer. 616 If the UUI data was included by the UA originator of the SIP request 617 or response, normal SIP mechanisms can be used to determine the 618 identity of the inserter of the UUI data. If the UUI data was 619 included by a UA that was not the originator of the request, a 620 History-Info header field can be used to determine the identity of 621 the inserter of the UUI data. UAs can apply policy based on the 622 origin of the UUI data using this information. In short, the UUI 623 data included in an INVITE can be trusted as much as the INVITE 624 itself can be trusted. 626 8. Appendix - Other Possible Mechanisms 628 Two other possible mechanisms for transporting UUI data will be 629 described: MIME body and URI parameter transport. 631 8.1. Why INFO is Not Used 633 Since the INFO method [RFC6086], was developed for ISUP interworking 634 of user-to-user information, it might seem to be the logical choice 635 here. For non-call control user-to-user information, INFO can be 636 utilized for end to end transport. However, for transport of call 637 control user-to-user information, INFO can not be used. As the call 638 flows in [RFC6567] show, the information is related to an attempt to 639 establish a session and must be passed with the session setup request 640 (INVITE), responses to that INVITE, or session termination requests. 641 As a result, it is not possible to use INFO in these cases. 643 8.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used 645 Other protocols have the ability to transport UUI data. For example, 646 consider the ITU-T Q.931 User to User Information Element (UU IE) 647 [Q931] and the ITU-T Q.763 User to User Information Parameter [Q763]. 648 In addition, NSS (Narrowband Signaling System) [Q1980] is also able 649 to transport UUI data. Should one of these protocols be in use, and 650 present in both User Agents, then utilizing these other protocols to 651 transport UUI data might be a logical solution. Essentially, this is 652 just adding an additional layer in the protocol stack. In these 653 cases, SIP is not transporting the UUI data; it is encapsulating 654 another protocol, and that protocol is transporting the UUI data. 655 Once a mechanism to transport that other protocol using SIP exists, 656 the UUI data transport function is essentially obtained without any 657 additional effort or work. 659 However, the CUSS working group believes, consistent with its 660 charter, that SIP needs to have its own native UUI data transport 661 mechanism. It is not reasonable for a SIP UA to have to implement 662 another entire protocol (either ISDN or NSS, for example) just to get 663 the very simple UUI data transport service. Of course, this work 664 does not preclude anyone from using other protocols with SIP to 665 transport UUI data. 667 8.3. MIME body Approach 669 One method of transport is to use a MIME body. This is in keeping 670 with the SIP-T architecture [RFC3372] in which MIME bodies are used 671 to transport ISUP information. Since the INVITE will normally have 672 an SDP message body, the resulting INVITE with SDP and UUI data will 673 be multipart MIME. This is not ideal as many SIP UAs do not support 674 multipart MIME INVITEs. 676 A bigger problem is the insertion of a UUI message body by a redirect 677 server or in a REFER. The body would need to be encoded in the 678 Contact URI of the 3xx response or the Refer-To URI of a REFER. 679 Currently, the authors are not aware of any UAs that support this 680 capability today for any body type. As such, the complete set of 681 semantics for this operation would need to be determined and defined. 682 Some issues will need to be resolved, such as, do all the Content-* 683 header fields have to be included as well? And, what if the included 684 Content-Length does not agree with the included body? 686 Since proxies cannot remove a body from a request or response, it is 687 not clear how this mechanism could meet REQ-9. 689 The requirement for integrity protection could be met by the use of 690 an S/MIME signature over the body, as defined in Section 23.3 of RFC 691 3261 "Securing MIME bodies". Alternatively, this could be achieved 692 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy 693 could be met using S/MIME encryption or using encryption at the 694 application layer. However, note that neither S/MIME or RFC 4474 695 enjoys deployment in SIP today. 697 An example: 699 700 Contact: 702 704 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, 705 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, 706 although the authors do not have a specific mechanism to propose. 707 Meeting REQ-3 is problematic, but not impossible for this mechanism. 708 However, this mechanism does not seem to be able to meet REQ-9. 710 8.4. URI Parameter 712 Another proposed approach is to encode the UUI data as a URI 713 parameter. This UUI parameter could be included in a Request-URI or 714 in the Contact URI or Refer-To URI. It is not clear how it could be 715 transported in a responses which does not have a Request-URI, or in 716 BYE requests or responses. 718 719 Contact: 721 723 An INVITE sent to this Contact URI would contain UUI data in the 724 Request-URI of the INVITE. The URI parameter has a drawback in that 725 a URI parameter carried in a Request-URI will not survive retargeting 726 by a proxy as shown in Figure 2 of [RFC6567]. That is, if the URI is 727 included with an Address of Record instead of a Contact URI, the URI 728 parameter in the Reqeuest-URI will not be copied over to the Contact 729 URI, resulting in the loss of the information. Note that if this 730 same URI was present in a Refer-To header field, the same loss of 731 information would occur. 733 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and 734 REQ-11. It is possible the approach could meet REQ-12 and REQ-13. 735 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and 736 REQ-14. 738 9. Acknowledgements 740 Joanne McMillen was a major contributor and co-author of earlier 741 versions of this document. Thanks to Paul Kyzivat for his 742 contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith 743 Drage, Vijay Gurbani, and Laura Liess for their review of the 744 document. The authors wish to thank Roland Jesske, Celine Serrut- 745 Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen 746 Jennings, and Mahalingam Mani for their comments. Thanks to Scott 747 Kelly and Joel Halperin for their reviews. 749 10. References 751 10.1. Informative References 753 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 754 formats and codes", 755 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 757 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 758 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 760 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 761 for Telephones (SIP-T): Context and Architectures", 762 BCP 63, RFC 3372, September 2002. 764 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 765 Initiation Protocol (SIP) INFO Method and Package 766 Framework", RFC 6086, January 2011. 768 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 769 and H. Schulzrinne, "Session Initiation Protocol (SIP) 770 Torture Test Messages", RFC 4475, May 2006. 772 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 773 for the Session Initiation Protocol (SIP) and the Real- 774 time Applications and Infrastructure Area", BCP 67, 775 RFC 5727, March 2010. 777 [I-D.ietf-cuss-sip-uui-isdn] 778 Drage, K. and A. Johnston, "Interworking ISDN Call Control 779 User Information with SIP", 780 draft-ietf-cuss-sip-uui-isdn-07 (work in progress), 781 February 2014. 783 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) - 784 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/ 785 sg11aap/history/q1980.1/q1980.1.html . 787 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 788 Extensions to the Session Initiation Protocol (SIP) for 789 Asserted Identity within Trusted Networks", RFC 3325, 790 November 2002. 792 [RFC6567] Johnston, A. and L. Liess, "Problem Statement and 793 Requirements for Transporting User-to-User Call Control 794 Information in SIP", RFC 6567, April 2012. 796 10.2. Normative References 798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 799 Requirement Levels", BCP 14, RFC 2119, March 1997. 801 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 802 A., Peterson, J., Sparks, R., Handley, M., and E. 803 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 804 June 2002. 806 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 807 Authenticated Identity Management in the Session 808 Initiation Protocol (SIP)", RFC 4474, August 2006. 810 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 811 C. Holmberg, "An Extension to the Session Initiation 812 Protocol (SIP) for Request History Information", RFC 7044, 813 February 2014. 815 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 816 Protocol (SIP)", RFC 4916, June 2007. 818 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 819 "Indicating User Agent Capabilities in the Session 820 Initiation Protocol (SIP)", RFC 3840, August 2004. 822 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 823 Method", RFC 3515, April 2003. 825 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 826 Protocol (SIP) "Replaces" Header", RFC 3891, 827 September 2004. 829 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 830 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 832 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 833 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 834 May 2008. 836 Authors' Addresses 838 Alan Johnston 839 Avaya 840 St. Louis, MO 63124 842 Email: alan.b.johnston@gmail.com 844 James Rafferty 845 Human Communications 846 Norfolk, MA 02056 848 Email: jay@humancomm.com