idnits 2.17.1 draft-ietf-sipping-req-history-04.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 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 (June 2003) is 7619 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Mary Barnes,Editor 2 Document: draft-ietf-sipping-req-history-04.txt Mark Watson 3 Nortel Networks 4 Cullen Jennings 5 Cisco Systems 6 Jon Peterson 7 Category: Informational NeuStar, Inc. 8 Expires December 2003 June 2003 10 SIP Generic Request History Capability Requirements 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 25 material 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 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 Many services that SIP is anticipated to support require the ability 39 to determine why and how the call arrived at a specific application. 40 Examples of such services include (but are not limited to) sessions 41 initiated to call centers via "click to talk" SIP URLs on a web page, 42 "call history/logging" style services within intelligent "call 43 management" software for SIP UAs and calls to voicemail servers and 44 call centers. While SIP implicitly provides the redirect/retarget 45 capabilities that enable calls to be routed to chosen applications, 46 there is currently no standard mechanism within SIP for communicating 47 the history of such a request. This "request history" information 48 allows the receiving application to determine hints about how and why 49 the call arrived at the application/user. 51 This draft discusses the motivations in support of a mechanism for 52 recording the "request history", and proposes detailed requirements 53 for such a generic "request history" capability. 55 Table of Contents 57 1. Introduction: Why define a Generic "Request History" capability? 58 2 59 2. Conventions used in this document...............................3 60 3. "Request History" Requirements..................................3 61 4. Security Considerations.........................................5 62 5. Privacy Considerations..........................................6 63 6. IANA Considerations.............................................6 64 7. References......................................................6 65 8. Contributors....................................................7 66 9. Acknowledgments.................................................7 67 10. Appendix A - Scenarios..........................................8 68 10.1 Sequentially forking with Retargeting..................9 69 10.2 Voicemail.............................................10 71 1. Introduction: Why define a Generic "Request History" capability? 73 SIP implicitly provides redirect/retarget capabilities that enable 74 calls to be routed to specific applications as defined in [1]. The 75 term retarget will be used henceforth in this draft to refer to the 76 process of a Proxy Server/UAC changing a URI in a request and thus 77 changing the target of the request. This term is chosen to avoid 78 associating this request history only with the specific SIP Redirect 79 Server capability that provides for a response to be sent back to a 80 UAC requesting that the UAC should retarget the original request to 81 an alternate URI. The rules for determining request targets as 82 described in section 16.5 of [1] are consistent with the use of the 83 retarget term in this draft. 85 The motivation for the request history is that in the process of 86 retargeting old routing information can be forever lost. This lost 87 information may be important history that allows elements to which 88 the call is retargeted to process the call in a locally defined, 89 application specific manner. The proposal in this draft is to provide 90 a mechanism for transporting the request history. It is not 91 proposing any behavior for a Proxy or UA upon receipt of the 92 information. Indeed, such behavior should be a local decision for the 93 recipient application. 95 Current network applications provide the ability for elements 96 involved with the call to exchange additional information relating to 97 how and why the call was routed to a particular destination. The 98 following are examples of such applications: 100 1. Web "referral" applications, whereby an application residing 101 within a web server determines that a visitor to a website has 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 "history" 106 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 secure 122 manner provides an additional means (without requiring signed keys) 123 for the original requestor to be assured that the request was 124 properly retargeted. 126 This draft summarizes the requirements for defining a generic 127 mechanism for the transport of request history information. Example 128 scenarios are provided in the appendix illustrating how a SIP 129 building block that provides request history information could be 130 used by some applications. It is not the intent, nor is it within the 131 scope, of this requirement's draft to prescribe a complete solution 132 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 this 138 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 is 146 out of scope of this draft. 148 1) CAPABILITY-req: The "Request History" capability will provide a 149 capability to inform proxies and UAs involved in processing a request 150 about the history/progress of that request. While this is inherently 151 provided when the retarget is in response to a SIP redirect, it is 152 deemed useful for non-redirect retargeting scenarios, as well. 154 2) OPTIONALITY-req: The "Request History" information is optional. 156 2.1) In many cases, it is anticipated that whether the history is 157 added to the Request would be a local policy decision enforced by the 158 specific application, thus no specific protocol element is needed. 160 2.2) Due to the capability being "optional" from the SIP protocol 161 perspective, the impact to an application of not having the "Request 162 History" must be described. Applicability guidelines to be addressed 163 by applications using this capability must be provided as part of the 164 solution to these requirements. 166 3) GENERATION-req: "Request History" information is generated when 167 the request is retargeted. 169 3.1) In some scenarios, it might be possible for more than one 170 instance of retargeting to occur within the same Proxy. A proxy 171 should also generate Request History information for the 'internal 172 retargeting'. 174 3.2) An entity (UA or proxy) retargeting in response to a redirect or 175 REFER should include any Request History information from the 176 redirect/REFER in the new request. 178 4) ISSUER-req: "Request History" information can be generated by a 179 UA, proxy or redirect server. It can be passed in both requests and 180 responses. 182 5) CONTENT-req: The "Request History" information for each 183 occurrence of retargeting, shall include the following: 185 5.1) The new URI or address to which the request is in the process 186 of being retargeted, 188 5.2) The URI or address from which the request was retargeted, 189 5.3) The reason for the Request-URI modification, 191 5.4) Chronological ordering of the Request History information. 193 6) REQUEST-VALIDITY-req: Request-History is applicable to requests 194 not sent within an established dialog. (i.e. INVITE, REGISTER, 195 MESSAGE, and OPTIONS). 197 7) BACKWARDS-req: Request-History information may be passed from the 198 generating entity backwards towards the UAC. This is needed to enable 199 services that inform the calling party about the dialog establishment 200 attempts. 202 8) FORWARDS-req: Request-History information may also be included by 203 the generating entity in the request, if it is forwarded onwards. 205 4. Security Considerations 207 The Request History information is being inserted by a network 208 element retargeting a Request, resulting in a slightly different 209 problem than the basic SIP header problem, thus requiring specific 210 consideration. It is recognized that these security requirements can 211 be generalized to a basic requirement of being able to secure 212 information that is inserted by proxies. 214 The potential security problems include the following: 215 1) A rogue application could insert a bogus Request History entry 216 either by adding an additional entry as a result of retargeting or 217 entering invalid information. 219 2) Loss of privacy associated with forwarding a specific Request URI 220 in the Request History. 222 3) A rogue application could re-arrange the Request History 223 information to change the nature of the end application or to mislead 224 the receiver of the information. 226 Thus, a security solution for "Request History" must meet the 227 following requirements: 229 1) SEC-req-1: The entity receiving the Request History must be able 230 to determine whether any of the previously added Request History 231 content has been altered. 233 2) SEC-req-2: The ordering of the Request History information must be 234 preserved at each instance of retargeting. 236 3) SEC-req-3: The entity receiving the information conveyed by the 237 Request History must be able to authenticate the source of the 238 information. 240 4) SEC-req-4: To ensure the confidentiality of the Request History 241 information, only entities which process the request should have 242 visibility to the information. 244 It should be noted that these security requirements apply to any 245 entity making use of the Request History information, either by 246 retargeting and capturing the information, or as an application 247 making use of the information in a Request or Response. 249 5. Privacy Considerations 251 Since the Request URI that is captured could inadvertently reveal 252 information about the originator, there are general privacy 253 requirements that MUST be met: 255 1) PRIV-req-1: The entity retargeting the Request must ensure that it 256 maintains the network-provided privacy (as described in [2]) 257 associated with the Request as it is retargeted. 259 2) PRIV-req-2: The entity receiving the Request History must maintain 260 the privacy associated with the information. 262 In addition, local policy at a proxy may identify privacy 263 requirements associated with Request History information. Request 264 History information subject to privacy requirements shall not be 265 included in outgoing messages unless it is protected as described in 266 [2]. 268 6. IANA Considerations 270 This document does not have any implications for IANA. 272 7. References 274 [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261, 275 June, 2002. 277 [2] J. Peterson, "A Privacy Mechanism for the Session Initiation 278 Protocol (SIP)", RFC 3323, November, 2002. 280 8. Contributors 282 Robert Sparks contributed excellent feedback and direction for the 283 Security considerations section of this document. In addition, he 284 highlighted the importance of addressing the optionality aspects of 285 the "Request History" capability. 287 9. Acknowledgments 289 The editor would like to thank Sanjoy Sen, Ben Campbell, Rohan 290 Mahy, Jonathan Rosenberg and John Elwell for providing useful 291 comments and suggestions related to this draft. 293 Authors' Addresses 295 Mary Barnes 296 Nortel Networks 297 2380 Performance Drive 298 Richardson, Texas 75082 299 USA 301 Phone: +1 972-684-5432 302 EMail: mbarnes@nortelnetworks.com 304 Mark Watson 305 Nortel Networks 306 Maidenhead Office Park (Bray House) 307 Westacott Way 308 Maidenhead, Berkshire 309 England 311 Phone: +44 (0)1628-434456 312 EMail: mwatson@nortelnetworks.com 314 Cullen Jennings 315 Cisco Systems 316 170 West Tasman Drive 317 MS: SJC-21/3 318 San Jose, CA 95134 319 USA 321 Phone: +1 408-527-9132 322 EMail: fluffy@cisco.com 324 Jon Peterson 325 NeuStar, Inc. 327 1800 Sutter Street, Suite 570 328 Concord, CA 94520 329 USA 331 Phone: +1 925-363-8720 332 EMail: Jon.Peterson@NeuStar.biz 334 Full Copyright Statement 336 Copyright (C) The Internet Society (2003). All Rights Reserved. 338 This document and translations of it may be copied and furnished to 339 others, and derivative works that comment on or otherwise explain 340 it or assist in its implementation may be prepared, copied, 341 published and distributed, in whole or in part, without restriction 342 of any kind, provided that the above copyright notice and this 343 paragraph are included on all such copies and derivative works. 344 However, this document itself may not be modified in any way, such 345 as by removing the copyright notice or references to the Internet 346 Society or other Internet organizations, except as needed for the 347 purpose of developing Internet standards in which case the 348 procedures for copyrights defined in the Internet Standards process 349 must be followed, or as required to translate it into languages 350 other than English. The limited permissions granted above are 351 perpetual and will not be revoked by the Internet Society or its 352 successors or assigns. This document and the information contained 353 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY 354 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 355 WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 356 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 357 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 358 FOR A PARTICULAR PURPOSE." 360 10. Appendix A - Scenarios 362 This section highlights some scenarios under which the Request 363 History Capability could be applicable. 365 Certainly, various other solutions can be applied in some fashion 366 to each of these scenarios. However, the objective of this draft 367 has been to abstract the requirements from these scenarios towards 368 providing a more robust solution for each and at the same time 369 providing fundamental building block(s) applicable to future 370 applications. 372 10.1 Sequentially forking with Retargeting 374 This scenario is as follows: 376 UA 1 sends a call to proxy 1. Proxy 1 sequentially tries several 377 places (UA2, UA3 and UA4) before retargeting the call to Proxy 2. 378 Proxy 2 unfortunately tries several of the same places (UA3 and 379 UA4), before completing at UA5. 381 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 383 | | | | | | | 384 |--INVITE -->| | | | | | 385 | | | | | | | 386 | |--INVITE -------->| | | | 387 |<--100 -----| | | | | | 388 | |<-302 ------------| | | | 389 | | | | | | | 390 | |-------INVITE ------------>| | | 391 | | | | | | | 392 | |<-------180 ---------------| | | 393 |<---180 ----| | | | | | 394 | . . |-------INVITE------------->| | | 395 | | timeout | | | | 396 | | | | | | | 397 | |------INVITE ---------------------->| | 398 |<--100 -----| | | | | | 399 | |<-302 ------------------------------| | 400 | | | | | | | 401 | |-INVITE->| | | | | 402 | | | | | | | 403 | | |---INVITE ------>| | | 404 | | | | | | | 405 | | |<---180----------| | | 406 |<---180 --------------| | | | | 407 | | | | | | | 408 | . . | |----INVITE------>| | | 409 | | | timeout | | | 410 | | | | | | | 411 | | |------INVITE ------------>| | 412 |<--100 ---------------| | | | | 413 | | |<-302 --------------------| | 414 | | | | | | | 415 | | |------INVITE --------------------->| 416 | | | | | | | 417 | | |<-----200 OK---------------------->| 418 |<--200 OK-------------| | | | | 419 | | | | | | | 420 |--ACK --------------------------------------------------->| 421 | | | | | | | 423 This scenario is provided to show the duplication of messaging when 424 there isn't sufficient knowledge to optimize a sequential attempt 425 at reaching an end user. With the "Request History" capability, 426 this flow could be optimized as follows: 428 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 430 | | | | | | | 431 |--INVITE -->| | | | | | 432 | | | | | | | 433 | |--INVITE -------->| | | | 434 |<--100 -----| | | | | | 435 | |<-302 ------------| | | | 436 | | | | | | | 437 | |-------INVITE ------------>| | | 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 460 This scenario highlights an example where the request history 461 information is primarily of use by an edge service (e.g. Voicemail 462 Server). It should be noted that this isn't intended to be a 463 complete specification for this specific edge service as it is 464 quite likely that additional information is needed by the edge 465 service. 467 This scenario is as follows: 469 UA 1 called UA A which had been forwarded to UA B which forwarded 470 to a UA VM (voicemail server) which needs information (e.g. 471 reason the call was retargeted, original Request URI) to make a 472 policy decision about what mailbox to use, which greeting to play 473 etc. This scenario shows that something like the "Request 474 History" capability must be used for this service to function. 476 UA1 Proxy UA-A UA-B UA-VM 478 | | | | | 479 |--INVITE ---->| | | | 480 | | | | | 481 | |--INVITE ---->| | | 482 |<--100 -------| | | | 483 | |<-302 --------| | | 484 | | | | | 485 | |--------INVITE ------------>| | 486 | | | | | 487 | |<--------180 ---------------| | 488 |<---180 ------| | | | 489 | . . . |--------INVITE------------->| | 490 | | timeout | | 491 | | | | | 492 | |-------INVITE ------------------------>| 493 | | | | | 494 | |<-200 ---------------------------------| 495 | | | | | 496 |<-200---------| | | | 497 | | | | | 498 |--ACK ----------------------------------------------->| 499 | | | | | 500 | | | | | 502 This scenario is specifically highlighting a case whereby the desired 503 functionality (e.g. via local policy) is for a call which is not 504 answered (or undeliverable for other reasons) to revert to the 505 voicemail server of UA A. Additional scenarios are certainly valid 506 whereby the call is routed to the voicemail server of UA B, thus NOT 507 necessarily requiring history information to process the request. This 508 latter situation further highlights that the use of the request 509 history information is not prescriptive for any particular service.