idnits 2.17.1 draft-ietf-cuss-sip-uui-reqs-00.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 (November 9, 2010) is 4916 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3261' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC3372' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC2976' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC3324' is defined on line 426, 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 (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CUSS WG A. Johnston, Ed. 3 Internet-Draft Avaya 4 Intended status: Informational J. McMillen 5 Expires: May 13, 2011 Unaffiliated 6 L. Liess 7 Deutsche Telekom AG 8 November 9, 2010 10 Problem Statement and Requirements for Transporting User to User Call 11 Control Information in SIP 12 draft-ietf-cuss-sip-uui-reqs-00 14 Abstract 16 This document introduces the transport of call control related User 17 to User Information (UUI) in the Session Initiation Protocol (SIP), 18 and develops several requirements for a new SIP mechanism. Some SIP 19 sessions are established by or related to a non-SIP application. 20 This application may have information that needs to be transported 21 between the SIP User Agents during session establishment. A common 22 example in another protocol is the ISDN User to User Information 23 Service. As networks move to SIP it is important that applications 24 requiring this data can continue to function in SIP networks as well 25 as the ability to interwork with this ISDN service for end-to-end 26 transparency. This document discusses requirements and approaches. 27 This extension will also be used for native SIP endpoints 28 implementing similar services and interworking with ISDN services. 29 Example use cases include an exchange between two user agents, 30 retargeting by a proxy, and redirection. An example application is 31 an Automatic Call Distributor (ACD) in a contact center. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 4 71 3.2. Proxy Retargeting . . . . . . . . . . . . . . . . . . . . 4 72 3.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 77 7. Informative References . . . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Overview 82 This document describes the transport of User to User Information 83 (UUI) during session setup. This section will introduce UUI and 84 explain 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, the application needs the UUI to be 92 transported at the time of session establishment. This information 93 is essentially opaque data to SIP - it is unrelated to SIP routing, 94 authentication, or any other SIP function. This application can be 95 considered to be operating at a higher layer on the protocol stack. 96 As a result, SIP should not interpret, understand, or perform any 97 operations on the UUI. Should this not be the case, then the 98 information being transported is not considered UUI, and another SIP 99 mechanism will be needed to transport the information (such as a new 100 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 would not provide any 105 benefits and instead could create cross layer coupling. Secondly, it 106 is neither feasible nor desirable for a SIP User Agent to understand 107 the information but instead the goal is for the User Agent to pass 108 the information as efficiently as possible to an application which 109 does understand the information. 111 An important application is the interworking with User to User 112 Information (UUI) in ISDN, specifically, the transport of 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 In the rest of this document, the requirements are discussed with use 122 cases. Five different use case call flows are then discussed. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in BCP 14, RFC 2119 129 [RFC2119]. 131 3. Use Cases 133 This section discusses four use cases for the transport of call 134 control related user to user information. What is not discussed here 135 is the transport of non-call control UUI which can be done using the 136 SIP INFO method. These use cases will help motivate the requirements 137 for SIP call control UUI. 139 3.1. User Agent to User Agent 141 In this scenario, the originator UA includes UUI in the INVITE sent 142 through a proxy to the terminating UA. The terminator can use the 143 UUI in any way. If it is an ISDN gateway, it could map the UUI into 144 the appropriate DSS1 information element or QSIG information element 145 or ISUP parameter. Alternatively, the using application might render 146 the information to the user, or use it during alerting or as a lookup 147 for a screen pop. In this case, the proxy does not need to 148 understand the UUI mechanism, but normal proxy rules should result in 149 the UUI being forwarded without modification. This call flow is 150 shown in Figure 1. 152 Originator Proxy Terminator 153 | | | 154 | INVITE (UUI) F1 | | 155 |------------------->| INVITE (UUI) F2 | 156 | 100 Trying F3 |------------------->| 157 |<-------------------| 200 OK F4 | 158 | 200 OK F5 |<-------------------| 159 |<-------------------| | 160 | ACK F6 | | 161 |------------------->| ACK F7 | 162 | |------------------->| 164 Figure 1. Call flow with UUI exchanged between Originator and 165 Terminator. 167 3.2. Proxy Retargeting 169 In this scenario, the originator UA includes UUI in the INVITE sent 170 through a proxy to the terminating UA. The proxy retargets the 171 INVITE, sending it to a different termination UA. The UUI 172 information is then received and processed by the terminating UA. 173 This call flow is shown in Figure 2. 175 Originator Proxy Terminator 2 176 | | | 177 | INVITE (UUI) F1 | | 178 |------------------->| INVITE (UUI) F2 | 179 | 100 Trying F3 |------------------->| 180 |<-------------------| 200 OK F4 | 181 | 200 OK F5 |<-------------------| 182 |<-------------------| | 183 | ACK F6 | | 184 |------------------->| ACK F7 | 185 | |------------------->| 187 Figure 2. Call flow with Proxy Retargeting. 189 The UUI in the INVITE needs to be passed unchanged through this proxy 190 retargeting operation. 192 3.3. Redirection 194 In this scenario, UUI is inserted by an application which utilizes a 195 SIP redirect server. The UUI is then included in the INVITE sent by 196 the Originator to the Terminator. In this case, the Originator does 197 not necessarily need to support the UUI mechanism but does need to 198 support the SIP redirection mechanism used to include the UUI 199 information. Two examples of UUI with redirection (transfer and 200 diversion) are defined in [ANSII] and [ETSI]. 202 Note that this case may not precisely map to an equivalent ISDN 203 service use case. This is because there is no one-to-one mapping 204 between elements in a SIP network and elements in an ISDN network. 205 Also, there is not an exact one-to-one mapping between SIP call 206 control and ISDN call control. 208 In redirection scenarios, if the Redirect Server is not in the same 209 administrative domain as the Terminator, the Redirect Server must not 210 remove or replace any UUI in the initial INVITE. In Figure 3, this 211 means that if F1 included UUI, the Redirect Server could not modify 212 or replace the UUI in F2. However, if the Redirect Server and the 213 Terminator are part of the same administrative domain, they may have 214 a policy allowing the Redirect Server to modify or rewrite UUI 215 information. In fact, many UUI uses within an Enterprise rely on 216 this feature to work today in ISDN. 218 Originator Redirect Server Terminator 219 | | | 220 | INVITE F1 | | 221 |------------------->| | 222 | 302 Moved (UUI) F2 | | 223 |<-------------------| | 224 | ACK F3 | | 225 |------------------->| | 226 | INVITE (UUI) F4 | | 227 |---------------------------------------->| 228 | 200 OK F5 | 229 |<----------------------------------------| 230 | ACK F6 | 231 |---------------------------------------->| 233 Figure 3. Call flow with UUI exchanged between Redirect Server and 234 Terminator 236 A common application of this call flow is an Automatic Call 237 Distributer (ACD) in a PSTN contact center. The originator would be 238 a PSTN gateway. The ACD would act as a Redirect Server, inserting 239 UUI based on called number, calling number, time of day, and other 240 information. The resulting UUI would be passed to the agent's 241 handset which acts as the Terminator. The UUI could be used to 242 lookup information rendered to the agent at the time of call 243 answering. 245 This redirection scenario, and the referral scenario in the next 246 section are the most important scenarios for contact center 247 applications. Incoming calls to a contact center almost always are 248 redirected or referred to a final destination, sometimes multiple 249 times, based on collected information and business logic. The 250 ability to maintain UUI in these scenarios is critical. 252 3.4. Referral 254 In this scenario, application uses a UA initiate a referral, which 255 causes an INVITE to be generated between the Originator and 256 Terminator with UUI information inserted by the Referrer UA. Note 257 that this REFER [RFC3515] could be part of a transfer operation or it 258 might be unrelated to an existing call, such as out-of-dialog REFER 259 call control. In some cases, this call flow is used in place of the 260 redirection call flow, but where immediately upon answer, the REFER 261 is sent. This scenario is shown in Figure 4. 263 Originator Referrer Terminator 264 | | | 265 | REFER (UUI) F1 | | 266 |<-------------------| | 267 | 202 Accepted F2 | | 268 |------------------->| | 269 | NOTIFY (100 Trying) F3 | 270 |------------------->| | 271 | 200 OK F4 | | 272 |<-------------------| | 273 | INVITE (UUI) F5 | | 274 |---------------------------------------->| 275 | 200 OK F6 | 276 |<----------------------------------------| 277 | ACK F7 | 278 |---------------------------------------->| 279 | NOTIFY (200 OK) F8 | | 280 |------------------->| | 281 | 200 OK F9 | | 282 |<-------------------| | 284 Figure 4. Call flow with transfer after answer. 286 4. Requirements 288 This section discusses the requirements for the transport of call 289 control related user to user information (UUI). We define call 290 control UUI as information that is generated, transported, and 291 consumed at the time of call setup (i.e. during a pending INVITE 292 transaction). The information can be used for call routing, 293 alerting, call distribution, or simply rendering. The exact usage 294 and semantics of call control UUI is out of scope - SIP is simply 295 providing the transport function for this, in the same manner as the 296 ISDN service provides in the PSTN. Non-call control UUI can be sent 297 using the INFO method, and is outside the scope of this work. 299 REQ-1: The mechanism will allow user agents (UAs) to insert and 300 receive UUI data in SIP call setup requests and responses. 302 SIP messages covered by this include INVITE requests and end-to- 303 end responses to the INVITE, which includes 18x and 200 responses. 305 REQ-2: The mechanism will allow UAs to insert and receive UUI data in 306 SIP dialog terminating requests and responses. 308 Q.931 UUI supports inclusion in release and release completion 309 messages. SIP messages covered by this include BYE and 200 OK 310 responses to a BYE. 312 REQ-3: The mechanism will allow UUI to be inserted and retrieved in 313 SIP redirects to INVITEs. 315 SIP messages covered by this include 3xx responses to INVITE and 316 REFER requests. 318 REQ-4: The mechanism will allow UUI to be able to survive proxy 319 retargeting or any other form of redirection of the request. 321 Retargeting is a common method of call routing in SIP, and must 322 not result in the loss of user to user information. 324 REQ-5: The mechanism should not require processing entities to 325 dereference a URL to retrieve the UUI information. 327 Passing a pointer or link to the UUI information will not meet the 328 real-time processing considerations and will complicate 329 interworking with the PSTN. 331 REQ-6: The mechanism will minimize reliance on SIP extensions or 332 uncommon SIP behavior. 334 OPEN ISSUE: Does this requirement need to be reworked, or does it 335 not provide any useful value? 337 REQ-7: The mechanism will support interworking with call control 338 related DSS1 information elements or QSIG information elements or 339 ISUP parameters. 341 REQ-8: The mechanism will allow the inserter of UUI to be sure that 342 the UAS understands the call control UUI mechanism. 344 This could be useful in ensuring that a request destined for the 345 PSTN is routed to a gateway that supports the ISDN UUI service. 346 This mechanism is related to REQ-10. 348 REQ-9: The mechanism will allow proxies to remove a particular type 349 of UUI information from a request or response. 351 This is a common security function provided by border elements to 352 header fields such as Alert-Info or Call-Info URIs. 354 REQ-10: The mechanism will provide the ability for a UA to discover 355 which types or application usages of UUI another UA understands or 356 supports. 358 OPEN ISSUE: For the ISDN Service, is there value in extending this 359 down the protocol discriminator, which is the first octet of the 360 ISDN UUI information? 362 REQ-11: The solution MUST provide a mechanism of transporting at 363 least 128 octets of user data and a one octet protocol discriminator, 364 i.e. 129 octets in total. 366 REQ-12: The recipient of UUI MUST be able to determine the entity 367 that inserted the UUI. It is acceptable that this is performed 368 implicitly where it is known that there is only one other end UA 369 involved in the dialog. Where that does not exist, some other 370 mechanism will need to be provided. 372 5. Security Considerations 374 UUI information can contain sensitive information. UUI transported 375 over SIP may need integrity protection, confidentiality, and the 376 ability to determine the identity of the source of the UUI. 378 Since the security requirements and key management of the UUI 379 information are likely to be quite different from the SIP signaling 380 transport, applications using this mechanism to transport information 381 requiring confidentiality will likely perform their own encryption at 382 the application layer before being passed to SIP for transport. 384 6. Acknowledgements 386 Thanks to Spencer Dawkins, Keith Drage, and Vijay Gurbani for their 387 review of earlier versions of this document. The authors wish to 388 thank Christer Holmberg, Frederique Forestie, Francois Audet, Denis 389 Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for 390 their comments on this topic. 392 7. Informative References 394 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 395 A., Peterson, J., Sparks, R., Handley, M., and E. 396 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 397 June 2002. 399 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 400 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 402 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 403 formats and codes", 404 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 406 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 407 Digital Network (ISDN)-Explicit Call Transfer 408 Supplementary Service". 410 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 411 Digital Network (ISDN); Diversion supplementary services". 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 417 for Telephones (SIP-T): Context and Architectures", 418 BCP 63, RFC 3372, September 2002. 420 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 421 October 2000. 423 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 424 Method", RFC 3515, April 2003. 426 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 427 Identity", RFC 3324, November 2002. 429 Authors' Addresses 431 Alan Johnston (editor) 432 Avaya 433 St. Louis, MO 63124 435 Email: alan.b.johnston@gmail.com 437 Joanne McMillen 438 Unaffiliated 440 Email: c.joanne.mcmillen@gmail.com 442 Laura Liess 443 Deutsche Telekom AG 445 Email: laura.liess.dt@gmail.com