idnits 2.17.1 draft-ietf-sipping-req-history-01.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 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.) ** The document seems to lack an Authors' Addresses Section. 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 (December 2002) is 7801 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 282 looks like a reference -- Missing reference section? '2' on line 285 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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-01.txt Mark Watson 4 Nortel Networks 5 Cullen Jennings 6 Cisco 7 Jon Peterson 8 Category: Informational NeuStar 9 Expires June 2003 December 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 December 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. Privacy Considerations.........................................6 61 6. IANA Considerations............................................6 62 7. References.....................................................6 63 8. Contributors...................................................6 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 December 2002 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 December 2002 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 December 2002 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 December 2002 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 It is recognized that meeting the privacy requirements can impact 272 the functionality of this solution by overriding the request to 273 generate the information. The applicability guidelines for a 274 solution must clearly address this impact. 276 6.IANA Considerations 278 This document does not have any implications for IANA. 280 7.References 282 [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 283 3261, June, 2002. 285 [2] J. Peterson, "A Privacy Mechanism for the Session Initiation 286 Protocol (SIP)", RFC 3323, November, 2002. 288 8. Contributors 290 Robert Sparks contributed excellent feedback and direction for 291 the Security considerations section of this document. In 292 SIP Generic Request History Capability - Requirements December 2002 294 addition, he highlighted the importance of addressing the 295 optionality aspects of the "Request History" capability. 297 9. Acknowledgments 299 The editor would like to thank Sanjoy Sen, Ben Campbell, Rohan 300 Mahy and Jonathan Rosenberg for providing useful comments and 301 suggestions related to this draft. 303 Authors� Addresses 305 Mark Watson 306 Nortel Networks (UK) 307 Maidenhead Office Park (Bray House) 308 Westacott Way 309 Maidenhead, 310 Berkshire Tel: +44 (0)1628-434456 311 England Email: mwatson@nortelnetworks.com 313 Mary Barnes 314 Nortel Networks Tel: +1 972-684-5432 315 Richardson, Texas Email: mbarnes@nortelnetworks.com 317 Jon Peterson 318 NeuStar, Inc. 319 1800 Sutter Street, Suite 570 320 Concord, CA 94520 Email: Jon.Peterson@NeuStar.com 322 Cullen Jennings 323 Cisco Systems 324 170 West Tasman Dr Tel: +1 408 527 9132 325 MS: SJC-21/3 Email: fluffy@cisco.com 327 Full Copyright Statement 329 Copyright (C) The Internet Society (2002). All Rights Reserved. 331 This document and translations of it may be copied and furnished to 332 others, and derivative works that comment on or otherwise explain 333 it or assist in its implementation may be prepared, copied, 334 published and distributed, in whole or in part, without restriction 335 of any kind, provided that the above copyright notice and this 336 paragraph are included on all such copies and derivative works. 337 However, this document itself may not be modified in any way, such 338 as by removing the copyright notice or references to the Internet 339 Society or other Internet organizations, except as needed for the 340 purpose of developing Internet standards in which case the 341 procedures for copyrights defined in the Internet Standards process 342 SIP Generic Request History Capability - Requirements December 2002 344 must be followed, or as required to translate it into languages 345 other than English. The limited permissions granted above are 346 perpetual and will not be revoked by the Internet Society or its 347 successors or assigns. This document and the information contained 348 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY 349 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 350 WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 351 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 352 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 353 FOR A PARTICULAR PURPOSE." 355 10. Appendix A - Scenarios 357 This section highlights some scenarios under which the Request 358 History Capability could be applicable. 360 Certainly, various other solutions can be applied in some fashion 361 to each of these scenarios. However, the objective of this draft 362 has been to abstract the requirements from these scenarios towards 363 providing a more robust solution for each and at the same time 364 providing fundamental building block(s) applicable to future 365 applications. 367 10.1 Sequentially forking with Retargeting 369 This scenario is as follows: 371 UA 1 sends a call to proxy 1. Proxy 1 sequentially tries several 372 places (UA2, UA3 and UA4) before retargeting the call to Proxy 2. 373 Proxy 2 unfortunately tries several of the same places (UA3 and 374 UA4), before completing at UA5. 376 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 378 | | | | | | | 379 |--INVITE -->| | | | | | 380 | | | | | | | 381 | |--INVITE -------->| | | | 382 |<--100 -----| | | | | | 383 | |<-302 ------------| | | | 384 | | | | | | | 385 | |-------INVITE ------------>| | | 386 | | | | | | | 387 | |<-------180 ---------------| | | 388 |<---180 ----| | | | | | 389 SIP Generic Request History Capability - Requirements December 2002 391 | . . |-------INVITE------------->| | | 392 | | timeout | | | | 393 | | | | | | | 394 | |------INVITE ---------------------->| | 395 |<--100 -----| | | | | | 396 | |<-302 ------------------------------| | 397 | | | | | | | 398 | |-INVITE->| | | | | 399 | | | | | | | 400 | | |---INVITE ------>| | | 401 | | | | | | | 402 | | |<---180----------| | | 403 |<---180 --------------| | | | | 404 | | | | | | | 405 | . . | |----INVITE------>| | | 406 | | | timeout | | | 407 | | | | | | | 408 | | |------INVITE ------------>| | 409 |<--100 ---------------| | | | | 410 | | |<-302 --------------------| | 411 | | | | | | | 412 | | |------INVITE --------------------->| 413 | | | | | | | 414 | | |<-----200 OK---------------------->| 415 |<--200 OK-------------| | | | | 416 | | | | | | | 417 |--ACK --------------------------------------------------->| 418 | | | | | | | 420 This scenario is provided to show the duplication of messaging when 421 there isn�t sufficient knowledge to optimize a sequential attempt 422 at reaching an end user. With the "Request History" capability, 423 this flow could be optimized as follows: 425 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 427 | | | | | | | 428 |--INVITE -->| | | | | | 429 | | | | | | | 430 | |--INVITE -------->| | | | 431 |<--100 -----| | | | | | 432 | |<-302 ------------| | | | 433 | | | | | | | 434 | |-------INVITE ------------>| | | 435 | | | | | | | 436 | |<-------180 ---------------| | | 437 |<---180 ----| | | | | | 438 | . . |-------INVITE------------->| | | 439 SIP Generic Request History Capability - Requirements December 2002 441 | | timeout | | | | 442 | | | | | | | 443 | |------INVITE ---------------------->| | 444 |<--100 -----| | | | | | 445 | |<-302 ------------------------------| | 446 | | | | | | | 447 | |-INVITE->| | | | | 448 | | | | | | | 449 | | | | | | | 450 | | |------INVITE --------------------->| 451 | | | | | | | 452 | | |<-----200 OK---------------------->| 453 |<--200 OK-------------| | | | | 454 | | | | | | | 455 |--ACK --------------------------------------------------->| 456 | | | | | | | 458 10.2 Voicemail 460 This scenario is as follows: 462 UA 1 called UA A which had been forwarded to UA B which forwarded 463 to a UA VM (voicemail server) which needs information (e.g. 464 reason the call was retargeted, original Request URI) to make a 465 policy decision about what mailbox to use, which greeting to play 466 etc. This scenario shows that something like the "Request 467 History" capability must be used for this service to function. 469 UA1 Proxy UA-A UA-B UA-VM 471 | | | | | 472 |--INVITE ---->| | | | 473 | | | | | 474 | |--INVITE ---->| | | 475 |<--100 -------| | | | 476 | |<-302 --------| | | 477 | | | | | 478 | |--------INVITE ------------>| | 479 | | | | | 480 | |<--------180 ---------------| | 481 |<---180 ------| | | | 482 | . . . |--------INVITE------------->| | 483 | | timeout | | 484 | | | | | 485 | |-------INVITE ------------------------>| 486 | | | | | 487 SIP Generic Request History Capability - Requirements December 2002 489 | |<-200 ---------------------------------| 490 | | | | | 491 |<-200---------| | | | 492 | | | | | 493 |--ACK ----------------------------------------------->| 494 | | | | | 495 | | | | | 497 Certainly, another valid scenario for the support of voicemail would 498 be that this 'policy decision' on which mailbox to use (etc.) is made 499 by the UA which forwarded to voicemail (UA B), or by the Proxy which 500 performed the forwarding on behalf of B. In this case, the UA or Proxy 501 can put all the information that the Voicemail server needs to 502 identity the correct mailbox, etc., into the Request-URI. This fits 503 with the SIP service paradigm where the Request-URI identifies the 504 resource (namely, the particular mailbox/greeting etc.) that is 505 required. 507 However, whilst this model is certainly applicable and required in 508 SIP, it places service intelligence away from the system providing the 509 key aspect of the service (the VM server). 511 The proposal in this draft is to rely on generic information-providing 512 capabilities in the UA/Proxy, allowing the Voicemail system to provide 513 more and better voicemail-related services without relying on specific 514 capabilities in the UA/Proxy. This would allow voicemail service 515 providers to innovate independently of the particular UA/Proxy that 516 their customers are using, and its capabilities. Presently, with the 517 information loss problem, VM service providers, and any other similar 518 service providers, are limited in the services they can provide 519 because they do not have complete information about how the call 520 reached them. They rely on the UA/proxy of their customers having the 521 necessary capabilities to formulate a Request-URI identifying exactly 522 what should happen next. Finally, there is obviously a desire to use 523 existing voicemail platforms based on PSTN/ISDN technology, which 524 operate according to the paradigm in this example.