idnits 2.17.1 draft-ietf-sipping-req-history-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2002) is 7924 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mary Barnes,Editor 3 Document: draft-ietf-sipping-req-history-00.txt Mark Watson 4 Nortel Networks 5 Cullen Jennings 6 Cisco 7 Jon Peterson 8 Category: Informational NeuStar 9 Expires February 2003 August 2002 11 SIP Generic Request History Capability � Requirements 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Many services that SIP is anticipated to support require the ability 35 to determine why and how the call arrived at a specific application. 36 Examples of such services include (but are not limited to) sessions 37 initiated to call centers via "click to talk" SIP URLs on a web page, 38 "call history/logging" style services within intelligent "call 39 management" software for SIP UAs and calls to voicemail servers and 40 call centers. While SIP implicitly provides the redirect/retarget 41 capabilities that enable calls to be routed to chosen applications, 42 there is currently no standard mechanism within SIP for communicating 43 the history of such a request. This "request history" information 44 allows the receiving application to determine hints about how and why 45 the call arrived at the application/user. 47 This draft discusses the motivations in support of a mechanism for 48 recording the "request history", and proposes detailed requirements 49 for such a generic "request history" capability. 51 SIP Generic Request History Capability - Requirements August 2002 53 Table of Contents 55 1. Introduction: Why define a Generic "Request History" capability? 56 2 57 2. Conventions used in this document..............................3 58 3. "Request History" Requirements.................................3 59 4. Security Considerations........................................5 60 5. IANA Considerations............................................6 61 7. Contributors...................................................6 62 8. Acknowledgments................................................6 63 9. Appendix A - Scenarios.........................................8 64 9.1. Sequentially forking with Retargetting................8 65 9.2. Voicemail............................................10 67 1. Introduction: Why define a Generic "Request History" capability? 69 SIP implicitly provides redirect/retarget capabilities that enable 70 calls to be routed to specific applications as defined in [1]. The 71 term retarget will be used henceforth in this draft to refer to the 72 process of a Proxy Server/UAC changing a URI in a request and thus 73 changing the target of the request. This term is chosen to avoid 74 associating this request history only with the specific SIP 75 Redirect Server capability that provides for a response to be sent 76 back to a UAC requesting that the UAC should retarget the original 77 request to an alternate URI. The rules for determining request 78 targets as described in section 16.5 of [1] are believed to be 79 consistent with the use of the retarget term in this draft. 81 The motivation for the request history is that in the process of 82 retargeting old routing information can be forever lost. This lost 83 information may be important history that allows elements to which 84 the call is retargeted to process the call in a locally defined, 85 application specific manner. The proposal in this draft is to 86 provide a mechanism for transporting the request history. It is 87 not proposing any behavior for a Proxy or UA upon receipt of the 88 information. Indeed, such behavior should be a local decision for 89 the recipient application. 91 Current network applications provide the ability for elements 92 involved with the call to exchange additional information relating 93 to how and why the call was routed to a particular destination. 94 The following are examples of such applications: 95 1. Web "referral" applications, whereby an application residing 96 within a web server determines that a visitor to a website has 97 arrived at the site via an "associate" site which will receive 98 some "referral" commission for generating this traffic, 99 SIP Generic Request History Capability - Requirements August 2002 101 2. Email forwarding whereby the forwarded-to user obtains a 102 "history" of who sent the email to whom and at what time 104 3. Traditional telephony based call redirection services such as 105 Voicemail, call-center "automatic call distribution", and 106 "follow-me" style services. 108 Several of the aforementioned applications, and specifically those 109 applications based on email or WWW, define application specific 110 mechanisms through which it is possible to obtain the necessary 111 history information. 113 In order to prevent differing proprietary mechanisms emerging to 114 obtain the required "request history" information, it is proposed 115 that the SIPPING WG evaluate the requirements and determine a 116 generic mechanism for the transport of such "request history" 117 information. 119 2. Conventions used in this document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 123 this document are to be interpreted as described in RFC-2119. 125 3. "Request History" Requirements 127 The following list constitutes a set of requirements for a "Request 128 History" capability. It is anticipated that some of these 129 requirements can be met using existing elements within SIP; whether 130 and what SIP extensions would be needed to meet these requirements 131 is out of scope of this draft. 133 1) CAPABILITY-req: The "Request History" capability will provide a 134 capability to inform proxies and UAs involved in processing a 135 request about the history/progress of that request. While this is 136 inherently provided when the retarget is in response to a SIP 137 redirect, it is deemed useful for non-redirect retargeting 138 scenarios, as well. 140 2) OPTIONALITY-req: The "Request History" information is optional. 142 2.1) In many cases, it is anticipated that whether the history is 143 added to the Request would be a local policy decision enforced by 144 the specific application, thus no specific protocol element is 145 needed. 147 2.2) Due to the capability being "optional" from the SIP protocol 148 perspective, the impact to an application of not having the 149 SIP Generic Request History Capability - Requirements August 2002 151 "Request History" must be described. Applicability guidelines to be 152 addressed by applications using this capability must be provided as 153 part of the solution to these requirements. 155 3) GENERATION-req: "Request History" information is generated when 156 the request is retargeted. 158 3.1) In some scenarios, it might be possible for more than one 159 instance of retargeting to occur within the same Proxy. A proxy 160 should also generate Request History information for the 'internal 161 retargeting'. 163 3.2) An entity (UA or proxy) retargeting in response to a redirect 164 or REFER should include any Request History information from the 165 redirect/REFER in the new request. 167 4) ISSUER-req: "Request History" information can be generated by a 168 UA, proxy or redirect server. It can be passed in both requests and 169 responses. 171 5) CONTENT-req: The "Request History" information for each 172 occurrence of retargeting, shall include the following: 174 5.1) The new URI or address to which the request is in the 175 process of being retargeted, 177 5.2) The URI or address from which the request was retargeted, 179 5.3) The reason for the Request-URI modification. The reason for 180 the retargeting is only known to the application performing the 181 retargeting. However, a set of commonly required reasons should 182 be defined, 184 5.4) Chronological ordering of the Request History information. 186 6) REQUEST-VALIDITY-req: Request-History is applicable to requests 187 not sent within an established dialog. (i.e. INVITE, REGISTER, 188 MESSAGE, and OPTIONS). 190 7) BACKWARDS-req: Request-History information may be passed from 191 the generating entity backwards towards the UAC. This is needed to 192 enable services that inform the calling party about the dialog 193 establishment attempts. 195 SIP Generic Request History Capability - Requirements August 2002 197 8) FORWARDS-req: Request-History information may also be included 198 by the generating entity in the request, if it is forwarded 199 onwards. 201 4. Security Considerations 203 The Request History information is being inserted by a network 204 element retargeting a Request, resulting in a slightly different 205 problem than the basic SIP header problem, thus requiring specific 206 consideration. In addition, there may be privacy implications 207 associated with some of the Request History information. 209 The potential security problems introduced include the following: 210 1) A rogue application could insert a bogus Request History entry 211 either by adding an additional entry as a result of retargeting or 212 entering invalid information. 214 2) Loss of privacy associated with forwarding a specific Request 215 URI in the Request History. 217 3) A rogue application could re-arrange the Request History 218 information to change the nature of the end application or to 219 mislead the receiver of the information. 221 Thus, any solution to "Request History" capability must meet the 222 following requirements: 224 1) SEC-req-1: The entity receiving the Request History must be able 225 to determine whether any of the previously added Request History 226 content has been altered. 228 2) SEC-req-2: The ordering of the Request History information must 229 be preserved at each instance of retargeting. 231 3) SEC-req-3: The entity receiving the information conveyed by the 232 Request History must be able to authenticate the source of the 233 information. 235 It is likely that the solutions to several of the requirements are 236 inter-related. For example, with the requirement for Chronological 237 ordering [Requirement 5.4 in section 3], it is likely that the 238 solution to SEC-req-1 would also meet SEC-req-2. 239 It should also be noted that these requirements apply to any entity 240 making use of the Request History information, either by 241 retargeting and capturing the information, or as an application 242 making use of the information in a Request or Response. However, 243 to ensure the overall integrity of this information as it traverses 244 SIP Generic Request History Capability - Requirements August 2002 246 the network, an additional requirement with regards to the security 247 of the transport is introduced: 249 4) SEC-req-4: To ensure the overall integrity of the chain of 250 Request History information, the transport must be secure. 252 In addition, there are general privacy requirements that MUST be 253 met: 254 5) PRIV-req-1: The entity retargeting the Request must ensure that 255 it maintains the privacy (as described in [2]) associated with the 256 original Request URI which is retargeted. 258 6) PRIV-req-2: The entity receiving the Request History must 259 maintain the privacy associated with the information. 261 It is recognized that meeting the privacy requirements can impact 262 the functionality of this solution by overriding the request to 263 generate the information. The applicability guidelines for a 264 solution must clearly address this impact. 266 5. IANA Considerations 268 This document does not have any implications for IANA. 270 6. References 272 [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 273 3261, June, 2002. 275 [2] J. Peterson, "SIP Privacy", draft-ietf-sip-privacy-general- 276 01.txt, June, 2002. 278 7. Contributors 280 Robert Sparks contributed excellent feedback and direction for 281 the Security considerations section of this document. In 282 addition, he highlighted the importance of addressing the 283 optionality aspects of the "Request History" capability. 285 8. Acknowledgments 287 The authors would like to thank Chris Hogg for serving as the 288 editor for the initial (-00) version of this draft. In addition, 289 Sanjoy Sen and Ben Campbell provided useful comments and 290 suggestions related to this draft. 292 SIP Generic Request History Capability - Requirements August 2002 294 Authors� Addresses 296 Mark Watson 297 Nortel Networks (UK) 298 Maidenhead Office Park (Bray House) 299 Westacott Way 300 Maidenhead, 301 Berkshire Tel: +44 (0)1628-434456 302 England Email: mwatson@nortelnetworks.com 304 Mary Barnes 305 Nortel Networks Tel: +1 972-684-5432 306 Richardson, Texas Email: mbarnes@nortelnetworks.com 308 Jon Peterson 309 NeuStar, Inc. 310 1800 Sutter Street, Suite 570 311 Concord, CA 94520 Email: Jon.Peterson@NeuStar.com 313 Cullen Jennings 314 Cisco Systems 315 170 West Tasman Dr Tel: +1 408 527 9132 316 MS: SJC-21/3 Email: fluffy@cisco.com 318 Full Copyright Statement 320 Copyright (C) The Internet Society (2002). All Rights Reserved. 322 This document and translations of it may be copied and furnished to 323 others, and derivative works that comment on or otherwise explain 324 it or assist in its implementation may be prepared, copied, 325 published and distributed, in whole or in part, without restriction 326 of any kind, provided that the above copyright notice and this 327 paragraph are included on all such copies and derivative works. 328 However, this document itself may not be modified in any way, such 329 as by removing the copyright notice or references to the Internet 330 Society or other Internet organizations, except as needed for the 331 purpose of developing Internet standards in which case the 332 procedures for copyrights defined in the Internet Standards process 333 must be followed, or as required to translate it into languages 334 other than English. The limited permissions granted above are 335 perpetual and will not be revoked by the Internet Society or its 336 successors or assigns. This document and the information contained 337 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY 338 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 339 WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 340 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 341 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 342 FOR A PARTICULAR PURPOSE." 343 SIP Generic Request History Capability - Requirements August 2002 345 9. Appendix A - Scenarios 347 This section highlights some scenarios under which the Request 348 History Capability could be applicable. 350 Certainly, various other solutions can be applied in some fashion 351 to each of these scenarios. However, the objective of this draft 352 has been to abstract the requirements from these scenarios towards 353 providing a more robust solution for each and at the same time 354 providing fundamental building block(s) applicable to future 355 applications. 357 9.1. Sequentially forking with Retargeting 359 This scenario is as follows: 361 UA 1 sends a call to proxy 1. Proxy 1 sequentially tries several 362 places (UA2, UA3 and UA4) before retargeting the call to Proxy 2. 363 Proxy 2 unfortunately tries several of the same places (UA3 and 364 UA4), before completing at UA5. 366 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 368 | | | | | | | 369 |--INVITE -->| | | | | | 370 | | | | | | | 371 | |--INVITE -------->| | | | 372 |<--100 -----| | | | | | 373 | |<-302 ------------| | | | 374 | | | | | | | 375 | |-------INVITE ------------>| | | 376 | | | | | | | 377 | |<-------180 ---------------| | | 378 |<---180 ----| | | | | | 379 | . . |-------INVITE------------->| | | 380 | | timeout | | | | 381 | | | | | | | 382 | |------INVITE ---------------------->| | 383 |<--100 -----| | | | | | 384 | |<-302 ------------------------------| | 385 | | | | | | | 386 | |-INVITE->| | | | | 387 | | | | | | | 388 | | |---INVITE ------>| | | 389 SIP Generic Request History Capability - Requirements August 2002 391 | | | | | | | 392 | | |<---180----------| | | 393 |<---180 --------------| | | | | 394 | | | | | | | 395 | . . | |----INVITE------>| | | 396 | | | timeout | | | 397 | | | | | | | 398 | | |------INVITE ------------>| | 399 |<--100 ---------------| | | | | 400 | | |<-302 --------------------| | 401 | | | | | | | 402 | | |------INVITE --------------------->| 403 | | | | | | | 404 | | |<-----200 OK---------------------->| 405 |<--200 OK-------------| | | | | 406 | | | | | | | 407 |--ACK --------------------------------------------------->| 408 | | | | | | | 410 This scenario is provided to show the duplication of messaging when 411 there isn�t sufficient knowledge to optimize a sequential attempt 412 at reaching an end user. With the "Request History" capability, 413 this flow could be optimized as follows: 415 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 417 | | | | | | | 418 |--INVITE -->| | | | | | 419 | | | | | | | 420 | |--INVITE -------->| | | | 421 |<--100 -----| | | | | | 422 | |<-302 ------------| | | | 423 | | | | | | | 424 | |-------INVITE ------------>| | | 425 | | | | | | | 426 | |<-------180 ---------------| | | 427 |<---180 ----| | | | | | 428 | . . |-------INVITE------------->| | | 429 | | timeout | | | | 430 | | | | | | | 431 | |------INVITE ---------------------->| | 432 |<--100 -----| | | | | | 433 | |<-302 ------------------------------| | 434 | | | | | | | 435 | |-INVITE->| | | | | 436 | | | | | | | 437 | | | | | | | 438 | | |------INVITE --------------------->| 439 SIP Generic Request History Capability - Requirements August 2002 441 | | | | | | | 442 | | |<-----200 OK---------------------->| 443 |<--200 OK-------------| | | | | 444 | | | | | | | 445 |--ACK --------------------------------------------------->| 446 | | | | | | | 448 9.2. Voicemail 450 This scenario is as follows: 452 UA 1 called UA A which had been forwarded to UA B which forwarded 453 to a UA VM (voicemail server) which needs information (e.g. 454 reason the call was retargeted, original Request URI) to make a 455 policy decision about what mailbox to use, which greeting to play 456 etc. This scenario shows that something like the "Request 457 History" capability must be used for this service to function. 459 UA1 Proxy UA-A UA-B UA-VM 461 | | | | | 462 |--INVITE ---->| | | | 463 | | | | | 464 | |--INVITE ---->| | | 465 |<--100 -------| | | | 466 | |<-302 --------| | | 467 | | | | | 468 | |--------INVITE ------------>| | 469 | | | | | 470 | |<--------180 ---------------| | 471 |<---180 ------| | | | 472 | . . . |--------INVITE------------->| | 473 | | timeout | | 474 | | | | | 475 | |-------INVITE ------------------------>| 476 | | | | | 477 | |<-200 ---------------------------------| 478 | | | | | 479 |<-200---------| | | | 480 | | | | | 481 |--ACK ----------------------------------------------->| 482 | | | | | 483 | | | | | 484 SIP Generic Request History Capability - Requirements August 2002 486 Certainly, another valid scenario for the support of voicemail would 487 be that this 'policy decision' on which mailbox to use (etc.) is made 488 by the UA which forwarded to voicemail (UA B), or by the Proxy which 489 performed the forwarding on behalf of B. In this case, the UA or Proxy 490 can put all the information that the Voicemail server needs to 491 identity the correct mailbox, etc., into the Request-URI. This fits 492 with the SIP service paradigm where the Request-URI identifies the 493 resource (namely, the particular mailbox/greeting etc.) that is 494 required. 496 However, whilst this model is certainly applicable and required in 497 SIP, it places service intelligence away from the system providing the 498 key aspect of the service (the VM server). 500 The proposal in this draft is to rely on generic information-providing 501 capabilities in the UA/Proxy, allowing the Voicemail system to provide 502 more and better voicemail-related services without relying on specific 503 capabilities in the UA/Proxy. This would allow voicemail service 504 providers to innovate independently of the particular UA/Proxy that 505 their customers are using, and its capabilities. Presently, with the 506 information loss problem, VM service providers, and any other similar 507 service providers, are limited in the services they can provide 508 because they do not have complete information about how the call 509 reached them. They rely on the UA/proxy of their customers having the 510 necessary capabilities to formulate a Request-URI identifying exactly 511 what should happen next. Finally, there is obviously a desire to use 512 existing voicemail platforms based on PSTN/ISDN technology, which 513 operate according to the paradigm in this example.