Internet Draft Mark Watson
Document: draft-watson-sipping-req-history-01.txt Mary Barnes
Nortel Networks
Cullen Jennings
Cisco
Jon Peterson
Category: Informational NeuStar
Expires October 2002 April 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 Expires - October 2002 [Page 1]
Generic Request History Capability - Requirements April 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
1. Introduction: Why define a Generic "Request History"
capability?......................................................2
2. Conventions used in this document.............................3
3. "Request History" Requirements................................3
4. Further Requirements Related Considerations...................4
4.1 Further considerations for capturing retargeting..........4
4.2 Reason for retargeting....................................5
4.3 Optionality of the ôRequest Historyö capability...........5
5. Going forward.................................................5
6. Security Considerations.......................................5
7. IANA Considerations...........................................6
8. Appendix A - Scenarios........................................7
8.1 Sequentially forking with Retargetting....................8
8.2 Voicemail.................................................9
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
Watson Expires - October 2002 [Page 2]
Generic Request History Capability - Requirements April 2002
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,
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. 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 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.
Watson Expires - October 2002 [Page 3]
Generic Request History Capability - Requirements April 2002
2) GENERATION-req: "Request History" information is generated when
the request is retargetted [see section 4.1 for further discussion
of this requirement].
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 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 reason for the Request-URI modification [See section 4.2
for further description of this requirement].
4.4) Chronological ordering of the Request History information.
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.
4. Further Requirements Related Considerations
This section of the document further addresses some concerns that
arise out of the Requirements specification in section 3.
4.1 Further considerations for capturing retargeting
Watson Expires - October 2002 [Page 4]
Generic Request History Capability - Requirements April 2002
The original request URI of a retargetted request SHOULD identify
the user, service or resource which performed the retargeting as
captured in requirement 4.2 in section 3. In some scenarios, it
might be possible for more than one instance of retargeting to
occur within the same Proxy. It is recommended that a proxy SHOULD
NOT 'internally retarget' a request to a different user, service or
resource on the same proxy, without generating Call History
information for the 'internal retargetting' as well.
4.2 Reason for retargeting
The reason for the retargetting is only known to the application
performing the retargeting. 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.
4.3 Optionality of the ôRequest Historyö capability
Requirement 2 in section 3 specifies that "Request History"
information is generated when the request is retargeted. The
optionality of the generation of the ôRequest Historyö must be
specified by the application using the generic mechanism. In many
cases, it is anticipated that whether the history is added to the
Request would be a local policy decision which is enforced by the
specific application, thus no specific protocol element is needed.
5. 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.
6. 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.
Watson Expires - October 2002 [Page 5]
Generic Request History Capability - Requirements April 2002
Security should be re-evaluated once a stable solution proposal
based on these requirements is put forth.
7.IANA Considerations
This document does not have any implications for IANA.
References
[1] J. Rosenberg et al, ôSIP: Session initiation protocol," draft-
ietf-sip-rfc2543bis-09.txt, February 27th, 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 th Privacy", draft-ietf-sip-privacy-04.txt, February 27 , 2002.
[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 01.txt, February, 28 , 2002.
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
provided useful comments and suggestions related to this draft.
AuthorsÆ Addresses
Mark Watson
Nortel Networks (UK)
Maidenhead Office Park (Bray House)
Westacott Way
Watson Expires - October 2002 [Page 6]
Generic Request History Capability - Requirements April 2002
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."
8. Appendix A - Scenarios
This section highlights some scenarios under which the Request
History Capability could be applicable.
Watson Expires - October 2002 [Page 7]
Generic Request History Capability - Requirements April 2002
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.
8.1 Sequentially forking with Retargetting
This scenario is as follows:
o UA 1 sends a call to proxy 1. Proxy 1 sequentially tries
several places (UA2, UA3 and UA4) before retargetting 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 ------>| | |
| | | | | | |
| | |<---180----------| | |
|<---180 --------------| | | | |
| | | | | | |
| . . | |----INVITE------>| | |
| | | timeout | | |
| | | | | | |
| | |------INVITE ------------>| |
Watson Expires - October 2002 [Page 8]
Generic Request History Capability - Requirements April 2002
|<--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.
8.2 Voicemail
This scenario is as follows:
o 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 retargetted) to make a
policy decision about what mailbox to use, which greeting to
play etc.
UA1 Proxy UA-A UA-B UA-VM
| | | | |
|--INVITE ---->| | | |
| | | | |
| |--INVITE ---->| | |
|<--100 -------| | | |
| |<-302 --------| | |
| | | | |
| |--------INVITE ------------>| |
| | | | |
| |<--------180 ---------------| |
|<---180 ------| | | |
| . . . |--------INVITE------------->| |
| | timeout | |
| | | | |
| |-------INVITE ------------------------>|
| | | | |
| |<-200 ---------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
Watson Expires - October 2002 [Page 9]
Generic Request History Capability - Requirements April 2002
|--ACK ----------------------------------------------->|
| | | | |
| | | | |
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 - October 2002 [Page 10]