SIPPING Working Group Mark Watson Internet Draft Chris Hogg Mary Barnes Nortel Networks Cullen Jennings Cisco Jon Peterson Category: Informational NeuStar Expires August 2002 February 2002 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. Watson [Page 1] Internet Draft SIP Generic Request History February 2002 This draft discusses the motivations in support of a mechanism which records the ôrequest historyö and proposes detailed requirements for such a generic "request history" capability. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Conventions used in this document..............................2 2 Introduction: Why define a Generic "Request History" capability? 2 3 "Request History" Requirements.................................3 4 Going forward..................................................5 5 Security Considerations........................................5 6 IANA Considerations............................................5 7 References.....................................................6 8 Acknowledgments................................................6 9 AuthorsÆ Addresses.............................................6 10 Full Copyright Statement.....................................7 1 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. 2 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 applicable to retargeting as discussed 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 Watson Expires August, 2002 [Page 2] Internet Draft SIP Generic Request History February 2002 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 exchange additional information relating to how and why the call was routed to a particular destination. The following are examples of such applications: - 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, - Email forwarding whereby the forwarded-to user obtains a "history" of who sent the email to whom and at what time - 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. 6 "Request History" Requirements The following list constitutes a set of requirements for a "Request History" capability. Note that some of these requirements may 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. The requirements have been enumerated and tagged to facilitate reference to each requirement: 1) CAPABILITY-req: The "Request History" capability will provide a capability to inform proxies and UA s 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) GENERATION-req: "Request History" information is generated when the Request-URI is modified or when a new Request-URI is supplied for the request [see NOTE 1]. Watson Expires August, 2002 [Page 3] Internet Draft SIP Generic Request History February 2002 3) ISSUER-req: "Request History" information can be generated by a UA, proxy or redirect server. It can be passed in both requests and responses. 4) CONTENT-req: The "Request History" information for each occurrence of retargeting, shall include some or all of the following: 4.1) The new URI or address to which the request is in the process of being retargeted 4.2) The URI or address from which the request was retargeted. 4.3) The identity of the entity which modified the Request-URI or the identity of the user on whose behalf this modification was carried out (e.g. by CPL script), or both. 4.4) The reason for the Request-URI modification [See NOTE 2]. 4.5) Chronological ordering of the Request History information. This could be in the form of a counter to track the number of times the request history has been updated, thus allowing for the detection of retarget loops between the SIP network and the PSTN. 5) REQUEST-VALIDITY-req: Request-History is applicable to requests not sent within an established dialog. (i.e. INVITE, REGISTER, MESSAGE, and OPTIONS). 6) BACKWARDS-req: Request-History information may be passed from the generating entity backwards towards the UAC. This is needed to enable services which inform the calling party about the dialog establishment attempts. 7) FORWARDS-req: Request-History information may also be included by the generating entity in the request, if it is forwarded onwards. 8) REDIRECT-RESP-req: An entity (UA or proxy) retargeting in response to a redirect or REFER shall include any Request History information from the redirect/REFER in the new request. 9) COMPLETENESS-req: It shall be possible for an entity receiving Request History information to determine whether the information may be incomplete û i.e. to determine whether there may have been retargeting which did not result in Request History being recorded. NOTE 1: A key issue is what constitutes "modification" of the Request-URI in this context. We have two options for this problem: Watson Expires August, 2002 [Page 4] Internet Draft SIP Generic Request History February 2002 (a) Agree a clear definition of what type of modifications to the Request-URI should trigger Request History and which do not. A clear definition could be based on URI equivalency based on the URI comparison rules as define in [1]. (b) Specify that this is a matter for the application which is re- writing the Request-URI. Option (b) may be preferred in that it does provide more flexibility to the applications which are making use of the generic mechanism. NOTE 2: The reason for the modification of the Request-URI is only known to the application performing the modification. However it does make sense to define a set of reasons which will be commonly required. It is proposed that [8] provides a reasonable starting point for the definition for the set of reasons. 7 Going forward The authors request that the SIPPING WG study this contribution and come to consensus regarding the set of requirements necessary for a Generic Request History mechanism. It is further suggested that a suitable starting point for further work thereafter would be to analyze the various mechanisms proposed for this problem domain [2][3][4][5] [6] and [7] and determine the extent to which these meet the agreed requirements. Such an analysis would thus provide suitable grounds for determining what extensions (if any) are necessary to SIP in order to support the agreed requirements. 8 Security Considerations These requirements do not introduce any new Privacy or integrity requirements for SIP. However, since the Request History information is being inserted by an element in the network which is retargeting, it may be a slightly different problem than the basic SIP header problem, thus specific consideration may be needed. Security should be re-evaluated once a stable solution proposal based on these requirements is put forth. 9 IANA Considerations This document does not have any implications for IANA. Watson Expires August, 2002 [Page 5] Internet Draft SIP Generic Request History February 2002 10 References [1] J. Rosenberg et al, ôSIP: Session initiation protocol," draft- ietf-sip-rfc2543bis-08.txt, February 21st, 2002. [2] B. Campbell, R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001. [3] S. Levy, B. Byerly, J. Yang, "Diversion Indication in SIP", draft-levy-sip-diversion-03.txt, November, 2001. [4] W. Marshall et al, "SIP Extensions for Caller Identity and Privacy", draft-ietf-sip-privacy-03.txt, November 21st, 2001. [5] D. Willis, B. Rosen, "SIP Cookies", draft-willis-sip-cookies- 00.txt,July, 2001. [6] W. Marshall et al,"SIP Extensions for supporting distributed call state", draft-ietf-sip-state-02.txt, August, 2001. [7] D. Oran, H. Schulzrinne, ôSIP extension for tracking locations attemptedö, oran-sip-visited-00.txt, August 6, 2000. [8] H. Schulzrinne, D. Oran, G. Camarillo, ôThe Reason Header Field for the Session Initiation Protocolö, draft-schulzrinne-sip-reason- th 00.txt, December 17 , 2001. 11 Acknowledgments The authors would like to thank Sanjoy Sen for his useful comments and suggestions related to this draft. 12 AuthorsÆ Addresses Chris Hogg Nortel Networks (UK) Maidenhead Office Park (Bray House) Westacott Way Maidenhead, Berkshire England Tel: +44 (0)1628-431720 email: chogg@nortelnetworks.com Mark Watson Nortel Networks (UK) Maidenhead Office Park (Bray House) Westacott Way Maidenhead, Berkshire England Watson Expires August, 2002 [Page 6] Internet Draft SIP Generic Request History February 2002 Tel: +44 (0)1628-434456 email: mwatson@nortelnetworks.com Mary Barnes Nortel Networks Richardson, Texas Tel: +1 972-684-5432 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, MS: SJC-21/3 Tel: +1 408 527 9132 Email: fluffy@cisco.com 13 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 August, 2002 [Page 7]