draft-ietf-sipping-req-history-03.txt   draft-ietf-sipping-req-history-04.txt 
Internet Draft Mary Barnes,Editor Internet Draft Mary Barnes,Editor
Document: draft-ietf-sipping-req-history-03.txt Mark Watson Document: draft-ietf-sipping-req-history-04.txt Mark Watson
Nortel Networks Nortel Networks
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
Jon Peterson Jon Peterson
Category: Informational NeuStar, Inc. Category: Informational NeuStar, Inc.
Expires November 2003 May 2003 Expires December 2003 June 2003
SIP Generic Request History Capability Requirements SIP Generic Request History Capability Requirements
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
initiated to call centers via "click to talk" SIP URLs on a web page, initiated to call centers via "click to talk" SIP URLs on a web page,
"call history/logging" style services within intelligent "call "call history/logging" style services within intelligent "call
management" software for SIP UAs and calls to voicemail servers and management" software for SIP UAs and calls to voicemail servers and
call centers. While SIP implicitly provides the redirect/retarget call centers. While SIP implicitly provides the redirect/retarget
capabilities that enable calls to be routed to chosen applications, capabilities that enable calls to be routed to chosen applications,
there is currently no standard mechanism within SIP for communicating there is currently no standard mechanism within SIP for communicating
the history of such a request. This "request history" information the history of such a request. This "request history" information
allows the receiving application to determine hints about how and why allows the receiving application to determine hints about how and why
the call arrived at the application/user. the call arrived at the application/user.
SIP Generic Request History Capability - Requirements May 2003
This draft discusses the motivations in support of a mechanism for This draft discusses the motivations in support of a mechanism for
recording the "request history", and proposes detailed requirements recording the "request history", and proposes detailed requirements
for such a generic "request history" capability. for such a generic "request history" capability.
Table of Contents Table of Contents
1. Introduction: Why define a Generic "Request History" capability? 1. Introduction: Why define a Generic "Request History" capability?
2 2
2. Conventions used in this document...............................3 2. Conventions used in this document...............................3
3. "Request History" Requirements..................................3 3. "Request History" Requirements..................................3
skipping to change at page 3, line 4 skipping to change at page 3, line 4
information may be important history that allows elements to which information may be important history that allows elements to which
the call is retargeted to process the call in a locally defined, the call is retargeted to process the call in a locally defined,
application specific manner. The proposal in this draft is to provide application specific manner. The proposal in this draft is to provide
a mechanism for transporting the request history. It is not a mechanism for transporting the request history. It is not
proposing any behavior for a Proxy or UA upon receipt of the proposing any behavior for a Proxy or UA upon receipt of the
information. Indeed, such behavior should be a local decision for the information. Indeed, such behavior should be a local decision for the
recipient application. recipient application.
Current network applications provide the ability for elements Current network applications provide the ability for elements
involved with the call to exchange additional information relating to involved with the call to exchange additional information relating to
SIP Generic Request History Capability - Requirements May 2003
how and why the call was routed to a particular destination. The how and why the call was routed to a particular destination. The
following are examples of such applications: following are examples of such applications:
1. Web "referral" applications, whereby an application residing 1. Web "referral" applications, whereby an application residing
within a web server determines that a visitor to a website has within a web server determines that a visitor to a website has
arrived at the site via an "associate" site which will receive arrived at the site via an "associate" site which will receive
some "referral" commission for generating this traffic, some "referral" commission for generating this traffic,
2. Email forwarding whereby the forwarded-to user obtains a "history" 2. Email forwarding whereby the forwarded-to user obtains a "history"
of who sent the email to whom and at what time of who sent the email to whom and at what time
skipping to change at page 4, line 4 skipping to change at page 4, line 4
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119. document are to be interpreted as described in RFC-2119.
3. "Request History" Requirements 3. "Request History" Requirements
The following list constitutes a set of requirements for a "Request The following list constitutes a set of requirements for a "Request
History" capability. It is anticipated that some of these History" capability. It is anticipated that some of these
SIP Generic Request History Capability - Requirements May 2003
requirements can be met using existing elements within SIP; whether requirements can be met using existing elements within SIP; whether
and what SIP extensions would be needed to meet these requirements is and what SIP extensions would be needed to meet these requirements is
out of scope of this draft. out of scope of this draft.
1) CAPABILITY-req: The "Request History" capability will provide a 1) CAPABILITY-req: The "Request History" capability will provide a
capability to inform proxies and UAs involved in processing a request capability to inform proxies and UAs involved in processing a request
about the history/progress of that request. While this is inherently about the history/progress of that request. While this is inherently
provided when the retarget is in response to a SIP redirect, it is provided when the retarget is in response to a SIP redirect, it is
deemed useful for non-redirect retargeting scenarios, as well. deemed useful for non-redirect retargeting scenarios, as well.
skipping to change at page 5, line 4 skipping to change at page 5, line 4
UA, proxy or redirect server. It can be passed in both requests and UA, proxy or redirect server. It can be passed in both requests and
responses. responses.
5) CONTENT-req: The "Request History" information for each 5) CONTENT-req: The "Request History" information for each
occurrence of retargeting, shall include the following: occurrence of retargeting, shall include the following:
5.1) The new URI or address to which the request is in the process 5.1) The new URI or address to which the request is in the process
of being retargeted, of being retargeted,
5.2) The URI or address from which the request was retargeted, 5.2) The URI or address from which the request was retargeted,
SIP Generic Request History Capability - Requirements May 2003
5.3) The reason for the Request-URI modification, 5.3) The reason for the Request-URI modification,
5.4) Chronological ordering of the Request History information. 5.4) Chronological ordering of the Request History information.
6) REQUEST-VALIDITY-req: Request-History is applicable to requests 6) REQUEST-VALIDITY-req: Request-History is applicable to requests
not sent within an established dialog. (i.e. INVITE, REGISTER, not sent within an established dialog. (i.e. INVITE, REGISTER,
MESSAGE, and OPTIONS). MESSAGE, and OPTIONS).
7) BACKWARDS-req: Request-History information may be passed from the 7) BACKWARDS-req: Request-History information may be passed from the
generating entity backwards towards the UAC. This is needed to enable generating entity backwards towards the UAC. This is needed to enable
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Thus, a security solution for "Request History" must meet the Thus, a security solution for "Request History" must meet the
following requirements: following requirements:
1) SEC-req-1: The entity receiving the Request History must be able 1) SEC-req-1: The entity receiving the Request History must be able
to determine whether any of the previously added Request History to determine whether any of the previously added Request History
content has been altered. content has been altered.
2) SEC-req-2: The ordering of the Request History information must be 2) SEC-req-2: The ordering of the Request History information must be
preserved at each instance of retargeting. preserved at each instance of retargeting.
SIP Generic Request History Capability - Requirements May 2003
3) SEC-req-3: The entity receiving the information conveyed by the 3) SEC-req-3: The entity receiving the information conveyed by the
Request History must be able to authenticate the source of the Request History must be able to authenticate the source of the
information. information.
4) SEC-req-4: To ensure the confidentiality of the Request History 4) SEC-req-4: To ensure the confidentiality of the Request History
information, only entities which process the request should have information, only entities which process the request should have
visibility to the information. visibility to the information.
It should be noted that these security requirements apply to any It should be noted that these security requirements apply to any
entity making use of the Request History information, either by entity making use of the Request History information, either by
skipping to change at page 7, line 5 skipping to change at page 7, line 5
This document does not have any implications for IANA. This document does not have any implications for IANA.
7. References 7. References
[1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261, [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261,
June, 2002. June, 2002.
[2] J. Peterson, "A Privacy Mechanism for the Session Initiation [2] J. Peterson, "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November, 2002. Protocol (SIP)", RFC 3323, November, 2002.
SIP Generic Request History Capability - Requirements May 2003
8. Contributors 8. Contributors
Robert Sparks contributed excellent feedback and direction for the Robert Sparks contributed excellent feedback and direction for the
Security considerations section of this document. In addition, he Security considerations section of this document. In addition, he
highlighted the importance of addressing the optionality aspects of highlighted the importance of addressing the optionality aspects of
the "Request History" capability. the "Request History" capability.
9. Acknowledgments 9. Acknowledgments
The editor would like to thank Sanjoy Sen, Ben Campbell, Rohan The editor would like to thank Sanjoy Sen, Ben Campbell, Rohan
skipping to change at page 8, line 5 skipping to change at page 8, line 5
MS: SJC-21/3 MS: SJC-21/3
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408-527-9132 Phone: +1 408-527-9132
EMail: fluffy@cisco.com EMail: fluffy@cisco.com
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
SIP Generic Request History Capability - Requirements May 2003
1800 Sutter Street, Suite 570 1800 Sutter Street, Suite 570
Concord, CA 94520 Concord, CA 94520
USA USA
Phone: +1 925-363-8720 Phone: +1 925-363-8720
EMail: Jon.Peterson@NeuStar.biz EMail: Jon.Peterson@NeuStar.biz
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
skipping to change at page 9, line 5 skipping to change at page 9, line 5
This section highlights some scenarios under which the Request This section highlights some scenarios under which the Request
History Capability could be applicable. History Capability could be applicable.
Certainly, various other solutions can be applied in some fashion Certainly, various other solutions can be applied in some fashion
to each of these scenarios. However, the objective of this draft to each of these scenarios. However, the objective of this draft
has been to abstract the requirements from these scenarios towards has been to abstract the requirements from these scenarios towards
providing a more robust solution for each and at the same time providing a more robust solution for each and at the same time
providing fundamental building block(s) applicable to future providing fundamental building block(s) applicable to future
applications. applications.
SIP Generic Request History Capability - Requirements May 2003
10.1 Sequentially forking with Retargeting 10.1 Sequentially forking with Retargeting
This scenario is as follows: This scenario is as follows:
UA 1 sends a call to proxy 1. Proxy 1 sequentially tries several 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. places (UA2, UA3 and UA4) before retargeting the call to Proxy 2.
Proxy 2 unfortunately tries several of the same places (UA3 and Proxy 2 unfortunately tries several of the same places (UA3 and
UA4), before completing at UA5. UA4), before completing at UA5.
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
skipping to change at page 10, line 4 skipping to change at page 10, line 4
| | | timeout | | | | | | timeout | | |
| | | | | | | | | | | | | |
| | |------INVITE ------------>| | | | |------INVITE ------------>| |
|<--100 ---------------| | | | | |<--100 ---------------| | | | |
| | |<-302 --------------------| | | | |<-302 --------------------| |
| | | | | | | | | | | | | |
| | |------INVITE --------------------->| | | |------INVITE --------------------->|
| | | | | | | | | | | | | |
| | |<-----200 OK---------------------->| | | |<-----200 OK---------------------->|
|<--200 OK-------------| | | | | |<--200 OK-------------| | | | |
SIP Generic Request History Capability - Requirements May 2003
| | | | | | | | | | | | | |
|--ACK --------------------------------------------------->| |--ACK --------------------------------------------------->|
| | | | | | | | | | | | | |
This scenario is provided to show the duplication of messaging when This scenario is provided to show the duplication of messaging when
there isn't sufficient knowledge to optimize a sequential attempt there isn't sufficient knowledge to optimize a sequential attempt
at reaching an end user. With the "Request History" capability, at reaching an end user. With the "Request History" capability,
this flow could be optimized as follows: this flow could be optimized as follows:
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
skipping to change at page 10, line 48 skipping to change at page 10, line 45
| | | | | | | | | | | | | |
| | |------INVITE --------------------->| | | |------INVITE --------------------->|
| | | | | | | | | | | | | |
| | |<-----200 OK---------------------->| | | |<-----200 OK---------------------->|
|<--200 OK-------------| | | | | |<--200 OK-------------| | | | |
| | | | | | | | | | | | | |
|--ACK --------------------------------------------------->| |--ACK --------------------------------------------------->|
| | | | | | | | | | | | | |
10.2 Voicemail 10.2 Voicemail
This scenario highlights an example where the request history
information is primarily of use by an edge service (e.g. Voicemail
Server). It should be noted that this isn't intended to be a
complete specification for this specific edge service as it is
quite likely that additional information is needed by the edge
service.
This scenario is as follows: This scenario is as follows:
SIP Generic Request History Capability - Requirements May 2003
UA 1 called UA A which had been forwarded to UA B which forwarded 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. to a UA VM (voicemail server) which needs information (e.g.
reason the call was retargeted, original Request URI) to make a reason the call was retargeted, original Request URI) to make a
policy decision about what mailbox to use, which greeting to play policy decision about what mailbox to use, which greeting to play
etc. This scenario shows that something like the "Request etc. This scenario shows that something like the "Request
History" capability must be used for this service to function. History" capability must be used for this service to function.
UA1 Proxy UA-A UA-B UA-VM UA1 Proxy UA-A UA-B UA-VM
| | | | | | | | | |
skipping to change at page 11, line 40 skipping to change at page 11, line 42
| |-------INVITE ------------------------>| | |-------INVITE ------------------------>|
| | | | | | | | | |
| |<-200 ---------------------------------| | |<-200 ---------------------------------|
| | | | | | | | | |
|<-200---------| | | | |<-200---------| | | |
| | | | | | | | | |
|--ACK ----------------------------------------------->| |--ACK ----------------------------------------------->|
| | | | | | | | | |
| | | | | | | | | |
Certainly, another valid scenario for the support of voicemail would This scenario is specifically highlighting a case whereby the desired
be that this 'policy decision' on which mailbox to use (etc.) is made functionality (e.g. via local policy) is for a call which is not
by the UA which forwarded to voicemail (UA B), or by the Proxy which answered (or undeliverable for other reasons) to revert to the
performed the forwarding on behalf of B. In this case, the UA or Proxy voicemail server of UA A. Additional scenarios are certainly valid
can put all the information that the Voicemail server needs to whereby the call is routed to the voicemail server of UA B, thus NOT
identity the correct mailbox, etc., into the Request-URI. This fits necessarily requiring history information to process the request. This
with the SIP service paradigm where the Request-URI identifies the latter situation further highlights that the use of the request
resource (namely, the particular mailbox/greeting etc.) that is history information is not prescriptive for any particular service.
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).
SIP Generic Request History Capability - Requirements May 2003
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.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/