idnits 2.17.1 draft-watson-sipping-req-history-02.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 4 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. ** There are 2 instances of too long lines in the document, the longest one being 118 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 573 has weird spacing: '...s draft is to...' -- 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 (June 2002) is 7985 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '10' is mentioned on line 320, but not defined == Unused Reference: '8' is defined on line 356, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-levy-sip-diversion-03 -- No information found for draft-schulzrinne-sip-reason- - is the name correct? == Outdated reference: A later version (-05) exists of draft-ietf-sip-referredby-00 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mark Watson 3 Document: draft-watson-sipping-req-history-02.txt Mary Barnes 4 Nortel Networks 5 Cullen Jennings 6 Cisco 7 Jon Peterson 8 Category: Informational NeuStar 9 Expires December 2002 June 2002 11 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 which 48 records the "request history" and proposes detailed requirements for 49 such a generic "request history" capability. 51 Table of Contents 53 1. Introduction: Why define a Generic "Request History" capability?. 54 2 55 2. Conventions used in this document................................3 56 3. "Request History" Requirements...................................3 57 4. Further Requirements Related Considerations......................4 58 5. Security Considerations..........................................5 59 6. Going forward....................................................7 60 7. IANA Considerations..............................................7 61 8. Appendix A - Scenarios...........................................9 63 1. Introduction: Why define a Generic "Request History" capability? 65 SIP implicitly provides redirect/retarget capabilities that enable 66 calls to be routed to specific applications as defined in [1]. The 67 term retarget will be used henceforth in this draft to refer to the 68 process of a Proxy Server/UAC changing a URI in a request and thus 69 changing the target of the request. This term is chosen to avoid 70 associating this request history only with the specific SIP 71 Redirect Server capability that provides for a response to be sent 72 back to a UAC requesting that the UAC should retarget the original 73 request to an alternate URI. The rules for determining request 74 targets as described in section 16.5 of [1] are believed to be 75 consistent with the use of the retarget term in this draft. 77 The motivation for the request history is that in the process of 78 retargeting old routing information can be forever lost. This lost 79 information may be important history that allows elements to which 80 the call is retargeted to process the call in a locally defined, 81 application specific manner. The proposal in this draft is to 82 provide a mechanism for transporting the request history. It is 83 not proposing any behavior for a Proxy or UA upon receipt of the 84 information. Indeed, such behavior should be a local decision for 85 the recipient application. 87 Current network applications provide the ability for elements 88 involved with the call to exchange additional information relating 89 to how and why the call was routed to a particular destination. 90 The following are examples of such applications: 91 1) Web "referral" applications, whereby an application residing 92 within a web server determines that a visitor to a website has 93 arrived at the site via an "associate" site which will receive 94 some "referral" commission for generating this traffic, 96 2) Email forwarding whereby the forwarded-to user obtains a 97 "history" of who sent the email to whom and at what time 98 3) Traditional telephony based call redirection services such as 99 Voicemail, call-center "automatic call distribution", and 100 "follow-me" style services. 102 Several of the aforementioned applications, and specifically those 103 applications based on email or WWW, define application specific 104 mechanisms through which it is possible to obtain the necessary 105 history information. 107 In order to prevent differing proprietary mechanisms emerging to 108 obtain the required "request history" information, it is proposed 109 that the SIPPING WG evaluate the requirements and determine a 110 generic mechanism for the transport of such "request history" 111 information. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 117 this document are to be interpreted as described in RFC-2119. 119 3. "Request History" Requirements 121 The following list constitutes a set of requirements for a "Request 122 History" capability. Note that some of these requirements may be 123 met using existing elements within SIP � whether and what SIP 124 extensions would be needed to meet these requirements is out of 125 scope of this draft. 127 The requirements have been enumerated and tagged to facilitate 128 reference to each requirement: 130 1) CAPABILITY-req: The "Request History" capability will provide a 131 capability to inform proxies and UAs involved in processing a 132 request about the history/progress of that request. While this is 133 inherently provided when the retarget is in response to a SIP 134 redirect, it is deemed useful for non-redirect retargeting 135 scenarios, as well. 137 2) GENERATION-req: "Request History" information is generated when 138 the request is retargetted [see section 4.1 for further discussion 139 of this requirement]. 141 3) ISSUER-req: "Request History" information can be generated by a 142 UA, proxy or redirect server. It can be passed in both requests and 143 responses. 145 4) CONTENT-req: The "Request History" information for each 146 occurrence of retargeting, shall include the following: 148 4.1) The new URI or address to which the request is in the 149 process of being retargeted 151 4.2) The URI or address from which the request was retargeted. 153 4.3) The reason for the Request-URI modification [See section 4.2 154 for further description of this requirement]. 156 4.4) Chronological ordering of the Request History information. 158 5) REQUEST-VALIDITY-req: Request-History is applicable to requests 159 not sent within an established dialog. (i.e. INVITE, REGISTER, 160 MESSAGE, and OPTIONS). 162 6) BACKWARDS-req: Request-History information may be passed from 163 the generating entity backwards towards the UAC. This is needed to 164 enable services which inform the calling party about the dialog 165 establishment attempts. 167 7) FORWARDS-req: Request-History information may also be included 168 by the generating entity in the request, if it is forwarded 169 onwards. 171 8) REDIRECT-RESP-req: An entity (UA or proxy) retargeting in 172 response to a redirect or REFER shall include any Request History 173 information from the redirect/REFER in the new request. 175 4. Further Requirements Related Considerations 177 This section of the document further addresses some concerns that 178 arise out of the Requirements specification in section 3. 180 4.1 Further considerations for capturing retargeting 182 The original request URI of a retargeted request SHOULD identify 183 the user, service or resource, which performed the retargeting, as 184 captured in requirement 4.2 in section 3. In some scenarios, it 185 might be possible for more than one instance of retargeting to 186 occur within the same Proxy. It is recommended that a proxy SHOULD 187 NOT 'internally retarget' a request to a different user, service or 188 resource on the same proxy, without generating Request History 189 information for the 'internal retargeting' as well. It should be 190 highlighted that an underlying requirement is to ensure that any 191 retargeting maintains the privacy associated with the original 192 Request URI. This requirement is addressed, along with additional 193 security specific requirements in Section 5. 195 4.2 Reason for retargeting 197 The reason for the retargeting is only known to the application 198 performing the retargeting. However, it does make sense to define 199 a set of reasons, which will be commonly required. It is proposed 200 that [6] provides a reasonable starting point for the definition 201 for the set of reasons. 203 4.3 Optionality of the "Request History" capability 205 Requirement 2 in section 3 specifies that "Request History" 206 information is generated when the request is retargeted. In many 207 cases, it is anticipated that whether the history is added to the 208 Request would be a local policy decision enforced by the specific 209 application, thus no specific protocol element is needed. However, 210 due to the capability being "optional" from the SIP protocol 211 perspective, the impact to an application of not having the 212 "Request History" must be described. For example, in a scenario 213 where there is sequential forking and retargeting, some of the 214 destinations previously tried could be retried. The impact of not 215 having the "Request History" information for this sample 216 application is that routing is inefficient. However, another 217 scenario involving a voicemail application, the impact of not 218 having the "Request History" information would be the service could 219 not operate without having the information as to why the call was 220 retargeted and the initial target for the call. Thus, the 221 expectation would be that the policy in a system that intended to 222 support this voicemail application would have to require the 223 entities within its domain which are capable of retargeting to 224 capture "Request History" information. Appendix A of this document 225 in section 8 provides further details of these examples. 227 5. Security Considerations 229 The Request History information is being inserted by a network 230 element retargeting a Request, resulting in a slightly different 231 problem than the basic SIP header problem, thus requiring specific 232 consideration. In addition, there may be privacy implications 233 associated with some of the Request History information. 235 The potential security problems introduced include the following: 236 1) A rogue application could insert a bogus Request History entry 237 either by adding an additional entry as a result of retargeting or 238 entering invalid information. 240 2) A rogue application could delete an entry added by a previous 241 retargeting. While this may be a valid scenario for some 242 applications, this may indicate a loss of integrity of the Request 243 History content, which could significantly impact other 244 applications. 246 3) Loss of privacy associated with forwarding a specific Request 247 URI in the Request History. 249 4) A rogue application could re-arrange the Request History 250 information to change the nature of the end application or to 251 mislead the receiver of the information. 253 Thus, any solution to "Request History" capability must meet the 254 following requirements: 256 1) SEC-req-1: The entity receiving the Request History must be able 257 to determine whether any of the previously added Request History 258 content has been altered. 260 2) SEC-req-2: The ordering of the Request History information must 261 be preserved at each instance of retargeting. 263 3) SEC-req-3: The entity receiving the Request History must be able 264 to determine whether a previously added Request History content has 265 been removed. 267 4) SEC-req-4: The entity receiving the information conveyed by the 268 Request History must be able to authenticate the source of the 269 information. 271 It is likely that the solutions to several of the requirements are 272 inter-related. For example, with the requirement for Chronological 273 ordering [Requirement 4.4 in section 3], it is likely that the 274 solution to SEC-req-1 would also meet SEC-req-2. Following on this, 275 if SEC-req-2 is met, then SEC-req-3 could make use of the 276 Chronological ordering to detect if information had been removed. 278 It should also be noted that these requirements apply to any entity 279 making use of the Request History information, either by 280 retargeting and capturing the information, or as an application 281 making use of the information in a Request or Response. However, 282 to ensure the overall integrity of this information as it traverses 283 the network, an additional requirement with regards to the security 284 of the transport is introduced: 286 5) SEC-req-5: To ensure the overall integrity of the chain of 287 Request History information, the transport must be secure. 289 In addition, there are general privacy requirements that MUST be 290 met: 292 6) PRIV-req-1: The entity retargeting the Request must ensure that 293 it maintains the privacy (as described in [7]) associated with the 294 original Request URI which is retargeted. 296 7) PRIV-req-2: The entity receiving the Request History must 297 maintain the privacy associated with the information. 299 It is recognized that meeting the privacy requirements may impact 300 the functionality of this solution. The applicability guidelines 301 for a solution must clearly address this impact. 303 6. Going forward 305 The authors request that the SIPPING WG study this contribution and 306 come to consensus regarding the set of requirements necessary for a 307 Generic Request History mechanism. A next step is proposed to 308 document the analysis of the various mechanisms proposed for this 309 problem domain [2][3][4] and [5] and determine the extent to which 310 these meet the agreed requirements. Such an analysis would thus 311 provide suitable grounds for determining what extensions are 312 necessary to SIP in order to support the agreed requirements. 314 In addition, it is proposed that further analysis of the 315 requirements resulting in a solution would include the following: 317 1) Further analysis of the security requirements and potential 318 solutions. The solution to some of the security requirements 319 appears to be in the same problem domain as the security 320 requirements for the Referredby header [10] and further analysis 321 is required to determine if this is case and whether there is 322 potential for synergy in the security solutions. 324 2) Further scenarios, highlighting in more detail some of the 325 issues that will be encountered due to the optionality of the 326 "Request History" capability. This will enable the solution 327 documentation to provide more explicit guidelines on the 328 applicability of the solution. 330 7. IANA Considerations 332 This document does not have any implications for IANA. 334 References 336 [1] J. Rosenberg et al, "SIP: Session initiation protocol," draft- 337 ietf-sip-rfc2543bis-09.txt, February 27th, 2002. 339 [2] B. Campbell, R. Sparks, "Control of Service Context using SIP 340 Request-URI", RFC 3087, April 2001. 342 [3] S. Levy, B. Byerly, J. Yang, "Diversion Indication in SIP", 343 draft-levy-sip-diversion-03.txt, November, 2001. 345 [4] W. Marshall et al, "SIP Extensions for Caller Identity and th Privacy", draft-ietf-sip-privacy-04.txt, February 27 , 2002. 347 [5] D. Oran, H. Schulzrinne, "SIP extension for tracking locations 348 attempted", oran-sip-visited-00.txt, August 6, 2000. 350 [6] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header Field 351 for the Session Initiation Protocol", draft-schulzrinne-sip-reason- th 01.txt, February, 28 , 2002. 353 [7] J. Peterson, "SIP Privacy", draft-ietf-sip-privacy-general- 354 01.txt, June, 2002. 356 [8] R. Sparks, "The SIP Referredby Header Field", draft-ietf-sip- 357 referredby-00.txt, May, 2002. 359 Contributors 361 Robert Sparks contributed excellent feedback and direction for 362 the Security considerations section of this document. In 363 addition, he highlighted the importance of addressing the 364 optionality aspects of the "Request History" capability. 366 Acknowledgments 368 The authors would like to thank Chris Hogg for serving as the 369 editor for the initial (-00) version of this draft. In addition, 370 Sanjoy Sen provided useful comments and suggestions related to 371 this draft. 373 Authors� Addresses 375 Mark Watson 376 Nortel Networks (UK) 377 Maidenhead Office Park (Bray House) 378 Westacott Way 379 Maidenhead, 380 Berkshire Tel: +44 (0)1628-434456 381 England Email: mwatson@nortelnetworks.com 383 Mary Barnes 384 Nortel Networks Tel: +1 972-684-5432 385 Richardson, Texas Email: mbarnes@nortelnetworks.com 386 Jon Peterson 387 NeuStar, Inc. 388 1800 Sutter Street, Suite 570 389 Concord, CA 94520 Email: Jon.Peterson@NeuStar.com 391 Cullen Jennings 392 Cisco Systems 393 170 West Tasman Dr Tel: +1 408 527 9132 394 MS: SJC-21/3 Email: fluffy@cisco.com 396 Full Copyright Statement 398 Copyright (C) The Internet Society (2002). All Rights Reserved. 400 This document and translations of it may be copied and furnished to 401 others, and derivative works that comment on or otherwise explain 402 it or assist in its implementation may be prepared, copied, 403 published and distributed, in whole or in part, without restriction 404 of any kind, provided that the above copyright notice and this 405 paragraph are included on all such copies and derivative works. 406 However, this document itself may not be modified in any way, such 407 as by removing the copyright notice or references to the Internet 408 Society or other Internet organizations, except as needed for the 409 purpose of developing Internet standards in which case the 410 procedures for copyrights defined in the Internet Standards process 411 must be followed, or as required to translate it into languages 412 other than English. The limited permissions granted above are 413 perpetual and will not be revoked by the Internet Society or its 414 successors or assigns. This document and the information contained 415 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY 416 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 417 WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 418 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 419 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 420 FOR A PARTICULAR PURPOSE." 422 8.Appendix A - Scenarios 424 This section highlights some scenarios under which the Request 425 History Capability could be applicable. 427 Certainly, various other solutions can be applied in some fashion 428 to each of these scenarios, however, the objective of this draft 429 has been to abstract the requirements from these scenarios towards 430 providing a more robust solution for each and at the same time 431 providing fundamental building block(s) applicable to future 432 applications. 434 8.1 Sequentially forking with Retargetting 436 This scenario is as follows: 438 o UA 1 sends a call to proxy 1. Proxy 1 sequentially tries 439 several places (UA2, UA3 and UA4) before retargetting the call 440 to Proxy 2. Proxy 2 unfortunately tries several of the same 441 places (UA3 and UA4), before completing at UA5. 443 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 445 | | | | | | | 446 |--INVITE -->| | | | | | 447 | | | | | | | 448 | |--INVITE -------->| | | | 449 |<--100 -----| | | | | | 450 | |<-302 ------------| | | | 451 | | | | | | | 452 | |-------INVITE ------------>| | | 453 | | | | | | | 454 | |<-------180 ---------------| | | 455 |<---180 ----| | | | | | 456 | . . |-------INVITE------------->| | | 457 | | timeout | | | | 458 | | | | | | | 459 | |------INVITE ---------------------->| | 460 |<--100 -----| | | | | | 461 | |<-302 ------------------------------| | 462 | | | | | | | 463 | |-INVITE->| | | | | 464 | | | | | | | 465 | | |---INVITE ------>| | | 466 | | | | | | | 467 | | |<---180----------| | | 468 |<---180 --------------| | | | | 469 | | | | | | | 470 | . . | |----INVITE------>| | | 471 | | | timeout | | | 472 | | | | | | | 473 | | |------INVITE ------------>| | 474 |<--100 ---------------| | | | | 475 | | |<-302 --------------------| | 476 | | | | | | | 477 | | |------INVITE --------------------->| 478 | | | | | | | 479 | | |<-----200 OK---------------------->| 480 |<--200 OK-------------| | | | | 481 | | | | | | | 482 |--ACK --------------------------------------------------->| 483 | | | | | | | 485 This scenario is provided to show the duplication of messaging when 486 there isn�t sufficient knowledge to optimize a sequential attempt 487 at reaching an end user. With the "Request History" capability, 488 this flow could be optimized as follows: 490 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 492 | | | | | | | 493 |--INVITE -->| | | | | | 494 | | | | | | | 495 | |--INVITE -------->| | | | 496 |<--100 -----| | | | | | 497 | |<-302 ------------| | | | 498 | | | | | | | 499 | |-------INVITE ------------>| | | 500 | | | | | | | 501 | |<-------180 ---------------| | | 502 |<---180 ----| | | | | | 503 | . . |-------INVITE------------->| | | 504 | | timeout | | | | 505 | | | | | | | 506 | |------INVITE ---------------------->| | 507 |<--100 -----| | | | | | 508 | |<-302 ------------------------------| | 509 | | | | | | | 510 | |-INVITE->| | | | | 511 | | | | | | | 512 | | | | | | | 513 | | |------INVITE --------------------->| 514 | | | | | | | 515 | | |<-----200 OK---------------------->| 516 |<--200 OK-------------| | | | | 517 | | | | | | | 518 |--ACK --------------------------------------------------->| 519 | | | | | | | 521 8.2 Voicemail 523 This scenario is as follows: 525 o UA 1 called UA A which had been forwarded to UA B which 526 forwarded to a UA VM (voicemail server) which needs 527 information (e.g. reason the call was retargeted, original 528 Request URI) to make a policy decision about what mailbox to 529 use, which greeting to play etc. This scenario shows that 530 something like the "Request History" capability must be used 531 for this service to function. 533 UA1 Proxy UA-A UA-B UA-VM 535 | | | | | 536 |--INVITE ---->| | | | 537 | | | | | 538 | |--INVITE ---->| | | 539 |<--100 -------| | | | 540 | |<-302 --------| | | 541 | | | | | 542 | |--------INVITE ------------>| | 543 | | | | | 544 | |<--------180 ---------------| | 545 |<---180 ------| | | | 546 | . . . |--------INVITE------------->| | 547 | | timeout | | 548 | | | | | 549 | |-------INVITE ------------------------>| 550 | | | | | 551 | |<-200 ---------------------------------| 552 | | | | | 553 |<-200---------| | | | 554 | | | | | 555 |--ACK ----------------------------------------------->| 556 | | | | | 557 | | | | | 559 Certainly, another valid scenario for the support of voicemail would 560 be that this 'policy decision' on which mailbox to use (etc.) is made 561 by the UA which forwarded to voicemail (UA B), or by the Proxy which 562 performed the forwarding on behalf of B. In this case, the UA or Proxy 563 can put all the information that the Voicemail server needs to 564 identity the correct mailbox, etc., into the Request-URI. This fits 565 with the SIP service paradigm where the Request-URI identifies the 566 resource (namely, the particular mailbox/greeting etc.) that is 567 required. 569 However, whilst this model is certainly applicable and required in 570 SIP, it places service intelligence away from the system providing the 571 key aspect of the service (the VM server). 573 The proposal in this draft is to rely on generic information- 574 providing capabilities in the UA/Proxy, allowing the Voicemail system 575 to provide more and better voicemail-related services without relying 576 on specific capabilities in the UA/Proxy. This would allow voicemail 577 service providers to innovate independently of the particular UA/Proxy 578 that their customers are using, and its capabilities. Presently, with 579 the information loss problem, VM service providers, and any other 580 similar service providers, are limited in the services they can 581 provide because they do not have complete information about how the 582 call reached them. They rely on the UA/proxy of their customers having 583 the necessary capabilities to formulate a Request-URI identifying 584 exactly what should happen next. Finally, there is obviously a desire 585 to use existing voicemail platforms based on PSTN/ISDN technology 586 which operate according to the paradigm in this example.