idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- 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 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 (February 2003) is 7712 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 283 looks like a reference -- Missing reference section? '2' on line 286 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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-02.txt Mark Watson 4 Nortel Networks 5 Cullen Jennings 6 Cisco 7 Jon Peterson 8 Category: Informational NeuStar 9 Expires August 2003 February 2003 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 February 2003 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. Privacy Considerations.........................................6 61 6. IANA Considerations............................................6 62 7. References.....................................................6 63 8. Contributors...................................................7 64 9. Acknowledgments................................................7 65 10. Appendix A - Scenarios.........................................8 66 10.1 Sequentially forking with Retargeting.................8 67 10.2 Voicemail............................................10 69 1.Introduction: Why define a Generic "Request History" capability? 71 SIP implicitly provides redirect/retarget capabilities that enable 72 calls to be routed to specific applications as defined in [1]. The 73 term retarget will be used henceforth in this draft to refer to the 74 process of a Proxy Server/UAC changing a URI in a request and thus 75 changing the target of the request. This term is chosen to avoid 76 associating this request history only with the specific SIP 77 Redirect Server capability that provides for a response to be sent 78 back to a UAC requesting that the UAC should retarget the original 79 request to an alternate URI. The rules for determining request 80 targets as described in section 16.5 of [1] are consistent with the 81 use of the retarget term in this draft. 83 The motivation for the request history is that in the process of 84 retargeting old routing information can be forever lost. This lost 85 information may be important history that allows elements to which 86 the call is retargeted to process the call in a locally defined, 87 application specific manner. The proposal in this draft is to 88 provide a mechanism for transporting the request history. It is 89 not proposing any behavior for a Proxy or UA upon receipt of the 90 information. Indeed, such behavior should be a local decision for 91 the recipient application. 93 Current network applications provide the ability for elements 94 involved with the call to exchange additional information relating 95 to how and why the call was routed to a particular destination. 96 The following are examples of such applications: 98 1. Web "referral" applications, whereby an application residing 99 within a web server determines that a visitor to a website has 100 SIP Generic Request History Capability - Requirements February 2003 102 arrived at the site via an "associate" site which will receive 103 some "referral" commission for generating this traffic, 105 2. Email forwarding whereby the forwarded-to user obtains a 106 "history" of who sent the email to whom and at what time 108 3. Traditional telephony services such as Voicemail, call-center 109 "automatic call distribution", and "follow-me" style services. 111 Several of the aforementioned applications define application 112 specific mechanisms through which it is possible to obtain the 113 necessary history information. 115 In addition, request history information could be used to enhance 116 basic SIP functionality by providing: 118 4. Some diagnostic information for debugging SIP requests. 120 5. A stronger security solution for SIP. A side effect is that each 121 proxy which captures the "request history" information in a 122 secure manner provides an additional means (without requiring 123 signed keys) for the original requestor to be assured that the 124 request was properly retargeted. 126 This draft summarizes the requirements for defining a generic 127 mechanism for the transport of request history information. 128 Example scenarios are provided in the appendix illustrating how a 129 SIP building block that provides request history information could 130 be used by some applications. It is not the intent, nor is it 131 within the scope, of this requirement's draft to prescribe a 132 complete solution for any of these applications. 134 2.Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 138 this document are to be interpreted as described in RFC-2119. 140 3. "Request History" Requirements 142 The following list constitutes a set of requirements for a "Request 143 History" capability. It is anticipated that some of these 144 requirements can be met using existing elements within SIP; whether 145 and what SIP extensions would be needed to meet these requirements 146 is out of scope of this draft. 148 SIP Generic Request History Capability - Requirements February 2003 150 1) CAPABILITY-req: The "Request History" capability will provide a 151 capability to inform proxies and UAs involved in processing a 152 request about the history/progress of that request. While this is 153 inherently provided when the retarget is in response to a SIP 154 redirect, it is deemed useful for non-redirect retargeting 155 scenarios, as well. 157 2) OPTIONALITY-req: The "Request History" information is optional. 159 2.1) In many cases, it is anticipated that whether the history is 160 added to the Request would be a local policy decision enforced by 161 the specific application, thus no specific protocol element is 162 needed. 164 2.2) Due to the capability being "optional" from the SIP protocol 165 perspective, the impact to an application of not having the 166 "Request History" must be described. Applicability guidelines to be 167 addressed by applications using this capability must be provided as 168 part of the solution to these requirements. 170 3) GENERATION-req: "Request History" information is generated when 171 the request is retargeted. 173 3.1) In some scenarios, it might be possible for more than one 174 instance of retargeting to occur within the same Proxy. A proxy 175 should also generate Request History information for the 'internal 176 retargeting'. 178 3.2) An entity (UA or proxy) retargeting in response to a redirect 179 or REFER should include any Request History information from the 180 redirect/REFER in the new request. 182 4) ISSUER-req: "Request History" information can be generated by a 183 UA, proxy or redirect server. It can be passed in both requests and 184 responses. 186 5) CONTENT-req: The "Request History" information for each 187 occurrence of retargeting, shall include the following: 189 5.1) The new URI or address to which the request is in the 190 process of being retargeted, 192 5.2) The URI or address from which the request was retargeted, 194 5.3) The reason for the Request-URI modification, 195 SIP Generic Request History Capability - Requirements February 2003 197 5.4) Chronological ordering of the Request History information. 199 6) REQUEST-VALIDITY-req: Request-History is applicable to requests 200 not sent within an established dialog. (i.e. INVITE, REGISTER, 201 MESSAGE, and OPTIONS). 203 7) BACKWARDS-req: Request-History information may be passed from 204 the generating entity backwards towards the UAC. This is needed to 205 enable services that inform the calling party about the dialog 206 establishment attempts. 208 8) FORWARDS-req: Request-History information may also be included 209 by the generating entity in the request, if it is forwarded 210 onwards. 212 4. Security Considerations 214 The Request History information is being inserted by a network 215 element retargeting a Request, resulting in a slightly different 216 problem than the basic SIP header problem, thus requiring specific 217 consideration. It is recognized that these security requirements 218 can be generalized to a basic requirement of being able to secure 219 information that is inserted by proxies. 221 The potential security problems include the following: 222 1) A rogue application could insert a bogus Request History entry 223 either by adding an additional entry as a result of retargeting or 224 entering invalid information. 226 2) Loss of privacy associated with forwarding a specific Request 227 URI in the Request History. 229 3) A rogue application could re-arrange the Request History 230 information to change the nature of the end application or to 231 mislead the receiver of the information. 233 Thus, a security solution for "Request History" must meet the 234 following requirements: 236 1) SEC-req-1: The entity receiving the Request History must be able 237 to determine whether any of the previously added Request History 238 content has been altered. 240 2) SEC-req-2: The ordering of the Request History information must 241 be preserved at each instance of retargeting. 243 SIP Generic Request History Capability - Requirements February 2003 245 3) SEC-req-3: The entity receiving the information conveyed by the 246 Request History must be able to authenticate the source of the 247 information. 249 4) SEC-req-4: To ensure the confidentiality of the Request History 250 information, only entities which process the request should have 251 visibility to the information. 253 It should be noted that these security requirements apply to any 254 entity making use of the Request History information, either by 255 retargeting and capturing the information, or as an application 256 making use of the information in a Request or Response. 258 5.Privacy Considerations 260 Since the Request URI that is captured could inadvertently reveal 261 information about the originator, there are general privacy 262 requirements that MUST be met: 264 1) PRIV-req-1: The entity retargeting the Request must ensure that 265 it maintains the network-provided privacy (as described in [2]) 266 associated with the Request as it is retargeted. 268 2) PRIV-req-2: The entity receiving the Request History must 269 maintain the privacy associated with the information. 271 In addition, local policy at a proxy may identify privacy 272 requirements associated with Request History information. Request 273 History information subject to privacy requirements shall not be 274 included in outgoing messages unless it is protected as described 275 in [2]. 277 6.IANA Considerations 279 This document does not have any implications for IANA. 281 7.References 283 [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 284 3261, June, 2002. 286 [2] J. Peterson, "A Privacy Mechanism for the Session Initiation 287 Protocol (SIP)", RFC 3323, November, 2002. 289 SIP Generic Request History Capability - Requirements February 2003 291 8. Contributors 293 Robert Sparks contributed excellent feedback and direction for 294 the Security considerations section of this document. In 295 addition, he highlighted the importance of addressing the 296 optionality aspects of the "Request History" capability. 298 9. Acknowledgments 300 The editor would like to thank Sanjoy Sen, Ben Campbell, Rohan 301 Mahy, Jonathan Rosenberg and John Elwell for providing useful 302 comments and suggestions related to this draft. 304 Authors' Addresses 306 Mark Watson 307 Nortel Networks (UK) 308 Maidenhead Office Park (Bray House) 309 Westacott Way 310 Maidenhead, 311 Berkshire Tel: +44 (0)1628-434456 312 England Email: mwatson@nortelnetworks.com 314 Mary Barnes 315 Nortel Networks Tel: +1 972-684-5432 316 Richardson, Texas Email: mbarnes@nortelnetworks.com 318 Jon Peterson 319 NeuStar, Inc. 320 1800 Sutter Street, Suite 570 321 Concord, CA 94520 Email: Jon.Peterson@NeuStar.com 323 Cullen Jennings 324 Cisco Systems 325 170 West Tasman Dr Tel: +1 408 527 9132 326 MS: SJC-21/3 Email: fluffy@cisco.com 328 Full Copyright Statement 330 Copyright (C) The Internet Society (2002). All Rights Reserved. 332 This document and translations of it may be copied and furnished to 333 others, and derivative works that comment on or otherwise explain 334 it or assist in its implementation may be prepared, copied, 335 published and distributed, in whole or in part, without restriction 336 of any kind, provided that the above copyright notice and this 337 paragraph are included on all such copies and derivative works. 338 However, this document itself may not be modified in any way, such 339 SIP Generic Request History Capability - Requirements February 2003 341 as by removing the copyright notice or references to the Internet 342 Society or other Internet organizations, except as needed for the 343 purpose of developing Internet standards in which case the 344 procedures for copyrights defined in the Internet Standards process 345 must be followed, or as required to translate it into languages 346 other than English. The limited permissions granted above are 347 perpetual and will not be revoked by the Internet Society or its 348 successors or assigns. This document and the information contained 349 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY 350 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 351 WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 352 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 353 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 354 FOR A PARTICULAR PURPOSE." 356 10. Appendix A - Scenarios 358 This section highlights some scenarios under which the Request 359 History Capability could be applicable. 361 Certainly, various other solutions can be applied in some fashion 362 to each of these scenarios. However, the objective of this draft 363 has been to abstract the requirements from these scenarios towards 364 providing a more robust solution for each and at the same time 365 providing fundamental building block(s) applicable to future 366 applications. 368 10.1 Sequentially forking with Retargeting 370 This scenario is as follows: 372 UA 1 sends a call to proxy 1. Proxy 1 sequentially tries several 373 places (UA2, UA3 and UA4) before retargeting the call to Proxy 2. 374 Proxy 2 unfortunately tries several of the same places (UA3 and 375 UA4), before completing at UA5. 377 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 379 | | | | | | | 380 |--INVITE -->| | | | | | 381 | | | | | | | 382 | |--INVITE -------->| | | | 383 |<--100 -----| | | | | | 384 | |<-302 ------------| | | | 385 | | | | | | | 386 SIP Generic Request History Capability - Requirements February 2003 388 | |-------INVITE ------------>| | | 389 | | | | | | | 390 | |<-------180 ---------------| | | 391 |<---180 ----| | | | | | 392 | . . |-------INVITE------------->| | | 393 | | timeout | | | | 394 | | | | | | | 395 | |------INVITE ---------------------->| | 396 |<--100 -----| | | | | | 397 | |<-302 ------------------------------| | 398 | | | | | | | 399 | |-INVITE->| | | | | 400 | | | | | | | 401 | | |---INVITE ------>| | | 402 | | | | | | | 403 | | |<---180----------| | | 404 |<---180 --------------| | | | | 405 | | | | | | | 406 | . . | |----INVITE------>| | | 407 | | | timeout | | | 408 | | | | | | | 409 | | |------INVITE ------------>| | 410 |<--100 ---------------| | | | | 411 | | |<-302 --------------------| | 412 | | | | | | | 413 | | |------INVITE --------------------->| 414 | | | | | | | 415 | | |<-----200 OK---------------------->| 416 |<--200 OK-------------| | | | | 417 | | | | | | | 418 |--ACK --------------------------------------------------->| 419 | | | | | | | 421 This scenario is provided to show the duplication of messaging when 422 there isn't sufficient knowledge to optimize a sequential attempt 423 at reaching an end user. With the "Request History" capability, 424 this flow could be optimized as follows: 426 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 428 | | | | | | | 429 |--INVITE -->| | | | | | 430 | | | | | | | 431 | |--INVITE -------->| | | | 432 |<--100 -----| | | | | | 433 | |<-302 ------------| | | | 434 | | | | | | | 435 | |-------INVITE ------------>| | | 436 SIP Generic Request History Capability - Requirements February 2003 438 | | | | | | | 439 | |<-------180 ---------------| | | 440 |<---180 ----| | | | | | 441 | . . |-------INVITE------------->| | | 442 | | timeout | | | | 443 | | | | | | | 444 | |------INVITE ---------------------->| | 445 |<--100 -----| | | | | | 446 | |<-302 ------------------------------| | 447 | | | | | | | 448 | |-INVITE->| | | | | 449 | | | | | | | 450 | | | | | | | 451 | | |------INVITE --------------------->| 452 | | | | | | | 453 | | |<-----200 OK---------------------->| 454 |<--200 OK-------------| | | | | 455 | | | | | | | 456 |--ACK --------------------------------------------------->| 457 | | | | | | | 459 10.2 Voicemail 461 This scenario is as follows: 463 UA 1 called UA A which had been forwarded to UA B which forwarded 464 to a UA VM (voicemail server) which needs information (e.g. 465 reason the call was retargeted, original Request URI) to make a 466 policy decision about what mailbox to use, which greeting to play 467 etc. This scenario shows that something like the "Request 468 History" capability must be used for this service to function. 470 UA1 Proxy UA-A UA-B UA-VM 472 | | | | | 473 |--INVITE ---->| | | | 474 | | | | | 475 | |--INVITE ---->| | | 476 |<--100 -------| | | | 477 | |<-302 --------| | | 478 | | | | | 479 | |--------INVITE ------------>| | 480 | | | | | 481 | |<--------180 ---------------| | 482 |<---180 ------| | | | 483 | . . . |--------INVITE------------->| | 484 SIP Generic Request History Capability - Requirements February 2003 486 | | timeout | | 487 | | | | | 488 | |-------INVITE ------------------------>| 489 | | | | | 490 | |<-200 ---------------------------------| 491 | | | | | 492 |<-200---------| | | | 493 | | | | | 494 |--ACK ----------------------------------------------->| 495 | | | | | 496 | | | | | 498 Certainly, another valid scenario for the support of voicemail would 499 be that this 'policy decision' on which mailbox to use (etc.) is made 500 by the UA which forwarded to voicemail (UA B), or by the Proxy which 501 performed the forwarding on behalf of B. In this case, the UA or Proxy 502 can put all the information that the Voicemail server needs to 503 identity the correct mailbox, etc., into the Request-URI. This fits 504 with the SIP service paradigm where the Request-URI identifies the 505 resource (namely, the particular mailbox/greeting etc.) that is 506 required. 508 However, whilst this model is certainly applicable and required in 509 SIP, it places service intelligence away from the system providing the 510 key aspect of the service (the VM server). 512 The proposal in this draft is to rely on generic information-providing 513 capabilities in the UA/Proxy, allowing the Voicemail system to provide 514 more and better voicemail-related services without relying on specific 515 capabilities in the UA/Proxy. This would allow voicemail service 516 providers to innovate independently of the particular UA/Proxy that 517 their customers are using, and its capabilities. Presently, with the 518 information loss problem, VM service providers, and any other similar 519 service providers, are limited in the services they can provide 520 because they do not have complete information about how the call 521 reached them. They rely on the UA/proxy of their customers having the 522 necessary capabilities to formulate a Request-URI identifying exactly 523 what should happen next. Finally, there is obviously a desire to use 524 existing voicemail platforms based on PSTN/ISDN technology, which 525 operate according to the paradigm in this example.