draft-ietf-sipcore-rfc4244bis-02.txt   draft-ietf-sipcore-rfc4244bis-03.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: April 29, 2011 S. Schubert Expires: August 18, 2011 S. Schubert
NTT NTT
J. van Elburg J. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
October 26, 2010 February 14, 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-02.txt draft-ietf-sipcore-rfc4244bis-03.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 call 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
History-Info, for capturing the history information in requests. SIP field, History-Info, for capturing the history information in
header field parameters are defined to tag the method by which the requests. The document also defines SIP header field parameters for
target of a request is determined. In addition, this document the History-Info and Contact header fields to tag the method by which
defines a value for the Privacy header specific to the History-Info the target of a request is determined. In addition, this document
header. defines a value for the Privacy header field specific to the History-
Info header field.
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 April 29, 2011. This Internet-Draft will expire on August 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. General User Agent Behavior . . . . . . . . . . . . . . . . . 10 5. History-Info Header Field Protocol Structure . . . . . . . . . 7
5.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 10 5.1. History-Info Header Field Example Scenario . . . . . . . . 9
5.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 10 6. User Agent Handling of the History-Info Header Field . . . . . 12
5.2.1. Processing of Requests with History-Info . . . . . . . 10 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 12
5.2.2. Generation of Responses with History-Info . . . . . . 11 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 12
5.3. Redirect Server Behavior . . . . . . . . . . . . . . . . . 11 6.2.1. Processing of Requests with History-Info . . . . . . . 12
6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.2. Generation of Responses with History-Info . . . . . . 13
6.1. Adding the History-Info Header to Requests . . . . . . . . 12 7. Proxy/Intermediary Handling of History-Info Header Fields . . 13
6.1.1. Initial Request . . . . . . . . . . . . . . . . . . . 12 7.1. Adding the History-Info Header Field to Requests . . . . . 13
6.1.2. Re-sending based on failure response . . . . . . . . . 13 7.1.1. Forwarding a Request . . . . . . . . . . . . . . . . . 14
6.1.3. Re-sending based on redirection response . . . . . . . 14 7.1.2. Retargeting based on failure or 3xx response . . . . . 14
6.2. Sending History-Info in Responses . . . . . . . . . . . . 14 7.2. Sending History-Info in Responses . . . . . . . . . . . . 15
7. The History-Info header field . . . . . . . . . . . . . . . . 14 8. Redirect Server Handling of History-Info Header Fields . . . . 16
7.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Processing the History-Info Header Field Parameters . . . . . 16
7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Privacy in the History-Info Header Field . . . . . . . . . 16
7.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . . 16
7.3.1. Privacy in the History-Info Header . . . . . . . . . . 17 9.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . . 17
7.3.2. Reason in the History-Info Header . . . . . . . . . . 18 9.2. Reason in the History-info Header Field . . . . . . . . . 18
7.3.3. Indexing in the History-Info Header . . . . . . . . . 18 9.3. Indexing in the History-Info Header Field . . . . . . . . 19
7.3.4. Request Target in the History-Info Header . . . . . . 20 9.4. Mechanism for Target Determination in the History-Info
8. Application Considerations . . . . . . . . . . . . . . . . . . 21 Header Field . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Application Considerations . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. Registration of New SIP History-Info Header . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.2. Registration of "history" for SIP Privacy Header . . . . . 24 12.1. Registration of New SIP History-Info Header Field . . . . 24
10.3. Registration of Header Field Parameters . . . . . . . . . 24 12.2. Registration of "history" for SIP Privacy Header Field . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 12.3. Registration of Header Field Parameters . . . . . . . . . 25
12. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Backwards compatibility . . . . . . . . . . . . . . . . . 26 14. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 25
13. Changes since last Version . . . . . . . . . . . . . . . . . . 27 14.1. Backwards compatibility . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. Changes since last Version . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . . 33
Appendix A. Request History Requirements . . . . . . . . . . . . 33 16.2. Informative References . . . . . . . . . . . . . . . . . . 34
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 34 Appendix A. Request History Requirements . . . . . . . . . . . . 34
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 35 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 35
Appendix B. Example call flows . . . . . . . . . . . . . . . . . 35 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 36
B.1. Sequentially Forking (History-Info in Response) . . . . . 35 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 37
B.2. History-Info with Privacy Header . . . . . . . . . . . . . 43 B.1. Sequentially Forking (History-Info in Response) . . . . . 37
B.3. Privacy Header for a Specific History-Info Entry . . . . . 45 B.2. History-Info with Privacy Header Field . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 B.3. Privacy for a Specific History-Info Entry . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
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 the call arrived at a specific application. to determine why and how a SIP requests arrived at a specific
Examples of such services include (but are not limited to) sessions application. Examples of such services include (but are not limited
initiated to call centers via "click to talk" SIP Uniform Resource to) sessions initiated to call centers via "click to talk" SIP
Locators (URLs) on a web page, "call history/logging" style services Uniform Resource Locators (URLs) on a web page, "call history/
within intelligent "call management" software for SIP User Agents logging" style services within intelligent "call management" software
(UAs), and calls to voicemail servers. Although SIP implicitly for SIP User Agents (UAs), and calls to voicemail servers. Although
provides the retarget capabilities that enable calls to be routed to SIP implicitly provides the retarget capabilities that enable SIP
chosen applications, there is a need for a standard mechanism within requests to be routed to chosen applications, there is a need for a
SIP for communicating the retargeting history of such a request. standard mechanism within SIP for communicating the retargeting
This "request history" information allows the receiving application history of the requests. This "request history" information allows
to determine hints about how and why the call arrived at the the receiving application to determine hints about how and why the
application/user. SIP request arrived at the application/user.
This document defines a SIP header, History-Info, to provide a This document defines a SIP header field, History-Info, to provide a
standard mechanism for capturing the request history information to standard mechanism for capturing the request history information to
enable a wide variety of services for networks and end-users. SIP enable a wide variety of services for networks and end-users. SIP
header field parameters are defined to tag the method by which the header field parameters are defined for the History-Info and Contact
target of a request is determined. In addition, this document header fields to tag the method by which the target of a request is
defines a value for the Privacy header specific to the History-Info determined. In addition, this document defines a value for the
header. Privacy header field specific to the History-Info header.
The History-Info header provides a building block for development of The History-info header field provides a building block for
SIP based applications and services. The requirements for the development of SIP based applications and services. The requirements
solution described in this document are included in Appendix A. for the solution described in this document are included in
Example scenarios using the History-Info header are included in Appendix A. Example scenarios using the History-info header field
Appendix B. are included in Appendix B.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The term "retarget" is used in this document to refer to the process The term "retarget" is used in this document to refer to the process
of a SIP entity changing a Uniform Resource Identifier (URI) in a of a SIP entity changing a Uniform Resource Identifier (URI) in a
request based on the rules for determining request targets as request based on the rules for determining request targets as
skipping to change at page 5, line 14 skipping to change at page 5, line 14
used consistent with the terminology in [RFC3261]. used consistent with the terminology in [RFC3261].
The references to "domain for which the SIP entity/Proxy/Intermediary The references to "domain for which the SIP entity/Proxy/Intermediary
is responsible" are consistent with and intended to convey the same is responsible" are consistent with and intended to convey the same
context as the usage of that terminology in [RFC3261]. The context as the usage of that terminology in [RFC3261]. The
applicability of History-Info to architectures or models outside the applicability of History-Info to architectures or models outside the
context of [RFC3261] is outside the scope of this specification. context of [RFC3261] is outside the scope of this specification.
3. Background 3. Background
SIP implicitly provides retargeting capabilities that enable calls to SIP implicitly provides retargeting capabilities that enable SIP
be routed to specific applications as defined in [RFC3261]. The requests to be routed to specific applications as defined in
motivation for capturing the request history is that in the process [RFC3261]. The motivation for capturing the request history is that
of retargeting a request, old routing information can be forever in the process of retargeting a request, old routing information can
lost. This lost information may be important history that allows be forever lost. This lost information may be important history that
elements to which the call is retargeted to process the call in a allows elements to which the request is retargeted to process the
locally defined, application-specific manner. This document defines request in a locally defined, application-specific manner. This
a mechanism for transporting the request history. Application- document defines a mechanism for transporting the request history.
specific behavior is outside the scope of this specification. Application-specific behavior is outside the scope of this
specification.
Current network applications provide the ability for elements Current network applications provide the ability for elements
involved with the call to exchange additional information relating to involved with the request to obtain additional information relating
how and why the call was routed to a particular destination. The to how and why the request was routed to a particular destination.
following are examples of such applications: The following are examples of such applications:
1. Web "referral" applications, whereby an application residing 1. Web "referral" applications, whereby an application residing
within a web server determines that a visitor to a website has within a web server determines that a visitor to a website has
arrived at the site via an "associate" site that will receive arrived at the site via an "associate" site that will receive
some "referral" commission for generating this traffic some "referral" commission for generating this traffic
2. Email forwarding whereby the forwarded-to user obtains a 2. Email forwarding whereby the forwarded-to user obtains a
"history" of who sent the email to whom and at what time "history" of who sent the email to whom and at what time
3. Traditional telephony services such as voicemail, call-center 3. Traditional telephony services such as voicemail, call-center
skipping to change at page 6, line 13 skipping to change at page 6, line 16
[RFC5627], which can be overwritten by a home proxy upon receipt [RFC5627], which can be overwritten by a home proxy upon receipt
of the initial request. of the initial request.
o Facilitating the use of limited use addresses (minted on demand) o Facilitating the use of limited use addresses (minted on demand)
and sub-addressing. and sub-addressing.
o Preserving service specific URIs that can be overwritten by a o Preserving service specific URIs that can be overwritten by a
downstream proxy, such as those defined in [RFC3087], and control downstream proxy, such as those defined in [RFC3087], and control
of network announcements and IVR with SIP URI [RFC4240]. of network announcements and IVR with SIP URI [RFC4240].
4. Overview of Operation 4. Overview
The fundamental functionality provided by the request history The fundamental functionality provided by the request history
information is the ability to inform proxies and UAs involved in information is the ability to inform proxies and UAs involved in
processing a request about the history or progress of that request processing a request about the history or progress of that request.
(CAPABILITY-req, see Appendix A). The solution is to capture the The solution is to capture the Request-URIs as a request is
Request-URIs as a request is retargeted, in a SIP header: History- retargeted, in a SIP header field: History-Info. This allows for the
Info (CONTENT-req, see Appendix A). This allows for the capturing of capturing of the history of a request that would be lost with the
the history of a request that would be lost with the normal SIP normal SIP processing involved in the subsequent retargeting of the
processing involved in the subsequent retargeting of the request. request.
The History-Info header can appear in any request not associated with The History-info header field is added to a Request when a new
an early or established dialog (e.g., INVITE, REGISTER, MESSAGE, request is created by a UAC or forwarded by a Proxy, or when the
REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY- target of a request is changed. It is possible for the target of a
req, see Appendix A) and any provisional or final responses to these request to be changed by the same proxy/SIP Intermediary multiple
requests (ISSUER-req, see Appendix A). times (referred to as 'internal retargeting'). A SIP entity changing
the target of a request in response to a redirect also propagates any
History-info header field from the initial request in the new
request. The ABNF and detailed description of the History-Info
header field parameters, along with examples is provided in
Section 5. Section 6, Section 7 and Section 8 provide the detailed
handling of the History-Info header field by SIP User Agents, Proxies
and Redirect Servers respectively.
The following information is carried in the History-Info header as This specification also defines two new SIP header field parameters,
detailed in Section 7.1: "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
detail on the use of these header field parameters is provided in
Section 9.4.
o Targeted-to-URI: The targeted-to-URI entry captures the Request- In addition, this specification defines a priv-value for the Privacy
URI for the specific request as it is forwarded. header, "history", that applies to all the History-info header field
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.
o Index: The index reflects the chronological order of the 5. History-Info Header Field Protocol Structure
information, indexed to also reflect the forking and nesting of
requests.
o Reason: Reason describes why an entry was retargeted. The History-info header field can appear in any request not
associated with an early or established dialog (e.g., INVITE,
REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.)
and any non-100 provisional or final responses to these requests
(ISSUER-req, see Appendix A).
o Privacy: Privacy is used to request that an entry be anonymized if The following provides details for the information that is captured
the request is retargeted to a domain for which the retargeting in the History-Info header field entries for each target used for
entity is not responsible. forwarding a request:
o Target: A parameter indicating whether the Targeted-to-URI is a o hi-targeted-to-uri: A mandatory parameter for capturing the
registered contact ("rc") for another user mapped ("mp") from the Request-URI for the specific request as it is forwarded.
Request-URI in the incoming request that was retargeted. The
index of the History-Info entry for the URI that was retargeted is
included in each of these parameters. Note that there may be
other reasons a request is retargeted such as normal routing and
forwarding, strict routing, etc., thus not all history-info
entries have a target header field parameter. The "rc" and "mp"
scenarios are what is anticipated to be most useful to end
applications/users.
In addition, this specification defines a value for the Privacy o hi-index: A mandatory parameter for History-Info reflecting the
header, "history", that applies to all the History-Info header chronological order of the information, indexed to also reflect
entries in a Request or to a specific History-Info header entry as the forking and nesting of requests. The format for this
described above. Further detailed is provided in Section 7.3.1. parameter is a string of digits, separated by dots to indicate the
number of forward hops and retargets. This results in a tree
representation of the history of the request, with the lowest-
level index reflecting a branch of the tree. By adding the new
entries in order (i.e., following existing entries per the details
in Section 9.3), including the index and securing the header, the
ordering of the History-info header fields in the request is
assured. In addition, applications may extract a variety of
metrics (total number of retargets, total number of retargets from
a specific branch, etc.) based upon the index values.
The History-Info header is added to a Request when a new request is o hi-target-param: An optional parameter reflecting the mechanism by
created by a UAC or forwarded by a Proxy, or when the target of a which the Request URI captured in the hi-targeted-to-uri in the
request is changed. It is possible for the target of a request to be hi-entry was determined. This parameter contains either an "rc"
changed by the same proxy/SIP Intermediary multiple times (referred or "mp" header field parameter, which is interpreted as follows:
to as 'internal retargeting'). A SIP entity changing the target of a
request in response to a redirect or REFER also propagates any "rc": The hi-targeted-to-URI is a contact for the Request-URI,
History-Info header from the initial Request in the new request. in the incoming request, that is bound to an AOR in an abstract
location service. The AOR-to-contact binding has been placed
into the location service by a SIP Registrar that received a
SIP REGISTER request. The "rc" header field parameter contains
the value of the hi-index in the hi-entry with an
hi-targeted-to- uri that reflects the Request-URI that was
retargeted
"mp": The hi-targeted-to-URI represents a user other than the
user associated with the Request-URI in the incoming request
that was retargeted. This occurs when a request is to
statically or dynamically retargeted to another user. The
value of the index in the "mp" header field parameter
represents the value of the hi-index in the hi-entry with an
hi-targeted-to- uri that reflects the Request-URI that was
retargeted, thus identifying the "mapped from" target.
o Extension (hi-extension): A parameter to allow for future optional
extensions. As per [RFC3261], any implementation not
understanding an extension MUST ignore it.
The ABNF syntax for the History-info header field and header field
parameters is as follows:
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = name-addr
hi-param = hi-index / hi-target / hi-extension
index-val = 1*DIGIT *("." 1*DIGIT)
hi-index = "index" EQUAL index-val
hi-target-param = rc-param / mp-param
rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val
hi-extension = generic-param
The ABNF definitions for "generic-param" and "name-addr" are from
[RFC3261].
This document also extends the "contact-params" for the Contact
header field as defined in [RFC3261] with the "rc" and "mp" header
field parameters defined above.
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
are both escaped in the hi-targeted-to-uri as described below:
o Reason: An optional parameter for History-Info, reflected in the
History-info header field by including the Reason header field
[RFC3326] escaped in the hi-targeted-to-uri. A reason is included
for the hi-targeted-to-uri that was retargeted as opposed to the
hi-targeted-to-uri to which it was retargeted.
o Privacy: An optional parameter for History-Info, reflected in the
History-Info header field values by including the Privacy Header
[RFC3323] escaped in the hi- targeted-to-uri or by adding the
Privacy header field to the request. The latter case indicates
that the History-Info entries for the domain MUST be anonymized
prior to forwarding, whereas the use of the Privacy header field
escaped in the hi-targeted-to-uri means that a specific hi-entry
MUST be anonymized.
Note that since both the Reason and Privacy parameters are escaped 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
cases, the Tel-URI SHOULD be transformed into a SIP URI per section
19.1.6 of [RFC3261].
The following provides examples of the format for the History-info
header field. Note that the backslash and CRLF between the fields in
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?Reason=SIP%3B\
cause%3D302>;index=1.1,\
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2;mp=1.1,\
<sip:45432@192.168.0.3>;index=1.3;rc=1.2
5.1. History-Info Header Field Example Scenario
The following is an illustrative example of usage of History-Info. The following is an illustrative example of usage of History-Info.
In this example, Alice (sip:alice@atlanta.example.com) calls Bob In this example, Alice (sip:alice@atlanta.example.com) calls Bob
(sip:bob@biloxi.example.com). Alice's home proxy (sip: (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip:
atlanta.example.com) forwards the request to Bob's proxy (sip: atlanta.example.com) forwards the request to Bob's proxy (sip:
biloxi.example.com). When the request arrives at sip: biloxi.example.com). When the request arrives at sip:
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" parameter contains the index of the hi-entry containing the lost
target information - i.e., the sip:bob@biloxi.example.com entry with target information - i.e., the sip:bob@biloxi.example.com hi-entry
index=1.1. Note that an hi-entry is not included for the fork to with index=1.1. Note that an hi-entry is not included for the fork
sip:bob@192.0.2.7 since there was no response at the time the 200 OK to sip:bob@192.0.2.7 since there was no response at the time the 200
is sent to Alice. 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 and
the headers in the URI are not shown properly formatted for escaping. the headers in the URI are not shown properly formatted for escaping.
Refer to Section 7.2 for the proper formatting. Additional detailed Refer to Section 5.1 for the proper formatting. Additional detailed
scenarios are available in the 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 | | |
| | | | | | | | | |
| | INVITE sip:bob@biloxi.example.com;p=x | | | INVITE sip:bob@biloxi.example.com;p=x |
skipping to change at page 10, line 6 skipping to change at page 12, line 6
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| 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
5. General User Agent Behavior 6. User Agent Handling of the History-Info Header Field
This section describes the processing specific to UAs for the This section describes the processing specific to UAs for the
History-Info header. History-info header field.
5.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 in the response. In addition, the UAC like the History-info header field in the response. In addition, the
SHOULD add a History-Info header, using the Request-URI of the UAC MUST add a History-info header field, using the Request-URI of
request as the hi-targeted-to-uri, in which case the index MUST be the request as the hi-targeted-to-uri. The hi-index MUST be set to a
set to a value of 1 in the hi-entry. As a result, intermediaries and value of 1 in the hi-entry. This allows intermediaries and the UAS
the UAS at least know the original Request-URI, and if the Request- to at least know the original Request-URI. In the case of a B2BUA, a
URI was modified by a previous hop. In the case of a B2BUA UAC MAY add the hi-entries received in the incoming request at the
implementation, a UAC MAY add the hi-entries received in the incoming UAS to the subsequent outgoing request.
request at the UAS to the subsequent outgoing request.
A UAC that does not want an hi-entry added due to privacy
considerations MUST include a Privacy header with a priv-value(s) of
"header" or "history". A UAC that wants to ensure that privacy not
be applied to its identity MUST include a Privacy header with a priv-
value of "none".
In the case where a UAC receives a 3xx response with a Contact header In the case where a UAC receives a 3xx response with a Contact header
and sends a new request in response to it, the UAC MAY include in the field and sends a new request in response to it, the UAC MAY include
outgoing request the previous hi-entry(s) received in the response. in the outgoing request the previous hi-entry(s) received in the
In this case, the reason header MUST be associated with the hi- response. In this case, the UAC MUST escape the Reason header field
targeted-to-uri in the previous (last) hi-entry, as described in in the previous (last) hi-entry, as described in Section 9.2. The
Section 7.3.2. A new hi-entry MUST then be added for the URI from UAC MUST add an hi-entry using the Request-URI of the outgoing
the Contact header (which becomes the new Request-URI). An index request as the hi-targeted-to-uri. An hi-index MUST be added to the
MUST be added to the hi-entry. The value for the index is determined hi-entry. The value for the index is determined following the rules
following the rules for "Retargeting based upon a Response" as for "Retargeting based upon a Response" as prescribed in Section 9.3.
prescribed in Section 7.3.3. If the Contact header contained any of If the Contact header field contains an "rc" or "mp" header field
the header parameter fields defined in this specification, the UAC parameter, the UAC MUST add the header field parameter to the new hi-
MUST include the header parameter field as a header parameter field entry as described in Section 9.4. The procedures defined in
associated with the current hi-entry as described in Section 7.3.4. Section 9.1 are followed to indicate any privacy that the UAC wants
applied to the hi-targeted-to-uri.
5.2. User Agent Server (UAS) Behavior 6.2. User Agent Server (UAS) Behavior
5.2.1. Processing of Requests with History-Info 6.2.1. Processing of Requests with History-Info
Once the request terminates at the UAS, the UAS evaluates the Once the request terminates at the UAS, the UAS evaluates the
History-Info header. The last hi-entry reflects the most recent History-info header field. The last hi-entry reflects the most
target and MUST contain the Request-URI for the received request, recent target and contains the Request-URI for the received request,
unless the previous entity that forwarded the request does not unless the previous entity that forwarded the request does not
support the History-Info header. If the Request-URI of the incoming support the History-info header field. If the Request-URI of the
request does not match the last hi-entry (e.g., the last proxy does incoming request does not match the last hi-entry (e.g., the previous
not support History-Info), the UAS MUST insert an hi-entry. The UAS entity does not support History-Info), the UAS MUST insert an hi-
MUST set the hi-targeted-to-uri based to the value of Request-URI in entry. The UAS MUST set the hi-targeted-to-uri based to the value of
the incoming request. If privacy is required, a privacy header with Request-URI in the incoming request. If privacy is required for the
a value of "history" MUST be added to the hi-entry. The UAS MUST hi-entry in the response, the UAS MUST escape a Privacy header field
include an hi-index attribute as described in Section 7.3.3. The UAS with a value of "history" in the hi-entry. The UAS MUST include an
MUST NOT include a hi-target attribute, since the UAS has no way to hi-index parameter as described in Section 9.3. The UAS MUST NOT
know the mechanism by which the Request-URI was determined. The include a hi-target attribute, since the UAS has no way to know the
addition of the missing hi-entry ensures that the most complete mechanism by which the Request-URI was determined. The addition of
information can be provided in the response and provides consistency the missing hi-entry ensures that the most complete information can
in the information presented to applications. The information can be provided in the response and provides consistency in the
also be useful for implementations with B2BUAs that include the information presented to applications. The information can also be
History-Info, received in the incoming request, in the outgoing useful for implementations with B2BUAs that include the History-Info,
request. received in the incoming request, in the outgoing request.
Prior to any application usage of the information, the validity MUST Prior to any application usage of the information, the UAS ascertains
be ascertained. If gaps are detected, this MUST NOT be treated as an the validity of the information as described in Section 10.
error since gaps are possible if the request is forwarded through
intermediate entities that do not support the History-Info header.
The interpretation of the information in the History-Info header by a
UAS in a request depends upon the specific applications supported by
the UAS; an application might need to provide special handling in
some cases where there are gaps. Application considerations and
guidelines are provided in section 7.
5.2.2. Generation of Responses with History-Info 6.2.2. Generation of Responses with History-Info
If the "histinfo" option tag is received in a request, the UAS MUST If the "histinfo" option tag is received in a request, the UAS MUST
include any History-Info received in the request in the subsequent include any History-Info received in the request and any hi-entries
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 response. If privacy is required, entries MUST be anonymized as
described in Section 7.3.1. The UAS MUST follow the rules for a described in Section 9.1. The UAS MUST follow the rules for a
redirect server per Section 5.3 in generating a 3xx response. redirect server per Section 8 in generating a 3xx response.
The processing of History-Info in responses follows the methodology
described in Section 16.7 of [RFC3261], with the processing of
History-Info headers adding an additional step, just before Step 9,
"Forwarding the Response".
5.3. Redirect Server Behavior
A redirect server MUST include the History-Info headers 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 a proxy Section 6. In generating the Contact header in the 3xx
response, the redirect server MUST add the appropriate target header
field parameter to each Contact header as described in Section 7.3.4.
6. Proxy Behavior 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 adding History-Info headers when requests are intermediaries for adding History-Info headers when requests are
retargeted. retargeted.
6.1. Adding the History-Info Header to Requests 7.1. Adding the History-Info Header Field to Requests
This section describes the process of adding the History-Info header This section describes the process of adding the History-Info header
to requests for the following cases: 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
o Forwarding of initial request (see Section 6.1.1) responses (Section 7.1.2). Retargeting is an iterative process,
i.e., an intermediary may retarget "internally " more than one time.
o Resending based on failure response (see Section 6.1.2) 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
o Resending based on redirection response (see Section 6.1.3) forwards to a registered contact bound to that new AOR. In cases of
internal retargeting, an intermediary MUST add multiple hi-entries.
Retargeting is an iterative process, i.e., a proxy may redirect For example, an intermediary that retargets bob@example.com to
"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 these cases, a proxy MUST add multiple hi-entry
fields. For example, a proxy that retargets bob@example.com to
office@example.com and then to office@192.0.2.5 adds hi-entries for 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 both office@example.com and office@192.0.2.5, in order to provide a
logical description of the retargeting process internal to the proxy. logical description of the retargeting process internal to the
A Reason MAY be associated with the hi-targeted-to-uri that has been intermediary. Thus, the intermediary MAY escape a Reason header
retargeted as shown in the example in Appendix B.1. 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.
6.1.1. Initial Request 7.1.1. Forwarding a Request
Upon receipt of an initial request for a dialog, or a standalone Upon receipt of a request for a dialog, or a standalone request, a
request, a proxy forwarding the request MUST perform the following proxy or intermediary forwarding the request performs the following
steps. Note that those steps below do not apply if the request is steps. Note that those steps below do not apply if the request is
being re-sent as a result of failure (i.e., timeout, reception of an being retargeted as a result of failure (i.e., timeout, reception of
error response). an error response).
Step 1: Adding Entries on Behalf of Previous Hops Step 1: Adding Entries on Behalf of Previous Hops
If an incoming request does not already have a History-Info header If an incoming request does not already have a History-Info header
field (e.g., the UAC does not include any History-Info header and field (i.e., the UAC does not include any History-info header
no proxies in between support History-Info), or if the Request-URI field and none of the previous SIP intermediaries support History-
of the incoming request does not match the last hi-entry (e.g., Info) or if the Request-URI of the incoming request does not match
the last proxy does not support History-Info), the proxy MUST the hi-targeted-to-uri in the last hi-entry (i.e., the previous
insert an hi-entry. The proxy MUST set the hi-targeted-to-uri intermediary does not support History-Info) an hi-entry MUST be
based to the value of Request-URI in the incoming request, unless inserted on behalf of the UAC or intermediary. The SIP
privacy is required. If privacy is required, the procedures of intermediary MUST set the hi-targeted-to-uri to the value of the
Section 7.3.1 MUST be used. The proxy MUST NOT include a hi- Request-URI in the incoming request. If privacy is required, the
target attribute. The proxy MUST include an hi-index attribute procedures of Section 9.1 are followed. The SIP intermediary MUST
with a value of "1", as described in Section 7.3.3. 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 Step 2: Generating New Entries for Each Outgoing Request
The proxy then proceeds to request forwarding as per 16.6/ The SIP intermediary then proceeds to request forwarding as per
[RFC3261]. The proxy MUST add a separate hi-entry in each 16.6/[RFC3261]. For each outgoing request relating to a target in
separate outgoing request for each of the current (outgoing) the target set, the intermediary MUST add an hi-entry for the
targets in the target set. The proxy MUST set the hi-targeted-to- specific target. The intermediary MUST set the hi-targeted-to-uri
uri in those separate hi-entry(s) to the value of the Request-URI in the hi-entry to the value of the Request-URI of the current
of the current (outgoing) request, unless privacy is required. If (outgoing) request. If privacy is required, the procedures of
privacy is required, the procedures of Section 7.3.1 MUST be used. Section 9.1 are followed. The proxy MUST include an hi-index for
The proxy MUST include an hi-index for each of the separate hi- the hi-entry as described in Section 9.3. The proxy then includes
entry(s) as described in Section 7.3.3. The proxy MUST include an "rc" or "mp" header field parameter in the hi-entry, if
the appropriate hi-target header field parameter for each of the applicable, as described in Section 9.4.
separate entry(s) as described in Section 7.3.4, if applicable.
6.1.2. Re-sending based on failure response 7.1.2. Retargeting based on failure or 3xx response
When re-sending a request as a result of retargeting because of When retargeting a request because of a failure (i.e., either
failure (i.e., either reception of error responses or a timeout which reception of error responses or a timeout which is considered to be
is considered to be an implicit 408 error response), the proxy MUST an implicit 408 error response) or receipt of a 3XX response, the SIP
perform the following steps: entity performs the following steps:
Step 1: Including the Entries from Error Responses & Timeouts Step 1: Including the Entries from Responses
The proxy MUST build the History-Info header field(s) sent in the Along with the History-Info header fields sent in the original
outgoing request using the aggregate information associated with request that received an error or 3xx response or timed out, the
the received error responses(s) and timeout(s) for all the SIP entity MUST include any new History-Info header field(s)
branches that are generating failures, including the header contained in all responses received thus far (including any new
entries in the order indicated by the indexing (see hi-entries in the error or 3xx response) in the new outgoing
Section 7.3.3). If the received error response did not include request. The hi-entries MUST be added to the new outgoing request
any History-Info header fields, the proxy MUST use the same in the order indicated by the values in the hi-index parameters of
History-Info header fields that were sent in the outgoing request the hi-entries.
that failed to build the outgoing request.
Step 2: Tagging the Last Entries Step 2: Tagging the Last Entries
The proxy then examines the last hi-entry of the History-Info that The SIP entity then examines the History-Info header fields
was just generated in Step 1 for each one of the branches that generated in Step 1. For each of the branches that generated
generated failures or timeouts and MUST add a Reason header for failures or timeouts or received a 3xx response, the SIP entity
each one of those entries as per the procedures of Section 7.3.2. MUST add a Reason header field to the hi-entry for each of those
branches per the procedures of Section 9.2.
Step 3: Generating New Entries for Each Outgoing Requests Step 3: Generating New Entries for Each Outgoing Requests
Same as per Step 2 above for the normal forwarding case Same as per Step 2 above for the normal forwarding case
Section 6.1.1. Section 7.1.1.
6.1.3. Re-sending based on redirection response
When re-sending a request as a result of retargeting because of
redirection (i.e., receipt of a 3XX response), the following steps
apply:
Step 1: Including Previous Entries
The proxy MUST include the History-Info header fields that were
sent in the outgoing request that is being redirected.
Step 2: Tagging the Last Entry
The proxy then examines the last hi-entry of the History-Info that
was just generated in Step 1 and MUST add a Reason header this
entry as per the procedures of Section 7.3.2.
Step 3: Generating New Entries for Each Outgoing Requests
Same as per Step 2 for the normal forwarding case Section 6.1.1.
6.2. Sending History-Info in Responses
A proxy that receives a request with the "histinfo" option tag in the
Supported header, MUST forward captured History-Info in subsequent,
provisional, and final responses to the request sent by the ultimate
UAS (see Section 5.2). Any hi-entry containing a Privacy header with
a value of "history" MUST be anonymized prior to a proxy sending a
response with that hi-entry.
The processing of History-Info in responses follows the methodology
described in Section 16.7 of [RFC3261], with the processing of
History-Info headers adding an additional step, just before Step 9,
"Forwarding the Response".
7. The History-Info header field
7.1. Definition
History-Info is a header field as defined by [RFC3261]. It may
appear in any initial request for a dialog, standalone request or
responses associated with these requests. For example, History-Info
may appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS, SUBSCRIBE,
and PUBLISH and any valid responses, plus NOTIFY requests that
initiate a dialog.
The History-Info header carries the following information when the
header is included in a request or response:
o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for
capturing the Request-URI for the specific request as it is
forwarded.
o Index (hi-index): A mandatory parameter for History-Info
reflecting the chronological order of the information, indexed to
also reflect the forking and nesting of requests. The format for
this parameter is a string of digits, separated by dots to
indicate the number of forward hops and retargets. This results
in a tree representation of the history of the request, with the
lowest-level index reflecting a branch of the tree. By adding the
new entries in order (i.e., following existing entries per the
details in Section 6.1), including the index and securing the
header, the ordering of the History-Info headers in the request is
assured (SEC-req-2, see Appendix A.1). In addition, applications
may extract a variety of metrics (total number of retargets, total
number of retargets from a specific branch, etc.) based upon the
index values.
o Reason: An optional parameter for History-Info, reflected in the
History-Info header by including the Reason Header [RFC3326]
escaped in the hi-targeted-to-uri. A reason is included for the
hi-targeted-to-uri that was retargeted as opposed to the hi-
targeted-to-uri to which it was retargeted.
o Privacy: An optional parameter for History-Info, reflected in the
History-Info header field values by including the Privacy Header
[RFC3323] escaped in the hi- targeted-to-uri or by adding the
Privacy header to the request. The latter case indicates that the
History-Info entries for the domain MUST be anonymized prior to
forwarding, whereas the use of the Privacy header escaped in the
hi-targeted-to-uri means that a specific hi-entry MUST be
anonymized.
o Target (hi-target): An optional parameter for the History-Info and
Contact headers. The hi-target is added for a hi-entry when it is
first added in a History-Info header field, and only one value is
permitted. Upon receipt of a request or response containing the
History-Info header, a UA can determine the mechanism by which the
target was determined. The following header field parameters are
defined for this parameter:
"rc": The hi-targeted-to-URI is a contact for the Request-URI,
in the incoming request, that is bound to an AOR in an abstract
location service. The AOR-to-contact binding has been placed
into the location service by a SIP Registrar that received a
SIP REGISTER request. The "rc" header field parameter contains
the index of the hi-entry associated with the URI in the
incoming request.
"mp": The hi-targeted-to-URI represents a user other than the
user associated with the Request-URI in the incoming
requesting. This occurs when a request is to be statically or
dynamically retargeted to another user. The value of the "mp"
header field parameter is the index parameter for the hi-
targeted-to- uri that was retargeted, thus identifying the
"mapped from" target.
o Extension (hi-extension): A parameter to allow for future optional
extensions. As per [RFC3261], any implementation not
understanding an extension MUST ignore it.
The ABNF syntax for the History-Info header is defined as follows:
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = name-addr 7.2. Sending History-Info in Responses
hi-param = hi-index / hi-target / hi-extension A SIP entity that receives a request with the "histinfo" option tag
in the Supported header, MUST forward captured History-Info in
subsequent, provisional, and final responses to the request sent by
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.
index-val = 1*DIGIT *("." 1*DIGIT) The the addition of the History-Info header fields to responses
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".
hi-index = "index" EQUAL index-val 8. Redirect Server Handling of History-Info Header Fields
hi-target = rc-param / mp-param A redirect server MUST include the History-info header fields
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.
rc-param = "rc" EQUAL index-val 9. Processing the History-Info Header Field Parameters
mp-param = "mp" EQUAL index-val The following sections describe the procedures for processing
History-Info header field parameters and the header fields escaped in
the History-info header field. These procedures are applicable to
SIP entities such as Proxies/Intermediaries, Redirect Servers or User
Agents.
hi-extension = generic-param 9.1. Privacy in the History-Info Header Field
The ABNF definitions for "generic-param" and "name-addr" are from The privacy requirements for this document are described in
[RFC3261]. Appendix A.2. Section 9.1.1 describes the use of the Privacy header
field defined in [RFC3323] to indicate the privacy to be applied to
the History-Info header field entries. Section 9.1.2 describes the
processing of the priv-values in the Privacy header field to privacy
protect the History-Info header field entries in the request or
response that is being forwarded.
Note that since both the Reason and Privacy parameters are escaped in 9.1.1. Indicating Privacy
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].
7.2. Examples As with other SIP headers described in [RFC3323], the hi-targeted-to-
uris in the History-info header field can inadvertently reveal
information about the initiator of the request. Thus, the UAC needs
a mechanism to indicate that the hi-targeted-to-uris in the hi-
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-
entries in the request as follows:
The following provides some examples of the History-Info header. o If the UAC is including a Privacy header field with a priv-value
Note that the backslash and CRLF between the fields in the examples of "header" in the request, then the UAC SHOULD NOT include a
below are for readability purposes only. priv-value of "history" in the the Privacy header field in the
Request.
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar 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
of "history" in the Privacy header field in the Request.
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\ o If the UAC is not including any priv-values in the Privacy header
cause%3D302>;index=1.1,\ field in the request, then the UAC MUST add a Privacy header
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\ field, with a priv-value of "history", to the request. The UAC
cause%3D486>;index=1.2;mp=1.1,\ MUST NOT include a priv-value of "critical" in the Privacy header
<sip:45432@192.168.0.3>;index=1.3;rc=1.2 field in the Request in this case.
7.3. Procedures In addition, the History-info header field can reveal general routing
and diverting information within an intermediary, which the
intermediary wants to privacy protect. In this case, the
intermediary MUST set a Privacy header field to a priv-value of
"history" and escape the Privacy header field in the hi-targeted-to-
uri, for each hi-entry added by intermediary, as the request is
retargeted within the domain for which the SIP entity is responsible.
The intermediary MUST NOT include any other priv-values in this
Privacy header field. Note that the priv-value in the Privacy header
for the incoming request does not necessarily influence whether the
intermediary includes a Privacy header field in 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 escaped in the hi-
targeted-to-uri.
The following sections define procedures for processing of the Finally, the terminator of the request may not want to reveal the
parameters (and headers) associated with the History-Info header. final reached target to the originator. In this case, the terminator
These procedures may be applicable to processing entities such as MUST include a Privacy header field with a priv-value of "history",
Proxies, Redirect Servers or User Agents. escaped in 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 priv-values in the Privacy header field escaped in the hi-
entry.
7.3.1. Privacy in the History-Info Header 9.1.2. Applying Privacy
The privacy requirements for this document are described in When a request is retargeted to a URI associated with a domain for
Appendix A.2. which the SIP intermediary is not responsible or a response is
forwarded, a Privacy Service at the boundary of the domain applies
the appropriate privacy based on the value of the Privacy header
field in the request and in the individual hi-entries.
As with other SIP headers described in [RFC3323], the History-Info If there is a Privacy header field in the request with a priv-value
header can inadvertently reveal information about the originator. A of "header" or "history", then the hi-targeted-to-uris in the hi-
value of "header" in the Privacy header is used to indicate that such entries, associated with the domain for which a SIP intermediary is
headers in the request be privacy protected when the request is responsible, are anonymized. The Privacy Service MUST change any hi-
forwarded by the intermediary. A value of "history" in the Privacy targeted-to-uris in the hi-entries that have not been anonymized to
header indicates that the History-Info header should be privacy anonymous URIs containing a domain of anonymous.invalid (e.g.,
protected. If there is a Privacy header in the request with a priv- anonymous@anonymous.invalid). If the hi-entry has an escaped Privacy
value of "header" or "history", then the initial hi-entry MUST be header field value, then the Privacy header field value MUST be
anonymized and the header removed when the request leaves a domain removed from the hi-entry. Once all the appropriate hi-entries have
for which the SIP entity is responsible. been anonymized, the priv-value of "history" MUST be removed from the
Privacy header field. If there are no remaining priv-values in the
Privacy header field, the Privacy header field MUST be removed from
the request per [RFC3323].
In addition, the History-Info header can reveal general routing and If there is not a Privacy header field in the request or response
diverting information within an intermediary, which the intermediary that is being forwarded, the Privacy Service MUST anonymize any hi-
may want to privacy protect. In this case, a value of "history" in entries, associated with the domain for which a SIP intermediary is
the Privacy header is used to indicate which History-Info header responsible, that contain a Privacy header field with a priv-value of
entries added by a SIP entity are to be anonymized. The priv-value "history". The Privacy Service MUST populate the hi-targeted-to-uri
of "history" MUST be in the privacy header escaped in the hi- with an anonymous URI with a domain of anonymous.invalid (e.g.,
targeted-to-uri for each hi-entry, added by the SIP entity, as the anonymous@anonymous.invalid). Any other priv-values in the Privacy
request is retargeted within the domain for which the SIP entity is header field in the hi-entries MUST be ignored. In any case, the
responsible. If a request is being retargeted to a URI associated Privacy Service MUST remove the Privacy header field from the hi-
with a domain for which the SIP entity is not responsible, the entries prior to forwarding.
processing entity MUST anonymize the hi-entries with a priv-value of
"history" and MUST remove the Privacy header from the hi-entries
prior to forwarding, unless the processing entity knows a priori that
it can rely on a downstream processing entity to apply the requested
privacy. The mechanism for the latter functionality is outside the
scope of this specification.
Finally, the terminator of the request may not want to reveal the 9.2. Reason in the History-info Header Field
final reached target to the originator. In this case, the terminator
uses the a value of "history" in the Privacy header in the last hi-
entry in the response. The SIP entity that forwards the response
MUST anonymize that hi-entry and remove the Privacy header.
7.3.2. Reason in the History-Info Header If the retargeting is due to receipt of an explicit SIP response and
the response contains any Reason header fields (see [RFC3326]), then
the SIP entity MUST escape the Reason header fields in the hi-entry
with the hi-targeted-to-uri containing the URI of the request that
was retargeted. If the SIP response does not contain a Reason header
field, the SIP entity MUST include an escaped Reason header field,
containing the SIP Response Code that triggered the retargeting, in
the hi-entry with the hi-targeted-to-uri containing the URI of the
request that was retargeted.
For retargets that are the result of an explicit SIP response, a If a request has timed out (instead of being explicitly rejected),
Reason MUST be associated with the hi-targeted-to-uri. If the SIP the SIP entity MUST escape a Reason header field, containing a SIP
response does not include a Reason header (see [RFC3326]), the SIP error response code of 408 "Request Timeout" in in the hi-entry with
Response Code that triggered the retargeting MUST be included as the the hi-targeted-to-uri containing the URI of the request that was
Reason associated with the hi-targeted-to-uri that has been retargeted. The SIP entity MAY also be escape a Reason header field
retargeted. If the response contains a Reason header for a protocol in the hi-entry with the hi-targeted-to-uri containing the URI of the
that is not SIP (e.g., Q.850), it MUST be captured as an additional request that was retargeted as a result of internal retargeting.
Reason associated with the hi-targeted-to-uri that has been
retargeted, along with the SIP Response Code. If the Reason header
is a SIP reason, then it MUST be used as the Reason associated with
the hi-targeted-to-uri rather than the SIP response code.
If a request has timed out (instead of being explicitly rejected), it If additional Reason headers are defined in the future per [RFC3326],
MUST be treated as if a 408 "Request Terminated" error response code the use of these Reason headers for the History-Info header field
was received. MUST follow the same rules as described above.
7.3.3. Indexing in the History-Info Header 9.3. Indexing in the History-Info Header Field
In order to maintain ordering and accurately reflect the nesting and In order to maintain ordering and accurately reflect the retargeting
retargeting of the request, an index MUST be included along with the of the request, the SIP entity MUST add an hi-index to each hi-entry.
Targeted-to-URI being captured. Per the syntax in Section 7, the Per the syntax in Section 5, the hi-index consists of a series of
index consists of a dot-delimited series of digits (e.g., 1.1.2). digits separated by dots (e.g., 1.1.2). Each dot reflects a SIP
Each dot reflects a hop or level of nesting; thus, the number of hops forwarding hop. The digit following each dot reflects the order in
is determined by the total number of dots. Within each level, the which a request was retargeted at the hop. The highest digit at each
integer reflects the number of peer entities to which the request has hop reflects the number of entities to which the request has been
been routed. Thus, the indexing results in a logical tree retargeted at the specific hop (i.e., the number of branches). Thus,
representation for the history of the request. the indexing results in a logical tree representation for the history
of the request.
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 proxy adds an entry on behalf of the previous hop, In the case that a SIP entity (intermediary or UAS) adds an hi-entry
the index MUST be set to 1. For each level of indexing, the index 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
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 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. Basic Forwarding: In the case of a request that is being
forwarded, the index is determined by adding another sub-level of forwarded, the hi-index reflects the increasing length of the
indexing since the depth/length of the branch is increasing. To branch. In this case, the SIP entity MUST read the value from
accomplish this, the processing entity MUST read the value from the History-info header field in the received request and MUST
the History-Info header in the received request and MUST add add another level of indexing by appending the dot delimiter
another level of indexing by appending the dot delimiter followed followed by an initial hi-index for the new level of 1. For
by an initial index for the new level of 1. For example, if the example, if the hi-index in the last History-info header field in
index in the last History-Info header field in the received the received request is 1.1, a proxy would add an hi-entry with
request is 1.1, this proxy would initialize its index to 1.1.1 an hi-index to 1.1.1 and forward the request.
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 first instance of retargeting within a processing entity, the SIP
calculation of the index follows that 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 processing each subsequent retargeting of a request by the same SIP entity,
entity, another branch MUST be added. The index for each new the SIP entity MUST add another branch. The SIP entity MUST
branch MUST be calculated by incrementing the last/lowest digit calculate the hi-index for each new branch by incrementing the
at the current level, the index in the next request forwarded by value from the hi-index in the last hi-entry at the current
this same processing entity, following the example above, would level. Per the example above, the hi-index in the next request
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 index MUST be calculated to a specific response (e.g., 302), the SIP entity MUST calculate
per rule 3. That is, the lowest/last digit of the index MUST be the hi-index calculated per rule 3. That is, the lowest/last
incremented (i.e., a new branch is created), with the increment digit of the hi-index MUST be incremented (i.e., a new branch is
of 1. For example, if the index in the History-Info header of created), with the increment of 1. For example, if the hi-index
the sent request is 1.2 and the response to the request is a 302, in the History-Info header of the sent request is 1.2 and the
then the index in the History-Info header field for the new hi- response to the request is a 302, then the hi-index in the
targeted- to-URI would be 1.3. History-Info header field for the new hi-targeted- to-URI would
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 index MUST be captured forks (sequentially or in parallel), the SIP entity MUST set the
for each forked request per the rules above, with each new hi-index for each hi-entry for each forked request per the rules
request having a unique index. Each index MUST be sequentially above, with each new request having a unique index. Each index
assigned. For example, if the index in the last History-Info MUST be sequentially assigned. For example, if the index in the
header field in the received request is 1.1, this processing last History-Info header field in the received request is 1.1,
entity would initialize its index to 1.1.1 for the first fork, this processing entity would initialize its index to 1.1.1 for
1.1.2 for the second, and so forth (see Figure 1 for an example). the first fork, 1.1.2 for the second, and so forth (see Figure 1
Note that for each individual fork, only the entry corresponding for an example). Note that for each individual fork, only the
to that fork is included (e.g., the entry for fork 1.1.1 is not hi-entry corresponding to that fork is included (e.g., the hi-
included in the request sent to fork 1.1.2, and vice-versa). entry for fork 1.1.1 is not included in the request sent to fork
1.1.2, and vice-versa).
6. When a response is built and it represents the aggregate of
responses to multiple forks (e.g., multiple forks that fail), the
processing entity MUST build the subsequent response using the
aggregated information associated with each of the forks for
which there have been responses and MUST include the header
entries in the order indicated by the indexing. For example, if
a procesing entity received failure responses for forks 1.1.1 and
1.1.2, it would return both the 1.1.1 and 1.1.2 entries to the
entity that generated the hi-entry with index of 1. See
Appendix B.1 for an example. Note that in the case of parallel
forking where one fork is successful, only the forks for which
responses have been received at the time the proxy sends the
successful response are included in that response. Responses are
processed as described in Section 16.7 of [RFC3261] with the
aggregated History-Info entries processed similar to Step 7
"Aggregate Authentication Header Field Values".
7.3.4. Request Target in the History-Info Header 9.4. Mechanism for Target Determination in the History-Info Header
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. The specific parameter field to be for a request is determined. Both parameters contain an index whose
included in the History-Info header is determined as the targets are value is the hi-index of the hi-entry with an hi-targeted-to-uri that
added to the target set per the procedures of 16.5 or when the represents the Request-URI that was retargeted.
Contact header field in a 3xx response is populated. Both parameters
contain an index whose value corresponds to the index in the hi-entry
containing the Request-URI that was retargeted.
The specific parameter field to be included in the History-Info The SIP entity MUST determine the specific parameter field to be
header is determined as follows: 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
section 8.1.3.4 [RFC3261] in the case of 3xx responses. In the
latter case, the specific header parameter field in the Contact
header becomes the header field parameter that is used in the hi-
entry when the request is retargeted. If the Contact header field
does not contain an "rc" or "mp" header field parameter, then the SIP
entity MUST NOT include an "rc" or "mp" in the hi-entry when the
request is retargeted.
o "rc": If the hi-targeted-to-URI was determined based on a contact The SIP entity (intermediary or redirect server) determines the
for the Request-URI being retargeted that is bound to an AOR in an specific header field parameter to be used based on the following
abstract location service, then the "rc" header field parameter criteria:
MUST be included in the hi-entry. The index of the "rc" parameter
MSUT be set to the hi-index containing the Request-URI being
retargeted.
o "mp": If the hi-targeted-to-URI was determined based on a mapping o "rc": The target was determined based on a contact that is bound
to a user other than the user associated with the Request-URI to an AOR in an abstract location service for the Request-URI
being retargeted, then the "mp" header field parameter MUST be being retargeted.
included in the hi-entry. The index of the "mp" parameter MUST be
set to the hi-index containing 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" parameter can be
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.
8. Application Considerations The SIP entity MUST add the "rc" or "mp" header field parameter to
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 information the entries MUST be evaluated to application usage of the History-Info header field parameters, the
determine gaps in indices. If gaps are detected, this MUST NOT be SIP entity that processes the hi-entries MUST evaluate the hi-
treated as an error since gaps are possible if the request is entries. The SIP entity MUST determine if there are gaps in the
forwarded through intermediate entities that do not support the indices. Gaps are possible if the request is forwarded through
History-Info header. The interpretation of the information in the intermediaries that do not support the History-info header field and
History-Info header depends upon the specific application; an are reflected by the existence of multiple hi-entries with an index
application might need to provide special handling in some cases of "1". Gaps are also possible in the case of parallel forking if
where there are gaps. 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,
the SIP entity MUST NOT treat this as an error, but rather indicate
to any applications that there are gaps. The most complete
information available to the application is the History-Info entries
starting with the last hi-entry with an index of "1". The
interpretation of the information in the History-info header field
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 summarizes the categories of information that
applications may 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. Entry with the index that matches the value of the last entry 2. Hi-entry with the index that matches the value of the last hi-
with a "rc" header parameter in the Request received by a UAS - entry with a "rc" header parameter in the Request received by a
i.e., the Request URI associated with the destination of the UAS - i.e., the Request URI associated with the destination of
request was determined based on an AOR-to-contact binding in an the request was determined based on an AOR-to-contact binding in
abstract location service. an abstract location service.
3. Entry with the index that matches the value of the last entry 3. Hi-entry with the index that matches the value of the last hi-
with a "mp" header parameter in the Request received by a UAS - entry with a "mp" header parameter in the Request received by a
i.e., the last Request URI that was mapped to reach the UAS - i.e., the last Request URI that was mapped to reach the
destination. destination.
4. Entry with the index that matches the value of the first entry 4. Hi-entry with the index that matches the value of the first hi-
with a "rc" header parameter in the Request received by a UAS. entry with a "rc" header parameter in the Request received by a
Note, this would be the original AoR if all entries support the UAS. Note, this would be the original AoR if all the entities
History-Info header and there is absence of a "mp" header involved support the History-info header field and there is
parameter prior to the "rc" header parameter in the History-Info absence of a "mp" header parameter prior to the "rc" header
header. However, there is no guarantee that all entities will parameter in the History-info header field. However, there is no
support History-Info, thus the first entry with an "rc" header guarantee that all entities will support History-Info, thus the
parameter within the domain associated with the target URI at the first hi-entry with an "rc" header parameter within the domain
destination is more likely to be useful. associated with the target URI at the destination is more likely
to be useful.
5. Entry with the index that matches the value of the first entry 5. Hi-entry with the index that matches the value of the first hi-
with a "mp" header parameter in the Request received by a UAS. entry with a "mp" header parameter in the Request received by a
Note, this would be the original mapped URI if all entities UAS. Note, this would be the original mapped URI if all entities
supported the History-Info header. However, there is no supported the History-info header field. However, there is no
guarantee that all entities will support History-Info, thus the guarantee that all entities will support History-Info, thus the
first entry with an "mp" header parameter within the domain first hi-entry with an "mp" header 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 entry who index matches the index of the first that utilizes the hi-entry who index matches the index of the first
History-Info entry with an hi-target value of "mp", may also display History-Info entry with an hi-target value of "mp", may also display
other agents, reflected by other History-Info entries prior to other agents, reflected by other History-Info entries prior to
entries with hi-target values of "rc", to whom the call was targeted entries with hi-target values of "rc", to whom the call was targeted
prior to its arrival at the current agent. This could allow the prior to its arrival at the current agent. This could allow the
agent the ability to decide how they might forward or reroute the agent the ability to decide how they might forward or reroute the
call if necessary (avoiding agents that were not previously available call if necessary (avoiding agents that were not previously available
for whatever reason, etc.). for whatever reason, etc.).
Since support for History-Info header is optional, a service MUST Since support for History-info header field is optional, a service
define default behavior for requests and responses not containing MUST define default behavior for requests and responses not
History-Info headers. For example, an entity may receive only containing History-Info headers. For example, an entity may receive
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.
9. Security Considerations 11. 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
no more, secure than other SIP headers, which generally have even no more, secure than other SIP headers, which generally have even
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. History-info header field.
With the level of security provided by TLS (SEC-req-3), the
information in the History-Info header can thus be evaluated to
determine if information has been removed by evaluating the indices
for gaps (SEC-req-1, SEC-req-2). It would be up to the application
to define whether it can make use of the information in the case of
missing entries.
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.
10. IANA Considerations 12. 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].
10.1. Registration of New SIP History-Info Header 12.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 19 skipping to change at page 24, line 34
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.
10.2. Registration of "history" for SIP Privacy Header 12.2. Registration of "history" for SIP Privacy Header Field
This document defines a priv-value for the SIP Privacy header: 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: 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(s) mary.barnes@polycom.com History-info header mary.barnes@polycom.com
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.
10.3. Registration of Header Field Parameters 12.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.
11. Acknowledgements 13. 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 29 skipping to change at page 25, line 45
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.
12. Changes from RFC 4244 14. 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 26, line 23 skipping to change at page 26, line 39
o [RFC4244] does not include clear procedures on how to deliver o [RFC4244] does not include clear procedures on how to deliver
current target URI information to the UAS when the Request-URI is current target URI information to the UAS when the Request-URI is
replaced with a contact. replaced with a contact.
o [RFC4244] does not allow for marking History-Info entries for easy o [RFC4244] does not allow for marking History-Info entries for easy
processing by User Agents. processing by User Agents.
The following summarizes the functional changes between this The following summarizes the functional changes between this
specification and [RFC4244]: specification and [RFC4244]:
1. Added header parameters to capture the specific method by which a 1. Added header field parameters to capture the specific method by
target is determined to facilitate processing by users of the which a target is determined to facilitate processing by users of
History-Info header entries. A specific header parameter is the History-info header field entries. A specific header field
captured for each of the target URIs as the target set is parameter is captured for each of the target URIs as the target
determined (per section 16.5 of [RFC3261]). The header parameter set is determined (per section 16.5 of [RFC3261]). The header
is used in both the History-Info and the Contact headers. field parameter is used in both the History-Info and the Contact
header fields.
2. Rather than recommending that entries be removed in the case of 2. Rather than recommending that entries be removed in the case of
certain values of the privacy header, recommend that the entries certain values of the Privacy header field, the entries are
are anonymized. anonymized.
3. Updated the security section to be equivalent to the security 3. Updated the security section to be equivalent to the security
recommendations for other SIP headers inserted by intermediaries. recommendations for other SIP headers inserted by intermediaries.
The first 2 changes are intended to facilitate application usage of The first 2 changes are intended to facilitate application usage of
the History-Info header and eliminate the need to make assumptions the History-info header field and eliminate the need to make
based upon the order of the entries and ensure that the most complete assumptions based upon the order of the entries and ensure that the
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. The examples were the text, moving the requirements to an appendix and removing the
simplified and updated to reflect the protocol changes. Several of inline references to the requirements. The examples were simplified
the call flows in the appendix were removed and put into a separate and updated to reflect the protocol changes. Several of the call
document that includes additional use cases that require the new flows in the appendix were removed and put into a separate document
header parameters. that includes additional use cases that require the new header
parameters.
12.1. Backwards compatibility 14.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.
13. Changes since last Version 15. 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 02 to 03:
1. Lots of editorial:
A. Reorganized sections similar to the RFC 4244 order - i.e.,
introduce header field parameters and syntax first, then
describe how the functional entities use the header. This
removes redundant (and often inconsistent) text describing
the parameters.
B. Expanded use of "header" to "header field"
C. More precision in terms of "escaping" of the Privacy and
Reason headers in the hi-targeted-to-uri (versus
"adding"/"setting"/etc. them to the hi-entry).
D. Consistent use of parameter names (i.e., hi-entry versus
entry, hi-target versus target, etc.)
E. Moved item 6 in the Index section to the section on Response
handling
F. Removed last remaining vestiges of inline references to
requirements.
2. Clarifications of functionality/applicability including:
A. which messages may contain History-Info
B. removing security text with regards to being able to figure
out if there are missing entries when using TLS (issue #44)
C. More complete information on the new header field parameters
as they relate to the hi-target parameter.
D. Changed wording from passive to active for normative
statements in many cases and removed superfluous normative
language.
3. Rewrite of the Privacy section to address issues and splitting
into the setting of the Privacy header fields and the processing/
application of the privacy header field priv-values.
4. Rewrite of the Reason header field section - simplifying the text
and adding back the RFC 4244 text with regards to the use of the
Reason header field in cases of internal retargeting.
Changes from 01 to 02: Changes from 01 to 02:
1. Editorial nits/clarifications. [Issues: 1,6,17,18,21- 1. Editorial nits/clarifications. [Issues: 1,6,17,18,21-
23,25,26,30-33,35-37,39,40] 23,25,26,30-33,35-37,39,40]
2. Removing extraneous 4244 text - e.g., errors in flows, 2. Removing extraneous 4244 text - e.g., errors in flows,
"stronger" security, "session" privacy. [Issues: 3,5,7,11 ] "stronger" security, "session" privacy. [Issues: 3,5,7,11 ]
3. Updated definition of "retarget" to be all encompassing - i.e., 3. Updated definition of "retarget" to be all encompassing - i.e.,
also includes internal changes of target URI. Clarified text also includes internal changes of target URI. Clarified text
skipping to change at page 28, line 7 skipping to change at page 29, line 24
9. Changed "hit" URI parameter to header parameters: [Issues:4,40] 9. Changed "hit" URI parameter to header parameters: [Issues:4,40]
* Added index to all target header parameters. [Issues: 41] * Added index to all target header parameters. [Issues: 41]
* Updated all the relevant sections documenting setting and use * Updated all the relevant sections documenting setting and use
of new header parameters. [Issue: 40] of new header parameters. [Issue: 40]
10. Updated/clarified privacy handling. [Issue: 16] 10. Updated/clarified privacy handling. [Issue: 16]
11. Updated Redirect Server section to allow adding History-Info 11. Updated Redirect Server section to allow adding History-info
headers. [Issue: 24 ] header fields. [Issue: 24 ]
12. Added text around restrictions for Tel-URIs - i.e., no privacy 12. Added text around restrictions for Tel-URIs - i.e., no privacy
or reason. [Issues: 4, 12] or reason. [Issues: 4, 12]
13. Updated text for forking - what goes in response. [Issues: 13. Updated text for forking - what goes in response. [Issues:
19,20] 19,20]
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. handling of the History-info header field.
3. Updated the Application considerations section: 3. Updated the Application considerations section:
* 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.
skipping to change at page 29, line 26 skipping to change at page 30, line 43
4. Added index parameter to "mp" 4. Added index parameter to "mp"
5. Added use-cases and call-flows from target-uri into appendix. 5. Added use-cases and call-flows from target-uri into appendix.
Changes from barnes-sipcore-4244bis-01 to 02: Changes from barnes-sipcore-4244bis-01 to 02:
1. Added hi-aor parameter that gets marked on the "incoming" hi- 1. Added hi-aor parameter that gets marked on the "incoming" hi-
entry. entry.
2. Hi-target parameter defined to be either rc, oc, mp, rt, and now 2. Hi-target parameter defined to be either rc, oc, mp, rt, and now
gets included when adding an entry. gets included when adding an hi-entry.
3. Added section on backwards compatibility, as well as added the 3. Added section on backwards compatibility, as well as added the
recognition and handling of requests that do not support this recognition and handling of requests that do not support this
specification in the appropriate sections. specification in the appropriate sections.
4. Updated redirect server/3xx handling to support the new 4. Updated redirect server/3xx handling to support the new
parameters - i.e., the redirecting entity must add the new entry parameters - i.e., the redirecting entity must add the new hi-
since the proxy does not have access to the information as to how entry since the proxy does not have access to the information as
the Contact was determined. to how the Contact was determined.
5. Added section on normative differences between this document and 5. Added section on normative differences between this document and
RFC 4244. RFC 4244.
6. Restructuring of document to be more in line with current IETF 6. Restructuring of document to be more in line with current IETF
practices. practices.
7. Moved Requirements section into an Appendix. 7. Moved Requirements section into an Appendix.
8. Fixed ABNF to remove unintended ordering requirement on hi-index 8. Fixed ABNF to remove unintended ordering requirement on hi-index
skipping to change at page 32, line 8 skipping to change at page 33, line 24
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.
14. References 16. References
14.1. Normative References 16.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 32, line 34 skipping to change at page 34, line 5
[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.
14.2. Informative References 16.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.
skipping to change at page 34, line 28 skipping to change at page 35, line 46
The Request History information is being inserted by a network The Request History information is being inserted by a network
element retargeting a Request, resulting in a slightly different element retargeting a Request, resulting in a slightly different
problem than the basic SIP header problem, thus requiring specific problem than the basic SIP header problem, thus requiring specific
consideration. It is recognized that these security requirements can consideration. It is recognized that these security requirements can
be generalized to a basic requirement of being able to secure be generalized to a basic requirement of being able to secure
information that is inserted by proxies. information that is inserted by proxies.
The potential security problems include the following: The potential security problems include the following:
1. A rogue application could insert a bogus Request History entry 1. A rogue application could insert a bogus Request History-Info
either by adding an additional entry as a result of retargeting entry either by adding an additional hi-entry as a result of
or entering invalid information. retargeting or entering invalid information.
2. A rogue application could re-arrange the Request History 2. A rogue application could re-arrange the Request History
information to change the nature of the end application or to information to change the nature of the end application or to
mislead the receiver of the information. mislead the receiver of the information.
3. A rogue application could delete some or all of the Request 3. A rogue application could delete some or all of the Request
History information. History information.
Thus, a security solution for "Request History" must meet the Thus, a security solution for "Request History" must meet the
following requirements: following requirements:
skipping to change at page 35, line 35 skipping to change at page 37, line 8
requirements associated with the Request-URI being captured in requirements associated with the Request-URI being captured in
the Request History information. the Request History information.
3. PRIV-req-3: Request History information subject to privacy shall 3. PRIV-req-3: Request History information subject to privacy shall
not be included in ougoing messages unless it is protected as not be included in ougoing messages unless it is protected as
described in [RFC3323]. described in [RFC3323].
Appendix B. Example call flows Appendix B. Example call flows
The scenarios in this section provide sample use cases for the The scenarios in this section provide sample use cases for the
History-Info header for informational purposes only. They are not History-info header field for informational purposes only. They are
intended to be normative. A basic forking use case is included, not intended to be normative. A basic forking use case is included,
along with two use cases illustrating the use of the privacy. along with two use cases illustrating the use of the privacy.
B.1. Sequentially Forking (History-Info in Response) B.1. Sequentially Forking (History-Info in Response)
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 entry to Alice. The hi-entry containing the initial contact is the hi-
just prior to the firt entry tagged with an hi-target value of "rc". entry just prior to the first hi-entry tagged with an hi-target value
In this example, the Office and Home are not the same AOR as of "rc". In this example, the Office and Home are not the same AOR
sip:bob@example.com, but rather different AORs that have been as sip:bob@example.com, but rather different AORs that have been
configured as alternate addresses for Bob in the proxy. In other configured as alternate addresses for Bob in the proxy. In other
words, Office and Bob are not bound through SIP Registration with words, Office and Bob are not bound through SIP Registration with
Bob's AOR. This type of arrangement is common for example when a Bob's AOR. This type of arrangement is common for example when a
"routing" rule to a PSTN number is manually configured in a Proxy. "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 "mp" 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
skipping to change at page 39, line 25 skipping to change at page 40, line 25
INVITE sip:office@192.0.2.3.com SIP/2.0 INVITE sip:office@192.0.2.3.com SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP;cause=302>;\ History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:office@example.com>;index=1.2;mp=1 History-Info: <sip:office@example.com>;index=1.2;mp=1
History-Info: <sip:office@192.0.2.5>;index=1.2.1 History-Info: <sip:office@192.0.2.5>;index=1.2.1
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: Alice <sip:alice@192.0.2.3> Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F7 180 Ringing office -> example.com F7 180 Ringing office -> example.com
SIP/2.0 180 Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com>;tag=5 To: Bob <sip:bob@example.com>;tag=5
Supported: histinfo Supported: histinfo
Call-ID: 12345600@example.com Call-ID: 12345600@example.com
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP;cause=302>;\ History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:office@example.com>;index=1.2;mp=1 History-Info: <sip:office@example.com>;index=1.2;mp=1
History-Info: <sip:office@192.0.2.5>;index=1.2.1 History-Info: <sip:office@192.0.2.5>;index=1.2.1
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
F8 180 Ringing example.com -> alice F8 180 Ringing example.com -> alice
SIP/2.0 180 Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/TCP example.com:5060 Via: SIP/2.0/TCP example.com:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP;cause=302>;\ History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:office@example.com>;index=1.2;mp=1 History-Info: <sip:office@example.com>;index=1.2;mp=1
History-Info: <sip:office@192.0.2.5>;index=1.2.1 History-Info: <sip:office@192.0.2.5>;index=1.2.1
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
F9 INVITE example.com -> home F9 INVITE example.com -> home
INVITE sip:home@192.0.2.6 SIP/2.0 INVITE sip:home@192.0.2.6 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP;cause=302>;\ History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:office@example.com>;index=1.2;mp=1 History-Info: <sip:office@example.com>;index=1.2;mp=1
History-Info: <sip:office@192.0.2.5?Reason=SIP;cause=480>;\ History-Info: <sip:office@192.0.2.5?Reason=SIP%3Bcause%3D408>;\
index=1.2.1>;index=1.2.1 index=1.2.1>;index=1.2.1
History-Info: <sip:home@example.com>;index=1.3;mp=1 History-Info: <sip:home@example.com>;index=1.3;mp=1
History-Info: <sip:home@192.0.2.6>;index=1.3.1 History-Info: <sip:home@192.0.2.6>;index=1.3.1
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: Alice <sip:alice@192.0.2.3> Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F10 100 Trying home -> example.com F10 100 Trying home -> example.com
skipping to change at page 42, line 14 skipping to change at page 43, line 14
F11 486 Busy Here home -> example.com F11 486 Busy Here home -> example.com
SIP/2.0 486 Busy Here SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP;cause=302>;\ History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:office@example.com>;index=1.2;mp=1 History-Info: <sip:office@example.com>;index=1.2;mp=1
History-Info: <sip:office@192.0.2.5?Reason=SIP;cause=480>;\ History-Info: <sip:office@192.0.2.5?Reason=SIP%3Bcause%3D408>;\
index=1.2.1>;index=1.2.1 index=1.2.1>;index=1.2.1
History-Info: <sip:home@example.com>;index=1.3;mp=1 History-Info: <sip:home@example.com>;index=1.3;mp=1
History-Info: <sip:home@192.0.2.6>;index=1.3.1 History-Info: <sip:home@192.0.2.6>;index=1.3.1
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
F12 486 Busy Here example.com -> alice F12 486 Busy Here example.com -> alice
SIP/2.0 486 Busy Here SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP;cause=302>;\ History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:office@example.com>;index=1.2;mp=1 History-Info: <sip:office@example.com>;index=1.2;mp=1
History-Info: <sip:office@192.0.2.5?Reason=SIP;cause=480>;\ History-Info: <sip:office@192.0.2.5?Reason=SIP%3Bcause%3D408>;\
index=1.2.1>;index=1.2.1 index=1.2.1>;index=1.2.1
History-Info: <sip:home@example.com>;index=1.3;mp=1 History-Info: <sip:home@example.com>;index=1.3;mp=1
History-Info: <sip:home@192.0.2.6>;index=1.3.1 History-Info: <sip:home@192.0.2.6>;index=1.3.1
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
F13 ACK example.com -> home F13 ACK example.com -> home
ACK sip:home@example.com SIP/2.0 ACK sip:home@example.com SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060 Via: SIP/2.0/TCP proxy.example.com:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
skipping to change at page 43, line 25 skipping to change at page 44, line 25
ACK sip:bob@example.com SIP/2.0 ACK sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Route: <sip:proxy.example.com;lr> Route: <sip:proxy.example.com;lr>
CSeq: 1 ACK CSeq: 1 ACK
Content-Length: 0 Content-Length: 0
B.2. History-Info with Privacy Header B.2. History-Info with Privacy Header Field
This example provides a basic call scenario without forking. Alice This example provides a basic call scenario without forking. Alice
has indicated that she wants Privacy associated with her History-Info has indicated that she wants Privacy associated with the History-Info
entry and sip:biloxi.example.com adds Privacy headers indicating that header field entries. In addition, sip:biloxi.example.com adds
the History-Info header information is anonymized outside the Privacy header fields indicating that the History-info header field
biloxi.example.com domain. Note, that if the atlanta.example.com information is anonymized outside the biloxi.example.com domain.
proxy had added privacy headers to all its hi-entries, then all the Note, that if the atlanta.example.com proxy had added privacy header
hi-entries in the response would be anonymous. fields to all its hi-entries, then all the hi-entries in the response
would be anonymous.
Alice atlanta.example.com biloxi.example.com Bob Alice atlanta.example.com biloxi.example.com Bob
| | | | | | | |
| INVITE sip:bob@biloxi.example.com;p=x | | INVITE sip:bob@biloxi.example.com;p=x |
|--------------->| | | |--------------->| | |
| Supported: histinfo | | | Supported: histinfo | |
| Privacy: History | | | Privacy: History | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| | | | | | | |
| | INVITE sip:bob@biloxi.example.com;p=x | | INVITE sip:bob@biloxi.example.com;p=x
skipping to change at page 44, line 47 skipping to change at page 45, line 47
|<---------------| | | |<---------------| | |
| History-Info: <sip:anonymous@anonymous.invalid>;index=1 | History-Info: <sip:anonymous@anonymous.invalid>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc=1.1 | History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc=1.1
| | | | | | | |
| ACK | | | | ACK | | |
|--------------->| ACK | | |--------------->| ACK | |
| |--------------->| ACK | | |--------------->| ACK |
| | |--------------->| | | |--------------->|
Figure 2: Example with Privacy Header Figure 2: Example with Privacy Header Fields
B.3. Privacy Header for a Specific History-Info Entry B.3. Privacy for a Specific History-Info Entry
This example provides a basic call scenario similar to Appendix B.2, This example provides a basic call scenario similar to Appendix B.2,
however, due to local policy at sip:biloxi.example.com, only the however, due to local policy at sip:biloxi.example.com, only the
final hi-entry in the History-Info, which is Bob's local URI, final hi-entry in the History-Info, which is Bob's local URI,
contains a priv-value of "history", thus providing Alice with some contains a privacy header field with a priv-value of "history", thus
information about the history of the request, but anonymizing Bob's providing Alice with some information about the history of the
local URI. request, but anonymizing Bob's local URI.
Alice atlanta.example.com biloxi.example.com Bob Alice atlanta.example.com biloxi.example.com Bob
| | | | | | | |
| INVITE sip:bob@biloxi.example.com;p=x | | INVITE sip:bob@biloxi.example.com;p=x |
|--------------->| | | |--------------->| | |
| Supported: histinfo | | | Supported: histinfo | |
| | | | | | | |
| | INVITE sip:bob@biloxi.example.com;p=x | | INVITE sip:bob@biloxi.example.com;p=x
| |--------------->| | | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
skipping to change at page 46, line 45 skipping to change at page 47, line 45
|<---------------| | | |<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:anonymous@anynymous.invalid>;index=1.1.1;rc=1.1 | History-Info: <sip:anonymous@anynymous.invalid>;index=1.1.1;rc=1.1
| | | | | | | |
| ACK | | | | ACK | | |
|--------------->| ACK | | |--------------->| ACK | |
| |--------------->| ACK | | |--------------->| ACK |
| | |--------------->| | | |--------------->|
Figure 3: Example with Privacy Header for Specific URI Figure 3: Example with Privacy Header Field for Specific URI
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Polycom Polycom
TX TX
US US
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
 End of changes. 146 change blocks. 
672 lines changed or deleted 749 lines changed or added

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