idnits 2.17.1 draft-ietf-cuss-sip-uui-reqs-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 14, 2010) is 4882 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3261' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC2976' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC3372' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC3324' is defined on line 465, 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 J. McMillen 5 Expires: June 17, 2011 Unaffiliated 6 L. Liess 7 Deutsche Telekom AG 8 December 14, 2010 10 Problem Statement and Requirements for Transporting User to User Call 11 Control Information in SIP 12 draft-ietf-cuss-sip-uui-reqs-01 14 Abstract 16 This document introduces the transport of call control related User 17 to User Information (UUI) using the Session Initiation Protocol 18 (SIP), and develops several requirements for a new SIP mechanism. 19 Some SIP sessions are established by or related to a non-SIP 20 application. This application may have information that needs to be 21 transported between the SIP User Agents during session establishment. 22 A common example in another protocol is the ISDN User to User 23 Information Service. As networks move to SIP it is important that 24 applications requiring this data can continue to function in SIP 25 networks as well as the ability to interwork with this ISDN service 26 for end-to-end transparency. This document discusses requirements 27 and approaches to achieve this. In addition, the extension will also 28 be used for native SIP endpoints implementing similar services and 29 interworking with ISDN services. Example use cases include an 30 exchange between two user agents, retargeting by a proxy, and 31 redirection. An example application is an Automatic Call Distributor 32 (ACD) in a contact center. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 17, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 5 71 3.2. Proxy Retargeting . . . . . . . . . . . . . . . . . . . . 6 72 3.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Overview 82 This document describes the transport of User to User Information 83 (UUI) during session setup. This section introduces UUI and explain 84 how it relates to SIP. 86 We define SIP UUI information as application-specific information 87 that is related to a session being established using SIP. It is 88 assumed that the application is running in both the originator of the 89 session and the terminator of the session. That is, the application 90 interacts with the User Agent Client (UAC) and User Agent Server 91 (UAS). In order to function properly, the application needs a small 92 piece of information, the UUI, to be transported at the time of 93 session establishment. This information is essentially opaque data 94 to SIP - it is unrelated to SIP routing, authentication, or any other 95 SIP function. This application can be considered to be operating at 96 a higher layer on the protocol stack. As a result, SIP should not 97 interpret, understand, or perform any operations on the UUI. Should 98 this not be the case, then the information being transported is not 99 considered UUI, and another SIP-specific mechanism will be needed to 100 transport the information (such as a new header field). 102 UUI is defined this way for two reasons. Firstly, this supports a 103 strict layering of protocols and data. Providing information and 104 understanding of the UUI to the transport layer (SIP in this case) 105 would not provide any benefits and instead could create cross layer 106 coupling. Secondly, it is neither feasible nor desirable for a SIP 107 User Agent (UA) to understand the information; instead the goal is 108 for the UA to simply pass the information as efficiently as possible 109 to the application which does understand the information. 111 An important application is the interworking with User to User 112 Information (UUI) in ISDN, specifically, the transport of the call 113 control related ITU-T Q.931 User to User Information Element (UU IE) 114 [Q931] and ITU-T Q.763 User to User Information Parameter [Q763] data 115 in SIP. ISDN UUI is widely used in the PSTN today in contact centers 116 and call centers. These applications are currently transitioning 117 away from using ISDN for session establishment to using SIP. Native 118 SIP endpoints will need to implement a similar service and be able to 119 interwork with this ISDN service. 121 Note that the distinction between call control UUI and non-call 122 control UUI is very important. SIP already has a mechanism for 123 sending arbitrary UUI information between UAs during a session or 124 dialog - the SIP INFO method. Call control UUI, in contrast, must be 125 exchanged at the time of setup and needs to be carried in the INVITE 126 and a few other methods and responses. Applications that exchange 127 UUI but do not have a requirement that it be transported and 128 processed during call setup can simply use SIP INFO and do not need a 129 new SIP extensions. 131 In this document, four different use case call flows are discussed. 132 Next, the requirements for call control UUI transport are discussed. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in BCP 14, RFC 2119 139 [RFC2119]. 141 3. Use Cases 143 This section discusses four use cases for the transport of call 144 control related user to user information. What is not discussed here 145 is the transport of non-call control UUI which can be done using the 146 SIP INFO method. These use cases will help motivate the requirements 147 for SIP call control UUI. 149 3.1. User Agent to User Agent 151 In this scenario, the originator UA includes UUI in the INVITE sent 152 through a proxy to the terminating UA. The terminator can use the 153 UUI in any way. If it is an ISDN gateway, it could map the UUI into 154 the appropriate DSS1 information element or QSIG information element 155 or ISUP parameter. Alternatively, the using application might render 156 the information to the user, or use it during alerting or as a lookup 157 for a screen pop. In this case, the proxy does not need to 158 understand the UUI mechanism, but normal proxy rules should result in 159 the UUI being forwarded without modification. This call flow is 160 shown in Figure 1. 162 Originator Proxy Terminator 163 | | | 164 | INVITE (UUI) F1 | | 165 |------------------->| INVITE (UUI) F2 | 166 | 100 Trying F3 |------------------->| 167 |<-------------------| 200 OK F4 | 168 | 200 OK F5 |<-------------------| 169 |<-------------------| | 170 | ACK F6 | | 171 |------------------->| ACK F7 | 172 | |------------------->| 174 Figure 1. Call flow with UUI exchanged between Originator and 175 Terminator. 177 3.2. Proxy Retargeting 179 In this scenario, the originator UA includes UUI in the INVITE sent 180 through a proxy to the terminating UA. The proxy retargets the 181 INVITE, sending it to a different termination UA. The UUI 182 information is then received and processed by the terminating UA. 183 This call flow is shown in Figure 2. 185 Originator Proxy Terminator 2 186 | | | 187 | INVITE (UUI) F1 | | 188 |------------------->| INVITE (UUI) F2 | 189 | 100 Trying F3 |------------------->| 190 |<-------------------| 200 OK F4 | 191 | 200 OK F5 |<-------------------| 192 |<-------------------| | 193 | ACK F6 | | 194 |------------------->| ACK F7 | 195 | |------------------->| 197 Figure 2. Call flow with Proxy Retargeting. 199 The UUI in the INVITE needs to be passed unchanged through this proxy 200 retargeting operation. 202 3.3. Redirection 204 In this scenario, UUI is inserted by an application which utilizes a 205 SIP redirect server. The UUI is then included in the INVITE sent by 206 the Originator to the Terminator. In this case, the Originator does 207 not necessarily need to support the UUI mechanism but does need to 208 support the SIP redirection mechanism used to include the UUI 209 information. Two examples of UUI with redirection (transfer and 210 diversion) are defined in [ANSII] and [ETSI]. 212 Note that this case may not precisely map to an equivalent ISDN 213 service use case. This is because there is no one-to-one mapping 214 between elements in a SIP network and elements in an ISDN network. 215 Also, there is not an exact one-to-one mapping between SIP call 216 control and ISDN call control. However, this should not prevent the 217 usage of SIP call control UUI in these cases. Instead, these slight 218 differences between the SIP UUI service and the ISDN service need to 219 be carefully noted and discussed in an interworking specification. 221 Figure 3 shows this scenario, with the Redirect inserting UUI which 222 is then included in the INVITE F4 send to the Terminator. 224 Originator Redirect Server Terminator 225 | | | 226 | INVITE F1 | | 227 |------------------->| | 228 | 302 Moved (UUI) F2 | | 229 |<-------------------| | 230 | ACK F3 | | 231 |------------------->| | 232 | INVITE (UUI) F4 | | 233 |---------------------------------------->| 234 | 200 OK F5 | 235 |<----------------------------------------| 236 | ACK F6 | 237 |---------------------------------------->| 239 Figure 3. Call flow with UUI exchanged between Redirect Server and 240 Terminator. 242 If the Redirect Server is not in the same administrative domain as 243 the Terminator, the Redirect Server must not remove or replace any 244 UUI in the initial INVITE. In Figure 3, this means that if F1 245 included UUI, the Redirect Server could not modify or replace the UUI 246 in F2. However, if the Redirect Server and the Terminator are part 247 of the same administrative domain, they may have a policy allowing 248 the Redirect Server to modify or rewrite UUI information. In fact, 249 many UUI uses within an Enterprise rely on this feature to work today 250 in ISDN. 252 A common example application of this call flow is an Automatic Call 253 Distributer (ACD) in a PSTN contact center. The originator would be 254 a PSTN gateway. The ACD would act as a Redirect Server, inserting 255 UUI based on called number, calling number, time of day, and other 256 information. The resulting UUI would be passed to the agent's 257 handset which acts as the Terminator. The UUI could be used to 258 lookup information rendered to the agent at the time of call 259 answering. 261 This redirection scenario, and the referral scenario in the next 262 section, are the most important scenarios for contact center 263 applications. Incoming calls to a contact center almost always are 264 redirected or referred to a final destination, sometimes multiple 265 times, based on collected information and business logic. The 266 ability to maintain UUI in these scenarios is critical. 268 3.4. Referral 270 In this scenario, application uses a UA to initiate a referral, which 271 causes an INVITE to be generated between the Originator and 272 Terminator with UUI information inserted by the Referrer UA. Note 273 that this REFER [RFC3515] could be part of a transfer operation or it 274 might be unrelated to an existing call, such as out-of-dialog REFER 275 call control. In some cases, this call flow is used in place of the 276 redirection call flow, but where immediately upon answer, the REFER 277 is sent. This scenario is shown in Figure 4. 279 Originator Referrer Terminator 280 | | | 281 | REFER (UUI) F1 | | 282 |<-------------------| | 283 | 202 Accepted F2 | | 284 |------------------->| | 285 | NOTIFY (100 Trying) F3 | 286 |------------------->| | 287 | 200 OK F4 | | 288 |<-------------------| | 289 | INVITE (UUI) F5 | | 290 |---------------------------------------->| 291 | 200 OK F6 | 292 |<----------------------------------------| 293 | ACK F7 | 294 |---------------------------------------->| 295 | NOTIFY (200 OK) F8 | | 296 |------------------->| | 297 | 200 OK F9 | | 298 |<-------------------| | 300 Figure 4. Call flow with Referral and UUI. 302 4. Requirements 304 This section discusses the requirements for the transport of call 305 control related user to user information (UUI). 307 REQ-1: The mechanism will allow UAs to insert and receive UUI data in 308 SIP call setup requests and responses. 310 SIP messages covered by this include INVITE requests and end-to- 311 end responses to the INVITE, which includes 18x and 200 responses. 313 REQ-2: The mechanism will allow UAs to insert and receive UUI data in 314 SIP dialog terminating requests and responses. 316 Q.931 UUI supports inclusion in release and release completion 317 messages. SIP messages covered by this include BYE and 200 OK 318 responses to a BYE. 320 REQ-3: The mechanism will allow UUI to be inserted and retrieved in 321 SIP redirects and referrals. 323 SIP messages covered by this include 3xx responses to INVITE and 324 REFER requests. 326 REQ-4: The mechanism will allow UUI to be able to survive proxy 327 retargeting or any other form of redirection of the request. 329 Retargeting is a common method of call routing in SIP, and must 330 not result in the loss of user to user information. 332 REQ-5: The mechanism should not require processing entities to 333 dereference a URL in order to retrieve the UUI information. 335 Passing a pointer or link to the UUI information will not meet the 336 real-time processing considerations and would complicate 337 interworking with the PSTN. 339 REQ-6 has been deleted. To avoid confusion, the number will not be 340 reused. 342 REQ-7: The mechanism will support interworking with call control 343 related DSS1 information elements or QSIG information elements or 344 ISUP parameters. 346 REQ-8: The mechanism will allow a UAC to learn or request that a UAS 347 understands the call control UUI mechanism. 349 This could be useful in ensuring that a request destined for the 350 PSTN is routed to a gateway that supports the ISDN UUI service 351 rather than an otherwise equivalent PSTN gateway that does not 352 support the ISDN UUI service. Note that support of the UUI 353 mechanism does not, by itself, imply that a particular user 354 application is supported - see REQ-10. 356 REQ-9: The mechanism will allow proxies to remove a particular type 357 of UUI information from a request or response. 359 This is a common security function provided by border elements to 360 header fields such as Alert-Info or Call-Info URIs. 362 REQ-10: The mechanism will provide the ability for a UA to discover 363 which types or application usages of UUI another UA understands or 364 supports. 366 The creation of a registry of application usages for the SIP UUI 367 mechanism is implied by this requirement. For the ISDN Service, 368 there could be value in utilizing the protocol discriminator, 369 which is the first octet of the ISDN UUI information, for this 370 purpose. 372 REQ-11: The solution will provide a mechanism of transporting at 373 least 128 octets of user data and a one octet protocol discriminator, 374 i.e. 129 octets in total. 376 There is the potential for non-ISDN services to allow UUI to be 377 larger than 128 octets. However, users of the mechanism will need 378 be cognizant of the size of SIP messages and the ability of 379 parsers to handle extremely large values. 381 REQ-12: The recipient of UUI will be able to determine the entity 382 that inserted the UUI. It is acceptable that this is performed 383 implicitly where it is known that there is only one other end UA 384 involved in the dialog. Where that does not exist, some other 385 mechanism will need to be provided. 387 This requirement comes into play during redirection, retargeting, 388 and referral scenarios. 390 REQ-13: The mechanism will allow integrity protection of the UUI. 392 This allows the UAS to be able to know that the UUI has not been 393 modified or tampered with by intermediaries. This property is 394 assumed (but not guaranteed by the protocol) in the ISDN 395 application. 397 REQ-14: The mechanism will allow end-to-end privacy of the UUI. 399 Some UUI may contain private or sensitive information and may 400 require different security handling from the rest of the SIP 401 message. Note that this property is not available in the ISDN 402 application. In some cases, this requirement could be met by a 403 SIP privacy mechanism. In other cases, the application may 404 provide this service, encrypting the UUI before passing to the SIP 405 layer and decrypting upon receipt after receiving the UUI from the 406 SIP layer. In no cases should an intermediary element assume that 407 it will be able to read or interpret the UUI, as it only has end- 408 to-end significance. 410 5. Security Considerations 412 The security requirements for the SIP UUI mechanism are described in 413 REQ-13 and REQ-14, providing integrity protection and/or privacy. In 414 addition, there is an identity requirement in REQ-12, which relates 415 to the ability for the UAS to know who inserted the UUI. 417 It is important to note that UUI security is jointly provided at the 418 application layer and at the SIP layer. As such, is important for 419 application users of SIP UUI to know the realistic level of security 420 used and deployed in SIP, and not assume that some rarely deployed 421 SIP level security mechanism is in place. 423 6. Acknowledgements 425 Thanks to Spencer Dawkins, Keith Drage, and Vijay Gurbani for their 426 review of earlier versions of this document. The authors wish to 427 thank Christer Holmberg, Frederique Forestie, Francois Audet, Denis 428 Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for 429 their comments on this topic. 431 7. Informative References 433 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 434 A., Peterson, J., Sparks, R., Handley, M., and E. 435 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 436 June 2002. 438 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 439 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 441 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 442 formats and codes", 443 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 445 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 446 Digital Network (ISDN)-Explicit Call Transfer 447 Supplementary Service". 449 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 450 Digital Network (ISDN); Diversion supplementary services". 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 456 October 2000. 458 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 459 for Telephones (SIP-T): Context and Architectures", 460 BCP 63, RFC 3372, September 2002. 462 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 463 Method", RFC 3515, April 2003. 465 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 466 Identity", RFC 3324, November 2002. 468 Authors' Addresses 470 Alan Johnston 471 Avaya 472 St. Louis, MO 63124 474 Email: alan.b.johnston@gmail.com 476 Joanne McMillen 477 Unaffiliated 479 Email: c.joanne.mcmillen@gmail.com 481 Laura Liess 482 Deutsche Telekom AG 484 Email: laura.liess.dt@gmail.com