draft-ietf-sipcore-rfc4244bis-04.txt   draft-ietf-sipcore-rfc4244bis-05.txt 
Network Working Group M. Barnes Network Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Obsoletes: 4244 (if approved) F. Audet Obsoletes: 4244 (if approved) F. Audet
Intended status: Standards Track Skype Intended status: Standards Track Skype
Expires: September 16, 2011 S. Schubert Expires: October 29, 2011 S. Schubert
NTT NTT
J. van Elburg J. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
March 15, 2011 April 27, 2011
An Extension to the Session Initiation Protocol (SIP) for Request An Extension to the Session Initiation Protocol (SIP) for Request
History Information History Information
draft-ietf-sipcore-rfc4244bis-04.txt draft-ietf-sipcore-rfc4244bis-05.txt
Abstract Abstract
This document defines a standard mechanism for capturing the history This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP) information associated with a Session Initiation Protocol (SIP)
request. This capability enables many enhanced services by providing request. This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific the information as to how and why a SIP request arrives at a specific
application or user. This document defines an optional SIP header application or user. This document defines an optional SIP header
field, History-Info, for capturing the history information in field, History-Info, for capturing the history information in
requests. The document also defines SIP header field parameters for requests. The document also defines SIP header field parameters for
the History-Info and Contact header fields to tag the method by which the History-Info and Contact header fields to tag the method by which
the target of a request is determined. In addition, this document the target of a request is determined. In addition, this document
defines a value for the Privacy header field specific to the History- defines a value for the Privacy header field specific to the History-
Info header field. Info header field. This document obsoletes RFC 4244.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 16, 2011. This Internet-Draft will expire on October 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. History-Info Header Field Protocol Structure . . . . . . . . . 7 5. History-Info Header Field Protocol Structure . . . . . . . . . 8
5.1. History-Info Header Field Example Scenario . . . . . . . . 9 5.1. History-Info Header Field Example Scenario . . . . . . . . 10
6. User Agent Handling of the History-Info Header Field . . . . . 12 6. User Agent Handling of the History-Info Header Field . . . . . 13
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 12 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 12 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13
7. Proxy/Intermediary Handling of History-Info Header Fields . . 12 7. Proxy/Intermediary Handling of History-Info Header Fields . . 13
8. Redirect Server Handling of History-Info Header Fields . . . . 13 8. Redirect Server Handling of History-Info Header Fields . . . . 14
9. Handling of History-Info Header Fields in Requests and 9. Handling of History-Info Header Fields in Requests and
Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Receiving a Request with History-Info . . . . . . . . . . 13 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14
9.2. Sending a Request with History-Info . . . . . . . . . . . 14 9.2. Sending a Request with History-Info . . . . . . . . . . . 15
9.3. Receiving a Response with History-Info . . . . . . . . . . 14 9.3. Receiving a Response with History-Info or Request
9.4. Sending History-Info in Responses . . . . . . . . . . . . 15 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Processing the History-Info Header Field . . . . . . . . . . . 15 9.4. Sending History-Info in Responses . . . . . . . . . . . . 16
10.1. Privacy in the History-Info Header Field . . . . . . . . . 15 10. Processing the History-Info Header Field . . . . . . . . . . . 16
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 16 10.1. Privacy in the History-Info Header Field . . . . . . . . . 17
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 17 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17
10.2. Reason in the History-info Header Field . . . . . . . . . 17 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18
10.3. Indexing in the History-Info Header Field . . . . . . . . 18 10.2. Reason in the History-info Header Field . . . . . . . . . 19
10.4. Mechanism for Target Determination in the History-Info 10.3. Indexing in the History-Info Header Field . . . . . . . . 19
Header Field . . . . . . . . . . . . . . . . . . . . . . . 19 10.4. Indicating the Mechanism by which the Target was
11. Application Considerations . . . . . . . . . . . . . . . . . . 20 Determined . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Application Considerations . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
13.1. Registration of New SIP History-Info Header Field . . . . 23 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13.2. Registration of "history" for SIP Privacy Header Field . . 23 13.1. Registration of New SIP History-Info Header Field . . . . 24
13.3. Registration of Header Field Parameters . . . . . . . . . 24 13.2. Registration of "history" for SIP Privacy Header Field . . 25
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 13.3. Registration of Header Field Parameters . . . . . . . . . 25
15. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 25 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Backwards compatibility . . . . . . . . . . . . . . . . . 26 15. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 26
16. Changes since last Version . . . . . . . . . . . . . . . . . . 26 15.1. Backwards compatibility . . . . . . . . . . . . . . . . . 28
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 16. Changes since last Version . . . . . . . . . . . . . . . . . . 28
17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
17.2. Informative References . . . . . . . . . . . . . . . . . . 33 17.1. Normative References . . . . . . . . . . . . . . . . . . . 34
Appendix A. Request History Requirements . . . . . . . . . . . . 33 17.2. Informative References . . . . . . . . . . . . . . . . . . 35
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 35 Appendix A. Request History Requirements . . . . . . . . . . . . 35
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 35 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 36
Appendix B. Example call flows . . . . . . . . . . . . . . . . . 36 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 37
B.1. Sequentially Forking (History-Info in Response) . . . . . 36 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 38
B.2. History-Info with Privacy Header Field . . . . . . . . . . 43 B.1. Sequentially Forking (History-Info in Response) . . . . . 38
B.3. Privacy for a Specific History-Info Entry . . . . . . . . 45 B.2. History-Info with Privacy Header Field . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 B.3. Privacy for a Specific History-Info Entry . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
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 a SIP requests arrived at a specific to determine why and how a SIP request arrived at a specific
application. Examples of such services include (but are not limited application. Examples of such services include (but are not limited
to) sessions initiated to call centers via "click to talk" SIP to) sessions initiated to call centers via "click to talk" SIP
Uniform Resource Locators (URLs) on a web page, "call history/ Uniform Resource Locators (URLs) on a web page, "call history/
logging" style services within intelligent "call management" software logging" style services within intelligent "call management" software
for SIP User Agents (UAs), and calls to voicemail servers. Although for SIP User Agents (UAs), and calls to voicemail servers. Although
SIP implicitly provides the retarget capabilities that enable SIP SIP implicitly provides the retarget capabilities that enable SIP
requests to be routed to chosen applications, there is a need for a requests to be routed to chosen applications, there is a need for a
standard mechanism within SIP for communicating the retargeting standard mechanism within SIP for communicating the retargeting
history of the requests. This "request history" information allows history of the requests. This "request history" information allows
the receiving application to determine hints about how and why the the receiving application to determine hints about how and why the
skipping to change at page 7, line 14 skipping to change at page 8, line 14
5. History-Info Header Field Protocol Structure 5. History-Info Header Field Protocol Structure
The History-info header field can appear in any request not The History-info header field can appear in any request not
associated with an early or established dialog (e.g., INVITE, associated with an early or established dialog (e.g., INVITE,
REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.)
and any non-100 provisional or final responses to these requests and any non-100 provisional or final responses to these requests
(ISSUER-req, see Appendix A). (ISSUER-req, see Appendix A).
The following provides details for the information that is captured The following provides details for the information that is captured
in the History-Info header field entries for each target used for in the History-Info header field entry (hi-entry) for each target
forwarding a request: used for forwarding a request:
o hi-targeted-to-uri: A mandatory parameter for capturing the o hi-targeted-to-uri: A mandatory parameter for capturing the
Request-URI for the specific request as it is forwarded. Request-URI for the specific request as it is forwarded.
o hi-index: A mandatory parameter for History-Info reflecting the o hi-index: A mandatory parameter for History-Info reflecting the
chronological order of the information, indexed to also reflect chronological order of the information, indexed to also reflect
the forking and nesting of requests. The format for this the forking and nesting of requests. The format for this
parameter is a string of digits, separated by dots to indicate the parameter is a string of digits, separated by dots to indicate the
number of forward hops and retargets. This results in a tree number of forward hops and retargets. This results in a tree
representation of the history of the request, with the lowest- representation of the history of the request, with the lowest-
level index reflecting a branch of the tree. By adding the new level index reflecting a branch of the tree. By adding the new
entries in order (i.e., following existing entries per the details entries in order (i.e., following existing entries per the details
in Section 10.3), including the index and securing the header, the in Section 10.3), including the index and sending the messages
ordering of the History-info header fields in the request is using a secure transport, the ordering of the History-info header
assured. In addition, applications may extract a variety of fields in the request is assured. In addition, applications may
metrics (total number of retargets, total number of retargets from extract a variety of metrics (total number of retargets, total
a specific branch, etc.) based upon the index values. number of retargets from a specific branch, etc.) based upon the
index values.
o hi-target-param: An optional parameter reflecting the mechanism by o hi-target-param: An optional parameter reflecting the mechanism by
which the Request URI captured in the hi-targeted-to-uri in the which the Request URI captured in the hi-targeted-to-uri in the
hi-entry was determined. This parameter contains either an "rc" hi-entry was determined. This parameter contains either an "rc"
or "mp" header field parameter, which is interpreted as follows: or "mp" header field parameter, which is interpreted as follows:
"rc": The hi-targeted-to-URI is a contact for the Request-URI, "rc": The hi-targeted-to-URI is a contact bound to an AOR in an
in the incoming request, that is bound to an AOR in an abstract abstract location service, that AOR being the Request-URI that
location service. The AOR-to-contact binding has been placed was retargeted. The AOR-to-contact binding has been placed
into the location service by a SIP Registrar that received a into the location service by a SIP Registrar that received a
SIP REGISTER request. The "rc" header field parameter contains SIP REGISTER request. The "rc" header field parameter contains
the value of the hi-index in the hi-entry with an the value of the hi-index in the hi-entry with an
hi-targeted-to- uri that reflects the Request-URI that was hi-targeted-to- uri that reflects the Request-URI that was
retargeted retargeted
"mp": The hi-targeted-to-URI represents a user other than the "mp": The hi-targeted-to-URI represents a user other than the
user associated with the Request-URI in the incoming request user associated with the Request-URI in the incoming request
that was retargeted. This occurs when a request is to that was retargeted. This occurs when a request is statically
statically or dynamically retargeted to another user. The or dynamically retargeted to another user. The "mp" header
value of the index in the "mp" header field parameter field parameter contains the value of the hi-index in the hi-
represents the value of the hi-index in the hi-entry with an entry with an hi-targeted-to-uri that reflects the Request-URI
hi-targeted-to- uri that reflects the Request-URI that was that was retargeted, thus identifying the "mapped from" target.
retargeted, thus identifying the "mapped from" target.
o Extension (hi-extension): A parameter to allow for future optional o Extension (hi-extension): A parameter to allow for future optional
extensions. As per [RFC3261], any implementation not extensions. As per [RFC3261], any implementation not
understanding an extension MUST ignore it. understanding an extension MUST ignore it.
The ABNF syntax for the History-info header field and header field The ABNF syntax for the History-info header field and header field
parameters is as follows: parameters is as follows:
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param) hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = name-addr hi-targeted-to-uri = name-addr
hi-param = hi-index / hi-target / hi-extension hi-param = hi-index / hi-target-param / hi-extension
index-val = 1*DIGIT *("." 1*DIGIT) index-val = 1*DIGIT *("." 1*DIGIT)
hi-index = "index" EQUAL index-val hi-index = "index" EQUAL index-val
hi-target-param = rc-param / mp-param hi-target-param = rc-param / mp-param
rc-param = "rc" EQUAL index-val rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val mp-param = "mp" EQUAL index-val
skipping to change at page 8, line 43 skipping to change at page 9, line 43
hi-extension = generic-param hi-extension = generic-param
The ABNF definitions for "generic-param" and "name-addr" are from The ABNF definitions for "generic-param" and "name-addr" are from
[RFC3261]. [RFC3261].
This document also extends the "contact-params" for the Contact This document also extends the "contact-params" for the Contact
header field as defined in [RFC3261] with the "rc" and "mp" header header field as defined in [RFC3261] with the "rc" and "mp" header
field parameters defined above. field parameters defined above.
In addition to the parameters defined by the ABNF, an hi-entry may In addition to the parameters defined by the ABNF, an hi-entry may
also include a Reason header field and a Privacy header field, which also include a Reason header field and/or a Privacy header field,
are both included in the hi-targeted-to-uri as described below: which are both included in the "headers" component of the hi-
targeted-to-uri as described below:
o Reason: An optional parameter for History-Info, reflected in the o Reason: An optional parameter for History-Info, reflected in the
History-info header field by including the Reason header field History-info header field by including the Reason header field
[RFC3326] included in the hi-targeted-to-uri. A reason is [RFC3326] included in the hi-targeted-to-uri. A reason is
included for the hi-targeted-to-uri that was retargeted as opposed included in the hi-targeted-to-uri of an hi-entry to reflect
to the hi-targeted-to-uri to which it was retargeted. information received in a response to the request sent to that
URI.
o Privacy: An optional parameter for History-Info, reflected in the o Privacy: An optional parameter for History-Info, reflected in the
History-Info header field values by including the Privacy Header History-Info header field values by including the Privacy Header
[RFC3323] included in the hi- targeted-to-uri or by adding the [RFC3323] included in the hi- targeted-to-uri or by adding the
Privacy header field to the request. The latter case indicates Privacy header field to the request. The latter case indicates
that the History-Info entries for the domain MUST be anonymized that the History-Info entries for the domain MUST be anonymized
prior to forwarding, whereas the use of the Privacy header field prior to forwarding, whereas the use of the Privacy header field
included in the hi-targeted-to-uri means that a specific hi-entry included in the hi-targeted-to-uri means that a specific hi-entry
MUST be anonymized. MUST be anonymized.
skipping to change at page 9, line 50 skipping to change at page 11, line 5
biloxi.example.com, it does a location service lookup for biloxi.example.com, it does a location service lookup for
bob@biloxi.example.com and changes the target of the request to Bob's bob@biloxi.example.com and changes the target of the request to Bob's
Contact URIs provided as part of normal SIP registration. In this Contact URIs provided as part of normal SIP registration. In this
example, Bob is simultaneously contacted on a PC client and on a example, Bob is simultaneously contacted on a PC client and on a
phone, and Bob answers on the PC client. phone, and Bob answers on the PC client.
One important thing illustrated by this call flow is that without One important thing illustrated by this call flow is that without
History-Info, Bob would "lose" the target information, including any History-Info, Bob would "lose" the target information, including any
parameters in the request URI. Bob can recover that information by parameters in the request URI. Bob can recover that information by
locating the last hi-entry with an "rc" header field parameter. This locating the last hi-entry with an "rc" header field parameter. This
"rc" parameter contains the index of the hi-entry containing the lost "rc" header field parameter contains the index of the hi-entry
target information - i.e., the sip:bob@biloxi.example.com hi-entry containing the lost target information - i.e., the
with index=1.1. Note that an hi-entry is not included for the fork sip:bob@biloxi.example.com hi-entry with index=1.1. Note that an hi-
to sip:bob@192.0.2.7 since there was no response at the time the 200 entry is not included for the fork to sip:bob@192.0.2.7 since there
OK is sent to Alice. was no response at the time the 200 OK is sent to Alice.
The formatting in this scenario is for visual purposes; thus, The formatting in this scenario is for visual purposes; thus,
backslash and CRLF are used between the fields for readability and backslash and CRLF are used between the fields for readability.
the headers in the URI are not shown properly formatted for escaping.
Refer to Section 5.1 for the proper formatting. Additional detailed Refer to Section 5.1 for the proper formatting. Additional detailed
scenarios are available in Appendix B. scenarios are available in Appendix B.
Note: This example uses loose routing procedures. Note: This example uses loose routing procedures.
Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone
| | | | | | | | | |
| INVITE sip:bob@biloxi.example.com;p=x | | | INVITE sip:bob@biloxi.example.com;p=x | |
|--------------->| | | | |--------------->| | | |
| Supported: histinfo | | | | Supported: histinfo | | |
skipping to change at page 12, line 11 skipping to change at page 13, line 11
|--------------->| ACK | | | |--------------->| ACK | | |
| |--------------->| ACK | | | |--------------->| ACK | |
| | |--------------->| | | | |--------------->| |
Figure 1: Basic Call Figure 1: Basic Call
6. User Agent Handling of the History-Info Header Field 6. User Agent Handling of the History-Info Header Field
A B2BUA MAY follow the behavior of a SIP intermediary as an A B2BUA MAY follow the behavior of a SIP intermediary as an
alternative to following the behavior of a UAS per Section 6.2 and a alternative to following the behavior of a UAS per Section 6.2 and a
UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries
forward hi-entries received in requests at the UAS to the request forward hi-entries received in requests at the UAS to requests being
being forwarded by the UAC, as well as carrying forward responses forwarded by the UAC, as well as carrying forward hi-entries in
received at the UAC to the responses forwarded by the UAS, subject to responses received at the UAC to the responses forwarded by the UAS,
privacy considerations per Section 10.1. subject to privacy considerations per Section 10.1.
6.1. User Agent Client (UAC) Behavior 6.1. User Agent Client (UAC) Behavior
The UAC MUST include the "histinfo" option tag in the Supported The UAC MUST include the "histinfo" option tag in the Supported
header in any new or out-of-dialog request for which the UAC would header field in any new or out-of-dialog request for which the UAC
like the History-info header field in the response. When issuing a would like the History-info header field in the response. When
request, the UAC MUST follow the procedures in Section 9.2. Note issuing a request, the UAC MUST follow the procedures in Section 9.2.
that in the case of an initial request, there is no cache of hi- Note that in the case of an initial request, except where the UAC is
entries with which to populate the History-info header field as part of a B2BUA, there is no cache of hi-entries with which to
described in and the hi-index is set to 1 per Section 10.3. When populate the History-info header field and the hi-index is set to 1
receiving a response the UAC MUST follow the procedures in per Section 10.3. When receiving a response the UAC MUST follow the
Section 9.3. procedures in Section 9.3.
6.2. User Agent Server (UAS) Behavior 6.2. User Agent Server (UAS) Behavior
When receiving a request, a UAS MUST follow the procedures defined in When receiving a request, a UAS MUST follow the procedures defined in
Section 9.2. When sending a response other than a 3xx response, a Section 9.2. When sending a response other than a 3xx response, a
UAS MUST follows the procedures as defined in Section 9.4. When UAS MUST follows the procedures as defined in Section 9.4. When
sending a 3xx response, the UAS MUST follow the procedures defined sending a 3xx response, the UAS MUST follow the procedures defined
for a redirect server per Section 8. An application at the UAS can for a redirect server per Section 8. An application at the UAS can
make use of the cached hi-entries as described in Section 11. make use of the cached hi-entries as described in Section 11.
7. Proxy/Intermediary Handling of History-Info Header Fields 7. Proxy/Intermediary Handling of History-Info Header Fields
This section describes the procedures for proxies and other SIP This section describes the procedures for proxies and other SIP
intermediaries for the handling of the History-Info header fields for intermediaries for the handling of the History-Info header fields for
each of the following scenarios: each of the following scenarios:
For each outgoing request relating to a target in the target set, Receiving a Request: An intermediary MUST follow the procedures in
the intermediary MUST add an hi-entry for the specific target, per Section 9.1 for the handling of hi-entries in incoming SIP
the procedures in Section 9.2. requests.
An intermediary MUST follow the procedures in Section 9.1 for the Sending a Request: For each outgoing request relating to a target
handling of hi-entries in incoming SIP requests. in the target set, the intermediary MUST follow the procedures of
Section 9.2.
An intermediary MUST follow the procedures of Section 9.4 for for Receiving a Response or Timeout: An intermediary MUST follow the
the handling of the hi-entries when sending a SIP response. procedures of Section 9.3 when a SIP response is received or a
request times out.
An intermediary MUST follow the procedures of Section 9.3 when a Sending a Response: An intermediary MUST follow the procedures of
SIP response containing hi-entries is received. Section 9.4 for the handling of the hi-entries when sending a SIP
response.
In some cases, an intermediary may retarget a request more than once In some cases, an intermediary may retarget a request more than once
before forwarding - i.e., a request is retargeted to a SIP entity before forwarding - i.e., a request is retargeted to a SIP entity
that is "internal" to the intermediary before the same intermediary that is "internal" to the intermediary before the same intermediary
retargets the request to an external target . A typical example retargets the request to an external target . A typical example
would be a proxy that retargets a request first to a different user would be a proxy that retargets a request first to a different user
(i.e., it maps to a different AOR) and then forwards to a registered (i.e., it maps to a different AOR) and then forwards to a registered
contact bound to the same AOR. In this case, the intermediary MUST contact bound to the same AOR. In this case, the intermediary MUST
add an hi-entry for (each of) the internal target(s) per the add an hi-entry for (each of) the internal target(s) per the
procedures in Section 9.2. The intermediary MAY include a Reason procedures in Section 9.2. The intermediary MAY include a Reason
skipping to change at page 13, line 36 skipping to change at page 14, line 42
A redirect server MUST follow the procedures in Section 9.1 when it A redirect server MUST follow the procedures in Section 9.1 when it
receives a SIP Request. A redirect server MUST follow the procedures receives a SIP Request. A redirect server MUST follow the procedures
in Section 9.4 when it sends a SIP Response. When generating the in Section 9.4 when it sends a SIP Response. When generating the
Contact header field in a 3xx response, the redirect server MUST add Contact header field in a 3xx response, the redirect server MUST add
the appropriate target header field parameter to each Contact header the appropriate target header field parameter to each Contact header
field as described in Section 10.4, if applicable. field as described in Section 10.4, if applicable.
9. Handling of History-Info Header Fields in Requests and Responses 9. Handling of History-Info Header Fields in Requests and Responses
This section describes the procedures for SIP entities for the This section describes the procedures for SIP entities for the
handling of SIP requests and responses containing the History-Info handling of the History-Info header field in SIP requests and
header fields. responses.
9.1. Receiving a Request with History-Info 9.1. Receiving a Request
When receiving a request, a SIP entity MUST create a cache containing When receiving a request, a SIP entity MUST create a cache containing
the hi-entries associated with the request. The hi-entries MUST be the hi-entries associated with the request. The hi-entries MUST be
added to the cache in the order in which they were received in the added to the cache in the order in which they were received in the
request. request.
If the Request-URI of the incoming request does not match the hi- If the Request-URI of the incoming request does not match the hi-
targeted-to-uri in the last hi-entry (i.e., the previous SIP entity targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
that sent the request did not include a History-Info header field), that sent the request did not include a History-Info header field),
the SIP entity MUST add an hi-entry to end of the cache, on behalf of the SIP entity MUST add an hi-entry to end of the cache, on behalf of
the previous SIP entity, as follows: the previous SIP entity, as follows:
The SIP entity MUST set the hi-targeted-to-uri to the value of the o The SIP entity MUST set the hi-targeted-to-uri to the value of the
Request-URI in the incoming request. Request-URI in the incoming request.
If privacy is required, the SIP entity MUST follow the procedures o If privacy is required, the SIP entity MUST follow the procedures
of Section 10.1. of Section 10.1.
The SIP entity MUST set the hi-index parameter to a value of "1", o The SIP entity MUST set the hi-index parameter as described in
as described in Section 10.3. Section 10.3.
The SIP entity MUST NOT include an "rc" or "mp" header field o The SIP entity MUST NOT include an "rc" or "mp" header field
parameter. parameter.
9.2. Sending a Request with History-Info 9.2. Sending a Request with History-Info
When sending a request, a SIP entity MUST include all cached hi- When sending a request, a SIP entity MUST include all cached hi-
entries in the request. In addition, the SIP entity MUST add a new entries in the request. In addition, the SIP entity MUST add a new
hi-entry to the outgoing request populating the header field as hi-entry to the outgoing request, but the SIP entity MUST NOT add the
follows: new hi-entry to the cache at this time. The new hi-entry is
populated as follows:
The hi-targeted-to-uri MUST be set to the value of the Request-URI hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the
of the current (outgoing) request. value of the Request-URI of the current (outgoing) request.
If privacy is required, the procedures of Section 10.1 MUST be privacy: If privacy is required, the procedures of Section 10.1
followed. MUST be followed.
The SIP entity MUST include an hi-index for the hi-entry as hi-index: The SIP entity MUST include an hi-index for the hi-entry
described in Section 10.3. as described in Section 10.3.
The SIP entity MUST include an "rc" or "mp" header field parameter rc/mp: The SIP entity MUST include an "rc" or "mp" header field
in the hi-entry, if applicable, per the procedures in parameter in the hi-entry, if applicable, per the procedures in
Section 10.4. Section 10.4.
9.3. Receiving a Response with History-Info 9.3. Receiving a Response with History-Info or Request Timeouts
When a SIP entity receives a response other than a 100, the SIP When a SIP entity receives a non-100 response or a request times out,
entity performs the following steps: the SIP entity performs the following steps:
Step 1: Add hi-entry to cache Step 1: Add hi-entry to cache
The SIP entity MUST add the hi-entry that was added to the request The SIP entity MUST add the hi-entry that was added to the request
that received the non-100 response to the cache, if it was not that received the response or timed out to the cache, if it was
already cached. The hi-entry MUST be added to the cache in not already cached. The hi-entry MUST be added to the cache in
ascending order as indicated by the values in the hi-index ascending order as indicated by the values in the hi-index
parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but
before 1.3). before 1.2.2 or 1.3).
Step 2: Add Reason header field Step 2: Add Reason header field
The SIP entity then MUST add a Reason header field to the (newly) The SIP entity adds one or more Reason header fields to the hi-
cached hi-entry reflecting the SIP response code in the non-100 targeted-to-uri in the (newly) cached hi-entry per the procedures
response, per the procedures of Section 10.2. of Section 10.2, except in the case of a 2xx response.
Step 3: Add additional hi-entries Step 3: Add additional hi-entries
The SIP entity MUST also add to the cache any hi-entries received The SIP entity MUST also add to the cache any hi-entries received
in the response that are not already in the cache. This situation in the response that are not already in the cache. This situation
can occur when the entity that generated the non-100 response can occur when the entity that generated the response retargeted
retargeted the request before generating the response. As per the request before generating the response. As per Step 1, the
Step 1, the hi-entries MUST be added to the cache in ascending hi-entries MUST be added to the cache in ascending order as
order as indicated by the values in the hi-index parameters of the indicated by the values in the hi-index parameters of the hi-
hi-entries entries
It is important to note that the cache does not contain hi-entries It is important to note that the cache does not contain hi-entries
for requests that have not yet received a non-100 response, so there for requests that have not yet received a non-100 response, so there
can be gaps in indices (e.g., 1.2 and 1.4 could but present but not can be gaps in indices (e.g., 1.2 and 1.4 could but present but not
1.3). 1.3).
9.4. Sending History-Info in Responses 9.4. Sending History-Info in Responses
When sending a response other than a 100, a SIP entity MUST include When sending a response other than a 100, a SIP entity MUST include
all the cached hi-entries in the response with the following all the cached hi-entries in the response, subject to the privacy
exception: If the received request contained no hi-entries and there consideration in Section 10.1.2 with the following exception: If the
is no "histinfo" option tag in the Supported header field, the SIP received request contained no hi-entries and there is no "histinfo"
entity MUST NOT include hi-entries in the response. In the former option tag in the Supported header field, the SIP entity MUST NOT
case, the privacy procedures as described in Section 10.1.2 MUST be include hi-entries in the response.
followed.
10. Processing the History-Info Header Field 10. Processing the History-Info Header Field
The following sections describe the procedures for processing the The following sections describe the procedures for processing the
History-Info header field. These procedures are applicable to SIP History-Info header field. These procedures are applicable to SIP
entities such as Proxies/Intermediaries, Redirect Servers or User entities such as Proxies/Intermediaries, Redirect Servers or User
Agents. Agents.
10.1. Privacy in the History-Info Header Field 10.1. Privacy in the History-Info Header Field
The privacy requirements for this document are described in The privacy requirements for this document are described in
Appendix A.2. Section 10.1.1 describes the use of the Privacy header Appendix A.2. Section 10.1.1 describes the insertion of the Privacy
field defined in [RFC3323] to indicate the privacy to be applied to header field defined in [RFC3323] to indicate the privacy to be
the History-Info header field entries. Section 10.1.2 describes the applied to the History-Info header field entries. Section 10.1.2
processing of the priv-values in the Privacy header field to privacy describes how to apply privacy to a request or response that is being
protect the History-Info header field entries in the request or forwarded, based on the presence of the Privacy header field.
response that is being forwarded.
10.1.1. Indicating Privacy 10.1.1. Indicating Privacy
As with other SIP headers described in [RFC3323], the hi-targeted-to- As with other SIP headers described in [RFC3323], the hi-targeted-to-
uris in the History-info header field can inadvertently reveal uris in the History-info header field can inadvertently reveal
information about the initiator of the request. Thus, the UAC needs information about the initiator of the request. Thus, the UAC needs
a mechanism to indicate that the hi-targeted-to-uris in the hi- a mechanism to indicate that the hi-targeted-to-uris in the hi-
entries need to be privacy protected. The Privacy header field is entries need to be privacy protected. The Privacy header field is
used by the UAC to indicate the privacy to be applied to all the hi- used by the UAC to indicate that privacy is to be applied to all the
entries in the request as follows: hi-entries in the request as follows:
o If the UAC is including a Privacy header field with a priv-value o If the UAC is including a Privacy header field with a priv-value
of "header" in the request, then the UAC SHOULD NOT include a of "header" in the request, then the UAC SHOULD NOT include a
priv-value of "history" in the the Privacy header field in the priv-value of "history" in the the Privacy header field in the
Request. Request.
o If the UAC is including any priv-values other than "header" in the o If the UAC is including any priv-values other than "header" in the
Privacy header field, then the UAC MUST also include a priv-value Privacy header field, then the UAC MUST also include a priv-value
of "history" in the Privacy header field in the Request. of "history" in the Privacy header field in the Request.
skipping to change at page 16, line 35 skipping to change at page 17, line 44
field in the request, then the UAC MUST add a Privacy header field in the request, then the UAC MUST add a Privacy header
field, with a priv-value of "history", to the request. The UAC field, with a priv-value of "history", to the request. The UAC
MUST NOT include a priv-value of "critical" in the Privacy header MUST NOT include a priv-value of "critical" in the Privacy header
field in the Request in this case. field in the Request in this case.
In addition, the History-info header field can reveal general routing In addition, the History-info header field can reveal general routing
and diverting information within an intermediary, which the and diverting information within an intermediary, which the
intermediary wants to privacy protect. In this case, the intermediary wants to privacy protect. In this case, the
intermediary MUST set a Privacy header field to a priv-value of intermediary MUST set a Privacy header field to a priv-value of
"history" and include the Privacy header field in the hi-targeted-to- "history" and include the Privacy header field in the hi-targeted-to-
uri, for each hi-entry added by intermediary, as the request is uri, for each new hi-entry added by the intermediary, as the request
retargeted within the domain for which the SIP entity is responsible. is retargeted within the domain for which the SIP entity is
The intermediary MUST NOT include any other priv-values in this responsible. Note, that the hi-entries that are added to a request
Privacy header field. Note that the priv-value in the Privacy header from the cache are excluded in this case since the appropriate
for the incoming request does not necessarily influence whether the privacy was set for those hi-entries when they were originally added
intermediary includes a Privacy header field in the hi-entries. For to a request. The intermediary MUST NOT include any other priv-
example, even if the Privacy header for the incoming request values in this Privacy header field. Note that the priv-value in the
contained a priv-value of "none", the Proxy can still set a priv- Privacy header for the incoming request does not necessarily
value of "history" in the Privacy header field included in the hi- influence whether the intermediary includes a Privacy header field in
targeted-to-uri. the hi-entries. For example, even if the Privacy header for the
incoming request contained a priv-value of "none", the Proxy can
still set a priv-value of "history" in the Privacy header field
included in the hi-targeted-to-uri.
Finally, the terminator of the request may not want to reveal the Finally, the terminator of the request may not want to reveal the
final reached target to the originator. In this case, the terminator final reached target to the originator. In this case, the terminator
MUST include a Privacy header field with a priv-value of "history" in MUST include a Privacy header field with a priv-value of "history" in
the hi-targeted-to-uri in the last hi-entry, in the response. As the hi-targeted-to-uri in the last hi-entry, in the response. As
noted above, the terminator of the request MUST NOT use any other noted above, the terminator of the request MUST NOT use any other
priv-values in the Privacy header field included in the hi-entry. priv-values in the Privacy header field included in the hi-entry.
10.1.2. Applying Privacy 10.1.2. Applying Privacy
When a request is retargeted to a URI associated with a domain for When a request is retargeted to a URI associated with a domain for
which the SIP intermediary is not responsible or a response is which the SIP intermediary is not responsible or a response is
forwarded, a Privacy Service at the boundary of the domain applies forwarded to a domain for which the SIP intermediary is not
responsible, a Privacy Service at the boundary of the domain applies
the appropriate privacy based on the value of the Privacy header the appropriate privacy based on the value of the Privacy header
field in the request and in the individual hi-entries. field in the message header or in the "headers" component of the hi-
targeted-to-uri in the individual hi-entries.
If there is a Privacy header field in the request with a priv-value If there is a Privacy header field in the message header of a request
of "header" or "history", then the hi-targeted-to-uris in the hi- or response, with a priv-value of "header" or "history", then all the
entries, associated with the domain for which a SIP intermediary is hi-targeted-to-uris in the hi-entries, associated with the domain for
responsible, are anonymized. The Privacy Service MUST change any hi- which a SIP intermediary is responsible, are anonymized by the
targeted-to-uris in the hi-entries that have not been anonymized to Privacy Service. The Privacy Service MUST change any hi-targeted-to-
anonymous URIs containing a domain of anonymous.invalid (e.g., uris in the hi-entries that have not been anonymized to anonymous
anonymous@anonymous.invalid). If the hi-targeted-to-uri in the hi- URIs containing a domain of anonymous.invalid (e.g.,
entry contains an Privacy header field, then the Privacy header field anonymous@anonymous.invalid). If there is a Privacy header field in
value MUST be removed from the hi-entry. Once all the appropriate the "headers" component of the hi-targeted-to-uri in the hi-entry,
hi-entries have been anonymized, the priv-value of "history" MUST be then the Privacy header field value MUST be removed from the hi-
removed from the Privacy header field. If there are no remaining entry. Once all the appropriate hi-entries have been anonymized, the
priv-values in the Privacy header field, the Privacy header field Privacy Service MUST remove the priv-value of "history" from the
MUST be removed from the request per [RFC3323]. Privacy header field in the message header of the request or
response. If there are no remaining priv-values in the Privacy
header field, the Privacy Service MUST remove the Privacy header
field from the request or response per [RFC3323].
If there is not a Privacy header field in the request or response If there is not a Privacy header field in the message header of the
that is being forwarded, the Privacy Service MUST anonymize any hi- request or response that is being forwarded, but there is a Privacy
entries, associated with the domain for which a SIP intermediary is header field with a priv-value of "history" in the "headers"
responsible, that contain a Privacy header field with a priv-value of component in any of the hi-targeted-uris in the hi-entries associated
"history". The Privacy Service MUST populate the hi-targeted-to-uri with the domain for which a SIP intermediary is responsible, then the
with an anonymous URI with a domain of anonymous.invalid (e.g., Privacy Service MUST anonymize those hi-targeted-to-uris. The
Privacy Service MUST populate each of the hi-targeted-to-uris with an
anonymous URI with a domain of anonymous.invalid (e.g.,
anonymous@anonymous.invalid). Any other priv-values in the Privacy anonymous@anonymous.invalid). Any other priv-values in the Privacy
header field in the hi-entries MUST be ignored. In any case, the header field in the "headers" component of the hi-targeted-to-uris in
Privacy Service MUST remove the Privacy header field from the hi- the hi-entries MUST be ignored. In any case, the Privacy Service
entries prior to forwarding. MUST remove the Privacy header field from the "headers" compenent of
the hi-targeted-to-uris in the hi-entries prior to forwarding.
10.2. Reason in the History-info Header Field 10.2. Reason in the History-info Header Field
If the retargeting is due to receipt of an explicit SIP response and A Reason header field is added to the "headers" component in an hi-
the response contains any Reason header fields (see [RFC3326]), then targeted-to-uri when the hi-entry is added to the cache based upon
the SIP entity MUST include the Reason header fields in the hi- the receipt of a non-100 or non-2xx SIP response, as described in
targeted-to-uri containing the URI of the request that was Section 9.3. If the Reason header field is being added due to
retargeted, unless the hi-targeted-to-uri is a Tel-URI. If the SIP receipt of an explicit SIP response and the response contains any
response does not contain a Reason header field, the SIP entity MUST Reason header fields (see [RFC3326]), then the SIP entity MUST
include a Reason header field, containing the SIP Response Code that include the Reason header fields in the "headers" component of the
triggered the retargeting, in the hi-targeted-to-uri containing the hi-targeted-to-uri in the last hi-entry added to the cache, unless
URI of the request that was retargeted, except in the case that the the hi-targeted-to-uri is a Tel-URI. If the SIP response does not
hi-targeted-to-uri is a Tel-URI. contain a Reason header field, the SIP entity MUST include a Reason
header field, containing the SIP Response Code, in the "headers"
component of the hi-targeted-to-uri in the last hi-entry added to the
cache, unless the hi-targeted-to-uri is a Tel-URI.
If a request has timed out (instead of being explicitly rejected), If a request has timed out (instead of being explicitly rejected),
the SIP entity MUST include a Reason header field, containing a SIP the SIP entity MUST include a Reason header field, containing a SIP
error response code of 408 "Request Timeout" in hi-targeted-to-uri error response code of 408 "Request Timeout".
containing the URI of the request that was retargeted. The SIP
entity MAY also include a Reason header field in the hi-targeted-to-
uri containing the URI of the request that was retargeted as a result
of internal retargeting.
If additional Reason headers are defined in the future per [RFC3326], A SIP entity MAY also include a Reason header field in the "headers"
the use of these Reason headers for the History-Info header field component of an hi-targeted-to-uri containing the URI of a request
MUST follow the same rules as described above. that was retargeted as a result of internal retargeting.
If new protocol values for Reason headers are specified in the future
per [RFC3326], the use of these Reason headers for the History-Info
header field MUST follow the same rules as described above.
10.3. Indexing in the History-Info Header Field 10.3. Indexing in the History-Info Header Field
In order to maintain ordering and accurately reflect the retargeting In order to maintain ordering and accurately reflect the retargeting
of the request, the SIP entity MUST add an hi-index to each hi-entry. of the request, the SIP entity MUST add an hi-index to each hi-entry.
Per the syntax in Section 5, the hi-index consists of a series of Per the syntax in Section 5, the hi-index consists of a series of
digits separated by dots (e.g., 1.1.2). Each dot reflects a SIP digits separated by dots (e.g., 1.1.2). Each dot reflects a SIP
forwarding hop. The digit following each dot reflects the order in forwarding hop. The digit following each dot reflects the order in
which a request was retargeted at the hop. The highest digit at each which a request was retargeted at the hop. The highest digit at each
hop reflects the number of entities to which the request has been hop reflects the number of entities to which the request has been
skipping to change at page 18, line 36 skipping to change at page 20, line 11
The first index in a series of History-Info entries MUST be set to 1. The first index in a series of History-Info entries MUST be set to 1.
In the case that a SIP entity (intermediary or UAS) adds an hi-entry In the case that a SIP entity (intermediary or UAS) adds an hi-entry
on behalf of the previous hop, the hi-index MUST be set to 1. For on behalf of the previous hop, the hi-index MUST be set to 1. For
each forward hop (i.e., each new level of indexing), the hi-index each forward hop (i.e., each new level of indexing), the hi-index
MUST start at 1. An increment of 1 MUST be used for advancing to a MUST start at 1. An increment of 1 MUST be used for advancing to a
new branch. new branch.
The basic rules for adding the hi-index are summarized as follows: The basic rules for adding the hi-index are summarized as follows:
1. Basic Forwarding: In the case of a request that is being 1. Forwarding a request without changing the target: In the case of
forwarded, the hi-index reflects the increasing length of the a request that is being forwarded without changing the target,
branch. In this case, the SIP entity MUST read the value from the hi-index reflects the increasing length of the branch. In
the History-info header field in the received request and MUST this case, the SIP entity MUST read the value from the History-
add another level of indexing by appending the dot delimiter info header field in the received request and MUST add another
followed by an initial hi-index for the new level of 1. For level of indexing by appending the dot delimiter followed by an
example, if the hi-index in the last History-info header field in initial value of 1 for the new level. For example, if the hi-
the received request is 1.1, a proxy would add an hi-entry with index in the last History-info header field in the received
an hi-index to 1.1.1 and forward the request. request is 1.1, a proxy would add an hi-entry with an hi-index of
1.1.1 and forward the request.
2. Retargeting within a processing entity - 1st instance: For the 2. Retargeting within a processing entity - 1st instance: For the
first instance of retargeting within a processing entity, the SIP first instance of retargeting within a processing entity, the SIP
entity MUST calculate the hi-index as prescribed for basic entity MUST calculate the hi-index as prescribed for basic
forwarding. forwarding.
3. Retargeting within a processing entity - subsequent instance: For 3. Retargeting within a processing entity - subsequent instance: For
each subsequent retargeting of a request by the same SIP entity, each subsequent retargeting of a request by the same SIP entity,
the SIP entity MUST add another branch. The SIP entity MUST the SIP entity MUST calculate and add the hi-index for each new
calculate the hi-index for each new branch by incrementing the branch by incrementing the rightmost value from the hi-index in
value from the hi-index in the last hi-entry at the current the last hi-entry. Per the example above, the hi-index in the
level. Per the example above, the hi-index in the next request next request forwarded by this same SIP entity would be 1.1.2.
forwarded by this same SIP entity would be 1.1.2.
4. Retargeting based upon a Response: In the case of retargeting due 4. Retargeting based upon a Response: In the case of retargeting due
to a specific response (e.g., 302), the SIP entity MUST calculate to a specific response (e.g., 302), the SIP entity MUST calculate
the hi-index calculated per rule 3. That is, the lowest/last the hi-index calculated per rule 3. That is, the rightmost value
digit of the hi-index MUST be incremented (i.e., a new branch is of the hi-index MUST be incremented (i.e., a new branch is
created), with the increment of 1. For example, if the hi-index created). For example, if the hi-index in the History-Info
in the History-Info header of the sent request is 1.2 and the header of the sent request is 1.2 and the response to the request
response to the request is a 302, then the hi-index in the is a 302, then the hi-index in the History-Info header field for
History-Info header field for the new hi-targeted- to-URI would the new hi-targeted- to-URI would be 1.3.
be 1.3.
5. Forking requests: If the request forwarding is done in multiple 5. Forking requests: If the request forwarding is done in multiple
forks (sequentially or in parallel), the SIP entity MUST set the forks (sequentially or in parallel), the SIP entity MUST set the
hi-index for each hi-entry for each forked request per the rules hi-index for each hi-entry for each forked request per the rules
above, with each new request having a unique index. Each index above, with each new request having a unique index. Each index
MUST be sequentially assigned. For example, if the index in the MUST be sequentially assigned. For example, if the index in the
last History-Info header field in the received request is 1.1, last History-Info header field in the received request is 1.1,
this processing entity would initialize its index to 1.1.1 for this processing entity would initialize its index to 1.1.1 for
the first fork, 1.1.2 for the second, and so forth (see Figure 1 the first fork, 1.1.2 for the second, and so forth (see Figure 1
for an example). Note that for each individual fork, only the for an example). Note, that in the case of parallel forking,
hi-entry corresponding to that fork is included (e.g., the hi- only the hi-entry corresponding to the fork is included in the
entry for fork 1.1.1 is not included in the request sent to fork request.
1.1.2, and vice-versa).
10.4. Mechanism for Target Determination in the History-Info Header 10.4. Indicating the Mechanism by which the Target was Determined
Field
This specification defines two header field parameters, "rc" and This specification defines two header field parameters, "rc" and
"mp", indicating two non-inclusive mechanisms by which a new target "mp", indicating two mechanisms by which a new target for a request
for a request is determined. Both parameters contain an index whose is determined. Both parameters contain an index whose value is the
value is the hi-index of the hi-entry with an hi-targeted-to-uri that hi-index of the hi-entry with an hi-targeted-to-uri that represents
represents the Request-URI that was retargeted. the Request-URI that was retargeted.
The SIP entity MUST determine the specific parameter field to be The SIP entity MUST determine the specific parameter field to be
included in the History-info header field as the targets are added to included in the hi-target-param, in the History-info header field, as
the target set per the procedures in section 16.5 of [RFC3261] or per the targets are added to the target set per the procedures in section
section 8.1.3.4 [RFC3261] in the case of 3xx responses. In the 16.5 of [RFC3261] or per section 8.1.3.4 [RFC3261] in the case of
retargeting to a contact URI received in a 3xx response. In the
latter case, the specific header parameter field in the Contact latter case, the specific header parameter field in the Contact
header becomes the header field parameter that is used in the hi- header becomes the header field parameter that is used in the hi-
entry when the request is retargeted. If the Contact header field target-param in the hi-entry when the request is retargeted. If the
does not contain an "rc" or "mp" header field parameter, then the SIP Contact header field does not contain an "rc" or "mp" header field
entity MUST NOT include an "rc" or "mp" in the hi-entry when the parameter, then the SIP entity MUST NOT include an "rc" or "mp"
request is retargeted. header field parameter in the hi-target-param in the hi-entry when
the request is retargeted to a contact URI received in a 3xx
response.
The SIP entity (intermediary or redirect server) determines the The SIP entity (intermediary or redirect server) determines the
specific header field parameter to be used based on the following specific header field parameter ("rc" or "mp") to be used based on
criteria: the criteria defined in Section 5 (hi-target-param) for each of the
header field parameters.
o "rc": The target was determined based on a contact that is bound
to an AOR in an abstract location service for the Request-URI
being retargeted.
o "mp": The target was determined based on a mapping to a user other
than the user associated with the Request-URI being retargeted.
Note that there are two scenarios by which the "mp" parameter can be Note that there are two scenarios by which the "mp" header field
derived. parameter can be derived.
o The mapping was done by the receiving entity on its own authority, o The mapping was done by the receiving entity on its own authority,
in which case the mp-value is the parent index of the hi-entry's in which case the mp-value is the parent index of the hi-entry's
index. index.
o The mapping was done due to receiving a 3xx response, in which o The mapping was done due to receiving a 3xx response, in which
case the mp-value is an earlier sibling of the hi-entry's index, case the mp-value is an earlier sibling or descendant of an
that of the downstream request which received the 3xx response. earlier sibling of the hi-entry's index, that of the downstream
request which received the 3xx response.
11. Application Considerations 11. Application Considerations
History-Info provides a very flexible building block that can be used History-Info provides a very flexible building block that can be used
by intermediaries and UAs for a variety of services. Prior to any by intermediaries and UAs for a variety of services. Prior to any
application usage of the History-Info header field parameters, the application usage of the History-Info header field parameters, the
SIP entity that processes the hi-entries MUST evaluate the hi- SIP entity that processes the hi-entries MUST evaluate the hi-
entries. The SIP entity MUST determine if there are gaps in the entries. The SIP entity MUST determine if there are gaps in the
indices. Gaps are possible if the request is forwarded through indices. Gaps are possible if the request is forwarded through
intermediaries that do not support the History-info header field and intermediaries that do not support the History-info header field and
are reflected by the existence of multiple hi-entries with an index are reflected by the existence of multiple hi-entries with an index
of "1". Gaps are also possible in the case of parallel forking if of "1". Gaps are also possible in the case of parallel forking if
there is an outstanding request at the time the SIP entity sends a there is an outstanding request at the time the SIP entity sends a
response as described in Section 9.4. Thus, if gaps are detected, response as described in Section 9.4. Thus, if gaps are detected,
the SIP entity MUST NOT treat this as an error, but rather indicate the SIP entity MUST NOT treat this as an error, but SHOULD indicate
to any applications that there are gaps. The most complete to any applications that there are gaps. The interpretation of the
information available to the application is the History-Info entries information in the History-info header field depends upon the
starting with the last hi-entry with an index of "1". The specific application; an application might need to provide special
interpretation of the information in the History-info header field handling in some cases where there are gaps.
depends upon the specific application; an application might need to
provide special handling in some cases where there are gaps.
The following summarizes the categories of information that The following describes some categories of information that
applications can use: applications can use:
1. Complete history information - e.g., for debug or other 1. Complete history information - e.g., for debug or other
operational and management aspects, optimization of determining operational and management aspects, optimization of determining
targets to avoid retargeting to the same URI, etc. This targets to avoid retargeting to the same URI, etc. This
information is relevant to proxies, UACs and UASs. information is relevant to proxies, UACs and UASs.
2. Hi-entry with the index that matches the value of the last hi- 2. Hi-entry with the index that matches the value of the "rc" header
entry with a "rc" header parameter in the Request received by a field parameter in the last hi-entry with an "rc" header field
UAS - i.e., the Request URI associated with the destination of parameter in the Request received by a UAS - i.e., the last AOR
the request was determined based on an AOR-to-contact binding in that was retargeted to a contact based on an AOR-to-contact
an abstract location service. binding in an abstract location service.
3. Hi-entry with the index that matches the value of the last hi- 3. Hi-entry with the index that matches the value of the "mp" header
entry with a "mp" header parameter in the Request received by a field parameter in the last hi-entry with an "mp" header field
UAS - i.e., the last Request URI that was mapped to reach the parameter in the hi-target-param in the Request received by a UAS
- i.e., the last Request URI that was mapped to reach the
destination. destination.
4. Hi-entry with the index that matches the value of the first hi- 4. Hi-entry with the index that matches the value of the "rc" header
entry with a "rc" header parameter in the Request received by a field parameter in the first hi-entry with an "rc" header field
UAS. Note, this would be the original AoR if all the entities parameter in the Request received by a UAS. Note, this would be
involved support the History-info header field and there is the original AoR if all the entities involved support the
absence of a "mp" header parameter prior to the "rc" header History-info header field and there is absence of an "mp" header
parameter in the History-info header field. However, there is no field parameter prior to the "rc" header field parameter in the
guarantee that all entities will support History-Info, thus the hi-target-param in the History-info header field. However, there
first hi-entry with an "rc" header parameter within the domain is no guarantee that all entities will support History-Info, thus
associated with the target URI at the destination is more likely the hi-entry that matches the value of the "rc" parameter of the
to be useful. first hi-entry with an "rc" parameter in the hi-target-param
within the domain associated with the target URI at the
destination is more likely to be useful.
5. Hi-entry with the index that matches the value of the first hi- 5. Hi-entry with the index that matches the value of "mp" header
entry with a "mp" header parameter in the Request received by a field parameter in the first hi-entry with an "mp" header field
UAS. Note, this would be the original mapped URI if all entities parameter in the Request received by a UAS. Note, this would be
supported the History-info header field. However, there is no the original mapped URI if all entities supported the History-
guarantee that all entities will support History-Info, thus the info header field. However, there is no guarantee that all
first hi-entry with an "mp" header parameter within the domain entities will support History-Info, thus the hi-entry that
matches the value of the "mp" header field parameter of the first
hi-entry with an "mp" header field parameter within the domain
associated with the target URI at the destination is more likely associated with the target URI at the destination is more likely
to be useful. to be useful.
In many cases, applications are most interested in the information In many cases, applications are most interested in the information
within a particular domain(s), thus only a subset of the information within a particular domain(s), thus only a subset of the information
is required. is required.
Some applications may use multiple types of information. For Some applications may use multiple types of information. For
example, an Automatic Call Distribution (ACD)/Call center application example, an Automatic Call Distribution (ACD)/Call center application
that utilizes the hi-entry who index matches the index of the first that utilizes the hi-entry whose index matches the value of the "mp"
History-Info entry with an hi-target value of "mp", may also display header field parameter of the first hi-entry with an "mp" header
other agents, reflected by other History-Info entries prior to field parameter, may also display other agents, reflected by other
entries with hi-target values of "rc", to whom the call was targeted hi-entries prior to entries with an "rc" header field parameter, to
prior to its arrival at the current agent. This could allow the whom the call was targeted prior to its arrival at the current agent.
agent the ability to decide how they might forward or reroute the This could allow the agent the ability to decide how they might
call if necessary (avoiding agents that were not previously available forward or reroute the call if necessary (avoiding agents that were
for whatever reason, etc.). not previously available for whatever reason, etc.).
Since support for History-info header field is optional, a service Since support for History-info header field is optional, a service
MUST define default behavior for requests and responses not MUST define default behavior for requests and responses not
containing History-Info headers. For example, an entity may receive containing History-Info header fields. For example, an entity may
only partial History-Info entries or entries which are not tagged receive an incomplete set of hi-entries or hi-entries which are not
appropriately with an hi-target parameter. This may not impact some tagged appropriately with an hi-target-param. This may not impact
applications (e.g., debug), however, it could require some some applications (e.g., debug), however, it could require some
applications to make some default assumptions in this case. For applications to make some default assumptions in this case. For
example, in an ACD scenario, the application could select the oldest example, in an ACD scenario, the application could select the oldest
hi-entry with the domain associated with the ACD system and display hi-entry with the domain associated with the ACD system and display
that as the original called party. Depending upon how and where the that as the original called party. Depending upon how and where the
request may have been retargeted, the complete list of agents to whom request may have been retargeted, the complete list of agents to whom
the call was targeted may not be available. the call was targeted may not be available.
12. Security Considerations 12. Security Considerations
The security requirements for this document are specified in The security requirements for this document are specified in
skipping to change at page 22, line 44 skipping to change at page 24, line 18
more impact on the subsequent processing of SIP sessions than the more impact on the subsequent processing of SIP sessions than the
History-info header field. History-info header field.
Note that while using the SIPS scheme (as per [RFC5630]) protects Note that while using the SIPS scheme (as per [RFC5630]) protects
History-Info from tampering by arbitrary parties outside the SIP History-Info from tampering by arbitrary parties outside the SIP
message path, all the intermediaries on the path are trusted message path, all the intermediaries on the path are trusted
implicitly. A malicious intermediary could arbitrarily delete, implicitly. A malicious intermediary could arbitrarily delete,
rewrite, or modify History-Info. This specification does not attempt rewrite, or modify History-Info. This specification does not attempt
to prevent or detect attacks by malicious intermediaries. to prevent or detect attacks by malicious intermediaries.
In terms of ensuring the privacy of hi-entries, the same security
considerations as those described in [RFC3323] apply. Namely if the
entity requesting privacy wants to ensure privacy is applied to the
hi-entries, a Privacy Service that supports both [RFC3323] and this
specification is REQUIRED in the entity's domain, so that the privacy
can be applied, as described in Section 10.1.2, when a request or
response leaves the domain.
13. IANA Considerations 13. IANA Considerations
This document requires several IANA registrations detailed in the This document requires several IANA registrations detailed in the
following sections. following sections.
This document updates [RFC4244] but uses the same SIP header field This document obsoletes [RFC4244] but uses the same SIP header field
name and option tag. The IANA registry needs to update the name and option tag. The IANA registry needs to update the
references to [RFC4244] with [RFCXXXX]. references to [RFC4244] with [RFCXXXX].
13.1. Registration of New SIP History-Info Header Field 13.1. Registration of New SIP History-Info Header Field
This document defines a SIP header field name: History-Info and an This document defines a SIP header field name: History-Info and an
option tag: histinfo. The following changes have been made to option tag: histinfo. The following changes have been made to
http:///www.iana.org/assignments/sip-parameters The following row has http:///www.iana.org/assignments/sip-parameters The following row has
been added to the header field section:. been added to the header field section:.
skipping to change at page 23, line 33 skipping to change at page 25, line 16
---- ----------- --------- ---- ----------- ---------
histinfo When used with the Supported header, [RFCXXXX] histinfo When used with the Supported header, [RFCXXXX]
this option tag indicates the UAC this option tag indicates the UAC
supports the History Information to be supports the History Information to be
captured for requests and returned in captured for requests and returned in
subsequent responses. This tag is not subsequent responses. This tag is not
used in a Proxy-Require or Require used in a Proxy-Require or Require
header field since support of header field since support of
History-Info is optional. History-Info is optional.
Note to RFC Editor: Please replace RFC XXXX with the RFC number of Note to RFC Editor: Please replace RFCXXXX with the RFC number of
this specification. this specification.
13.2. Registration of "history" for SIP Privacy Header Field 13.2. Registration of "history" for SIP Privacy Header Field
This document defines a priv-value for the SIP Privacy header field: This document defines a priv-value for the SIP Privacy header field:
history The following changes have been made to history The following changes have been made to
http://www.iana.org/assignments/sip-priv-values The following has http://www.iana.org/assignments/sip-priv-values The following has
been added to the registration for the SIP Privacy header field: been added to the registration for the SIP Privacy header field:
Name Description Registrant Reference Name Description Registrant Reference
skipping to change at page 24, line 32 skipping to change at page 26, line 14
Note to RFC Editor: Please replace RFC XXXX with the RFC number of Note to RFC Editor: Please replace RFC XXXX with the RFC number of
this specification. this specification.
14. Acknowledgements 14. Acknowledgements
Jonathan Rosenberg et al produced the document that provided Jonathan Rosenberg et al produced the document that provided
additional use cases precipitating the requirement for the new header additional use cases precipitating the requirement for the new header
parameters to capture the method by which a Request URI is parameters to capture the method by which a Request URI is
determined. The authors would like to acknowledge the constructive determined. The authors would like to acknowledge the constructive
feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel
Kaplan and Dale Worley. Kaplan and Dale Worley. John Elwell provided excellent suggestions
in terms of document structure.
Mark Watson, Cullen Jennings and Jon Peterson provided significant Mark Watson, Cullen Jennings and Jon Peterson provided significant
input into the initial work that resulted in the development of of input into the initial work that resulted in the development of of
[RFC4244]. The editor would like to acknowledge the constructive [RFC4244]. The editor would like to acknowledge the constructive
feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John
Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony
Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin
Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and
Sebastien Garcin in the development of [RFC4244]. Sebastien Garcin in the development of [RFC4244].
skipping to change at page 26, line 36 skipping to change at page 28, line 19
optional SIP header field parameter to the History-Info and Contact optional SIP header field parameter to the History-Info and Contact
headers. Entities that have not implemented this specification MUST headers. Entities that have not implemented this specification MUST
ignore these parameters, however, per [RFC4244] an entity MUST NOT ignore these parameters, however, per [RFC4244] an entity MUST NOT
remove this parameter from an hi-entry. remove this parameter from an hi-entry.
16. Changes since last Version 16. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from 04 to 05:
1. Lots of editorial corrections/clarifications per John Elwell's
comment.
2. Updated Reason header section 10.2 to be consistent (i.e.,
removed references to retargeting) with section 9.3 (Receiving a
response) where the hi-entries and reason header are added to the
cache.
3. Updated section 9.3 (receiving responses) to also include
timeouts and updated to reflect that we don't add the Reason
header in the case of 2xx responses.
4. Added text in Security considerations with regards to needing a
Privacy Service per RFC 3323 to ensure that the privacy is
applied.
Changes from 03 to 04: Changes from 03 to 04:
1. Reorganization of sections per John Elwell's comments - i.e., a 1. Reorganization of sections per John Elwell's comments - i.e., a
common section for building HI referenced by the UA, Intermediary common section for building HI referenced by the UA, Intermediary
and Redirect server sections. and Redirect server sections.
2. Removing the use of "escape" when describing the handling of the 2. Removing the use of "escape" when describing the handling of the
Privacy and Reason header fields. Privacy and Reason header fields.
3. Clarification of TEL URIs in terms of not having a Privacy or 3. Clarification of TEL URIs in terms of not having a Privacy or
skipping to change at page 29, line 13 skipping to change at page 31, line 13
Changes from 00 to 01: Changes from 00 to 01:
1. Moved examples (except first) in appendix to a new 1. Moved examples (except first) in appendix to a new
(informational) document. (informational) document.
2. Updated UAS and UAC sections to clarify and expand on the 2. Updated UAS and UAC sections to clarify and expand on the
handling of the History-info header field. handling of the History-info header field.
3. Updated the Application considerations section: 3. Updated the Application considerations section:
4.
* Included more detail with regards to how applications can make * Included more detail with regards to how applications can make
use of the information, in particular based on the new tags. use of the information, in particular based on the new tags.
* Removed privacy consideration (2nd bullet) since privacy is * Removed privacy consideration (2nd bullet) since privacy is
now accomplished by anonymizing rather than removal of now accomplished by anonymizing rather than removal of
entries. entries.
Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf- Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf-
sipcore-4244bis-00: sipcore-4244bis-00:
skipping to change at page 33, line 37 skipping to change at page 35, line 37
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009. Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
using SIP Request-URI", RFC 3087, April 2001. using SIP Request-URI", RFC 3087, April 2001.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005. Media Services with SIP", RFC 4240, December 2005.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
Appendix A. Request History Requirements Appendix A. 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. History" capability.
1. CAPABILITY-req: The "Request History" capability provides a 1. CAPABILITY-req: The "Request History" capability provides a
capability to inform proxies and UAs involved in processing a capability to inform proxies and UAs involved in processing a
skipping to change at page 36, line 37 skipping to change at page 38, line 33
This scenario highlights an example where the History-Info in the This scenario highlights an example where the History-Info in the
response is useful to an application or user that originated the response is useful to an application or user that originated the
request. request.
Alice sends a call to Bob via sip:example.com. The proxy sip: Alice sends a call to Bob via sip:example.com. The proxy sip:
example.com sequentially tries Bob on a SIP UA that has bound a example.com sequentially tries Bob on a SIP UA that has bound a
contact with the sip:bob@example.com AOR, and then several alternate contact with the sip:bob@example.com AOR, and then several alternate
addresses (Office and Home) unsuccessfully before sending a response addresses (Office and Home) unsuccessfully before sending a response
to Alice. The hi-entry containing the initial contact is the hi- to Alice. The hi-entry containing the initial contact is the hi-
entry just prior to the first hi-entry tagged with an hi-target value entry just prior to the first hi-entry tagged with an "rc" header
of "rc". In this example, the Office and Home are not the same AOR field parameter. In this example, the Office and Home are not the
as sip:bob@example.com, but rather different AORs that have been same AOR as sip:bob@example.com, but rather different AORs that have
configured as alternate addresses for Bob in the proxy. In other been configured as alternate addresses for Bob in the proxy. In
words, Office and Bob are not bound through SIP Registration with other words, Office and Bob are not bound through SIP Registration
Bob's AOR. This type of arrangement is common for example when a with Bob's AOR. This type of arrangement is common for example when
"routing" rule to a PSTN number is manually configured in a Proxy. a "routing" rule to a PSTN number is manually configured in a Proxy.
These hi-entries are identified by the index contained in the hi- These hi-entries are identified by the index contained in the hi-
target "mp" parameter in the hi-entries. target-param "mp" header field parameter in the hi-entries.
This scenario illustrates that by providing the History-Info to This scenario illustrates that by providing the History-Info to
Alice, the end-user or an application at Alice could make a decision Alice, the end-user or an application at Alice could make a decision
on how best to attempt finding Bob without sending multiple requests on how best to attempt finding Bob without sending multiple requests
to the same destination. Upon receipt of the response containing the to the same destination. Upon receipt of the response containing the
History-Info entries, the Request URIs for the History-Info entries History-Info entries, the Request URIs for the History-Info entries
tagged with "mp" are extracted. Those Request-URIs can be compared tagged with "mp" header field parameter are extracted. Those
to other URIs (if any) that might be attempted in order to establish Request-URIs can be compared to other URIs (if any) that might be
the session with Bob. Thus, avoiding another INVITE to Bob's home attempted in order to establish the session with Bob. Thus, avoiding
phone. Without this mechanism, Alice might well attempt to reach Bob another INVITE to Bob's home phone. Without this mechanism, Alice
at his office phone, which would then retarget the request to Bob's might well attempt to reach Bob at his office phone, which would then
home phone. When that attempt failed, then Alice might attempt to retarget the request to Bob's home phone. When that attempt failed,
reach Bob directly at his home phone, unknowingly for a third time. then Alice might attempt to reach Bob directly at his home phone,
unknowingly for a third time.
Alice example.com Bob Office Home Alice example.com Bob Office Home
| | | | | | | | | |
| INVITE F1 | | | | | INVITE F1 | | | |
|----------->| INVITE F2 | | | |----------->| INVITE F2 | | |
| |----------------->| | | | |----------------->| | |
| 100 Trying F3 | | | | 100 Trying F3 | | |
|<-----------| 302 Move Temporarily F4 | | |<-----------| 302 Move Temporarily F4 | |
| |<-----------------| | | | |<-----------------| | |
| | ACK F5 | | | | | ACK F5 | | |
 End of changes. 81 change blocks. 
316 lines changed or deleted 358 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/