idnits 2.17.1 draft-johnston-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 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 15, 2010) is 4971 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3261' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC3372' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC2976' is defined on line 457, 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: March 19, 2011 Unaffiliated 6 L. Liess 7 Deutsche Telekom AG 8 September 15, 2010 10 Problem Statement and Requirements for Transporting User to User Call 11 Control Information in SIP 12 draft-johnston-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 ITU-T Q.931 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. This extension will also be used for native SIP 28 endpoints implementing similar services and interworking with ISDN 29 services. Example use cases include an exchange between two user 30 agents, retargeting by a proxy, and redirection. An example 31 application is an Automatic Call Distributor (ACD) in a contact 32 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 March 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 5 71 3.2. Proxy Retargeting . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 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 applicaiton 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 Q.931 or Q.763 element. Alternatively, the using 145 application might render the information to the user, or use it 146 during alerting or as a lookup for a screen pop. In this case, the 147 proxy does not need to understand the UUI mechanism, but normal proxy 148 rules should result in the UUI being forwarded without modification. 149 This call flow is shown in Figure 1. 151 Originator Proxy Terminator 152 | | | 153 | INVITE (UUI) F1 | | 154 |------------------->| INVITE (UUI) F2 | 155 | 100 Trying F3 |------------------->| 156 |<-------------------| 200 OK F4 | 157 | 200 OK F5 |<-------------------| 158 |<-------------------| | 159 | ACK F6 | | 160 |------------------->| ACK F7 | 161 | |------------------->| 163 Figure 1. Call flow with UUI exchanged between Originator and 164 Terminator. 166 3.2. Proxy Retargeting 168 In this scenario, the originator UA includes UUI in the INVITE sent 169 through a proxy to the terminating UA. The proxy retargets the 170 INVITE, sending it to a different termination UA. The UUI 171 information is then received and processed by the terminating UA. 172 This call flow is shown in Figure 2. 174 Originator Proxy Terminator 2 175 | | | 176 | INVITE (UUI) F1 | | 177 |------------------->| INVITE (UUI) F2 | 178 | 100 Trying F3 |------------------->| 179 |<-------------------| 200 OK F4 | 180 | 200 OK F5 |<-------------------| 181 |<-------------------| | 182 | ACK F6 | | 183 |------------------->| ACK F7 | 184 | |------------------->| 186 Figure 2. Call flow with Proxy Retargeting. 188 The UUI in the INVITE needs to be passed unchanged through this proxy 189 retargeting operation. 191 3.3. Redirection 193 In this scenario, UUI is inserted by an application which utilizes a 194 SIP redirect server. The UUI is then included in the INVITE sent by 195 the Originator to the Terminator. In this case, the Originator does 196 not necessarily need to support the UUI mechanism but does need to 197 support the SIP redirection mechanism used to include the UUI 198 information. Two examples of UUI with redirection (transfer and 199 diversion) are defined in [ANSII] and [ETSI]. 201 Note that this case may not precisely map to an equivalent ISDN 202 service use case. This is because there is no one-to-one mapping 203 between elements in a SIP network and elements in an ISDN network. 204 Also, there is not an exact one-to-one mapping between SIP call 205 control and ISDN call control. 207 In redirection scenarios, if the Redirect Server is not in the same 208 administrative domain as the Terminator, the Redirect Server must not 209 remove or replace any UUI in the initial INVITE. In Figure 3, this 210 means that if F1 included UUI, the Redirect Server could not modify 211 or replace the UUI in F2. However, if the Redirect Server and the 212 Terminator are part of the same administrative domain, they may have 213 a policy allowing the Redirect Server to modify or rewrite UUI 214 information. In fact, many UUI uses within an Enterprise rely on 215 this feature to work today in ISDN. 217 Originator Redirect Server Terminator 218 | | | 219 | INVITE F1 | | 220 |------------------->| | 221 | 302 Moved (UUI) F2 | | 222 |<-------------------| | 223 | ACK F3 | | 224 |------------------->| | 225 | INVITE (UUI) F4 | | 226 |---------------------------------------->| 227 | 200 OK F5 | 228 |<----------------------------------------| 229 | ACK F6 | 230 |---------------------------------------->| 232 Figure 3. Call flow with UUI exchanged between Redirect Server and 233 Terminator 235 A common application of this call flow is an Automatic Call 236 Distributer (ACD) in a PSTN contact center. The originator would be 237 a PSTN gateway. The ACD would act as a Redirect Server, inserting 238 UUI based on called number, calling number, time of day, and other 239 information. The resulting UUI would be passed to the agent's 240 handset which acts as the Terminator. The UUI could be used to 241 lookup information rendered to the agent at the time of call 242 answering. 244 This redirection scenario, and the referral scenario in the next 245 section are the most important scenarios for contact center 246 applications. Incoming calls to a contact center almost always are 247 redirected or referred to a final destination, sometimes multiple 248 times, based on collected information and business logic. The 249 ability to maintain UUI in these scenarios is critical. 251 3.4. Referral 253 In this scenario, application uses a UA initiate a referral, which 254 causes an INVITE to be generated between the Originator and 255 Terminator with UUI information inserted by the Referrer UA. Note 256 that this REFER [RFC3515] could be part of a transfer operation or it 257 might be unrelated to an existing call, such as out-of-dialog REFER 258 call control. In some cases, this call flow is used in place of the 259 redirection call flow, but where immediately upon answer, the REFER 260 is sent. This scenario is shown in Figure 4. 262 Originator Referrer Terminator 263 | | | 264 | REFER (UUI) F1 | | 265 |<-------------------| | 266 | 202 Accepted F2 | | 267 |------------------->| | 268 | NOTIFY (100 Trying) F3 | 269 |------------------->| | 270 | 200 OK F4 | | 271 |<-------------------| | 272 | INVITE (UUI) F5 | | 273 |---------------------------------------->| 274 | 200 OK F6 | 275 |<----------------------------------------| 276 | ACK F7 | 277 |---------------------------------------->| 278 | NOTIFY (200 OK) F8 | | 279 |------------------->| | 280 | 200 OK F9 | | 281 |<-------------------| | 283 Figure 4. Call flow with transfer after answer. 285 Some scenarios involving referral have been proposed to use a REFER 286 sent during an early dialog. This NOT RECOMMENDED call flow is shown 287 in Figure 5. This flow is not recommended due to the number of 288 messages exchanged (due to the REFER, CANCEL, and 487 responses) and 289 the sending of the REFER in the early dialog. Also, there are race 290 conditions that can occur if a 200 OK to the INVITE is received by 291 the Originator while the REFER is in progress. 293 Originator Referrer Terminator 294 | | | 295 | INVITE F1 | | 296 |------------------->| | 297 | 180 Ringing F2 | | 298 |<-------------------| | 299 | REFER (UUI) F3 | | 300 |<-------------------| | 301 | 202 Accepted F4 | | 302 |------------------->| | 303 | NOTIFY (100 Trying) F5 | 304 |------------------->| | 305 | 200 OK F6 | | 306 |<-------------------| | 307 | INVITE (UUI) F7 | | 308 |---------------------------------------->| 309 | 200 OK F8 | 310 |<----------------------------------------| 311 | ACK F9 | 312 |---------------------------------------->| 313 | NOTIFY (200 OK) F10| | 314 |------------------->| | 315 | 200 OK F11 | | 316 |<-------------------| | 317 | CANCEL F12 | | 318 |------------------->| | 319 | 200 OK F13 | | 320 |<-------------------| | 321 | 487 Request Terminated F14 | 322 |<-------------------| | 323 | ACK F15 | | 324 |------------------->| | 326 Figure 5. NOT RECOMMENDED call flow showing REFER prior to answer. 328 4. Requirements 330 This section discusses the requirements for the transport of call 331 control related user to user information (UUI). We define call 332 control UUI as information that is generated, transported, and 333 consumed at the time of call setup (i.e. during a pending INVITE 334 transaction). The information can be used for call routing, 335 alerting, call distribution, or simply rendering. The exact usage 336 and semantics of call control UUI is out of scope - SIP is simply 337 providing the transport function for this, in the same manner as the 338 ISDN service provides in the PSTN. Non-call control UUI can be sent 339 using the INFO method, and is outside the scope of this work. 341 REQ-1: The mechanism will allow user agents (UAs) to insert and 342 receive UUI data in SIP call setup requests and responses. 344 SIP messages covered by this include INVITE requests and end-to- 345 end responses to the INVITE, which includes 18x and 200 responses. 347 REQ-2: The mechanism will allow UAs to insert and receive UUI data in 348 SIP call teardown requests and responses. 350 Q.931 UUI supports inclusion in release and release completion 351 messages. SIP messages covered by this include BYE and 200 OK 352 responses to a BYE. 354 REQ-3: The mechanism will allow UUI to be inserted and retrieved in 355 SIP redirects to INVITEs. 357 SIP messages covered by this include 3xx responses to INVITE and 358 REFER requests. 360 REQ-4: The mechanism will allow UUI to be able to survive proxy 361 retargeting. 363 Retargeting is a common method of call routing in SIP, and must 364 not result in the loss of user to user information. 366 REQ-5: The mechanism should not require processing entities to 367 dereference a URL to retrieve the UUI information. 369 Passing a pointer or link to the UUI information will not meet the 370 real-time processing considerations and will complicate 371 interworking with the PSTN. 373 REQ-6: The mechanism will minimize reliance on SIP extensions or 374 uncommon SIP behavior. 376 REQ-7: The mechanism will support interworking with call control 377 related ITU-T Q.931 User to User Information Element (UU IE) [Q931] 378 and ITU-T Q.763 User to User Information Parameter [Q763]. 380 REQ-8: The mechanism will allow the inserter of UUI to be sure that 381 the recipient understands the call control UUI mechanism. 383 Understanding the mechanism means that the UAS will extract and 384 utilize the UUI information transported. Understanding the 385 protocol, format, and nature of the actual UUI data is not covered 386 by this requirement. Note that this requirement is not strictly 387 needed to implement the UUS 1 implicit service, but maps more 388 accurately to the UUS 1 explicit service. However, having an 389 option tag is good design for high reliability systems, and the 390 dynamic and heterogeneous nature of SIP interconnection (as 391 opposed to the PSTN's static trunking) makes this option tag much 392 more important and hence relevant to even the UUS 1 implicit 393 service. 395 REQ-9: The mechanism will allow proxies to remove a particular type 396 of UUI information from a request or response, or to block requests 397 based on the presence of a particular type of UUI. 399 This is a common security function provided by border elements to 400 header fields such as Alert-Info or Call-Info URIs. 402 5. Security Considerations 404 User to user information can be exchanged over SIP on a hop-by-hop or 405 end-to-end basis. In some cases, UUI may carry privacy information 406 that would require confidentiality and message integrity. Standard 407 SIP security mechanisms, viz., based on TLS, offer these properties 408 per-hop. To preserve multi-hop or end-end confidentiality and 409 integrity, an S/MIME profile MUST be utilized. Since the security 410 requirements and key management of the UUI information are likely to 411 be quite different from the SIP signaling transport, another approach 412 would be for the UUI information to be encrypted before being passed 413 to SIP for transport. 415 Received User-to-User information should only be trusted if it is 416 authenticated or if it is received within a trust domain. For 417 example, Spec-T, defined in [RFC3324] could be used to define a trust 418 domain. When utilized by a gateway to map information to or from 419 ISDN Q.931 and ISUP Q.763, appropriate policy should be applied based 420 on the PSTN trust domain. 422 6. Acknowledgements 424 Thanks to Spencer Dawkins, Keith Drage, and Vijay Gurbani for their 425 review of earlier versions of this document. The authors wish to 426 thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen 427 Jennings, and Mahalingam Mani for their comments on this topic. 429 7. Informative References 431 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 432 A., Peterson, J., Sparks, R., Handley, M., and E. 433 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 434 June 2002. 436 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 437 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 439 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 440 formats and codes", 441 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 443 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 444 Digital Network (ISDN)-Explicit Call Transfer 445 Supplementary Service". 447 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 448 Digital Network (ISDN); Diversion supplementary services". 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 454 for Telephones (SIP-T): Context and Architectures", 455 BCP 63, RFC 3372, September 2002. 457 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 458 October 2000. 460 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 461 Method", RFC 3515, April 2003. 463 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 464 Identity", RFC 3324, November 2002. 466 Authors' Addresses 468 Alan Johnston (editor) 469 Avaya 470 St. Louis, MO 63124 472 Email: alan.b.johnston@gmail.com 474 Joanne McMillen 475 Unaffiliated 477 Email: c.joanne.mcmillen@gmail.com 478 Laura Liess 479 Deutsche Telekom AG 481 Email: laura.liess.dt@gmail.com