idnits 2.17.1 draft-ietf-cuss-sip-uui-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 539 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 (September 20, 2011) is 4603 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 396, but not defined == Unused Reference: 'ETSI' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC3324' is defined on line 586, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3324 == Outdated reference: A later version (-09) exists of draft-ietf-cuss-sip-uui-reqs-05 ** 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-05 Summary: 3 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: March 23, 2012 Dialogic 6 September 20, 2011 8 A Mechanism for Transporting User to User Call Control Information in 9 SIP 10 draft-ietf-cuss-sip-uui-02 12 Abstract 14 There is a need for applications using SIP to exchange User to User 15 Information (UUI) data during session establishment. This 16 information, known as call control UUI, is a small piece of data 17 inserted by an application initiating the session, and utilized by an 18 application accepting the session. This data is opaque to SIP and 19 its function is unrelated to any basic SIP function. This document 20 defines a new SIP header field, User-to-User, to transport UUI, along 21 with an extension mechanism. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 23, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3 60 4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 5 62 4.2. Source Identity of UUI . . . . . . . . . . . . . . . . . . 6 63 5. Guidelines for Usages of the UUI Mechanism . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Registration of Header Field . . . . . . . . . . . . . . . 8 66 6.2. Registration of Header Field Parameters . . . . . . . . . 9 67 6.3. Registration of SIP Option Tag . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 10 70 8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 10 71 8.2. Why Other Protocol Encapsulation UUI Mechanisms are 72 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 11 74 8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 12 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Informative References . . . . . . . . . . . . . . . . . . 13 78 10.2. Normative References . . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Overview 83 This document describes the transport of User to User Information 84 (UUI) using SIP [RFC3261]. Specifically, we discuss a mechanism for 85 the transport of general application UUI and also for the transport 86 of call control related ITU-T Q.931 User to User Information Element 87 (UU IE) [Q931] and ITU-T Q.763 User to User Information Parameter 88 [Q763] data in SIP. UUI is widely used in the PSTN today in contact 89 centers and call centers which are transitioning away from ISDN to 90 SIP. This extension will also be used for native SIP endpoints 91 implementing similar services and interworking with ISDN services. 93 This mechanism was designed to meet the use cases, requirements, and 94 call flows for SIP call control UUI detailed in 95 [I-D.ietf-cuss-sip-uui-reqs]. All references to requirement numbers 96 (REQ-N) and figure numbers refer to this document. 98 The mechanism chosen is a new SIP header field, along with a new SIP 99 option tag. The header field carries the UUI information, along with 100 parameters indicating the encoding of the UUI, the application user 101 of the UUI, and optionally the content of the UUI. The header field 102 can be escaped into URIs supporting referral and redirection 103 scenarios. In these scenarios, History-Info is used to indicate the 104 inserter of the UUI. The SIP option tag is used to indicate support 105 for the header field. Support for the header field indicates that a 106 UA is able to extract the information in the UUI and pass it up the 107 protocol stack. Individual applications using the UUI mechanism will 108 utlize media feature tags to indicate that a UA supports a particular 109 application user of UUI. Guidelines for defininig usages of this 110 mechanism are provided. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. 119 3. Requirements Discussion 121 This section describes how the User-to-User header field meets the 122 requirements in [I-D.ietf-cuss-sip-uui-reqs]. The header field can 123 be included in INVITE requests and responses and BYE requests and 124 responses, meeting REQ-1 and REQ-2. 126 For redirection and referral use cases and REQ-3, the header field 127 would be escaped into the Contact or Refer-To URI. Currently, UAs 128 that support attended transfer support the ability to escape a 129 Replaces header field into a Refer-To URI, and when acting upon this 130 URI add the Replaces header field to the triggered INVITE. This 131 logic and behavior is identical for the UUI header field. The UA 132 processing the REFER or the 3xx to the INVITE will need to support 133 the UUI mechanism, as UAs in general do not process unknown escaped 134 header fields. 136 Since SIP proxy forwarding and retargeting does not affect header 137 fields, the header field meets REQ-4. 139 The UUI header field will carry the UUI data and not a pointer to the 140 data, so REQ-5 is met. 142 Since the basic design of the UUI header field is similar to the ISDN 143 UUI service, interworking with PSTN protocols will be straightforward 144 and will be documented in a separate specification, meeting REQ-6. 146 Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the 147 mechanism and supported applications. REQ-7 relates to support of 148 the UUI header field, while REQ-8 relates to routing based on support 149 of the UUI header field. REQ-7 is met by defining a new SIP option 150 tag 'uui'. The use of a 'Require: uui' in a request, or 'Supported: 151 uui' in an OPTIONS response could be used to require or discover 152 support of the mechanism. The presence of a Supported:uui or 153 Require:uui header field can be used by proxies to route to an 154 appropriate UA, meeting REQ-8. REQ-10 is met by creating a new class 155 of SIP feature tags. For example, the feature tag 'sip.uui-isdn' 156 could be used to indicate support of the ISDN UUI service, or 157 'sip.uui-app1' could be used to indicate support for a particular 158 application, app1. 160 Proxies commonly apply policy to the presence of certain SIP header 161 fields in requests by either passing them or removing them from 162 requests. REQ-9 is met by allowing proxies and other intermediaries 163 to remove UUI header fields in a request or response based on policy. 165 Carrying UUI data elements of at least 129 octets is trivial in the 166 UUI header field, meeting REQ-11. Note that very large UUI elements 167 should be avoided, as SIP header fields have traditionally not been 168 large. 170 To meet REQ-12 in redirection and referral use cases, History-Info 171 [I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting 172 cases, the changed Request-URI will be recorded in the History-Info 173 header field along with the identity of the element that performed 174 the retargeting. 176 The requirement for integrity protection in REQ-13 could be met by 177 the use of an S/MIME signature over a subset of header fields, as 178 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity 179 using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to- 180 end privacy could be met using S/MIME or using encryption at the 181 application layer. Note that the use of S/MIME to secure the UUI 182 will result in an additional body being added to the request. 183 Hopwise TLS allows the header field to meet REQ-15 for hop-by-hop 184 security. 186 4. Normative Definition 188 This document defines a new SIP header field "User-to-User" to 189 transport call control UUI to meet the requirements in 190 [I-D.ietf-cuss-sip-uui-reqs]. 192 To help tag and identify the UUI used with this header field, "app", 193 "content", and "encoding" parameters are defined. The "app" 194 parameter identifies the application which generates and consumes the 195 UUI information. For the case of interworking with the ISDN UUI 196 Service, the application is unknown, so a value to indicate ISDN UUI 197 Service interworking will be defined. If the "app" parameter is not 198 present, interworking with the ISDN UUI Service MUST be assumed. The 199 "content" parameter identifies the actual content of the UUI data. 200 If not present, the content MUST be assumed to be unknown as it is in 201 the ISDN UUI Service. For newly defined applications using the SIP 202 UUI service, a "content" value MUST be defined and SHOULD be used. 203 The "encoding" parameter indicates the method of encoding the 204 information in the UUI. This specification only defines 205 "encoding=hex". If the "encoding" parameter is not present, "hex" 206 MUST be assumed. 208 UUI data is considered an opaque series of octets. This mechanism 209 SHOULD NOT be used to convey a URL or URI: the Call-Info header field 210 [RFC3261] is used for this purpose. 212 4.1. Syntax for UUI Header Field 214 The User-to-User header field can be present in INVITE requests and 215 responses only and in BYE requests and responses. Note that only 216 end-to-end responses can be used, e.g. 1xx, 2xx, and 3xx responses. 218 The following syntax specification uses the augmented Backus-Naur 219 Form (BNF) as described in RFC 2234 and extends RFC 3261. 221 UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param) 222 uui-data = token 223 uui-param = enc-param / cont-param / app-param / generic-param 224 enc-param = "encoding" EQUAL ("hex" / token) 225 cont-param = "content" EQUAL token 226 app-param = "app" EQUAL token 228 A single User-to-User header field may be present in a request or a 229 response. Any size limitations on the UUI for a particular purpose 230 must be defined by that application. 232 4.2. Source Identity of UUI 234 It is important for the recipient of UUI to know the identity of the 235 UA that inserted the UUI. In a request without any History-Info 236 [I-D.ietf-sipcore-rfc4244bis] header field, the inserter of the UUI 237 will be the UA identified by the URI in the From header field. In a 238 request with a History-Info header field, the recipient needs to 239 parse the Targeted-to-URIs present (hi-targeted-to-uri) to see if any 240 escaped User-to-User header fields are present. If an escaped User- 241 to-User header field is present and matches the UUI in the request, 242 it indicates that redirection has taken place which has resulted in 243 the UUI inclusion in the request. The inserter of the UUI will be 244 the UA identified by the Targeted-to-URI of the History-Info element 245 prior to the element with the escaped UUI. In a response, the 246 inserter of the UUI will be the UA identified in the To header field 247 of the response. Note that any updates to this identity by use of 248 the SIP Connected Identity extension [RFC4916] will update this 249 information. 251 For an example of History-Info and redirection, consider Figure 2 252 from [I-D.ietf-cuss-sip-uui-reqs] where the Originating UA is Carol, 253 the Redirector Bob, and the Terminating UA Alice. The INVITE F4 254 containing UUI could be: 256 INVITE sips:alice@example.com SIP/2.0 257 Via: SIP/2.0/TLS lab.example.com:5061 258 ;branch=z9hG4bKnashds9 259 To: Bob 260 From: Carol ;tag=323sf33k2 261 Call-ID: dfaosidfoiwe83ifkdf 262 Max-Forwards: 70 263 Contact: 264 Supported: histinfo 265 User-to-User: 342342ef34;encoding=hex 266 History-Info: ;index=1 267 268 History-Info: ;index=1.1;rc=1 270 272 Without the redirection captured in the History-Info, Alice would 273 conclude the UUI was inserted by Carol. However, the History-Info 274 containing UUI (index=1.1) indicates that the inserter was Bob 275 (index=1). 277 To enable the inserter identity of UUI, UAs supporting this mechanism 278 SHOULD support History-Info [I-D.ietf-sipcore-rfc4244bis] and include 279 Supported: histinfo in all requests and responses. 281 5. Guidelines for Usages of the UUI Mechanism 283 All applications using this SIP UUI mechanism must publish a 284 standards track RFC which describes the usage. The SIP UUI mechanism 285 is applicable in the following situations: 287 1. The information is generated and consumed by an application 288 during session setup using SIP, but the application is not 289 necessarily SIP aware. 291 2. The behavior of SIP entities that support it is not 292 significantly changed (as discussed in Section 4 of [RFC5727]). 294 3. User Agent Clients (UAC) and User Agent Servers (UAS) are the 295 generators and consumers of the UUI data. Proxies may route based 296 on the application tag but not otherwise be involved. 298 4. Intermediary elements or proxies can remove or insert UUI 299 information 301 This mechanism is not applicable in the following situations: 303 1. The behavior of SIP entities that support it is significantly 304 changed (as discussed in Section 4 of [RFC5727]). 306 2. The information is generated and consumed at the SIP layer by 307 SIP elements. 309 3. SIP elements besides the UAC and UAS might be interested in 310 consuming (beyond adding or removing) the information. 312 4. There are specific privacy issues involved with the 313 information being transported (e.g., geolocation or emergency- 314 related information). 316 This specification defines only the value of "hex" for the "encoding" 317 parameter. New values can be defined and added to the IANA registry 318 with a standards track RFC, which needs to discuss the issues in this 319 section. 321 New "encoding" values must reference a common encoding scheme or 322 define the exact new encoding scheme. 324 New "content" values must describe the content of the UUI and give 325 some example use cases. The default "encoding" and other allowed 326 encoding methods must be defined for this new content. 328 New "app" values must describe the new application which is utilizing 329 the UUI data and give some example use cases. The default "content" 330 value and other allowed contents must be defined for this new 331 purpose. Any restrictions on the size of the UUI data must be 332 described for the new application. In addition, it is recommended 333 that a Media Feature tag be defined per RFC 3840 [RFC3840] to 334 indicate support for this application usage of UUI. For example, the 335 media feature tag sip.uui-app1 could be defined to indicate support 336 for an app named app1. The definition of a new SIP feature tag for 337 this application is NOT RECOMMENDED unless there are other SIP 338 behaviors needed to implement this feature. 340 For an example UUI usage definition, see 341 [I-D.drage-cuss-sip-uui-isdn]. 343 6. IANA Considerations 345 6.1. Registration of Header Field 347 This document defines a new SIP header field named "User-to-User". 349 The following row shall be added to the "Header Fields" section of 350 the SIP parameter registry: 352 +------------------+--------------+-----------+ 353 | Header Name | Compact Form | Reference | 354 +------------------+--------------+-----------+ 355 | User-to-User | | [RFCXXXX] | 356 +------------------+--------------+-----------+ 358 Editor's Note: [RFCXXXX] should be replaced with the designation of 359 this document. 361 6.2. Registration of Header Field Parameters 363 This document defines the parameters for the header field defined in 364 the preceding section. The header field "User-to-User" can contain 365 the parameters "encoding", "content", and "purpose". 367 The following rows shall be added to the "Header Field Parameters and 368 Parameter Values" section of the SIP parameter registry: 370 +------------------+----------------+-------------------+-----------+ 371 | Header Field | Parameter Name | Predefined Values | Reference | 372 +------------------+----------------+-------------------+-----------+ 373 | User-to-User | encoding | hex | [RFCXXXX] | 374 +------------------+----------------+-------------------+-----------+ 376 Editor's Note: [RFCXXXX] should be replaced with the designation of 377 this document. 379 6.3. Registration of SIP Option Tag 381 This specification registers a new SIP option tag, as per the 382 guidelines in Section 27.1 of [RFC3261]. 384 This document defines the SIP option tag "uui". 386 The following row has been added to the "Option Tags" section of the 387 SIP Parameter Registry: 389 +------------+------------------------------------------+-----------+ 390 | Name | Description | Reference | 391 +------------+------------------------------------------+-----------+ 392 | uui | This option tag is used to indicate that | [RFCXXXX] | 393 | | a UA supports and understands the | | 394 | | User-to-User header field. | | 395 +------------+------------------------------------------+-----------+ 396 Editor's Note: [RFCXXXX] should be replaced with the designation of 397 this document. 399 7. Security Considerations 401 User to user information can potentially carry sensitive information 402 that might require privacy or integrity protection. Standard 403 deployed SIP security mechanisms such as TLS transport, offer these 404 properties on a hop-by-hop basis. To preserve multi-hop or end-to- 405 end confidentiality and integrity of UUI, approaches using S/MIME can 406 be used, as discussed in the draft. However, the lack of deployment 407 of these mechanisms means that applications can not in general rely 408 on them. As such, applications are encouraged to utilize their own 409 security mechanisms. 411 8. Appendix - Other Possible Mechanisms 413 Two other possible mechanisms for transporting UUI will be described: 414 MIME body and URI parameter transport. 416 8.1. Why INFO is Not Used 418 Since the INFO method [RFC6086], was developed for ISUP interworking 419 of user-to-user information, it might seem to be the logical choice 420 here. For non-call control user-to-user information, INFO can be 421 utilized for end to end transport. However, for transport of call 422 control user-to-user information, INFO can not be used. As the call 423 flows in [I-D.ietf-cuss-sip-uui-reqs] show, the information is 424 related to an attempt to establish a session and must be passed with 425 the session setup request (INVITE), responses to that INVITE, or 426 session termination requests. As a result, it is not possible to use 427 INFO in these cases. 429 8.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used 431 Other protocols have the ability to transport UUI information. For 432 example, consider the ITU-T Q.931 User to User Information Element 433 (UU IE) [Q931] and the ITU-T Q.763 User to User Information Parameter 434 [Q763]. In addition, NSS (Narrowband Signaling System) [Q1980] is 435 also able to transport UUI information. Should one of these 436 protocols be in use, and present in both User Agents, then utilizing 437 these other protocols to transport UUI might be a logical solution. 438 Essentially, this is just adding an additional layer in the protocol 439 stack. In these cases, SIP is not transporting the UUI; it is 440 encapsulating another protocol, and that protocol is transporting the 441 UUI. Once a mechanism to transport that other protocol using SIP 442 exists, the UUI transport function is essentially obtained without 443 any additional effort or work. 445 However, the authors believe that SIP needs to have its own native 446 UUI transport mechanism. It is not reasonable for a SIP UA to have 447 to implement another entire protocol (either ISDN or NSS, for 448 example) just to get the very simple UUI transport service. Of 449 course, this work does not preclude anyone from using other protocols 450 with SIP to transport UUI information. 452 8.3. MIME body Approach 454 One method of transport is to use a MIME body. This is in keeping 455 with the SIP-T architecture [RFC3372] in which MIME bodies are used 456 to transport ISUP information. Since the INVITE will normally have 457 an SDP message body, the resulting INVITE with SDP and UUI will be 458 multipart MIME. This is not ideal as many SIP UAs do not support 459 multipart MIME INVITEs. 461 A bigger problem is the insertion of a UUI message body by a redirect 462 server or in a REFER. The body would need to be encoded in the 463 Contact URI of the 3xx response or the Refer-To URI of a REFER. 464 Currently, the authors are not aware of any UAs that support this 465 capability today for any body type. As such, the complete set of 466 semantics for this operation would need to be determined and defined. 467 Some issues will need to be resolved, such as, do all the Content-* 468 header fields have to be escaped as well? And, what if the escaped 469 Content-Length does not agree with the escaped body? 471 Since proxies cannot remove a body from a request or response, it is 472 not at all clear how this mechanism could meet REQ-9. 474 The requirement for integrity protection could be met by the use of 475 an S/MIME signature over the body, as defined in Section 23.3 of RFC 476 3261 "Securing MIME bodies". Alternatively, this could be achieved 477 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy 478 could be met using S/MIME encryption or using encryption at the 479 application layer. However, note that neither S/MIME or RFC 4474 480 enjoys deployment in SIP today. 482 An example: 484 485 Contact: 487 489 Note that the tag convention from SIP Torture Test 490 Messages [RFC4475] is used to show that there are no line breaks in 491 the actual message syntax. 493 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, 494 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, 495 although the authors do not have a specific mechanism to propose. 496 Meeting REQ-3 is problematic, but not impossible for this mechanism. 497 However, this mechanism does not seem to be able to meet REQ-9. 499 8.4. URI Parameter 501 Another proposed approach is to encode the UUI as a URI parameter. 502 This UUI parameter could be included in a Request-URI or in the 503 Contact URI or Refer-To URI. It is not clear how it could be 504 transported in a responses which does not have a Request-URI, or in 505 BYE requests or responses. 507 508 Contact: 510 512 An INVITE sent to this Contact URI would contain UUI in the Request- 513 URI of the INVITE. The URI parameter has a drawback in that a URI 514 parameter carried in a Request-URI will not survive retargeting by a 515 proxy as shown in Figure 2 of [I-D.ietf-cuss-sip-uui-reqs]. That is, 516 if the URI is included with an Address of Record instead of a Contact 517 URI, the URI parameter in the Reqeuest-URI will not be copied over to 518 the Contact URI, resulting in the loss of the information. Note that 519 if this same URI was present in a Refer-To header field, the same 520 loss of information would occur. 522 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and 523 REQ-11. It is possible the approach could meet REQ-12 and REQ-13. 524 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and 525 REQ-14. 527 9. Acknowledgements 529 Joanne McMillen was a major contributor and co-author of earlier 530 versions of this document. Thanks to Spencer Dawkins, Keith Drage, 531 Vijay Gurbani, and Laura Liess for their review of the document. The 532 authors wish to thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, 533 Cullen Jennings, and Mahalingam Mani for their comments. 535 10. References 536 10.1. Informative References 538 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 539 formats and codes", 540 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 542 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 543 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 545 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 546 Digital Network (ISDN); Diversion supplementary 547 services". 549 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 550 for Telephones (SIP-T): Context and Architectures", 551 BCP 63, RFC 3372, September 2002. 553 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 554 Initiation Protocol (SIP) INFO Method and Package 555 Framework", RFC 6086, January 2011. 557 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 558 and H. Schulzrinne, "Session Initiation Protocol (SIP) 559 Torture Test Messages", RFC 4475, May 2006. 561 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 562 for the Session Initiation Protocol (SIP) and the Real- 563 time Applications and Infrastructure Area", BCP 67, 564 RFC 5727, March 2010. 566 [I-D.drage-cuss-sip-uui-isdn] 567 Drage, K. and A. Johnston, "Interworking ISDN Call Control 568 User Information with SIP", 569 draft-drage-cuss-sip-uui-isdn-01 (work in progress), 570 September 2011. 572 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) - 573 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/ 574 sg11aap/history/q1980.1/q1980.1.html . 576 10.2. Normative References 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, March 1997. 581 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 582 A., Peterson, J., Sparks, R., Handley, M., and E. 583 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 584 June 2002. 586 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 587 Identity", RFC 3324, November 2002. 589 [I-D.ietf-cuss-sip-uui-reqs] 590 Johnston, A. and L. Liess, "Problem Statement and 591 Requirements for Transporting User to User Call Control 592 Information in SIP", draft-ietf-cuss-sip-uui-reqs-05 (work 593 in progress), September 2011. 595 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 596 Authenticated Identity Management in the Session 597 Initiation Protocol (SIP)", RFC 4474, August 2006. 599 [I-D.ietf-sipcore-rfc4244bis] 600 Barnes, M., Audet, F., Schubert, S., Gmbh, D., and C. 601 Holmberg, "An Extension to the Session Initiation Protocol 602 (SIP) for Request History Information", 603 draft-ietf-sipcore-rfc4244bis-05 (work in progress), 604 April 2011. 606 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 607 Protocol (SIP)", RFC 4916, June 2007. 609 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 610 "Indicating User Agent Capabilities in the Session 611 Initiation Protocol (SIP)", RFC 3840, August 2004. 613 Authors' Addresses 615 Alan Johnston 616 Avaya 617 St. Louis, MO 63124 619 Email: alan.b.johnston@gmail.com 621 James Rafferty 622 Dialogic 624 Email: james.rafferty@dialogic.com