idnits 2.17.1 draft-ietf-cuss-sip-uui-reqs-09.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 (January 3, 2012) is 4489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CUSS WG A. Johnston 3 Internet-Draft Avaya 4 Intended status: Informational L. Liess 5 Expires: July 6, 2012 Deutsche Telekom AG 6 January 3, 2012 8 Problem Statement and Requirements for Transporting User to User Call 9 Control Information in SIP 10 draft-ietf-cuss-sip-uui-reqs-09 12 Abstract 14 This document introduces the transport of call control related User 15 to User Information (UUI) using the Session Initiation Protocol 16 (SIP), and develops several requirements for a new SIP mechanism. 17 Some SIP sessions are established by or related to a non-SIP 18 application. This application may have information that needs to be 19 transported between the SIP User Agents during session establishment. 20 In addition to interworking with the ISDN UUI Service, this extension 21 will also be used for native SIP endpoints requiring application UUI. 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 July 6, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 4 60 2.2. Proxy Retargeting . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Overview 72 This document describes the transport of User to User Information 73 (UUI) during SIP [RFC3261] session setup. This section introduces 74 UUI and explains how it relates to SIP. 76 We define SIP UUI data as application-specific information that is 77 related to a session being established using SIP. It is assumed that 78 the application is running in both endpoints in a two party session. 79 That is, the application interacts with both the User Agents in a SIP 80 session. In order to function properly, the application needs a 81 small piece of information, the UUI, to be transported at the time of 82 session establishment. This information is essentially opaque data 83 to SIP - it is unrelated to SIP routing, authentication, or any other 84 SIP function. This application can be considered to be operating at 85 a higher layer on the protocol stack. As a result, SIP should not 86 interpret, understand, or perform any operations on the UUI. Should 87 this not be the case, then the information being transported is not 88 considered UUI, and another SIP-specific mechanism will be needed to 89 transport the information (such as a new header field). In 90 particular, this mechanism creates no requirements on intermediaries 91 such as proxies, Back-to-Back User Agents, and Session Border 92 Controllers. 94 UUI is defined this way for two reasons. Firstly, this supports a 95 strict layering of protocols and data. Providing information and 96 understanding of the UUI to the transport layer (SIP in this case) 97 would not provide any benefits and instead could create cross layer 98 coupling. Secondly, it is neither feasible nor desirable for a SIP 99 User Agent (UA) to understand the information; instead the goal is 100 for the UA to simply pass the information as efficiently as possible 101 to the application which does understand the information. 103 Note that this document does not discuss the transport of non-call 104 control UUI which can be done using the SIP INFO method. 106 An important application is the interworking with User to User 107 Information (UUI) in ISDN, specifically, the transport of the call 108 control related ITU-T Q.931 User to User Information Element (UU IE) 109 [Q931] and ITU-T Q.763 User to User Information Parameter [Q763] data 110 in SIP. ISDN UUI is widely used in the PSTN today in contact centers 111 and call centers. These applications are currently transitioning 112 away from using ISDN for session establishment to using SIP. Native 113 SIP endpoints will need to implement a similar service and be able to 114 interwork with this ISDN service. 116 Note that the distinction between call control UUI and non-call 117 control UUI is very important. SIP already has a mechanism for 118 sending arbitrary UUI data between UAs during a session or dialog - 119 the SIP INFO [RFC6086] method. Call control UUI, in contrast, must 120 be exchanged at the time of setup and needs to be carried in the 121 INVITE and a few other methods and responses. Applications that 122 exchange UUI but do not have a requirement that it be transported and 123 processed during call setup can simply use SIP INFO and do not need a 124 new SIP extension. 126 In this document, four different use case call flows are discussed. 127 Next, the requirements for call control UUI transport are discussed. 129 2. Use Cases 131 This section discusses four use cases for the transport of call 132 control related user to user information. These use cases will help 133 motivate the requirements for SIP call control UUI. 135 2.1. User Agent to User Agent 137 In this scenario, the originating UA includes UUI in the INVITE sent 138 through a proxy to the terminating UA. The terminating UA can use 139 the UUI in any way. If it is an ISDN gateway, it could map the UUI 140 into the appropriate DSS1 information element or QSIG [QSIG] 141 information element or ISUP parameter. Alternatively, the using 142 application might render the information to the user, or use it 143 during alerting or as a lookup for a screen pop. In this case, the 144 proxy does not need to understand the UUI mechanism, but normal proxy 145 rules should result in the UUI being forwarded without modification. 146 This call flow is shown in Figure 1. 148 Originating UA Proxy Terminating UA 149 | | | 150 | INVITE (UUI) F1 | | 151 |------------------->| INVITE (UUI) F2 | 152 | 100 Trying F3 |------------------->| 153 |<-------------------| 200 OK F4 | 154 | 200 OK F5 |<-------------------| 155 |<-------------------| | 156 | ACK F6 | | 157 |------------------->| ACK F7 | 158 | |------------------->| 160 Figure 1. Call flow with UUI exchanged between Originating and 161 Terminating UAs. 163 2.2. Proxy Retargeting 165 In this scenario, the originating UA includes UUI in the INVITE 166 request sent through a proxy to the terminating UA. The proxy 167 retargets the INVITE request, changing its request-URI to a URI that 168 addresses the terminating UA. The UUI data is then received and 169 processed by the terminating UA. This call flow is identical to 170 Figure 1 except that the proxy retargets the request, i.e., changes 171 the Request-URI as directed by some unspecified process. The UUI in 172 the INVITE request needs to be passed unchanged through this proxy 173 retargeting operation. Note that the contents of the UUI is not used 174 by the proxy for routing, as the UUI has only end-to-end significance 175 between UAs. 177 2.3. Redirection 179 In this scenario, UUI is inserted by an application which utilizes a 180 SIP redirect server. The UUI is then included in the INVITE request 181 sent by the originating UA to the terminating UA. In this case, the 182 originating UA does not necessarily need to support the UUI mechanism 183 but does need to support the SIP redirection mechanism used to 184 include the UUI data. Two examples of UUI with redirection (transfer 185 and diversion) are defined in [ANSII] and [ETSI]. 187 Note that this case may not precisely map to an equivalent ISDN 188 service use case. This is because there is no one-to-one mapping 189 between elements in a SIP network and elements in an ISDN network. 190 Also, there is not an exact one-to-one mapping between SIP call 191 control and ISDN call control. However, this should not prevent the 192 usage of SIP call control UUI in these cases. Instead, these slight 193 differences between the SIP UUI mechanism and the ISDN service need 194 to be carefully noted and discussed in an interworking specification. 196 Figure 2 shows this scenario, with the Redirect inserting UUI which 197 is then included in the INVITE request F4 send to the terminating UA. 199 Originating UA Redirect Server Terminating UA 200 | | | 201 | INVITE F1 | | 202 |------------------->| | 203 | 302 Moved (UUI) F2 | | 204 |<-------------------| | 205 | ACK F3 | | 206 |------------------->| | 207 | INVITE (UUI) F4 | | 208 |---------------------------------------->| 209 | 200 OK F5 | 210 |<----------------------------------------| 211 | ACK F6 | 212 |---------------------------------------->| 214 Figure 2. Call flow with UUI exchanged between Redirect Server and 215 Terminating UA. 217 A common example application of this call flow is an Automatic Call 218 Distributer (ACD) in a PSTN contact center. The originator would be 219 a PSTN gateway. The ACD would act as a Redirect Server, inserting 220 UUI based on called number, calling number, time of day, and other 221 information. The resulting UUI would be passed to the agent's 222 handset which acts as the terminating UA. The UUI could be used to 223 lookup information for rendering to the agent at the time of call 224 answering. 226 This redirection scenario, and the referral scenario in the next 227 section, are the most important scenarios for contact center 228 applications. Incoming calls to a contact center almost always are 229 redirected or referred to a final destination, sometimes multiple 230 times, based on collected information and business logic. The 231 ability to pass along UUI in these call redirection scenarios is 232 critical. 234 2.4. Referral 236 In this scenario, the application uses a UA to initiate a referral, 237 which causes an INVITE request to be generated between the 238 originating UA and terminating UA with UUI data inserted by the 239 Referrer UA. Note that this REFER method [RFC3515] could be part of 240 a transfer operation or it might be unrelated to an existing call, 241 such as out-of-dialog REFER request. In some cases, this call flow 242 is used in place of the redirection call flow: the referrer 243 immediately answers the call and then sends the REFER request. This 244 scenario is shown in Figure 3. 246 Originating UA Referrer Terminating UA 247 | | | 248 | REFER (UUI) F1 | | 249 |<-------------------| | 250 | 202 Accepted F2 | | 251 |------------------->| | 252 | INVITE (UUI) F3 | | 253 |---------------------------------------->| 254 | NOTIFY (100 Trying) F4 | 255 |------------------->| | 256 | 200 OK F5 | | 257 |<-------------------| | 258 | 200 OK F6 | 259 |<----------------------------------------| 260 | ACK F7 | 261 |---------------------------------------->| 262 | NOTIFY (200 OK) F8 | | 263 |------------------->| | 264 | 200 OK F9 | | 265 |<-------------------| | 267 Figure 3. Call flow with Referral and UUI. 269 3. Requirements 271 This section states the requirements for the transport of call 272 control related user to user information (UUI). 274 REQ-1: The mechanism will allow UAs to insert and receive UUI data in 275 SIP call setup requests and responses. 277 SIP messages covered by this include INVITE requests and end-to- 278 end responses to the INVITE, i.e. 18x and 200 responses. UUI data 279 may also be inserted in 3xx responses to an INVITE. However, if a 280 3xx response is recursed on by an intermediary proxy, the 281 resulting INVITE will not contain the UUI data from the 3xx 282 response. In a scenario where a proxy forks an INVITE to multiple 283 UAS who include UUI data in 3xx responses, if a 3xx response is 284 the best response sent upstream by the proxy, it will contain the 285 UUI data from only one 3xx response. 287 REQ-2: The mechanism will allow UAs to insert and receive UUI data in 288 SIP dialog terminating requests and responses. 290 Q.931 UUI supports inclusion in release and release completion 291 messages. SIP messages covered by this include BYE and 200 OK 292 responses to a BYE. 294 REQ-3: The mechanism will allow UUI to be inserted and retrieved in 295 SIP redirects and referrals. 297 SIP messages covered by this include REFER requests and 3xx 298 responses to INVITE requests. 300 REQ-4: The mechanism will allow UUI to be able to survive proxy 301 retargeting or redirection of the request. 303 Retargeting is a common method of call routing in SIP, and must 304 not result in the loss of user to user information. 306 REQ-5: The mechanism should not require processing entities to 307 dereference a URL in order to retrieve the UUI data. 309 Passing a pointer or link to the UUI data will not meet the real- 310 time processing considerations and would complicate interworking 311 with the PSTN. 313 REQ-6: The mechanism will support interworking with call control 314 related DSS1 information elements or QSIG information elements and 315 ISUP parameters. 317 REQ-7: The mechanism will allow a UAC to learn that a UAS understands 318 the UUI mechanism. 320 REQ-8: The mechanism will allow a UAC to require that a UAS 321 understands the call control UUI mechanism and have a request routed 322 based on this information. If the request cannot be routed to a UAS 323 that understands the UUI mechanism, the request will fail. 325 This could be useful in ensuring that a request destined for the 326 PSTN is routed to a gateway that supports the UUI mechanism rather 327 than an otherwise equivalent PSTN gateway that does not support 328 the ISDN mechanism. Note that support of the UUI mechanism does 329 not, by itself, imply that a particular application is supported - 330 see REQ-10. 332 REQ-9: The mechanism will allow proxies to remove a particular 333 application usage of UUI data from a request or response. 335 This is a common security function provided by border elements to 336 header fields such as Alert-Info or Call-Info URIs. There is no 337 requirement for UAs to be able to determine if a particular usage 338 of UUI data has been removed from a request or response. 340 REQ-10: The mechanism will provide the ability for a UA to discover 341 which application usages of UUI another UA understands or supports. 343 The creation of a registry of application usages for the UUI 344 mechanism is implied by this requirement. The ISDN Service 345 utilizes a field known as the protocol discriminator, which is the 346 first octet of the ISDN UUI data, for this purpose. 348 REQ-11: The UUI is a sequence of octets. The solution will provide a 349 mechanism of transporting at least 128 octets of user data and a one 350 octet protocol discriminator, i.e. 129 octets in total. 352 There is the potential for non-ISDN services to allow UUI to be 353 larger than 128 octets. However, users of the mechanism will need 354 be cognizant of the size of SIP messages and the ability of 355 parsers to handle extremely large values. 357 REQ-12: The recipient of UUI will be able to determine the entity 358 that inserted the UUI. It is acceptable that this is performed 359 implicitly where it is known that there is only one other end UA 360 involved in the dialog. Where that does not exist, some other 361 mechanism will need to be provided. The UUI mechanism does not 362 introduce stronger authorization requirements for SIP, but instead 363 the mechanism needs to be able to utilize existing SIP approaches for 364 request and response identity. 366 This requirement comes into play during redirection, retargeting, 367 and referral scenarios. 369 4. Security Considerations 371 The security requirements for the UUI mechanism are described in this 372 section. It is important to note that UUI security is jointly 373 provided at the application layer and at the SIP layer. As such, is 374 important for application users of the UUI mechanism to know the 375 level of security used and deployed in their particular SIP 376 environments, and not to assume that a standardized (but perhaps 377 rarely deployed) security mechanism is in place. 379 There are three main security models that need to be addressed by the 380 UUI mechanism. One model treats the SIP layer as untrusted and 381 requires end-to-end integrity protection and/or encryption. This 382 model can be achieved by providing these security services at a layer 383 above SIP. In this case, the application integrity protects and/or 384 encrypts the UUI data before passing it to the SIP layer. This 385 method has two advantages: it does not assume or rely on end-to-end 386 security mechanisms in SIP which have virtually no deployment, and 387 allows the application which understands the contents of the UUI to 388 apply a proper level of security. The other approach is for the 389 application to pass the UUI without any protection to the SIP layer 390 and require the SIP layer to provide this security. This approach is 391 possible in theory, although its practical use would be extremely 392 limited. 394 The third model utilizes a trust domain and relies on perimeter 395 security at the SIP layer. This is the security model of the PSTN 396 and ISDN where UUI is commonly used today. This approach uses hop- 397 by-hop security mechanisms and relies on border elements for 398 filtering and application of policy. This approach is used today in 399 UUI deployments. Within this approach, there is a requirement that 400 intermediary elements can detect and remove a UUI element based on 401 policy, but there is no requirement that an intermediary element be 402 able to read or interpret the UUI (as the UUI contents only have end- 403 to-end significance). 405 The next three requirements capture the UUI security requirements. 407 REQ-13: The mechanism will allow integrity protection of the UUI. 409 This allows the UAS to be able to know that the UUI has not been 410 modified or tampered with by intermediaries. Note that there are 411 tradeoffs between this requirement and requirement REQ-9 for 412 intermediaries to remove UUI. One possible way to satify both of 413 these requirements is to utilize hop-by-hop protection. This 414 property is not guaranteed by the protocol in the ISDN 415 application. 417 REQ-14: The mechanism will allow end-to-end privacy of the UUI. 419 Some UUI may contain private or sensitive information and may 420 require different security handling from the rest of the SIP 421 message. Note that this property is not available in the ISDN 422 application. 424 REQ-15: The mechanism will allow both end-to-end and hop-by-hop 425 security models. 427 The hop-by-hop model is required by the ISDN UUI service. 429 5. IANA Considerations 431 This document has no IANA requirements. 433 6. Acknowledgements 435 Thanks to Joanne McMillen who was a co-author of earlier versions of 436 this specification. Thanks to Spencer Dawkins, Keith Drage, Dale 437 Worley, and Vijay Gurbani for their review of earlier versions of 438 this document. The authors wish to thank Christer Holmberg, 439 Frederique Forestie, Francois Audet, Denis Alexeitsev, Paul Kyzivat, 440 Cullen Jennings, and Mahalingam Mani for their comments on this 441 topic. 443 7. Informative References 445 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 446 A., Peterson, J., Sparks, R., Handley, M., and E. 447 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 448 June 2002. 450 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 451 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 453 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 454 formats and codes", 455 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 457 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 458 Digital Network (ISDN)-Explicit Call Transfer 459 Supplementary Service". 461 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 462 Digital Network (ISDN); Diversion supplementary services". 464 [QSIG] "ECMA-143 "Private Integrated Services Network (PISN) - 465 Circuit Mode Bearer Services - Inter-Exchange Signalling 466 Procedures and Protocol" December 2001". 468 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 469 Initiation Protocol (SIP) INFO Method and Package 470 Framework", RFC 6086, January 2011. 472 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 473 Method", RFC 3515, April 2003. 475 Authors' Addresses 477 Alan Johnston 478 Avaya 479 St. Louis, MO 63124 481 Email: alan.b.johnston@gmail.com 483 Laura Liess 484 Deutsche Telekom AG 486 Email: laura.liess.dt@gmail.com