idnits 2.17.1 draft-ietf-cuss-sip-uui-reqs-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 11, 2011) is 4636 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3261' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'QSIG' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC3372' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC3324' is defined on line 454, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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: February 12, 2012 Deutsche Telekom AG 6 August 11, 2011 8 Problem Statement and Requirements for Transporting User to User Call 9 Control Information in SIP 10 draft-ietf-cuss-sip-uui-reqs-04 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 February 12, 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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 4 60 2.2. Proxy Retargeting . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 66 6. Informative References . . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Overview 71 This document describes the transport of User to User Information 72 (UUI) during SIP session setup. This section introduces UUI and 73 explains how it relates to SIP. 75 We define SIP UUI information as application-specific information 76 that is related to a session being established using SIP. It is 77 assumed that the application is running in both endpoints in a two 78 party session. That is, the application interacts with both the User 79 Agents in a SIP session. In order to function properly, the 80 application needs a small piece of information, the UUI, to be 81 transported at the time of session establishment. This information 82 is essentially opaque data to SIP - it is unrelated to SIP routing, 83 authentication, or any other SIP function. This application can be 84 considered to be operating at a higher layer on the protocol stack. 85 As a result, SIP should not interpret, understand, or perform any 86 operations on the UUI. Should this not be the case, then the 87 information being transported is not considered UUI, and another SIP- 88 specific mechanism will be needed to transport the information (such 89 as a new header field). 91 UUI is defined this way for two reasons. Firstly, this supports a 92 strict layering of protocols and data. Providing information and 93 understanding of the UUI to the transport layer (SIP in this case) 94 would not provide any benefits and instead could create cross layer 95 coupling. Secondly, it is neither feasible nor desirable for a SIP 96 User Agent (UA) to understand the information; instead the goal is 97 for the UA to simply pass the information as efficiently as possible 98 to the application which does understand the information. 100 An important application is the interworking with User to User 101 Information (UUI) in ISDN, specifically, the transport of the call 102 control related ITU-T Q.931 User to User Information Element (UU IE) 103 [Q931] and ITU-T Q.763 User to User Information Parameter [Q763] data 104 in SIP. ISDN UUI is widely used in the PSTN today in contact centers 105 and call centers. These applications are currently transitioning 106 away from using ISDN for session establishment to using SIP. Native 107 SIP endpoints will need to implement a similar service and be able to 108 interwork with this ISDN service. 110 Note that the distinction between call control UUI and non-call 111 control UUI is very important. SIP already has a mechanism for 112 sending arbitrary UUI information between UAs during a session or 113 dialog - the SIP INFO [RFC2976] method. Call control UUI, in 114 contrast, must be exchanged at the time of setup and needs to be 115 carried in the INVITE and a few other methods and responses. 116 Applications that exchange UUI but do not have a requirement that it 117 be transported and processed during call setup can simply use SIP 118 INFO and do not need a new SIP extension. 120 In this document, four different use case call flows are discussed. 121 Next, the requirements for call control UUI transport are discussed. 123 2. Use Cases 125 This section discusses four use cases for the transport of call 126 control related user to user information. What is not discussed here 127 is the transport of non-call control UUI which can be done using the 128 SIP INFO method. These use cases will help motivate the requirements 129 for SIP call control UUI. 131 2.1. User Agent to User Agent 133 In this scenario, the originator UA includes UUI in the INVITE sent 134 through a proxy to the terminating UA. The terminator can use the 135 UUI in any way. If it is an ISDN gateway, it could map the UUI into 136 the appropriate DSS1 information element or QSIG information element 137 or ISUP parameter. Alternatively, the using application might render 138 the information to the user, or use it during alerting or as a lookup 139 for a screen pop. In this case, the proxy does not need to 140 understand the UUI mechanism, but normal proxy rules should result in 141 the UUI being forwarded without modification. This call flow is 142 shown in Figure 1. 144 Originator Proxy Terminator 145 | | | 146 | INVITE (UUI) F1 | | 147 |------------------->| INVITE (UUI) F2 | 148 | 100 Trying F3 |------------------->| 149 |<-------------------| 200 OK F4 | 150 | 200 OK F5 |<-------------------| 151 |<-------------------| | 152 | ACK F6 | | 153 |------------------->| ACK F7 | 154 | |------------------->| 156 Figure 1. Call flow with UUI exchanged between Originator and 157 Terminator. 159 2.2. Proxy Retargeting 161 In this scenario, the originator UA includes UUI in the INVITE sent 162 through a proxy to the terminating UA. The proxy retargets the 163 INVITE, sending it to a different termination UA. The UUI 164 information is then received and processed by the terminating UA. 165 This call flow is identical to Figure 1 but with a different 166 destination for the INVITE. The UUI in the INVITE needs to be passed 167 unchanged through this proxy retargeting operation. 169 2.3. Redirection 171 In this scenario, UUI is inserted by an application which utilizes a 172 SIP redirect server. The UUI is then included in the INVITE sent by 173 the Originator to the Terminator. In this case, the Originator does 174 not necessarily need to support the UUI mechanism but does need to 175 support the SIP redirection mechanism used to include the UUI 176 information. Two examples of UUI with redirection (transfer and 177 diversion) are defined in [ANSII] and [ETSI]. 179 Note that this case may not precisely map to an equivalent ISDN 180 service use case. This is because there is no one-to-one mapping 181 between elements in a SIP network and elements in an ISDN network. 182 Also, there is not an exact one-to-one mapping between SIP call 183 control and ISDN call control. However, this should not prevent the 184 usage of SIP call control UUI in these cases. Instead, these slight 185 differences between the SIP UUI service and the ISDN service need to 186 be carefully noted and discussed in an interworking specification. 188 Figure 2 shows this scenario, with the Redirect inserting UUI which 189 is then included in the INVITE F4 send to the Terminator. 191 Originator Redirect Server Terminator 192 | | | 193 | INVITE F1 | | 194 |------------------->| | 195 | 302 Moved (UUI) F2 | | 196 |<-------------------| | 197 | ACK F3 | | 198 |------------------->| | 199 | INVITE (UUI) F4 | | 200 |---------------------------------------->| 201 | 200 OK F5 | 202 |<----------------------------------------| 203 | ACK F6 | 204 |---------------------------------------->| 206 Figure 2. Call flow with UUI exchanged between Redirect Server and 207 Terminator. 209 A common example application of this call flow is an Automatic Call 210 Distributer (ACD) in a PSTN contact center. The originator would be 211 a PSTN gateway. The ACD would act as a Redirect Server, inserting 212 UUI based on called number, calling number, time of day, and other 213 information. The resulting UUI would be passed to the agent's 214 handset which acts as the Terminator. The UUI could be used to 215 lookup information for rendering to the agent at the time of call 216 answering. 218 This redirection scenario, and the referral scenario in the next 219 section, are the most important scenarios for contact center 220 applications. Incoming calls to a contact center almost always are 221 redirected or referred to a final destination, sometimes multiple 222 times, based on collected information and business logic. The 223 ability to pass along UUI in these call redirection scenarios is 224 critical. 226 2.4. Referral 228 In this scenario, the application uses a UA to initiate a referral, 229 which causes an INVITE to be generated between the Originator and 230 Terminator with UUI information inserted by the Referrer UA. Note 231 that this REFER [RFC3515] could be part of a transfer operation or it 232 might be unrelated to an existing call, such as out-of-dialog REFER. 233 In some cases, this call flow is used in place of the redirection 234 call flow where immediately upon answer, the REFER is sent. This 235 scenario is shown in Figure 3. 237 Originator Referrer Terminator 238 | | | 239 | REFER (UUI) F1 | | 240 |<-------------------| | 241 | 202 Accepted F2 | | 242 |------------------->| | 243 | INVITE (UUI) F3 | | 244 |---------------------------------------->| 245 | NOTIFY (100 Trying) F4 | 246 |------------------->| | 247 | 200 OK F5 | | 248 |<-------------------| | 249 | 200 OK F6 | 250 |<----------------------------------------| 251 | ACK F7 | 252 |---------------------------------------->| 253 | NOTIFY (200 OK) F8 | | 254 |------------------->| | 255 | 200 OK F9 | | 256 |<-------------------| | 258 Figure 3. Call flow with Referral and UUI. 260 3. Requirements 262 This section states the requirements for the transport of call 263 control related user to user information (UUI). 265 REQ-1: The mechanism will allow UAs to insert and receive UUI data in 266 SIP call setup requests and responses. 268 SIP messages covered by this include INVITE requests and end-to- 269 end responses to the INVITE, which includes 18x, 200, and 3xx 270 responses. 272 REQ-2: The mechanism will allow UAs to insert and receive UUI data in 273 SIP dialog terminating requests and responses. 275 Q.931 UUI supports inclusion in release and release completion 276 messages. SIP messages covered by this include BYE and 200 OK 277 responses to a BYE. 279 REQ-3: The mechanism will allow UUI to be inserted and retrieved in 280 SIP redirects and referrals. 282 SIP messages covered by this include REFER requests and 3xx 283 responses to INVITE requests. 285 REQ-4: The mechanism will allow UUI to be able to survive proxy 286 retargeting or any other form of redirection of the request. 288 Retargeting is a common method of call routing in SIP, and must 289 not result in the loss of user to user information. 291 REQ-5: The mechanism should not require processing entities to 292 dereference a URL in order to retrieve the UUI information. 294 Passing a pointer or link to the UUI information will not meet the 295 real-time processing considerations and would complicate 296 interworking with the PSTN. 298 REQ-6: The mechanism will support interworking with call control 299 related DSS1 information elements or QSIG information elements or 300 ISUP parameters. 302 REQ-7: The mechanism will allow a UAC to learn that a UAS understands 303 the UUI mechanism. 305 REQ-8: The mechanism will allow a UAC to require that a UAS 306 understands the call control UUI mechanism have a request routed 307 based on this information. If the UAS does not understand the 308 mechanism, the request will fail. 310 This could be useful in ensuring that a request destined for the 311 PSTN is routed to a gateway that supports the UUI mechanism rather 312 than an otherwise equivalent PSTN gateway that does not support 313 the ISDN mechanism. Note that support of the UUI mechanism does 314 not, by itself, imply that a particular application is supported - 315 see REQ-10. 317 REQ-9: The mechanism will allow proxies to remove a particular 318 application usage of UUI information from a request or response. 320 This is a common security function provided by border elements to 321 header fields such as Alert-Info or Call-Info URIs. 323 REQ-10: The mechanism will provide the ability for a UA to discover 324 which application usages of UUI another UA understands or supports. 326 The creation of a registry of application usages for the SIP UUI 327 mechanism is implied by this requirement. The ISDN Service 328 utilizes a field known as the protocol discriminator, which is the 329 first octet of the ISDN UUI information, for this purpose. 331 REQ-11: The solution will provide a mechanism of transporting at 332 least 128 octets of user data and a one octet protocol discriminator, 333 i.e. 129 octets in total. 335 There is the potential for non-ISDN services to allow UUI to be 336 larger than 128 octets. However, users of the mechanism will need 337 be cognizant of the size of SIP messages and the ability of 338 parsers to handle extremely large values. 340 REQ-12: The recipient of UUI will be able to determine the entity 341 that inserted the UUI. It is acceptable that this is performed 342 implicitly where it is known that there is only one other end UA 343 involved in the dialog. Where that does not exist, some other 344 mechanism will need to be provided. 346 This requirement comes into play during redirection, retargeting, 347 and referral scenarios. 349 4. Security Considerations 351 The security requirements for the SIP UUI mechanism are described in 352 this section. It is important to note that UUI security is jointly 353 provided at the application layer and at the SIP layer. As such, is 354 important for application users of SIP UUI to know the realistic 355 level of security used and deployed in SIP, and not assume that some 356 rarely deployed SIP level security mechanism is in place. 358 There are two main security models that need to be addressed by the 359 SIP UUI mechanism. One model treats the SIP layer as untrusted and 360 requires end-to-end integrity protection and/or encryption. This 361 model can be achieved by providing these security services at a layer 362 above SIP. In this case, the application integrity protects and/or 363 encrypts the UUI information before passing it to the SIP layer. 364 This method has two advantages: it does not assume or rely on end-to- 365 end security mechanisms in SIP which have virtually no deployment, 366 and allows the application which understands the contents of the UUI 367 to apply a proper level of security. The other approach is for the 368 application to pass the UUI without any protection to the SIP layer 369 and require the SIP layer to provide this security. This approach is 370 possible in theory, although its practical use would be extremely 371 limited. The SIP UUI mechanisim should support both of these 372 approaches. 374 The other model utilizes a trust domain and relies on perimeter 375 security at the SIP layer. This is the security model of the PSTN 376 and ISDN where UUI is commonly used today. This approach uses hop- 377 by-hop security mechanisms and relies on border elements for 378 filtering and application of policy. This approach is used today in 379 SIP UUI deployments. However, there is no requirement that an 380 intermediary element be able to read or interpret the UUI, as UUI 381 only has end-to-end significance. An intermediary element may remove 382 a UUI element based on policy, however. This SIP UUI mechanism needs 383 to support this model. 385 The next three requirements capture the SIP UUI security 386 requirements. 388 REQ-13: The mechanism will allow integrity protection of the UUI. 390 This allows the UAS to be able to know that the UUI has not been 391 modified or tampered with by intermediaries. This property is not 392 guaranteed by the protocol in the ISDN application. 394 REQ-14: The mechanism will allow end-to-end privacy of the UUI. 396 Some UUI may contain private or sensitive information and may 397 require different security handling from the rest of the SIP 398 message. Note that this property is not available in the ISDN 399 application. 401 REQ-15: The mechanism will allow both end-to-end and hop-by-hop 402 security models. 404 The hop-by-hop model is required by the ISDN UUI service. 406 5. Acknowledgements 408 Thanks to Joanne McMillen who was a co-author of earlier versions of 409 this specification. Thanks to Spencer Dawkins, Keith Drage, Dale 410 Worley, and Vijay Gurbani for their review of earlier versions of 411 this document. The authors wish to thank Christer Holmberg, 412 Frederique Forestie, Francois Audet, Denis Alexeitsev, Paul Kyzivat, 413 Cullen Jennings, and Mahalingam Mani for their comments on this 414 topic. 416 6. Informative References 418 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 419 A., Peterson, J., Sparks, R., Handley, M., and E. 420 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 421 June 2002. 423 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 424 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 426 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 427 formats and codes", 428 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 430 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 431 Digital Network (ISDN)-Explicit Call Transfer 432 Supplementary Service". 434 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 435 Digital Network (ISDN); Diversion supplementary services". 437 [QSIG] "ECMA-143 "Private Integrated Services Network (PISN) - 438 Circuit Mode Bearer Services - Inter-Exchange Signalling 439 Procedures and Protocol" December 2001". 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 445 October 2000. 447 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 448 for Telephones (SIP-T): Context and Architectures", 449 BCP 63, RFC 3372, September 2002. 451 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 452 Method", RFC 3515, April 2003. 454 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 455 Identity", RFC 3324, November 2002. 457 Authors' Addresses 459 Alan Johnston 460 Avaya 461 St. Louis, MO 63124 463 Email: alan.b.johnston@gmail.com 465 Laura Liess 466 Deutsche Telekom AG 468 Email: laura.liess.dt@gmail.com