Internet Draft Mary Barnes,Editor Document: draft-ietf-sipping-req-history-00.txt Mark Watson Nortel Networks Cullen Jennings Cisco Jon Peterson Category: Informational NeuStar Expires February 2003 August 2002 SIP Generic Request History Capability û Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Many services that SIP is anticipated to support require the ability to determine why and how the call arrived at a specific application. Examples of such services include (but are not limited to) sessions initiated to call centers via "click to talk" SIP URLs on a web page, "call history/logging" style services within intelligent "call management" software for SIP UAs and calls to voicemail servers and call centers. While SIP implicitly provides the redirect/retarget capabilities that enable calls to be routed to chosen applications, there is currently no standard mechanism within SIP for communicating the history of such a request. This "request history" information allows the receiving application to determine hints about how and why the call arrived at the application/user. This draft discusses the motivations in support of a mechanism for recording the "request history", and proposes detailed requirements for such a generic "request history" capability. Watson Expires - February 2003 [Page 1] SIP Generic Request History Capability - Requirements August 2002 Table of Contents 1. Introduction: Why define a Generic "Request History" capability? 2 2. Conventions used in this document..............................3 3. "Request History" Requirements.................................3 4. Security Considerations........................................5 5. IANA Considerations............................................6 7. Contributors...................................................6 8. Acknowledgments................................................6 9. Appendix A - Scenarios.........................................8 9.1. Sequentially forking with Retargetting................8 9.2. Voicemail............................................10 1. Introduction: Why define a Generic "Request History" capability? SIP implicitly provides redirect/retarget capabilities that enable calls to be routed to specific applications as defined in [1]. The term retarget will be used henceforth in this draft to refer to the process of a Proxy Server/UAC changing a URI in a request and thus changing the target of the request. This term is chosen to avoid associating this request history only with the specific SIP Redirect Server capability that provides for a response to be sent back to a UAC requesting that the UAC should retarget the original request to an alternate URI. The rules for determining request targets as described in section 16.5 of [1] are believed to be consistent with the use of the retarget term in this draft. The motivation for the request history is that in the process of retargeting old routing information can be forever lost. This lost information may be important history that allows elements to which the call is retargeted to process the call in a locally defined, application specific manner. The proposal in this draft is to provide a mechanism for transporting the request history. It is not proposing any behavior for a Proxy or UA upon receipt of the information. Indeed, such behavior should be a local decision for the recipient application. Current network applications provide the ability for elements involved with the call to exchange additional information relating to how and why the call was routed to a particular destination. The following are examples of such applications: 1. Web "referral" applications, whereby an application residing within a web server determines that a visitor to a website has arrived at the site via an "associate" site which will receive some "referral" commission for generating this traffic, Watson Expires - February 2003 [Page 2] SIP Generic Request History Capability - Requirements August 2002 2. Email forwarding whereby the forwarded-to user obtains a "history" of who sent the email to whom and at what time 3. Traditional telephony based call redirection services such as Voicemail, call-center "automatic call distribution", and "follow-me" style services. Several of the aforementioned applications, and specifically those applications based on email or WWW, define application specific mechanisms through which it is possible to obtain the necessary history information. In order to prevent differing proprietary mechanisms emerging to obtain the required "request history" information, it is proposed that the SIPPING WG evaluate the requirements and determine a generic mechanism for the transport of such "request history" information. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3. "Request History" Requirements The following list constitutes a set of requirements for a "Request History" capability. It is anticipated that some of these requirements can be met using existing elements within SIP; whether and what SIP extensions would be needed to meet these requirements is out of scope of this draft. 1) CAPABILITY-req: The "Request History" capability will provide a capability to inform proxies and UAs involved in processing a request about the history/progress of that request. While this is inherently provided when the retarget is in response to a SIP redirect, it is deemed useful for non-redirect retargeting scenarios, as well. 2) OPTIONALITY-req: The "Request History" information is optional. 2.1) In many cases, it is anticipated that whether the history is added to the Request would be a local policy decision enforced by the specific application, thus no specific protocol element is needed. 2.2) Due to the capability being "optional" from the SIP protocol perspective, the impact to an application of not having the Watson Expires - February 2003 [Page 3] SIP Generic Request History Capability - Requirements August 2002 "Request History" must be described. Applicability guidelines to be addressed by applications using this capability must be provided as part of the solution to these requirements. 3) GENERATION-req: "Request History" information is generated when the request is retargeted. 3.1) In some scenarios, it might be possible for more than one instance of retargeting to occur within the same Proxy. A proxy should also generate Request History information for the 'internal retargeting'. 3.2) An entity (UA or proxy) retargeting in response to a redirect or REFER should include any Request History information from the redirect/REFER in the new request. 4) ISSUER-req: "Request History" information can be generated by a UA, proxy or redirect server. It can be passed in both requests and responses. 5) CONTENT-req: The "Request History" information for each occurrence of retargeting, shall include the following: 5.1) The new URI or address to which the request is in the process of being retargeted, 5.2) The URI or address from which the request was retargeted, 5.3) The reason for the Request-URI modification. The reason for the retargeting is only known to the application performing the retargeting. However, a set of commonly required reasons should be defined, 5.4) Chronological ordering of the Request History information. 6) REQUEST-VALIDITY-req: Request-History is applicable to requests not sent within an established dialog. (i.e. INVITE, REGISTER, MESSAGE, and OPTIONS). 7) BACKWARDS-req: Request-History information may be passed from the generating entity backwards towards the UAC. This is needed to enable services that inform the calling party about the dialog establishment attempts. Watson Expires - February 2003 [Page 4] SIP Generic Request History Capability - Requirements August 2002 8) FORWARDS-req: Request-History information may also be included by the generating entity in the request, if it is forwarded onwards. 4. Security Considerations The Request History information is being inserted by a network element retargeting a Request, resulting in a slightly different problem than the basic SIP header problem, thus requiring specific consideration. In addition, there may be privacy implications associated with some of the Request History information. The potential security problems introduced include the following: 1) A rogue application could insert a bogus Request History entry either by adding an additional entry as a result of retargeting or entering invalid information. 2) Loss of privacy associated with forwarding a specific Request URI in the Request History. 3) A rogue application could re-arrange the Request History information to change the nature of the end application or to mislead the receiver of the information. Thus, any solution to "Request History" capability must meet the following requirements: 1) SEC-req-1: The entity receiving the Request History must be able to determine whether any of the previously added Request History content has been altered. 2) SEC-req-2: The ordering of the Request History information must be preserved at each instance of retargeting. 3) SEC-req-3: The entity receiving the information conveyed by the Request History must be able to authenticate the source of the information. It is likely that the solutions to several of the requirements are inter-related. For example, with the requirement for Chronological ordering [Requirement 5.4 in section 3], it is likely that the solution to SEC-req-1 would also meet SEC-req-2. It should also be noted that these requirements apply to any entity making use of the Request History information, either by retargeting and capturing the information, or as an application making use of the information in a Request or Response. However, to ensure the overall integrity of this information as it traverses Watson Expires - February 2003 [Page 5] SIP Generic Request History Capability - Requirements August 2002 the network, an additional requirement with regards to the security of the transport is introduced: 4) SEC-req-4: To ensure the overall integrity of the chain of Request History information, the transport must be secure. In addition, there are general privacy requirements that MUST be met: 5) PRIV-req-1: The entity retargeting the Request must ensure that it maintains the privacy (as described in [2]) associated with the original Request URI which is retargeted. 6) PRIV-req-2: The entity receiving the Request History must maintain the privacy associated with the information. It is recognized that meeting the privacy requirements can impact the functionality of this solution by overriding the request to generate the information. The applicability guidelines for a solution must clearly address this impact. 5. IANA Considerations This document does not have any implications for IANA. 6. References [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261, June, 2002. [2] J. Peterson, "SIP Privacy", draft-ietf-sip-privacy-general- 01.txt, June, 2002. 7. Contributors Robert Sparks contributed excellent feedback and direction for the Security considerations section of this document. In addition, he highlighted the importance of addressing the optionality aspects of the "Request History" capability. 8. Acknowledgments The authors would like to thank Chris Hogg for serving as the editor for the initial (-00) version of this draft. In addition, Sanjoy Sen and Ben Campbell provided useful comments and suggestions related to this draft. Watson Expires - February 2003 [Page 6] SIP Generic Request History Capability - Requirements August 2002 AuthorsÆ Addresses Mark Watson Nortel Networks (UK) Maidenhead Office Park (Bray House) Westacott Way Maidenhead, Berkshire Tel: +44 (0)1628-434456 England Email: mwatson@nortelnetworks.com Mary Barnes Nortel Networks Tel: +1 972-684-5432 Richardson, Texas Email: mbarnes@nortelnetworks.com Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 Email: Jon.Peterson@NeuStar.com Cullen Jennings Cisco Systems 170 West Tasman Dr Tel: +1 408 527 9132 MS: SJC-21/3 Email: fluffy@cisco.com Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Watson Expires - February 2003 [Page 7] SIP Generic Request History Capability - Requirements August 2002 9. Appendix A - Scenarios This section highlights some scenarios under which the Request History Capability could be applicable. Certainly, various other solutions can be applied in some fashion to each of these scenarios. However, the objective of this draft has been to abstract the requirements from these scenarios towards providing a more robust solution for each and at the same time providing fundamental building block(s) applicable to future applications. 9.1. Sequentially forking with Retargeting This scenario is as follows: UA 1 sends a call to proxy 1. Proxy 1 sequentially tries several places (UA2, UA3 and UA4) before retargeting the call to Proxy 2. Proxy 2 unfortunately tries several of the same places (UA3 and UA4), before completing at UA5. UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | | | | | | | | |--INVITE -------->| | | | |<--100 -----| | | | | | | |<-302 ------------| | | | | | | | | | | | |-------INVITE ------------>| | | | | | | | | | | |<-------180 ---------------| | | |<---180 ----| | | | | | | . . |-------INVITE------------->| | | | | timeout | | | | | | | | | | | | |------INVITE ---------------------->| | |<--100 -----| | | | | | | |<-302 ------------------------------| | | | | | | | | | |-INVITE->| | | | | | | | | | | | | | |---INVITE ------>| | | Watson Expires - February 2003 [Page 8] SIP Generic Request History Capability - Requirements August 2002 | | | | | | | | | |<---180----------| | | |<---180 --------------| | | | | | | | | | | | | . . | |----INVITE------>| | | | | | timeout | | | | | | | | | | | | |------INVITE ------------>| | |<--100 ---------------| | | | | | | |<-302 --------------------| | | | | | | | | | | |------INVITE --------------------->| | | | | | | | | | |<-----200 OK---------------------->| |<--200 OK-------------| | | | | | | | | | | | |--ACK --------------------------------------------------->| | | | | | | | This scenario is provided to show the duplication of messaging when there isnÆt sufficient knowledge to optimize a sequential attempt at reaching an end user. With the "Request History" capability, this flow could be optimized as follows: UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | | | | | | | | |--INVITE -------->| | | | |<--100 -----| | | | | | | |<-302 ------------| | | | | | | | | | | | |-------INVITE ------------>| | | | | | | | | | | |<-------180 ---------------| | | |<---180 ----| | | | | | | . . |-------INVITE------------->| | | | | timeout | | | | | | | | | | | | |------INVITE ---------------------->| | |<--100 -----| | | | | | | |<-302 ------------------------------| | | | | | | | | | |-INVITE->| | | | | | | | | | | | | | | | | | | | | |------INVITE --------------------->| Watson Expires - February 2003 [Page 9] SIP Generic Request History Capability - Requirements August 2002 | | | | | | | | | |<-----200 OK---------------------->| |<--200 OK-------------| | | | | | | | | | | | |--ACK --------------------------------------------------->| | | | | | | | 9.2. Voicemail This scenario is as follows: UA 1 called UA A which had been forwarded to UA B which forwarded to a UA VM (voicemail server) which needs information (e.g. reason the call was retargeted, original Request URI) to make a policy decision about what mailbox to use, which greeting to play etc. This scenario shows that something like the "Request History" capability must be used for this service to function. UA1 Proxy UA-A UA-B UA-VM | | | | | |--INVITE ---->| | | | | | | | | | |--INVITE ---->| | | |<--100 -------| | | | | |<-302 --------| | | | | | | | | |--------INVITE ------------>| | | | | | | | |<--------180 ---------------| | |<---180 ------| | | | | . . . |--------INVITE------------->| | | | timeout | | | | | | | | |-------INVITE ------------------------>| | | | | | | |<-200 ---------------------------------| | | | | | |<-200---------| | | | | | | | | |--ACK ----------------------------------------------->| | | | | | | | | | | Watson Expires - February 2003 [Page 10] SIP Generic Request History Capability - Requirements August 2002 Certainly, another valid scenario for the support of voicemail would be that this 'policy decision' on which mailbox to use (etc.) is made by the UA which forwarded to voicemail (UA B), or by the Proxy which performed the forwarding on behalf of B. In this case, the UA or Proxy can put all the information that the Voicemail server needs to identity the correct mailbox, etc., into the Request-URI. This fits with the SIP service paradigm where the Request-URI identifies the resource (namely, the particular mailbox/greeting etc.) that is required. However, whilst this model is certainly applicable and required in SIP, it places service intelligence away from the system providing the key aspect of the service (the VM server). The proposal in this draft is to rely on generic information-providing capabilities in the UA/Proxy, allowing the Voicemail system to provide more and better voicemail-related services without relying on specific capabilities in the UA/Proxy. This would allow voicemail service providers to innovate independently of the particular UA/Proxy that their customers are using, and its capabilities. Presently, with the information loss problem, VM service providers, and any other similar service providers, are limited in the services they can provide because they do not have complete information about how the call reached them. They rely on the UA/proxy of their customers having the necessary capabilities to formulate a Request-URI identifying exactly what should happen next. Finally, there is obviously a desire to use existing voicemail platforms based on PSTN/ISDN technology, which operate according to the paradigm in this example. Watson Expires - February 2003 [Page 11]