draft-ietf-sipping-req-history-02.txt   draft-ietf-sipping-req-history-03.txt 
Internet Draft Mary Barnes,Editor Internet Draft Mary Barnes,Editor
Document: draft-ietf-sipping-req-history-02.txt Mark Watson Document: draft-ietf-sipping-req-history-03.txt Mark Watson
Nortel Networks Nortel Networks
Cullen Jennings Cullen Jennings
Cisco Cisco Systems
Jon Peterson Jon Peterson
Category: Informational NeuStar Category: Informational NeuStar, Inc.
Expires August 2003 February 2003 Expires November 2003 May 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 all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Many services that SIP is anticipated to support require the ability Many services that SIP is anticipated to support require the ability
to determine why and how the call arrived at a specific application. to determine why and how the call arrived at a specific application.
Examples of such services include (but are not limited to) sessions 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, 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.
Barnes Expires - August 2003 [Page 1]
SIP Generic Request History Capability - Requirements February 2003
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
4. Security Considerations........................................5 4. Security Considerations.........................................5
5. Privacy Considerations.........................................6 5. Privacy Considerations..........................................6
6. IANA Considerations............................................6 6. IANA Considerations.............................................6
7. References.....................................................6 7. References......................................................6
8. Contributors...................................................7 8. Contributors....................................................7
9. Acknowledgments................................................7 9. Acknowledgments.................................................7
10. Appendix A - Scenarios.........................................8 10. Appendix A - Scenarios..........................................8
10.1 Sequentially forking with Retargeting.................8 10.1 Sequentially forking with Retargeting..................9
10.2 Voicemail............................................10 10.2 Voicemail.............................................10
1.Introduction: Why define a Generic "Request History" capability? 1.Introduction: Why define a Generic "Request History" capability?
SIP implicitly provides redirect/retarget capabilities that enable SIP implicitly provides redirect/retarget capabilities that enable
calls to be routed to specific applications as defined in [1]. The 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 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 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 changing the target of the request. This term is chosen to avoid
associating this request history only with the specific SIP associating this request history only with the specific SIP Redirect
Redirect Server capability that provides for a response to be sent Server capability that provides for a response to be sent back to a
back to a UAC requesting that the UAC should retarget the original UAC requesting that the UAC should retarget the original request to
request to an alternate URI. The rules for determining request an alternate URI. The rules for determining request targets as
targets as described in section 16.5 of [1] are consistent with the described in section 16.5 of [1] are consistent with the use of the
use of the retarget term in this draft. retarget term in this draft.
The motivation for the request history is that in the process of The motivation for the request history is that in the process of
retargeting old routing information can be forever lost. This lost retargeting old routing information can be forever lost. This lost
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 application specific manner. The proposal in this draft is to provide
provide a mechanism for transporting the request history. It is a mechanism for transporting the request history. It is not
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 information. Indeed, such behavior should be a local decision for the
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 involved with the call to exchange additional information relating to
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 SIP Generic Request History Capability - Requirements May 2003
within a web server determines that a visitor to a website has
Barnes Expires - August 2003 [Page 2] how and why the call was routed to a particular destination. The
SIP Generic Request History Capability - Requirements February 2003 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 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 2. Email forwarding whereby the forwarded-to user obtains a "history"
"history" of who sent the email to whom and at what time of who sent the email to whom and at what time
3. Traditional telephony services such as Voicemail, call-center 3. Traditional telephony services such as Voicemail, call-center
"automatic call distribution", and "follow-me" style services. "automatic call distribution", and "follow-me" style services.
Several of the aforementioned applications define application Several of the aforementioned applications define application
specific mechanisms through which it is possible to obtain the specific mechanisms through which it is possible to obtain the
necessary history information. necessary history information.
In addition, request history information could be used to enhance In addition, request history information could be used to enhance
basic SIP functionality by providing: basic SIP functionality by providing:
4. Some diagnostic information for debugging SIP requests. 4. Some diagnostic information for debugging SIP requests.
5. A stronger security solution for SIP. A side effect is that each 5. A stronger security solution for SIP. A side effect is that each
proxy which captures the "request history" information in a proxy which captures the "request history" information in a secure
secure manner provides an additional means (without requiring manner provides an additional means (without requiring signed keys)
signed keys) for the original requestor to be assured that the for the original requestor to be assured that the request was
request was properly retargeted. properly retargeted.
This draft summarizes the requirements for defining a generic This draft summarizes the requirements for defining a generic
mechanism for the transport of request history information. mechanism for the transport of request history information. Example
Example scenarios are provided in the appendix illustrating how a scenarios are provided in the appendix illustrating how a SIP
SIP building block that provides request history information could building block that provides request history information could be
be used by some applications. It is not the intent, nor is it used by some applications. It is not the intent, nor is it within the
within the scope, of this requirement's draft to prescribe a scope, of this requirement's draft to prescribe a complete solution
complete solution for any of these applications. for any of these applications.
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
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.
Barnes Expires - August 2003 [Page 3] SIP Generic Request History Capability - Requirements May 2003
SIP Generic Request History Capability - Requirements February 2003
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 1) CAPABILITY-req: The "Request History" capability will provide a
capability to inform proxies and UAs involved in processing a capability to inform proxies and UAs involved in processing a request
request about the history/progress of that request. While this is about the history/progress of that request. While this is inherently
inherently provided when the retarget is in response to a SIP provided when the retarget is in response to a SIP redirect, it is
redirect, it is deemed useful for non-redirect retargeting deemed useful for non-redirect retargeting scenarios, as well.
scenarios, as well.
2) OPTIONALITY-req: The "Request History" information is optional. 2) OPTIONALITY-req: The "Request History" information is optional.
2.1) In many cases, it is anticipated that whether the history is 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 added to the Request would be a local policy decision enforced by the
the specific application, thus no specific protocol element is specific application, thus no specific protocol element is needed.
needed.
2.2) Due to the capability being "optional" from the SIP protocol 2.2) Due to the capability being "optional" from the SIP protocol
perspective, the impact to an application of not having the perspective, the impact to an application of not having the "Request
"Request History" must be described. Applicability guidelines to be History" must be described. Applicability guidelines to be addressed
addressed by applications using this capability must be provided as by applications using this capability must be provided as part of the
part of the solution to these requirements. solution to these requirements.
3) GENERATION-req: "Request History" information is generated when 3) GENERATION-req: "Request History" information is generated when
the request is retargeted. the request is retargeted.
3.1) In some scenarios, it might be possible for more than one 3.1) In some scenarios, it might be possible for more than one
instance of retargeting to occur within the same Proxy. A proxy instance of retargeting to occur within the same Proxy. A proxy
should also generate Request History information for the 'internal should also generate Request History information for the 'internal
retargeting'. retargeting'.
3.2) An entity (UA or proxy) retargeting in response to a redirect 3.2) An entity (UA or proxy) retargeting in response to a redirect or
or REFER should include any Request History information from the REFER should include any Request History information from the
redirect/REFER in the new request. redirect/REFER in the new request.
4) ISSUER-req: "Request History" information can be generated by a 4) ISSUER-req: "Request History" information can be generated by a
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 5.1) The new URI or address to which the request is in the process
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,
5.3) The reason for the Request-URI modification, SIP Generic Request History Capability - Requirements May 2003
Barnes Expires - August 2003 [Page 4] 5.3) The reason for the Request-URI modification,
SIP Generic Request History Capability - Requirements February 2003
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 7) BACKWARDS-req: Request-History information may be passed from the
the generating entity backwards towards the UAC. This is needed to generating entity backwards towards the UAC. This is needed to enable
enable services that inform the calling party about the dialog services that inform the calling party about the dialog establishment
establishment attempts. attempts.
8) FORWARDS-req: Request-History information may also be included 8) FORWARDS-req: Request-History information may also be included by
by the generating entity in the request, if it is forwarded the generating entity in the request, if it is forwarded onwards.
onwards.
4. Security Considerations 4. Security Considerations
The Request History information is being inserted by a network The Request History information is being inserted by a network
element retargeting a Request, resulting in a slightly different element retargeting a Request, resulting in a slightly different
problem than the basic SIP header problem, thus requiring specific problem than the basic SIP header problem, thus requiring specific
consideration. It is recognized that these security requirements consideration. It is recognized that these security requirements can
can be generalized to a basic requirement of being able to secure be generalized to a basic requirement of being able to secure
information that is inserted by proxies. information that is inserted by proxies.
The potential security problems include the following: The potential security problems include the following:
1) A rogue application could insert a bogus Request History entry 1) A rogue application could insert a bogus Request History entry
either by adding an additional entry as a result of retargeting or either by adding an additional entry as a result of retargeting or
entering invalid information. entering invalid information.
2) Loss of privacy associated with forwarding a specific Request 2) Loss of privacy associated with forwarding a specific Request URI
URI in the Request History. in the Request History.
3) A rogue application could re-arrange the Request History 3) A rogue application could re-arrange the Request History
information to change the nature of the end application or to information to change the nature of the end application or to mislead
mislead the receiver of the information. the receiver of the information.
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 2) SEC-req-2: The ordering of the Request History information must be
be preserved at each instance of retargeting. preserved at each instance of retargeting.
Barnes Expires - August 2003 [Page 5] SIP Generic Request History Capability - Requirements May 2003
SIP Generic Request History Capability - Requirements February 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
retargeting and capturing the information, or as an application retargeting and capturing the information, or as an application
making use of the information in a Request or Response. making use of the information in a Request or Response.
5.Privacy Considerations 5.Privacy Considerations
Since the Request URI that is captured could inadvertently reveal Since the Request URI that is captured could inadvertently reveal
information about the originator, there are general privacy information about the originator, there are general privacy
requirements that MUST be met: requirements that MUST be met:
1) PRIV-req-1: The entity retargeting the Request must ensure that 1) PRIV-req-1: The entity retargeting the Request must ensure that it
it maintains the network-provided privacy (as described in [2]) maintains the network-provided privacy (as described in [2])
associated with the Request as it is retargeted. associated with the Request as it is retargeted.
2) PRIV-req-2: The entity receiving the Request History must 2) PRIV-req-2: The entity receiving the Request History must maintain
maintain the privacy associated with the information. the privacy associated with the information.
In addition, local policy at a proxy may identify privacy In addition, local policy at a proxy may identify privacy
requirements associated with Request History information. Request requirements associated with Request History information. Request
History information subject to privacy requirements shall not be History information subject to privacy requirements shall not be
included in outgoing messages unless it is protected as described included in outgoing messages unless it is protected as described in
in [2]. [2].
6.IANA Considerations 6.IANA Considerations
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 [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261,
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.
Barnes Expires - August 2003 [Page 6] SIP Generic Request History Capability - Requirements May 2003
SIP Generic Request History Capability - Requirements February 2003
8. Contributors 8. Contributors
Robert Sparks contributed excellent feedback and direction for Robert Sparks contributed excellent feedback and direction for the
the Security considerations section of this document. In Security considerations section of this document. In addition, he
addition, he highlighted the importance of addressing the highlighted the importance of addressing the optionality aspects of
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
Mahy, Jonathan Rosenberg and John Elwell for providing useful Mahy, Jonathan Rosenberg and John Elwell for providing useful
comments and suggestions related to this draft. comments and suggestions related to this draft.
Authors' Addresses Authors' Addresses
Mary Barnes
Nortel Networks
2380 Performance Drive
Richardson, Texas 75082
USA
Phone: +1 972-684-5432
EMail: mbarnes@nortelnetworks.com
Mark Watson Mark Watson
Nortel Networks (UK) Nortel Networks
Maidenhead Office Park (Bray House) Maidenhead Office Park (Bray House)
Westacott Way Westacott Way
Maidenhead, Maidenhead, Berkshire
Berkshire Tel: +44 (0)1628-434456 England
England Email: mwatson@nortelnetworks.com
Mary Barnes Phone: +44 (0)1628-434456
Nortel Networks Tel: +1 972-684-5432 EMail: mwatson@nortelnetworks.com
Richardson, Texas Email: mbarnes@nortelnetworks.com
Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/3
San Jose, CA 95134
USA
Phone: +1 408-527-9132
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 Email: Jon.Peterson@NeuStar.com Concord, CA 94520
USA
Cullen Jennings Phone: +1 925-363-8720
Cisco Systems EMail: Jon.Peterson@NeuStar.biz
170 West Tasman Dr Tel: +1 408 527 9132
MS: SJC-21/3 Email: fluffy@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
Barnes Expires - August 2003 [Page 7]
SIP Generic Request History Capability - Requirements February 2003
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages must be followed, or as required to translate it into languages
other than English. The limited permissions granted above are other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY herein is provided on an "AS IS" basis and THE INTERNET SOCIETY
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
skipping to change at line 378 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
| | | | | | | | | | | | | |
|--INVITE -->| | | | | | |--INVITE -->| | | | | |
| | | | | | | | | | | | | |
| |--INVITE -------->| | | | | |--INVITE -------->| | | |
|<--100 -----| | | | | | |<--100 -----| | | | | |
| |<-302 ------------| | | | | |<-302 ------------| | | |
| | | | | | | | | | | | | |
Barnes Expires - August 2003 [Page 8]
SIP Generic Request History Capability - Requirements February 2003
| |-------INVITE ------------>| | | | |-------INVITE ------------>| | |
| | | | | | | | | | | | | |
| |<-------180 ---------------| | | | |<-------180 ---------------| | |
|<---180 ----| | | | | | |<---180 ----| | | | | |
| . . |-------INVITE------------->| | | | . . |-------INVITE------------->| | |
| | timeout | | | | | | timeout | | | |
| | | | | | | | | | | | | |
| |------INVITE ---------------------->| | | |------INVITE ---------------------->| |
|<--100 -----| | | | | | |<--100 -----| | | | | |
| |<-302 ------------------------------| | | |<-302 ------------------------------| |
skipping to change at line 429 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
| | | | | | | | | | | | | |
|--INVITE -->| | | | | | |--INVITE -->| | | | | |
| | | | | | | | | | | | | |
| |--INVITE -------->| | | | | |--INVITE -------->| | | |
|<--100 -----| | | | | | |<--100 -----| | | | | |
| |<-302 ------------| | | | | |<-302 ------------| | | |
| | | | | | | | | | | | | |
| |-------INVITE ------------>| | | | |-------INVITE ------------>| | |
Barnes Expires - August 2003 [Page 9]
SIP Generic Request History Capability - Requirements February 2003
| | | | | | | | | | | | | |
| |<-------180 ---------------| | | | |<-------180 ---------------| | |
|<---180 ----| | | | | | |<---180 ----| | | | | |
| . . |-------INVITE------------->| | | | . . |-------INVITE------------->| | |
| | timeout | | | | | | timeout | | | |
| | | | | | | | | | | | | |
| |------INVITE ---------------------->| | | |------INVITE ---------------------->| |
|<--100 -----| | | | | | |<--100 -----| | | | | |
| |<-302 ------------------------------| | | |<-302 ------------------------------| |
| | | | | | | | | | | | | |
skipping to change at line 477 skipping to change at page 11, line 5
| | |<-----200 OK---------------------->| | | |<-----200 OK---------------------->|
|<--200 OK-------------| | | | | |<--200 OK-------------| | | | |
| | | | | | | | | | | | | |
|--ACK --------------------------------------------------->| |--ACK --------------------------------------------------->|
| | | | | | | | | | | | | |
10.2 Voicemail 10.2 Voicemail
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 line 498 skipping to change at page 11, line 28
| | | | | | | | | |
| |--INVITE ---->| | | | |--INVITE ---->| | |
|<--100 -------| | | | |<--100 -------| | | |
| |<-302 --------| | | | |<-302 --------| | |
| | | | | | | | | |
| |--------INVITE ------------>| | | |--------INVITE ------------>| |
| | | | | | | | | |
| |<--------180 ---------------| | | |<--------180 ---------------| |
|<---180 ------| | | | |<---180 ------| | | |
| . . . |--------INVITE------------->| | | . . . |--------INVITE------------->| |
Barnes Expires - August 2003 [Page 10]
SIP Generic Request History Capability - Requirements February 2003
| | timeout | | | | timeout | |
| | | | | | | | | |
| |-------INVITE ------------------------>| | |-------INVITE ------------------------>|
| | | | | | | | | |
| |<-200 ---------------------------------| | |<-200 ---------------------------------|
| | | | | | | | | |
|<-200---------| | | | |<-200---------| | | |
| | | | | | | | | |
|--ACK ----------------------------------------------->| |--ACK ----------------------------------------------->|
| | | | | | | | | |
skipping to change at line 528 skipping to change at page 12, line 5
can put all the information that the Voicemail server needs to can put all the information that the Voicemail server needs to
identity the correct mailbox, etc., into the Request-URI. This fits identity the correct mailbox, etc., into the Request-URI. This fits
with the SIP service paradigm where the Request-URI identifies the with the SIP service paradigm where the Request-URI identifies the
resource (namely, the particular mailbox/greeting etc.) that is resource (namely, the particular mailbox/greeting etc.) that is
required. required.
However, whilst this model is certainly applicable and required in However, whilst this model is certainly applicable and required in
SIP, it places service intelligence away from the system providing the SIP, it places service intelligence away from the system providing the
key aspect of the service (the VM server). 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 The proposal in this draft is to rely on generic information-providing
capabilities in the UA/Proxy, allowing the Voicemail system to provide capabilities in the UA/Proxy, allowing the Voicemail system to provide
more and better voicemail-related services without relying on specific more and better voicemail-related services without relying on specific
capabilities in the UA/Proxy. This would allow voicemail service capabilities in the UA/Proxy. This would allow voicemail service
providers to innovate independently of the particular UA/Proxy that providers to innovate independently of the particular UA/Proxy that
their customers are using, and its capabilities. Presently, with the their customers are using, and its capabilities. Presently, with the
information loss problem, VM service providers, and any other similar information loss problem, VM service providers, and any other similar
service providers, are limited in the services they can provide service providers, are limited in the services they can provide
because they do not have complete information about how the call because they do not have complete information about how the call
reached them. They rely on the UA/proxy of their customers having the reached them. They rely on the UA/proxy of their customers having the
necessary capabilities to formulate a Request-URI identifying exactly necessary capabilities to formulate a Request-URI identifying exactly
what should happen next. Finally, there is obviously a desire to use what should happen next. Finally, there is obviously a desire to use
existing voicemail platforms based on PSTN/ISDN technology, which existing voicemail platforms based on PSTN/ISDN technology, which
operate according to the paradigm in this example. operate according to the paradigm in this example.
Barnes Expires - August 2003 [Page 11]
 End of changes. 

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