idnits 2.17.1 draft-ietf-cuss-sip-uui-04.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 639 has weird spacing: '...ats and codes...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 31, 2011) is 4558 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 497, but not defined == Unused Reference: 'ETSI' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'RFC3324' is defined on line 686, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3324 ** Downref: Normative reference to an Informational RFC: RFC 3325 == Outdated reference: A later version (-09) exists of draft-ietf-cuss-sip-uui-reqs-07 ** Downref: Normative reference to an Informational draft: draft-ietf-cuss-sip-uui-reqs (ref. 'I-D.ietf-cuss-sip-uui-reqs') ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-12) exists of draft-ietf-sipcore-rfc4244bis-06 Summary: 5 errors (**), 0 flaws (~~), 8 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: May 3, 2012 Dialogic 6 October 31, 2011 8 A Mechanism for Transporting User to User Call Control Information in 9 SIP 10 draft-ietf-cuss-sip-uui-04 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 certain 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 May 3, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3 62 4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 5 64 4.2. Source Identity of UUI data . . . . . . . . . . . . . . . 6 65 5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Registration of User-to-User Header Field . . . . . . . . 9 68 6.2. Registration of User-to-User Header Field Parameters . . . 9 69 6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 10 70 6.4. Registration of UUI Content Parameters . . . . . . . . . . 10 71 6.5. Registration of UUI Encoding Parameters . . . . . . . . . 11 72 6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 12 75 8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 12 76 8.2. Why Other Protocol Encapsulation UUI Mechanisms are 77 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 13 79 8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 13 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 10.1. Informative References . . . . . . . . . . . . . . . . . . 14 83 10.2. Normative References . . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Overview 88 This document describes the transport of User to User Information 89 (UUI) data using SIP [RFC3261]. A mechanism is defined for the 90 transport of general application UUI data and for the transport of 91 call control related ITU-T Q.931 User to User Information Element (UU 92 IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763] 93 data in SIP. UUI data is widely used in the PSTN today for contact 94 centers and call centers. There is also a trend for the related 95 applications to transition from ISDN to SIP. The UUI extension for 96 SIP may also be used for native SIP endpoints implementing similar 97 services and to interwork with ISDN services. Note that in most 98 cases, there is an a priori understanding between the endpoints in 99 regard to what to do with received UUI data. 101 This mechanism was designed to meet the use cases, requirements, and 102 call flows for SIP call control UUI detailed in 103 [I-D.ietf-cuss-sip-uui-reqs]. All references to requirement numbers 104 (REQ-N) and figure numbers refer to this document. 106 The mechanism chosen is a new SIP header field, along with a new SIP 107 option tag. The header field carries the UUI data, along with 108 parameters indicating the encoding of the UUI data, the UUI package, 109 and optionally the content of the UUI data. The package definition 110 contains details about how a particular application can utilize the 111 UUI mechanism. The header field can be escaped into URIs supporting 112 referral and redirection scenarios. In these scenarios, History-Info 113 is used to indicate the inserter of the UUI data. The SIP option tag 114 can be used to indicate support for the header field. Support for 115 the UUI header field indicates that a UA is able to extract the 116 information in the UUI data and pass it up the protocol stack. 117 Individual packages using the UUI mechanism can utlize SIP media 118 feature tags to indicate that a UA supports a particular UUI package. 119 Guidelines for defining UUI packages are provided. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in BCP 14, RFC 2119 126 [RFC2119]. 128 3. Requirements Discussion 130 This section describes how the User-to-User header field meets the 131 requirements in [I-D.ietf-cuss-sip-uui-reqs]. The header field can 132 be included in INVITE requests and responses and BYE requests and 133 responses, meeting REQ-1 and REQ-2. 135 For redirection and referral use cases and REQ-3, the header field 136 shall be escaped into the Contact or Refer-To URI. Currently, UAs 137 that support attended transfer support the ability to escape a 138 Replaces header field into a Refer-To URI, and when acting upon this 139 URI add the Replaces header field to the triggered INVITE. This 140 logic and behavior is identical for the UUI header field. The UA 141 processing the REFER or the 3xx to the INVITE will need to support 142 the UUI mechanism, as UAs in general do not process unknown escaped 143 header fields. 145 Since SIP proxy forwarding and retargeting does not affect header 146 fields, the header field meets REQ-4. 148 The UUI header field will carry the UUI data and not a pointer to the 149 data, so REQ-5 is met. 151 Since the basic design of the UUI header field is similar to the ISDN 152 UUI service, interworking with PSTN protocols will be straightforward 153 and will be documented in a separate specification, meeting REQ-6. 155 Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the 156 mechanism and supported packages, and hence applications. REQ-7 157 relates to support of the UUI header field, while REQ-8 relates to 158 routing based on support of the UUI header field. REQ-7 is met by 159 defining a new SIP option tag 'uui'. The use of a Require:uui in a 160 request, or Supported:uui in an OPTIONS response could be used to 161 require or discover support of the mechanism. The presence of a 162 Supported:uui or Require:uui header field can be used by proxies to 163 route to an appropriate UA, meeting REQ-8. However, note that the 164 only endpoints are expected to understand the UUI data - proxies and 165 other intermediaries do not. REQ-10 is met by utlizing SIP feature 166 tags [RFC3840]. For example, the feature tag 'sip.uui-isdn' could be 167 used to indicate support of the ISDN UUI package, or 'sip.uui-pk1' 168 could be used to indicate support for a particular package, pk1. 170 Proxies commonly apply policy to the presence of certain SIP header 171 fields in requests by either passing them or removing them from 172 requests. REQ-9 is met by allowing proxies and other intermediaries 173 to remove UUI header fields in a request or response based on policy. 175 Carrying UUI data elements of at least 129 octets is trivial in the 176 UUI header field, meeting REQ-11. Note that very large UUI data 177 elements should be avoided, as SIP header fields have traditionally 178 not been large. 180 To meet REQ-12 for the redirection and referral use cases, History- 181 Info [I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting 182 cases, the changed Request-URI will be recorded in the History-Info 183 header field along with the identity of the element that performed 184 the retargeting. 186 The requirement for integrity protection in REQ-13 could be met by 187 the use of an S/MIME signature over a subset of header fields, as 188 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity 189 using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to- 190 end privacy could be met using S/MIME or using encryption at the 191 application layer. Note that the use of S/MIME to secure the UUI 192 data will result in an additional body being added to the request. 193 Hopwise TLS allows the header field to meet REQ-15 for hop-by-hop 194 security. 196 4. Normative Definition 198 This document defines a new SIP header field "User-to-User" to 199 transport call control UUI data to meet the requirements in 200 [I-D.ietf-cuss-sip-uui-reqs]. 202 To help tag and identify the UUI data used with this header field, 203 "package", "content", and "encoding" parameters are defined. The 204 "package" parameter identifies the package which defines the 205 generation and usage of the UUI data for a particular application. 206 For the case of interworking with the ISDN UUI Service, the ISDN UUI 207 Service interworking package is used. If the "package" parameter is 208 not present, interworking with the ISDN UUI Service MUST be assumed. 209 The "content" parameter identifies the actual content of the UUI 210 data. If not present, the content MUST be assumed to be unknown as 211 it is in the ISDN UUI Service. Newly defined UUI packages MUST 212 define a new "content" value. The "encoding" parameter indicates the 213 method of encoding the information in the UUI data. This 214 specification only defines "encoding=hex". If the "encoding" 215 parameter is not present, "hex" MUST be assumed. 217 UUI data is considered an opaque series of octets. This mechanism 218 SHOULD NOT be used to convey a URL or URI; the Call-Info header field 219 [RFC3261] is used for this purpose. 221 4.1. Syntax for UUI Header Field 223 The User-to-User header field can be present in INVITE requests and 224 responses only and in BYE requests and responses. Note that only 225 end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and 226 3xx responses. 228 The following syntax specification uses the augmented Backus-Naur 229 Form (BNF) as described in RFC 5234 and extends RFC 3261. 231 UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value) 232 uui-value = uui-data *(SEMI uui-param) 233 uui-data = token / quoted-string 234 uui-param = pkg-param / cont-param / enc-param / generic-param 235 pkg-param = "package" EQUAL token 236 cont-param = "content" EQUAL token 237 enc-param = "encoding" EQUAL ("hex" / token) 239 The rules for how many User-to-User header field of each package may 240 be present in a request or a response are defined for each package. 241 Any size limitations on the UUI data for a particular purpose must be 242 defined by the related UUI package. 244 4.2. Source Identity of UUI data 246 It is important for the recipient of UUI data to know the identity of 247 the UA that inserted the UUI data. In a request without a History- 248 Info [I-D.ietf-sipcore-rfc4244bis] header field, the identity of the 249 entity which inserted the UUI data will be assumed to be the source 250 of the SIP message. For a SIP request, typically this is the UA 251 identified by the URI in the From header field or a P-Asserted- 252 Identity [RFC3325] header field. In a request with a History-Info 253 header field, the recipient needs to parse the Targeted-to-URIs 254 present (hi-targeted-to-uri) to see if any escaped User-to-User 255 header fields are present. If an escaped User-to-User header field 256 is present and matches the UUI data in the request, this indicates 257 that redirection has taken place, resulting in the inclusion of UUI 258 data in the request. The inserter of the UUI data will be the UA 259 identified by the Targeted-to-URI of the History-Info element prior 260 to the element with the escaped UUI data. In a response, the 261 inserter of the UUI data will be the identity of the UA that 262 generated the response. Typically, this is the UA identified in the 263 To header field of the response. Note that any updates to this 264 identity by use of the SIP Connected Identity extension [RFC4916] or 265 others will update this information. 267 For an example of History-Info and redirection, consider Figure 2 268 from [I-D.ietf-cuss-sip-uui-reqs] where the Originating UA is Carol, 269 the Redirector Bob, and the Terminating UA Alice. The INVITE F4 270 containing UUI data could be: 272 INVITE sips:alice@example.com SIP/2.0 273 Via: SIP/2.0/TLS lab.example.com:5061 274 ;branch=z9hG4bKnashds9 275 To: Bob 276 From: Carol ;tag=323sf33k2 277 Call-ID: dfaosidfoiwe83ifkdf 278 Max-Forwards: 70 279 Contact: 280 Supported: histinfo 281 User-to-User: 342342ef34;encoding=hex 282 History-Info: ;index=1 283 284 History-Info: ;index=1.1;rc=1 286 288 Without the redirection captured in the History-Info, Alice would 289 conclude the UUI data was inserted by Carol. However, the History- 290 Info containing UUI data (index=1.1) indicates that the inserter was 291 Bob (index=1). 293 Note that the tag convention from SIP Torture Test 294 Messages [RFC4475] is used to show that there are no line breaks in 295 the actual message syntax. 297 To enable maintaining a record of the inserter identity of UUI data, 298 UAs supporting this mechanism SHOULD support History-Info 299 [I-D.ietf-sipcore-rfc4244bis] and include Supported: histinfo in all 300 requests and responses. 302 5. Guidelines for UUI Packages 304 UUI packages defined using this SIP UUI mechanism must publish a 305 standards track RFC which describes the usage. Note that this 306 mechanism is not suitable for the transport of arbitrary data between 307 endpoints. The following guidelines are provided to help determine 308 if this mechanism is appropriate or some other SIP mechanism should 309 be used. The SIP UUI mechanism is applicable when all of the 310 following conditions be met: 312 1. The information is generated and consumed by an application 313 during session setup using SIP, but the application is not 314 necessarily SIP aware. 316 2. The behavior of SIP entities that support it is not 317 significantly changed (as discussed in Section 4 of [RFC5727]). 319 3. User Agent Clients (UAC) and User Agent Servers (UAS) are the 320 generators and consumers of the UUI data. Proxies and other 321 intermediaries may route based on the presence of a User-to-User 322 header field or a particular package tag but do not otherwise 323 consume or generate the UUI data. 325 4. There are no overriding privacy issues associated with the 326 information being transported (e.g., geolocation or emergency- 327 related information are examples of inappropriate UUI data). 329 5. The UUI data is not being utilized for user-to-user Remote 330 Procedure Call (RPC) calls. 332 UUI packages define the semantics for a particular application usage 333 of UUI data. The content defines the syntax of the UUI data, while 334 the encoding defines the encoding of the UUI data. Each content is 335 defined as a stream of octets, which allows multiple encodings of 336 that content. For example, packages may define: 338 1. The SIP methods and responses in which the UUI data may be 339 present. 341 2. The number of UUI data elements that may be present in a 342 request or response. (The default is one.) 344 3. The default values for content and encoding if they are not 345 present. 347 4. Any size limitations on the UUI data. Size should be 348 specified in terms of the octet stream output of the content, 349 since the size of the resulting uui-data element will vary 350 depending on the encoding scheme. 352 New "package" values MUST describe the new application which is 353 utilizing the UUI data and provide some use case example examples. 354 The default "content" value and other allowed contents MUST be 355 defined or referenced in another document for the package. Any 356 restrictions on the size of the UUI data must be described. In 357 addition, a package may define a Media Feature tag per RFC 3840 358 [RFC3840] to indicate support for this UUI package. For example, the 359 media feature tag sip.uui-pk1 could be defined to indicate support 360 for a UUI package named pk1. The definition of a new SIP option tag 361 solely to identify support for a UUI package is NOT RECOMMENDED 362 unless there are additional SIP behaviors needed to implement this 363 feature. 365 For an example UUI package definition, see 366 [I-D.drage-cuss-sip-uui-isdn]. 368 This specification defines only the value of "hex" for the "encoding" 369 parameter. Hex encoding, as used for UUI data is defined to use only 370 the characters 0-9, A-F, or a-f. Hex encoded UUI data must have an 371 even number of octets, and is considered invalid if has an odd 372 number. Hex encoding is normally done as a token, although quoted- 373 string is permitted, in which case the quotes are ignored. Hex 374 encoding yields a sequence of octets, one octet per two hex digits, 375 in the same order, with the first digit of each pair defining the 376 high order four bits of the octet and the second digit providing the 377 low order four bits. 379 New "encoding" values must reference a common encoding scheme or 380 define the exact new encoding scheme. New values can be defined and 381 added to the IANA registry with a standards track RFC, which needs to 382 discuss the issues in this section. 384 New "content" values must describe the content of the UUI data and 385 give some example use cases. The default "encoding" and other 386 allowed encoding methods must be defined for this new content. Note 387 that a content value can be used by multiple UUI packages. In this 388 case, the semantics and usage of the content is defined by the 389 package. 391 6. IANA Considerations 393 6.1. Registration of User-to-User Header Field 395 This document defines a new SIP header field named "User-to-User". 397 The following row shall be added to the "Header Fields" section of 398 the SIP parameter registry: 400 +------------------+--------------+-----------+ 401 | Header Name | Compact Form | Reference | 402 +------------------+--------------+-----------+ 403 | User-to-User | | [RFCXXXX] | 404 +------------------+--------------+-----------+ 406 Editor's Note: [RFCXXXX] should be replaced with the designation of 407 this document. 409 6.2. Registration of User-to-User Header Field Parameters 411 This document defines the parameters for the header field defined in 412 the preceding section. The header field "User-to-User" can contain 413 the parameters "encoding", "content", and "package". 415 The following rows shall be added to the "Header Field Parameters and 416 Parameter Values" section of the SIP parameter registry: 418 +------------------+----------------+-------------------+-----------+ 419 | Header Field | Parameter Name | Predefined Values | Reference | 420 +------------------+----------------+-------------------+-----------+ 421 | User-to-User | encoding | hex | [RFCXXXX] | 422 +------------------+----------------+-------------------+-----------+ 423 | User-to-User | content | | [RFCXXXX] | 424 +------------------+----------------+-------------------+-----------+ 425 | User-to-User | package | | [RFCXXXX] | 426 +------------------+----------------+-------------------+-----------+ 428 Editor's Note: [RFCXXXX] should be replaced with the designation of 429 this document. 431 6.3. Registration of UUI Packages 433 This specification establishes the uui-packages sub-registry under 434 http://www.iana.org/assignments/sip-parameters. New uui-packages 435 shall be registered by standards track RFC publication. 437 The descriptive text for the table of uui-content is: 439 UUI Packages provides information about the usage of the UUI data in 440 a User-to-User header field [RFCXXXX]. 442 +------------+-------------------------------------------+-----------+ 443 | Package | Description | Reference | 444 +------------+-------------------------------------------+-----------+ 446 6.4. Registration of UUI Content Parameters 448 This specification establishes the uui-content sub-registry under 449 http://www.iana.org/assignments/sip-parameters. New uui-content 450 values shall be registered by standards track RFC publication. 452 The descriptive text for the table of uui-content is: 454 UUI Content provides information about the content of the UUI data in 455 a User-to-User header field [RFCXXXX]. 457 +------------+-------------------------------------------+-----------+ 458 | Content | Description | Reference | 459 +------------+-------------------------------------------+-----------+ 461 6.5. Registration of UUI Encoding Parameters 463 This specification establishes the uui-encoding sub-registry under 464 http://www.iana.org/assignments/sip-parameters and initiates its 465 population with the table below. Additional uui-encoding values 466 shall be registered by a standards track RFC publication. 468 The descriptive text for the table of uui-encoding is: 470 UUI Encoding provides information about the encoding of the UUI data 471 in a User-to-User header field [RFCXXXX]. 473 +------------+-------------------------------------------+-----------+ 474 | Encoding | Description | Reference | 475 +------------+-------------------------------------------+-----------+ 476 | hex | The UUI data is encoded using hexadecimal | | 477 +------------+-------------------------------------------+-----------+ 479 6.6. Registration of SIP Option Tag 481 This specification registers a new SIP option tag, as per the 482 guidelines in Section 27.1 of [RFC3261]. 484 This document defines the SIP option tag "uui". 486 The following row has been added to the "Option Tags" section of the 487 SIP Parameter Registry: 489 +------------+------------------------------------------+-----------+ 490 | Name | Description | Reference | 491 +------------+------------------------------------------+-----------+ 492 | uui | This option tag is used to indicate that | [RFCXXXX] | 493 | | a UA supports and understands the | | 494 | | User-to-User header field. | | 495 +------------+------------------------------------------+-----------+ 497 Editor's Note: [RFCXXXX] should be replaced with the designation of 498 this document. 500 7. Security Considerations 502 User to user information can potentially carry sensitive information 503 that might require privacy or integrity protection. Standard 504 deployed SIP security mechanisms such as TLS transport, offer these 505 properties on a hop-by-hop basis. To preserve multi-hop or end-to- 506 end confidentiality and integrity of UUI data, approaches using 507 S/MIME or IPSec can be used, as discussed in the draft. However, the 508 lack of deployment of these mechanisms means that applications can 509 not in general rely on them. As such, applications are encouraged to 510 utilize their own security mechanisms. 512 8. Appendix - Other Possible Mechanisms 514 Two other possible mechanisms for transporting UUI data will be 515 described: MIME body and URI parameter transport. 517 8.1. Why INFO is Not Used 519 Since the INFO method [RFC6086], was developed for ISUP interworking 520 of user-to-user information, it might seem to be the logical choice 521 here. For non-call control user-to-user information, INFO can be 522 utilized for end to end transport. However, for transport of call 523 control user-to-user information, INFO can not be used. As the call 524 flows in [I-D.ietf-cuss-sip-uui-reqs] show, the information is 525 related to an attempt to establish a session and must be passed with 526 the session setup request (INVITE), responses to that INVITE, or 527 session termination requests. As a result, it is not possible to use 528 INFO in these cases. 530 8.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used 532 Other protocols have the ability to transport UUI data. For example, 533 consider the ITU-T Q.931 User to User Information Element (UU IE) 534 [Q931] and the ITU-T Q.763 User to User Information Parameter [Q763]. 535 In addition, NSS (Narrowband Signaling System) [Q1980] is also able 536 to transport UUI data. Should one of these protocols be in use, and 537 present in both User Agents, then utilizing these other protocols to 538 transport UUI data might be a logical solution. Essentially, this is 539 just adding an additional layer in the protocol stack. In these 540 cases, SIP is not transporting the UUI data; it is encapsulating 541 another protocol, and that protocol is transporting the UUI data. 542 Once a mechanism to transport that other protocol using SIP exists, 543 the UUI data transport function is essentially obtained without any 544 additional effort or work. 546 However, the authors believe that SIP needs to have its own native 547 UUI data transport mechanism. It is not reasonable for a SIP UA to 548 have to implement another entire protocol (either ISDN or NSS, for 549 example) just to get the very simple UUI data transport service. Of 550 course, this work does not preclude anyone from using other protocols 551 with SIP to transport UUI data. 553 8.3. MIME body Approach 555 One method of transport is to use a MIME body. This is in keeping 556 with the SIP-T architecture [RFC3372] in which MIME bodies are used 557 to transport ISUP information. Since the INVITE will normally have 558 an SDP message body, the resulting INVITE with SDP and UUI data will 559 be multipart MIME. This is not ideal as many SIP UAs do not support 560 multipart MIME INVITEs. 562 A bigger problem is the insertion of a UUI message body by a redirect 563 server or in a REFER. The body would need to be encoded in the 564 Contact URI of the 3xx response or the Refer-To URI of a REFER. 565 Currently, the authors are not aware of any UAs that support this 566 capability today for any body type. As such, the complete set of 567 semantics for this operation would need to be determined and defined. 568 Some issues will need to be resolved, such as, do all the Content-* 569 header fields have to be escaped as well? And, what if the escaped 570 Content-Length does not agree with the escaped body? 572 Since proxies cannot remove a body from a request or response, it is 573 not clear how this mechanism could meet REQ-9. 575 The requirement for integrity protection could be met by the use of 576 an S/MIME signature over the body, as defined in Section 23.3 of RFC 577 3261 "Securing MIME bodies". Alternatively, this could be achieved 578 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy 579 could be met using S/MIME encryption or using encryption at the 580 application layer. However, note that neither S/MIME or RFC 4474 581 enjoys deployment in SIP today. 583 An example: 585 586 Contact: 588 590 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, 591 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, 592 although the authors do not have a specific mechanism to propose. 593 Meeting REQ-3 is problematic, but not impossible for this mechanism. 594 However, this mechanism does not seem to be able to meet REQ-9. 596 8.4. URI Parameter 598 Another proposed approach is to encode the UUI data as a URI 599 parameter. This UUI parameter could be included in a Request-URI or 600 in the Contact URI or Refer-To URI. It is not clear how it could be 601 transported in a responses which does not have a Request-URI, or in 602 BYE requests or responses. 604 605 Contact: 607 609 An INVITE sent to this Contact URI would contain UUI data in the 610 Request-URI of the INVITE. The URI parameter has a drawback in that 611 a URI parameter carried in a Request-URI will not survive retargeting 612 by a proxy as shown in Figure 2 of [I-D.ietf-cuss-sip-uui-reqs]. 613 That is, if the URI is included with an Address of Record instead of 614 a Contact URI, the URI parameter in the Reqeuest-URI will not be 615 copied over to the Contact URI, resulting in the loss of the 616 information. Note that if this same URI was present in a Refer-To 617 header field, the same loss of information would occur. 619 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and 620 REQ-11. It is possible the approach could meet REQ-12 and REQ-13. 621 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and 622 REQ-14. 624 9. Acknowledgements 626 Joanne McMillen was a major contributor and co-author of earlier 627 versions of this document. Thanks to Paul Kyzivat for his 628 contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith 629 Drage, Vijay Gurbani, and Laura Liess for their review of the 630 document. The authors wish to thank Francois Audet, Denis 631 Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for 632 their comments. 634 10. References 636 10.1. Informative References 638 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 639 formats and codes", 640 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 642 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 643 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 645 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 646 Digital Network (ISDN); Diversion supplementary 647 services". 649 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 650 for Telephones (SIP-T): Context and Architectures", 651 BCP 63, RFC 3372, September 2002. 653 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 654 Initiation Protocol (SIP) INFO Method and Package 655 Framework", RFC 6086, January 2011. 657 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 658 and H. Schulzrinne, "Session Initiation Protocol (SIP) 659 Torture Test Messages", RFC 4475, May 2006. 661 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 662 for the Session Initiation Protocol (SIP) and the Real- 663 time Applications and Infrastructure Area", BCP 67, 664 RFC 5727, March 2010. 666 [I-D.drage-cuss-sip-uui-isdn] 667 Drage, K. and A. Johnston, "Interworking ISDN Call Control 668 User Information with SIP", 669 draft-drage-cuss-sip-uui-isdn-01 (work in progress), 670 September 2011. 672 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) - 673 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/ 674 sg11aap/history/q1980.1/q1980.1.html . 676 10.2. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, March 1997. 681 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 682 A., Peterson, J., Sparks, R., Handley, M., and E. 683 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 684 June 2002. 686 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 687 Identity", RFC 3324, November 2002. 689 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 690 Extensions to the Session Initiation Protocol (SIP) for 691 Asserted Identity within Trusted Networks", RFC 3325, 692 November 2002. 694 [I-D.ietf-cuss-sip-uui-reqs] 695 Johnston, A. and L. Liess, "Problem Statement and 696 Requirements for Transporting User to User Call Control 697 Information in SIP", draft-ietf-cuss-sip-uui-reqs-07 (work 698 in progress), October 2011. 700 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 701 Authenticated Identity Management in the Session 702 Initiation Protocol (SIP)", RFC 4474, August 2006. 704 [I-D.ietf-sipcore-rfc4244bis] 705 Barnes, M., Audet, F., Schubert, S., Gmbh, D., and C. 706 Holmberg, "An Extension to the Session Initiation Protocol 707 (SIP) for Request History Information", 708 draft-ietf-sipcore-rfc4244bis-06 (work in progress), 709 October 2011. 711 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 712 Protocol (SIP)", RFC 4916, June 2007. 714 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 715 "Indicating User Agent Capabilities in the Session 716 Initiation Protocol (SIP)", RFC 3840, August 2004. 718 Authors' Addresses 720 Alan Johnston 721 Avaya 722 St. Louis, MO 63124 724 Email: alan.b.johnston@gmail.com 726 James Rafferty 727 Dialogic 729 Email: james.rafferty@dialogic.com