draft-ietf-sipcore-rfc4244bis-03.txt   draft-ietf-sipcore-rfc4244bis-04.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: August 18, 2011 S. Schubert Expires: September 16, 2011 S. Schubert
NTT NTT
J. van Elburg J. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
February 14, 2011 March 15, 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-03.txt draft-ietf-sipcore-rfc4244bis-04.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
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 August 18, 2011. This Internet-Draft will expire on September 16, 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 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. History-Info Header Field Protocol Structure . . . . . . . . . 7 5. History-Info Header Field Protocol Structure . . . . . . . . . 7
5.1. History-Info Header Field Example Scenario . . . . . . . . 9 5.1. History-Info Header Field Example Scenario . . . . . . . . 9
6. User Agent Handling of the History-Info Header Field . . . . . 12 6. User Agent Handling of the History-Info Header Field . . . . . 12
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 12 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 12
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 12 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 12
6.2.1. Processing of Requests with History-Info . . . . . . . 12 7. Proxy/Intermediary Handling of History-Info Header Fields . . 12
6.2.2. Generation of Responses with History-Info . . . . . . 13 8. Redirect Server Handling of History-Info Header Fields . . . . 13
7. Proxy/Intermediary Handling of History-Info Header Fields . . 13 9. Handling of History-Info Header Fields in Requests and
7.1. Adding the History-Info Header Field to Requests . . . . . 13 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1.1. Forwarding a Request . . . . . . . . . . . . . . . . . 14 9.1. Receiving a Request with History-Info . . . . . . . . . . 13
7.1.2. Retargeting based on failure or 3xx response . . . . . 14 9.2. Sending a Request with History-Info . . . . . . . . . . . 14
7.2. Sending History-Info in Responses . . . . . . . . . . . . 15 9.3. Receiving a Response with History-Info . . . . . . . . . . 14
8. Redirect Server Handling of History-Info Header Fields . . . . 16 9.4. Sending History-Info in Responses . . . . . . . . . . . . 15
9. Processing the History-Info Header Field Parameters . . . . . 16 10. Processing the History-Info Header Field . . . . . . . . . . . 15
9.1. Privacy in the History-Info Header Field . . . . . . . . . 16 10.1. Privacy in the History-Info Header Field . . . . . . . . . 15
9.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . . 16 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 16
9.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . . 17 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 17
9.2. Reason in the History-info Header Field . . . . . . . . . 18 10.2. Reason in the History-info Header Field . . . . . . . . . 17
9.3. Indexing in the History-Info Header Field . . . . . . . . 19 10.3. Indexing in the History-Info Header Field . . . . . . . . 18
9.4. Mechanism for Target Determination in the History-Info 10.4. Mechanism for Target Determination in the History-Info
Header Field . . . . . . . . . . . . . . . . . . . . . . . 20 Header Field . . . . . . . . . . . . . . . . . . . . . . . 19
10. Application Considerations . . . . . . . . . . . . . . . . . . 21 11. Application Considerations . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12.1. Registration of New SIP History-Info Header Field . . . . 24 13.1. Registration of New SIP History-Info Header Field . . . . 23
12.2. Registration of "history" for SIP Privacy Header Field . . 24 13.2. Registration of "history" for SIP Privacy Header Field . . 23
12.3. Registration of Header Field Parameters . . . . . . . . . 25 13.3. Registration of Header Field Parameters . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
14. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 25 15. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 25
14.1. Backwards compatibility . . . . . . . . . . . . . . . . . 27 15.1. Backwards compatibility . . . . . . . . . . . . . . . . . 26
15. Changes since last Version . . . . . . . . . . . . . . . . . . 27 16. Changes since last Version . . . . . . . . . . . . . . . . . . 26
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 17.1. Normative References . . . . . . . . . . . . . . . . . . . 32
16.2. Informative References . . . . . . . . . . . . . . . . . . 34 17.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Request History Requirements . . . . . . . . . . . . 34 Appendix A. Request History Requirements . . . . . . . . . . . . 33
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 35 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 35
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 36 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 35
Appendix B. Example call flows . . . . . . . . . . . . . . . . . 37 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 36
B.1. Sequentially Forking (History-Info in Response) . . . . . 37 B.1. Sequentially Forking (History-Info in Response) . . . . . 36
B.2. History-Info with Privacy Header Field . . . . . . . . . . 44 B.2. History-Info with Privacy Header Field . . . . . . . . . . 43
B.3. Privacy for a Specific History-Info Entry . . . . . . . . 46 B.3. Privacy for a Specific History-Info Entry . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
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 requests 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
skipping to change at page 6, line 44 skipping to change at page 6, line 44
request. The ABNF and detailed description of the History-Info request. The ABNF and detailed description of the History-Info
header field parameters, along with examples is provided in header field parameters, along with examples is provided in
Section 5. Section 6, Section 7 and Section 8 provide the detailed Section 5. Section 6, Section 7 and Section 8 provide the detailed
handling of the History-Info header field by SIP User Agents, Proxies handling of the History-Info header field by SIP User Agents, Proxies
and Redirect Servers respectively. and Redirect Servers respectively.
This specification also defines two new SIP header field parameters, This specification also defines two new SIP header field parameters,
"rc" and "mp", for the History-Info and Contact header fields, to tag "rc" and "mp", for the History-Info and Contact header fields, to tag
the method by which the target of a request is determined. Further the method by which the target of a request is determined. Further
detail on the use of these header field parameters is provided in detail on the use of these header field parameters is provided in
Section 9.4. Section 10.4.
In addition, this specification defines a priv-value for the Privacy In addition, this specification defines a priv-value for the Privacy
header, "history", that applies to all the History-info header field header, "history", that applies to all the History-info header field
entries in a Request or to a specific History-info header field hi- entries in a Request or to a specific History-info header field hi-
entry as described above. Further detail is provided in Section 9.1. entry as described above. Further detail is provided in
Section 10.1.
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
skipping to change at page 7, line 28 skipping to change at page 7, line 28
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 9.3), including the index and securing the header, the in Section 10.3), including the index and securing the header, the
ordering of the History-info header fields in the request is ordering of the History-info header fields in the request is
assured. In addition, applications may extract a variety of assured. In addition, applications may extract a variety of
metrics (total number of retargets, total number of retargets from metrics (total number of retargets, total number of retargets from
a specific branch, etc.) based upon the index values. 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:
skipping to change at page 8, line 44 skipping to change at page 8, line 44
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 a Privacy header field, which
are both escaped in the hi-targeted-to-uri as described below: are both included in 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] escaped in the hi-targeted-to-uri. A reason is included [RFC3326] included in the hi-targeted-to-uri. A reason is
for the hi-targeted-to-uri that was retargeted as opposed to the included for the hi-targeted-to-uri that was retargeted as opposed
hi-targeted-to-uri to which it was retargeted. to the hi-targeted-to-uri to which it was retargeted.
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] escaped 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
escaped 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.
Note that since both the Reason and Privacy parameters are escaped in Note that since both the Reason and Privacy parameters are included
the hi-targeted-to-uri, these fields will not be available in the in the hi-targeted-to-uri, these fields will not be available in the
case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. In such case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. In such
cases, the Tel-URI SHOULD be transformed into a SIP URI per section cases, the Tel-URI SHOULD be transformed into a SIP URI per section
19.1.6 of [RFC3261]. 19.1.6 of [RFC3261].
The following provides examples of the format for the History-info The following provides examples of the format for the History-info
header field. Note that the backslash and CRLF between the fields in header field. Note that the backslash and CRLF between the fields in
the examples below are for readability purposes only. the examples below are for readability purposes only.
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar
skipping to change at page 12, line 8 skipping to change at page 12, line 8
| History-Info: <sip:bob@192.0.2.3;index=1.1.1;rc=1.1 | History-Info: <sip:bob@192.0.2.3;index=1.1.1;rc=1.1
| | | | | | | | | |
| ACK | | | | | ACK | | | |
|--------------->| 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
This section describes the processing specific to UAs for the A B2BUA MAY follow the behavior of a SIP intermediary as an
History-info header field. 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
forward hi-entries received in requests at the UAS to the request
being forwarded by the UAC, as well as carrying forward responses
received at the UAC to the responses forwarded by the UAS, 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 in any new or out-of-dialog request for which the UAC would
like the History-info header field in the response. In addition, the like the History-info header field in the response. When issuing a
UAC MUST add a History-info header field, using the Request-URI of request, the UAC MUST follow the procedures in Section 9.2. Note
the request as the hi-targeted-to-uri. The hi-index MUST be set to a that in the case of an initial request, there is no cache of hi-
value of 1 in the hi-entry. This allows intermediaries and the UAS entries with which to populate the History-info header field as
to at least know the original Request-URI. In the case of a B2BUA, a described in and the hi-index is set to 1 per Section 10.3. When
UAC MAY add the hi-entries received in the incoming request at the receiving a response the UAC MUST follow the procedures in
UAS to the subsequent outgoing request. Section 9.3.
In the case where a UAC receives a 3xx response with a Contact header
field and sends a new request in response to it, the UAC MAY include
in the outgoing request the previous hi-entry(s) received in the
response. In this case, the UAC MUST escape the Reason header field
in the previous (last) hi-entry, as described in Section 9.2. The
UAC MUST add an hi-entry using the Request-URI of the outgoing
request as the hi-targeted-to-uri. An hi-index MUST be added to the
hi-entry. The value for the index is determined following the rules
for "Retargeting based upon a Response" as prescribed in Section 9.3.
If the Contact header field contains an "rc" or "mp" header field
parameter, the UAC MUST add the header field parameter to the new hi-
entry as described in Section 9.4. The procedures defined in
Section 9.1 are followed to indicate any privacy that the UAC wants
applied to the hi-targeted-to-uri.
6.2. User Agent Server (UAS) Behavior 6.2. User Agent Server (UAS) Behavior
6.2.1. Processing of Requests with History-Info 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
UAS MUST follows the procedures as defined in Section 9.4. When
sending a 3xx response, the UAS MUST follow the procedures defined
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.
Once the request terminates at the UAS, the UAS evaluates the 7. Proxy/Intermediary Handling of History-Info Header Fields
History-info header field. The last hi-entry reflects the most
recent target and contains the Request-URI for the received request,
unless the previous entity that forwarded the request does not
support the History-info header field. If the Request-URI of the
incoming request does not match the last hi-entry (e.g., the previous
entity does not support History-Info), the UAS MUST insert an hi-
entry. The UAS MUST set the hi-targeted-to-uri based to the value of
Request-URI in the incoming request. If privacy is required for the
hi-entry in the response, the UAS MUST escape a Privacy header field
with a value of "history" in the hi-entry. The UAS MUST include an
hi-index parameter as described in Section 9.3. The UAS MUST NOT
include a hi-target attribute, since the UAS has no way to know the
mechanism by which the Request-URI was determined. The addition of
the missing hi-entry ensures that the most complete information can
be provided in the response and provides consistency in the
information presented to applications. The information can also be
useful for implementations with B2BUAs that include the History-Info,
received in the incoming request, in the outgoing request.
Prior to any application usage of the information, the UAS ascertains This section describes the procedures for proxies and other SIP
the validity of the information as described in Section 10. intermediaries for the handling of the History-Info header fields for
each of the following scenarios:
6.2.2. Generation of Responses with History-Info For each outgoing request relating to a target in the target set,
the intermediary MUST add an hi-entry for the specific target, per
the procedures in Section 9.2.
If the "histinfo" option tag is received in a request, the UAS MUST An intermediary MUST follow the procedures in Section 9.1 for the
include any History-Info received in the request and any hi-entries handling of hi-entries in incoming SIP requests.
added by the UAS. In addition, in the case of a B2BUA, the UAS MAY
include any hi-entries received by the UAC in the subsequent
response. If privacy is required, entries MUST be anonymized as
described in Section 9.1. The UAS MUST follow the rules for a
redirect server per Section 8 in generating a 3xx response.
7. Proxy/Intermediary Handling of History-Info Header Fields An intermediary MUST follow the procedures of Section 9.4 for for
the handling of the hi-entries when sending a SIP response.
This section describes the procedures for proxies and other SIP An intermediary MUST follow the procedures of Section 9.3 when a
intermediaries for adding History-Info headers when requests are SIP response containing hi-entries is received.
retargeted.
7.1. Adding the History-Info Header Field to Requests In some cases, an intermediary may retarget a request more than once
before forwarding - i.e., a request is retargeted to a SIP entity
that is "internal" to the intermediary before the same intermediary
retargets the request to an external target . A typical example
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
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
procedures in Section 9.2. The intermediary MAY include a Reason
header field in the hi-entry with the hi-targeted-to-uri that has
been retargeted as shown in the INVITE (F6) in the example in
Appendix B.1. Figure 1 provides an example of internal retargeting.
This section describes the process of adding the History-Info header 8. Redirect Server Handling of History-Info Header Fields
to requests in the case of retargeting due to normal forwarding of
requests (Section 7.1.1) and in the case of failure or redirection
responses (Section 7.1.2). Retargeting is an iterative process,
i.e., an intermediary may retarget "internally " more than one time.
A typical example 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 contact bound to that new AOR. In cases of
internal retargeting, an intermediary MUST add multiple hi-entries.
For example, an intermediary that retargets bob@example.com to
office@example.com and then to office@192.0.2.5 adds hi-entries for
both office@example.com and office@192.0.2.5, in order to provide a
logical description of the retargeting process internal to the
intermediary. Thus, the intermediary MAY escape a Reason header
field in the hi-entry with the hi-targeted-to-uri that has been
retargeted as shown in the INVITE (F6) in the example in
Appendix B.1.
7.1.1. Forwarding a Request A redirect server MUST follow the procedures in Section 9.1 when it
receives a SIP Request. A redirect server MUST follow the procedures
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
the appropriate target header field parameter to each Contact header
field as described in Section 10.4, if applicable.
Upon receipt of a request for a dialog, or a standalone request, a 9. Handling of History-Info Header Fields in Requests and Responses
proxy or intermediary forwarding the request performs the following
steps. Note that those steps below do not apply if the request is
being retargeted as a result of failure (i.e., timeout, reception of
an error response).
Step 1: Adding Entries on Behalf of Previous Hops This section describes the procedures for SIP entities for the
handling of SIP requests and responses containing the History-Info
header fields.
If an incoming request does not already have a History-Info header 9.1. Receiving a Request with History-Info
field (i.e., the UAC does not include any History-info header
field and none of the previous SIP intermediaries support History-
Info) or 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
intermediary does not support History-Info) an hi-entry MUST be
inserted on behalf of the UAC or intermediary. The SIP
intermediary MUST set the hi-targeted-to-uri to the value of the
Request-URI in the incoming request. If privacy is required, the
procedures of Section 9.1 are followed. The SIP intermediary MUST
NOT include an "rc" or "mp" header field parameter. The hi-index
parameter MUST be set to a value of "1", as described in
Section 9.3.
Step 2: Generating New Entries for Each Outgoing Request When receiving a request, a SIP entity MUST create a cache containing
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
request.
The SIP intermediary then proceeds to request forwarding as per If the Request-URI of the incoming request does not match the hi-
16.6/[RFC3261]. For each outgoing request relating to a target in targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
the target set, the intermediary MUST add an hi-entry for the that sent the request did not include a History-Info header field),
specific target. The intermediary MUST set the hi-targeted-to-uri the SIP entity MUST add an hi-entry to end of the cache, on behalf of
in the hi-entry to the value of the Request-URI of the current the previous SIP entity, as follows:
(outgoing) request. If privacy is required, the procedures of
Section 9.1 are followed. The proxy MUST include an hi-index for
the hi-entry as described in Section 9.3. The proxy then includes
an "rc" or "mp" header field parameter in the hi-entry, if
applicable, as described in Section 9.4.
7.1.2. Retargeting based on failure or 3xx response The SIP entity MUST set the hi-targeted-to-uri to the value of the
Request-URI in the incoming request.
When retargeting a request because of a failure (i.e., either If privacy is required, the SIP entity MUST follow the procedures
reception of error responses or a timeout which is considered to be of Section 10.1.
an implicit 408 error response) or receipt of a 3XX response, the SIP
entity performs the following steps:
Step 1: Including the Entries from Responses The SIP entity MUST set the hi-index parameter to a value of "1",
as described in Section 10.3.
Along with the History-Info header fields sent in the original The SIP entity MUST NOT include an "rc" or "mp" header field
request that received an error or 3xx response or timed out, the parameter.
SIP entity MUST include any new History-Info header field(s)
contained in all responses received thus far (including any new
hi-entries in the error or 3xx response) in the new outgoing
request. The hi-entries MUST be added to the new outgoing request
in the order indicated by the values in the hi-index parameters of
the hi-entries.
Step 2: Tagging the Last Entries 9.2. Sending a Request with History-Info
The SIP entity then examines the History-Info header fields When sending a request, a SIP entity MUST include all cached hi-
generated in Step 1. For each of the branches that generated entries in the request. In addition, the SIP entity MUST add a new
failures or timeouts or received a 3xx response, the SIP entity hi-entry to the outgoing request populating the header field as
MUST add a Reason header field to the hi-entry for each of those follows:
branches per the procedures of Section 9.2.
Step 3: Generating New Entries for Each Outgoing Requests The hi-targeted-to-uri MUST be set to the value of the Request-URI
of the current (outgoing) request.
Same as per Step 2 above for the normal forwarding case If privacy is required, the procedures of Section 10.1 MUST be
Section 7.1.1. followed.
7.2. Sending History-Info in Responses The SIP entity MUST include an hi-index for the hi-entry as
described in Section 10.3.
A SIP entity that receives a request with the "histinfo" option tag The SIP entity MUST include an "rc" or "mp" header field parameter
in the Supported header, MUST forward captured History-Info in in the hi-entry, if applicable, per the procedures in
subsequent, provisional, and final responses to the request sent by Section 10.4.
the ultimate UAS (see Section 6.2), applying the privacy procedures
as described in Section 9.1.2. The captured History-Info includes
all hi-entries received in the request, as well as the hi-entries
that are generated by a SIP entity as a request is retargeted as
described in Section 7.1, which also includes hi-entries that are
received in other responses. Note that in the case of parallel
forking where one branch is successful, only the branches for which
responses have been received at the time the proxy sends the
successful response are included in that response. For example, an
intermediary receives a request with the last hi-entry having an hi-
index of 1.1. The intermediary forks three requests in parallel with
each request containing a unique hi-entry with the hi-targeted-to-
uris set to the value of the Request URI for the request. The hi-
entries each have unique hi-index values of 1.1.1, 1.1.2 and 1.1.3
respectively. If the processing entity receives a failure response
for the branch reflected by the hi-entry with the index of 1.1.2 and
a successful response for the branch reflected by the hi-entry with
the index of 1.1.3, but has not yet received a response for the
branch reflected by the hi-entry with an index of 1.1.1, it would
return only the 1.1.2 and 1.1.3 entries with indices of 1.1.2 and
1.1.3 to the entity that generated the hi-entry with index of 1.1.
See Appendix B.1 for an example.
The the addition of the History-Info header fields to responses 9.3. Receiving a Response with History-Info
described above follows the methodology described in Section 16.7 of
[RFC3261] for the addition of header fields, with the inclusion of
History-info header fields adding an additional step, just before
Step 9, "Forwarding the Response".
8. Redirect Server Handling of History-Info Header Fields When a SIP entity receives a response other than a 100, the SIP
entity performs the following steps:
A redirect server MUST include the History-info header fields Step 1: Add hi-entry to cache
received in the request in the 3XX response that it sends. A
redirect server MUST add any new History-Info entries in cases of
retargeting (both internal and to other SIP entities) in the same
manner as prescribed for SIP intermediaries Section 7. In generating
the Contact header field in the 3xx response, the redirect server
adds the appropriate target header field parameter to each Contact
header field as described in Section 9.4.
9. Processing the History-Info Header Field Parameters 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
already cached. The hi-entry MUST be added to the cache in
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
before 1.3).
The following sections describe the procedures for processing Step 2: Add Reason header field
History-Info header field parameters and the header fields escaped in
the History-info header field. These procedures are applicable to The SIP entity then MUST add a Reason header field to the (newly)
SIP entities such as Proxies/Intermediaries, Redirect Servers or User cached hi-entry reflecting the SIP response code in the non-100
response, per the procedures of Section 10.2.
Step 3: Add additional hi-entries
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
can occur when the entity that generated the non-100 response
retargeted the request before generating the response. As per
Step 1, the hi-entries MUST be added to the cache in ascending
order as indicated by the values in the hi-index parameters of the
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
can be gaps in indices (e.g., 1.2 and 1.4 could but present but not
1.3).
9.4. Sending History-Info in Responses
When sending a response other than a 100, a SIP entity MUST include
all the cached hi-entries in the response with the following
exception: If the received request contained no hi-entries and there
is no "histinfo" option tag in the Supported header field, the SIP
entity MUST NOT include hi-entries in the response. In the former
case, the privacy procedures as described in Section 10.1.2 MUST be
followed.
10. Processing the History-Info Header Field
The following sections describe the procedures for processing the
History-Info header field. These procedures are applicable to SIP
entities such as Proxies/Intermediaries, Redirect Servers or User
Agents. Agents.
9.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 9.1.1 describes the use of the Privacy header Appendix A.2. Section 10.1.1 describes the use of the Privacy header
field defined in [RFC3323] to indicate the privacy to be applied to field defined in [RFC3323] to indicate the privacy to be applied to
the History-Info header field entries. Section 9.1.2 describes the the History-Info header field entries. Section 10.1.2 describes the
processing of the priv-values in the Privacy header field to privacy processing of the priv-values in the Privacy header field to privacy
protect the History-Info header field entries in the request or protect the History-Info header field entries in the request or
response that is being forwarded. response that is being forwarded.
9.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 the privacy to be applied to all the hi-
entries in the request as follows: 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
skipping to change at page 17, line 26 skipping to change at page 16, line 34
o If the UAC is not including any priv-values in the Privacy header o If the UAC is not including any priv-values in the Privacy header
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 escape 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 hi-entry added by intermediary, as the request is
retargeted within the domain for which the SIP entity is responsible. retargeted within the domain for which the SIP entity is responsible.
The intermediary MUST NOT include any other priv-values in this The intermediary MUST NOT include any other priv-values in this
Privacy header field. Note that the priv-value in the Privacy header Privacy header field. Note that the priv-value in the Privacy header
for the incoming request does not necessarily influence whether the for the incoming request does not necessarily influence whether the
intermediary includes a Privacy header field in the hi-entries. For intermediary includes a Privacy header field in the hi-entries. For
example, even if the Privacy header for the incoming request example, even if the Privacy header for the incoming request
contained a priv-value of "none", the Proxy can still set a priv- contained a priv-value of "none", the Proxy can still set a priv-
value of "history" in the Privacy header field escaped in the hi- value of "history" in the Privacy header field included in the hi-
targeted-to-uri. 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", MUST include a Privacy header field with a priv-value of "history" in
escaped in the hi-targeted-to-uri in the last hi-entry, in the the hi-targeted-to-uri in the last hi-entry, in the response. As
response. As noted above, the terminator of the request MUST NOT use noted above, the terminator of the request MUST NOT use any other
any other priv-values in the Privacy header field escaped in the hi- priv-values in the Privacy header field included in the hi-entry.
entry.
9.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, 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 request and 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 request with a priv-value
of "header" or "history", then the hi-targeted-to-uris in the hi- of "header" or "history", then the hi-targeted-to-uris in the hi-
entries, associated with the domain for which a SIP intermediary is entries, associated with the domain for which a SIP intermediary is
responsible, are anonymized. The Privacy Service MUST change any hi- responsible, are anonymized. The Privacy Service MUST change any hi-
targeted-to-uris in the hi-entries that have not been anonymized to targeted-to-uris in the hi-entries that have not been anonymized to
anonymous URIs containing a domain of anonymous.invalid (e.g., anonymous URIs containing a domain of anonymous.invalid (e.g.,
anonymous@anonymous.invalid). If the hi-entry has an escaped Privacy anonymous@anonymous.invalid). If the hi-targeted-to-uri in the hi-
header field value, then the Privacy header field value MUST be entry contains an Privacy header field, then the Privacy header field
removed from the hi-entry. Once all the appropriate hi-entries have value MUST be removed from the hi-entry. Once all the appropriate
been anonymized, the priv-value of "history" MUST be removed from the hi-entries have been anonymized, the priv-value of "history" MUST be
Privacy header field. If there are no remaining priv-values in the removed from the Privacy header field. If there are no remaining
Privacy header field, the Privacy header field MUST be removed from priv-values in the Privacy header field, the Privacy header field
the request per [RFC3323]. MUST be removed from the request 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 request or response
that is being forwarded, the Privacy Service MUST anonymize any hi- that is being forwarded, the Privacy Service MUST anonymize any hi-
entries, associated with the domain for which a SIP intermediary is entries, associated with the domain for which a SIP intermediary is
responsible, that contain a Privacy header field with a priv-value of responsible, that contain a Privacy header field with a priv-value of
"history". The Privacy Service MUST populate the hi-targeted-to-uri "history". The Privacy Service MUST populate the hi-targeted-to-uri
with an anonymous URI with a domain of anonymous.invalid (e.g., 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 hi-entries MUST be ignored. In any case, the
Privacy Service MUST remove the Privacy header field from the hi- Privacy Service MUST remove the Privacy header field from the hi-
entries prior to forwarding. entries prior to forwarding.
9.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 If the retargeting is due to receipt of an explicit SIP response and
the response contains any Reason header fields (see [RFC3326]), then the response contains any Reason header fields (see [RFC3326]), then
the SIP entity MUST escape the Reason header fields in the hi-entry the SIP entity MUST include the Reason header fields in the hi-
with the hi-targeted-to-uri containing the URI of the request that targeted-to-uri containing the URI of the request that was
was retargeted. If the SIP response does not contain a Reason header retargeted, unless the hi-targeted-to-uri is a Tel-URI. If the SIP
field, the SIP entity MUST include an escaped Reason header field, response does not contain a Reason header field, the SIP entity MUST
containing the SIP Response Code that triggered the retargeting, in include a Reason header field, containing the SIP Response Code that
the hi-entry with the hi-targeted-to-uri containing the URI of the triggered the retargeting, in the hi-targeted-to-uri containing the
request that was retargeted. URI of the request that was retargeted, except in the case that 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 escape 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 in the hi-entry with error response code of 408 "Request Timeout" in hi-targeted-to-uri
the hi-targeted-to-uri containing the URI of the request that was containing the URI of the request that was retargeted. The SIP
retargeted. The SIP entity MAY also be escape a Reason header field entity MAY also include a Reason header field in the hi-targeted-to-
in the hi-entry with the hi-targeted-to-uri containing the URI of the uri containing the URI of the request that was retargeted as a result
request that was retargeted as a result of internal retargeting. of internal retargeting.
If additional Reason headers are defined in the future per [RFC3326], If additional Reason headers are defined in the future per [RFC3326],
the use of these Reason headers for the History-Info header field the use of these Reason headers for the History-Info header field
MUST follow the same rules as described above. MUST follow the same rules as described above.
9.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
retargeted at the specific hop (i.e., the number of branches). Thus, retargeted at the specific hop (i.e., the number of branches). Thus,
the indexing results in a logical tree representation for the history the indexing results in a logical tree representation for the history
skipping to change at page 20, line 28 skipping to change at page 19, line 36
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 for each individual fork, only the
hi-entry corresponding to that fork is included (e.g., the hi- hi-entry corresponding to that fork is included (e.g., the hi-
entry for fork 1.1.1 is not included in the request sent to fork entry for fork 1.1.1 is not included in the request sent to fork
1.1.2, and vice-versa). 1.1.2, and vice-versa).
9.4. Mechanism for Target Determination in the History-Info Header 10.4. Mechanism for Target Determination in the History-Info Header
Field 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 non-inclusive mechanisms by which a new target
for a request is determined. Both parameters contain an index whose for a request is determined. Both parameters contain an index whose
value is the hi-index of the hi-entry with an hi-targeted-to-uri that value is the hi-index of the hi-entry with an hi-targeted-to-uri that
represents the Request-URI that was retargeted. represents 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 History-info header field as the targets are added to
the target set per the procedures in section 16.5 of [RFC3261] or per the target set per the procedures in section 16.5 of [RFC3261] or per
skipping to change at page 21, line 23 skipping to change at page 20, line 29
derived. 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 of the hi-entry's index,
that of the downstream request which received the 3xx response. that of the downstream request which received the 3xx response.
The SIP entity MUST add the "rc" or "mp" header field parameter to 11. Application Considerations
the hi-entry when the request is forwarded to the target per step 2
in Section 7.1.1.
10. 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 7.2. 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 rather indicate
to any applications that there are gaps. The most complete to any applications that there are gaps. The most complete
information available to the application is the History-Info entries information available to the application is the History-Info entries
starting with the last hi-entry with an index of "1". The starting with the last hi-entry with an index of "1". The
interpretation of the information in the History-info header field interpretation of the information in the History-info header field
depends upon the specific application; an application might need to depends upon the specific application; an application might need to
provide special handling in some cases where there are gaps. provide special handling in some cases where there are gaps.
The following summarizes the categories of information that The following summarizes the categories of information that
applications can use: applications can use:
skipping to change at page 23, line 20 skipping to change at page 22, line 22
only partial History-Info entries or entries which are not tagged only partial History-Info entries or entries which are not tagged
appropriately with an hi-target parameter. This may not impact some appropriately with an hi-target parameter. This may not impact some
applications (e.g., debug), however, it could require 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.
11. Security Considerations 12. Security Considerations
The security requirements for this document are specified in The security requirements for this document are specified in
Appendix A.1. Appendix A.1.
This document defines a header for SIP. The use of the Transport This document defines a header for SIP. The use of the Transport
Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the
overall confidentiality of the History-Info headers (SEC-req-4) is overall confidentiality of the History-Info headers (SEC-req-4) is
strongly RECOMMENDED. This results in History-Info having at least strongly RECOMMENDED. This results in History-Info having at least
the same level of security as other headers in SIP that are inserted the same level of security as other headers in SIP that are inserted
by intermediaries. With TLS, History-Info headers are no less, nor by intermediaries. With TLS, History-Info headers are no less, nor
skipping to change at page 23, line 42 skipping to change at page 22, line 44
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.
12. 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 updates [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].
12.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:.
The following row has been added to the header field section: The following row has been added to the header field section:
Header Name Compact Form Reference Header Name Compact Form Reference
----------- ------------ --------- ----------- ------------ ---------
skipping to change at page 24, line 34 skipping to change at page 23, line 36
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 RFC XXXX with the RFC number of
this specification. this specification.
12.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
---- ----------- ---------- --------- ---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFCXXXX] history Privacy requested for Mary Barnes [RFCXXXX]
History-info header mary.barnes@polycom.com History-info header mary.barnes@polycom.com
fields(s) fields(s)
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.
12.3. Registration of Header Field Parameters 13.3. Registration of Header Field Parameters
This specification defines the following new SIP header field This specification defines the following new SIP header field
parameters in the SIP Header Field parameter sub-registry in the SIP parameters in the SIP Header Field parameter sub-registry in the SIP
Parameter Registry, http:/www.iana.org/assignments/sip-parameters. Parameter Registry, http:/www.iana.org/assignments/sip-parameters.
Header Field Parameter Name Predefined Reference Header Field Parameter Name Predefined Reference
Values Values
_____________________________________________________________________ _____________________________________________________________________
History-Info mp No [RFC xxxx] History-Info mp No [RFC xxxx]
History-Info rc No [RFC xxxx] History-Info rc No [RFC xxxx]
Contact mp No [RFC xxxx] Contact mp No [RFC xxxx]
Contact rc No [RFC xxxx] Contact rc No [RFC xxxx]
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.
13. 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.
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
skipping to change at page 25, line 45 skipping to change at page 25, line 5
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].
The editor would like to acknowledge the significant input from Rohan The editor would like to acknowledge the significant input from Rohan
Mahy on some of the normative aspects of the ABNF for [RFC4244], Mahy on some of the normative aspects of the ABNF for [RFC4244],
particularly around the need for and format of the index and around particularly around the need for and format of the index and around
the security aspects. the security aspects.
14. Changes from RFC 4244 15. Changes from RFC 4244
This RFC replaces [RFC4244]. This RFC replaces [RFC4244].
Deployment experience with [RFC4244] over the years has shown a Deployment experience with [RFC4244] over the years has shown a
number of issues, warranting an update: number of issues, warranting an update:
o In order to make [RFC4244] work in "real life", one needs to make o In order to make [RFC4244] work in "real life", one needs to make
"assumptions" on how History-Info is used. For example, many "assumptions" on how History-Info is used. For example, many
implementations filter out many entries, and only leave specific implementations filter out many entries, and only leave specific
entries corresponding, for example, to first and last redirection. entries corresponding, for example, to first and last redirection.
skipping to change at page 27, line 18 skipping to change at page 26, line 22
most complete set of information is available to the applications. most complete set of information is available to the applications.
In addition, editorial changes were done to both condense and clarify In addition, editorial changes were done to both condense and clarify
the text, moving the requirements to an appendix and removing the the text, moving the requirements to an appendix and removing the
inline references to the requirements. The examples were simplified inline references to the requirements. The examples were simplified
and updated to reflect the protocol changes. Several of the call and updated to reflect the protocol changes. Several of the call
flows in the appendix were removed and put into a separate document flows in the appendix were removed and put into a separate document
that includes additional use cases that require the new header that includes additional use cases that require the new header
parameters. parameters.
14.1. Backwards compatibility 15.1. Backwards compatibility
This specification is backwards compatible since [RFC4244] allows for This specification is backwards compatible since [RFC4244] allows for
the addition of new optional parameters. This specification adds an the addition of new optional parameters. This specification adds an
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.
15. 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 03 to 04:
1. Reorganization of sections per John Elwell's comments - i.e., a
common section for building HI referenced by the UA, Intermediary
and Redirect server sections.
2. Removing the use of "escape" when describing the handling of the
Privacy and Reason header fields.
3. Clarification of TEL URIs in terms of not having a Privacy or
Reason header field in the hi-targeted-to-uri.
Changes from 02 to 03: Changes from 02 to 03:
1. Lots of editorial: 1. Lots of editorial:
A. Reorganized sections similar to the RFC 4244 order - i.e., A. Reorganized sections similar to the RFC 4244 order - i.e.,
introduce header field parameters and syntax first, then introduce header field parameters and syntax first, then
describe how the functional entities use the header. This describe how the functional entities use the header. This
removes redundant (and often inconsistent) text describing removes redundant (and often inconsistent) text describing
the parameters. the parameters.
skipping to change at page 33, line 24 skipping to change at page 32, line 43
4. Added hi-target parameter values to HI header to ABNF and 4. Added hi-target parameter values to HI header to ABNF and
protocol description, as well as defining proxy, UAC and UAS protocol description, as well as defining proxy, UAC and UAS
behavior for the parameter. behavior for the parameter.
5. Simplified example call flow in section 4.5. Moved previous call 5. Simplified example call flow in section 4.5. Moved previous call
flow to appendix. flow to appendix.
6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new 6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new
parameter. parameter.
16. References 17. References
16.1. Normative References 17.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
skipping to change at page 34, line 5 skipping to change at page 33, line 22
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC4244] Barnes, M., "An Extension to the Session Initiation [RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244, Protocol (SIP) for Request History Information", RFC 4244,
November 2005. November 2005.
16.2. Informative References 17.2. Informative References
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[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.
 End of changes. 75 change blocks. 
280 lines changed or deleted 248 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/