draft-ietf-sipping-req-history-01.txt   draft-ietf-sipping-req-history-02.txt 
Internet Draft Mary Barnes,Editor Internet Draft Mary Barnes,Editor
Document: draft-ietf-sipping-req-history-01.txt Mark Watson Document: draft-ietf-sipping-req-history-02.txt Mark Watson
Nortel Networks Nortel Networks
Cullen Jennings Cullen Jennings
Cisco Cisco
Jon Peterson Jon Peterson
Category: Informational NeuStar Category: Informational NeuStar
Expires June 2003 December 2002 Expires August 2003 February 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 all
provisions of Section 10 of RFC2026. 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 Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at line 51 skipping to change at line 51
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.
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 - June 2003 [Page 1] Barnes Expires - August 2003 [Page 1]
SIP Generic Request History Capability - Requirements December 2002 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...................................................6 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.................8
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
skipping to change at line 102 skipping to change at line 102
the recipient application. the 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 how and why the call was routed to a particular destination. to how and why the call was routed to a particular destination.
The following are examples of such applications: The 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
Barnes Expires - June 2003 [Page 2] Barnes Expires - August 2003 [Page 2]
SIP Generic Request History Capability - Requirements December 2002 SIP Generic Request History Capability - Requirements February 2003
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" of who sent the email to whom and at what time "history" 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.
skipping to change at line 134 skipping to change at line 134
proxy which captures the "request history" information in a proxy which captures the "request history" information in a
secure manner provides an additional means (without requiring secure manner provides an additional means (without requiring
signed keys) for the original requestor to be assured that the signed keys) for the original requestor to be assured that the
request was properly retargeted. request was 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 scenarios are provided in the appendix illustrating how a Example scenarios are provided in the appendix illustrating how a
SIP building block that provides request history information could SIP building block that provides request history information could
be used by some applications. It is not the intent, nor is it be used by some applications. It is not the intent, nor is it
within the scope, of this requirements draft to prescribe a within the scope, of this requirement's draft to prescribe a
complete solution for any of these applications. complete solution 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 document are to be interpreted as described in RFC-2119. this 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 requirements can be met using existing elements within SIP; whether
and what SIP extensions would be needed to meet these requirements and what SIP extensions would be needed to meet these requirements
is out of scope of this draft. is out of scope of this draft.
Barnes Expires - June 2003 [Page 3] Barnes Expires - August 2003 [Page 3]
SIP Generic Request History Capability - Requirements December 2002 SIP Generic Request History Capability - Requirements February 2003
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 about the history/progress of that request. While this is request about the history/progress of that request. While this is
inherently provided when the retarget is in response to a SIP inherently provided when the retarget is in response to a SIP
redirect, it is deemed useful for non-redirect retargeting redirect, it is 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.
skipping to change at line 200 skipping to change at line 200
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 of being retargeted, process 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, 5.3) The reason for the Request-URI modification,
Barnes Expires - June 2003 [Page 4] Barnes Expires - August 2003 [Page 4]
SIP Generic Request History Capability - Requirements December 2002 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 generating entity backwards towards the UAC. This is needed to the generating entity backwards towards the UAC. This is needed to
enable services that inform the calling party about the dialog enable services that inform the calling party about the dialog
skipping to change at line 249 skipping to change at line 249
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 preserved at each instance of retargeting. be preserved at each instance of retargeting.
Barnes Expires - June 2003 [Page 5] Barnes Expires - August 2003 [Page 5]
SIP Generic Request History Capability - Requirements December 2002 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
skipping to change at line 278 skipping to change at line 278
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 maintains the network-provided privacy (as described in [2]) it 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 the privacy associated with the information. maintain the privacy associated with the information.
It is recognized that meeting the privacy requirements can impact In addition, local policy at a proxy may identify privacy
the functionality of this solution by overriding the request to requirements associated with Request History information. Request
generate the information. The applicability guidelines for a History information subject to privacy requirements shall not be
solution must clearly address this impact. included in outgoing messages unless it is protected as described
in [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, June, 2002. 3261, 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 February 2003
8. Contributors 8. Contributors
Robert Sparks contributed excellent feedback and direction for Robert Sparks contributed excellent feedback and direction for
the Security considerations section of this document. In the Security considerations section of this document. In
Barnes Expires - June 2003 [Page 6]
SIP Generic Request History Capability - Requirements December 2002
addition, he highlighted the importance of addressing the addition, he highlighted the importance of addressing the
optionality aspects of the "Request History" capability. optionality aspects of 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 and Jonathan Rosenberg for providing useful comments and Mahy, Jonathan Rosenberg and John Elwell for providing useful
suggestions related to this draft. comments and suggestions related to this draft.
Authors Addresses Authors' Addresses
Mark Watson Mark Watson
Nortel Networks (UK) Nortel Networks (UK)
Maidenhead Office Park (Bray House) Maidenhead Office Park (Bray House)
Westacott Way Westacott Way
Maidenhead, Maidenhead,
Berkshire Tel: +44 (0)1628-434456 Berkshire Tel: +44 (0)1628-434456
England Email: mwatson@nortelnetworks.com England Email: mwatson@nortelnetworks.com
Mary Barnes Mary Barnes
skipping to change at line 347 skipping to change at line 347
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). 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
Barnes Expires - June 2003 [Page 7]
SIP Generic Request History Capability - Requirements December 2002
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
WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE." FOR A PARTICULAR PURPOSE."
skipping to change at line 396 skipping to change at line 396
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 ----| | | | | |
Barnes Expires - June 2003 [Page 8]
SIP Generic Request History Capability - Requirements December 2002
| . . |-------INVITE------------->| | | | . . |-------INVITE------------->| | |
| | timeout | | | | | | timeout | | | |
| | | | | | | | | | | | | |
| |------INVITE ---------------------->| | | |------INVITE ---------------------->| |
|<--100 -----| | | | | | |<--100 -----| | | | | |
| |<-302 ------------------------------| | | |<-302 ------------------------------| |
| | | | | | | | | | | | | |
| |-INVITE->| | | | | | |-INVITE->| | | | |
| | | | | | | | | | | | | |
| | |---INVITE ------>| | | | | |---INVITE ------>| | |
skipping to change at line 434 skipping to change at line 434
| | | | | | | | | | | | | |
| | |------INVITE --------------------->| | | |------INVITE --------------------->|
| | | | | | | | | | | | | |
| | |<-----200 OK---------------------->| | | |<-----200 OK---------------------->|
|<--200 OK-------------| | | | | |<--200 OK-------------| | | | |
| | | | | | | | | | | | | |
|--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 isnt 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------------->| | |
Barnes Expires - June 2003 [Page 9]
SIP Generic Request History Capability - Requirements December 2002
| | timeout | | | | | | timeout | | | |
| | | | | | | | | | | | | |
| |------INVITE ---------------------->| | | |------INVITE ---------------------->| |
|<--100 -----| | | | | | |<--100 -----| | | | | |
| |<-302 ------------------------------| | | |<-302 ------------------------------| |
| | | | | | | | | | | | | |
| |-INVITE->| | | | | | |-INVITE->| | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | |------INVITE --------------------->| | | |------INVITE --------------------->|
skipping to change at line 498 skipping to change at line 498
| | | | | | | | | |
| |--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 ------------------------>|
| | | | | | | | | |
Barnes Expires - June 2003 [Page 10]
SIP Generic Request History Capability - Requirements December 2002
| |<-200 ---------------------------------| | |<-200 ---------------------------------|
| | | | | | | | | |
|<-200---------| | | | |<-200---------| | | |
| | | | | | | | | |
|--ACK ----------------------------------------------->| |--ACK ----------------------------------------------->|
| | | | | | | | | |
| | | | | | | | | |
Certainly, another valid scenario for the support of voicemail would Certainly, another valid scenario for the support of voicemail would
be that this 'policy decision' on which mailbox to use (etc.) is made be that this 'policy decision' on which mailbox to use (etc.) is made
skipping to change at line 543 skipping to change at line 543
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 - June 2003 [Page 11] 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/