draft-ietf-sipcore-rfc4244bis-07.txt   draft-ietf-sipcore-rfc4244bis-08.txt 
Network Working Group M. Barnes Network Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Obsoletes: 4244 (if approved) F. Audet Obsoletes: 4244 (if approved) F. Audet
Intended status: Standards Track Skype Intended status: Standards Track Skype
Expires: September 2, 2012 S. Schubert Expires: October 3, 2012 S. Schubert
NTT NTT
J. van Elburg J. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
Mar 2012 Apr 2012
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-07.txt draft-ietf-sipcore-rfc4244bis-08.txt
Abstract Abstract
This document defines a standard mechanism for capturing the history This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP) information associated with a Session Initiation Protocol (SIP)
request. This capability enables many enhanced services by providing request. This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific the information as to how and why a SIP request arrives at a specific
application or user. This document defines an optional SIP header application or user. This document defines an optional SIP header
field, History-Info, for capturing the history information in field, History-Info, for capturing the history information in
requests. The document also defines SIP header field parameters for requests. The document also defines SIP header field parameters for
the History-Info and Contact header fields to tag the method by which the History-Info and Contact header fields to tag the method by which
the target of a request is determined. In addition, this the target of a request is determined. In addition, this
specification defines a value for the Privacy header field specific specification defines a value for the Privacy header field that
to the History-Info header field. This document obsoletes RFC 4244. directs the anonymization of values in the History-Info header field
This document obsoletes RFC 4244.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2012. This Internet-Draft will expire on October 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. History-Info Header Field Protocol Structure . . . . . . . . . 8 5. History-Info Header Field Protocol Structure . . . . . . . . . 8
5.1. History-Info Header Field Example Scenario . . . . . . . . 10 5.1. History-Info Header Field Example Scenario . . . . . . . . 11
6. User Agent Handling of the History-Info Header Field . . . . . 13 6. User Agent Handling of the History-Info Header Field . . . . . 14
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 14
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 14
7. Proxy/Intermediary Handling of History-Info Header Fields . . 13 7. Proxy/Intermediary Handling of History-Info Header Fields . . 14
8. Redirect Server Handling of History-Info Header Fields . . . . 14 8. Redirect Server Handling of History-Info Header Fields . . . . 15
9. Handling of History-Info Header Fields in Requests and 9. Handling of History-Info Header Fields in Requests and
Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 16
9.2. Sending a Request with History-Info . . . . . . . . . . . 15 9.2. Sending a Request with History-Info . . . . . . . . . . . 16
9.3. Receiving a Response with History-Info or Request 9.3. Receiving a Response with History-Info or Request
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 15 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.4. Sending History-Info in Responses . . . . . . . . . . . . 16 9.4. Sending History-Info in Responses . . . . . . . . . . . . 17
10. Processing the History-Info Header Field . . . . . . . . . . . 16 10. Processing the History-Info Header Field . . . . . . . . . . . 18
10.1. Privacy in the History-Info Header Field . . . . . . . . . 17 10.1. Privacy in the History-Info Header Field . . . . . . . . . 18
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 18
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 19
10.2. Reason in the History-info Header Field . . . . . . . . . 19 10.2. Reason in the History-Info Header Field . . . . . . . . . 20
10.3. Indexing in the History-Info Header Field . . . . . . . . 19 10.3. Indexing in the History-Info Header Field . . . . . . . . 20
10.4. Mechanism for Target Determination in the History-Info 10.4. Mechanism for Target Determination in the History-Info
Header Field . . . . . . . . . . . . . . . . . . . . . . . 21 Header Field . . . . . . . . . . . . . . . . . . . . . . . 22
11. Application Considerations . . . . . . . . . . . . . . . . . . 22 11. Application Considerations . . . . . . . . . . . . . . . . . . 23
12. Application Specific Usage . . . . . . . . . . . . . . . . . . 24 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 25
12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 24 12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 25
12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 24 12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 26
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14.1. Registration of New SIP History-Info Header Field . . . . 26 14.1. Registration of New SIP History-Info Header Field . . . . 27
14.2. Registration of "history" for SIP Privacy Header Field . . 26 14.2. Registration of "history" for SIP Privacy Header Field . . 27
14.3. Registration of Header Field Parameters . . . . . . . . . 27 14.3. Registration of Header Field Parameters . . . . . . . . . 28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 29
16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 29 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30
17. Changes since last Version . . . . . . . . . . . . . . . . . . 30 17. Changes since last Version . . . . . . . . . . . . . . . . . . 31
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
18.1. Normative References . . . . . . . . . . . . . . . . . . . 37 18.1. Normative References . . . . . . . . . . . . . . . . . . . 38
18.2. Informative References . . . . . . . . . . . . . . . . . . 37 18.2. Informative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Request History Requirements . . . . . . . . . . . . 38 Appendix A. Request History Requirements . . . . . . . . . . . . 39
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 39 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 40
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 40 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 41
Appendix B. Example call flows . . . . . . . . . . . . . . . . . 40 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 42
B.1. PBX Voicemail call flow . . . . . . . . . . . . . . . . . 40 B.1. PBX Voicemail call flow . . . . . . . . . . . . . . . . . 42
B.2. Consumer Voicemail example call flow . . . . . . . . . . . 45 B.2. Consumer Voicemail example call flow . . . . . . . . . . . 46
B.3. Sequentially Forking (History-Info in Response) . . . . . 49 B.3. Sequentially Forking (History-Info in Response) . . . . . 50
B.4. History-Info with Privacy Header Field . . . . . . . . . . 56 B.4. History-Info with Privacy Header Field . . . . . . . . . . 58
B.5. Privacy for a Specific History-Info Entry . . . . . . . . 60 B.5. Privacy for a Specific History-Info Entry . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
Many services that SIP is anticipated to support require the ability Many services that SIP is anticipated to support require the ability
to determine why and how a SIP request arrived at a specific to determine why and how a SIP request arrived at a specific
application. Examples of such services include (but are not limited application. Examples of such services include (but are not limited
to) sessions initiated to call centers via "click to talk" SIP to) sessions initiated to call centers via "click to talk" SIP
Uniform Resource Locators (URLs) on a web page, "call history/ Uniform Resource Locators (URLs) on a web page, "call history/
logging" style services within intelligent "call management" software logging" style services within intelligent "call management" software
for SIP User Agents (UAs), and calls to voicemail servers. Although for SIP User Agents (UAs), and calls to voicemail servers. Although
SIP implicitly provides the retarget capabilities that enable SIP SIP implicitly provides the retarget capabilities that enable SIP
requests to be routed to chosen applications, there is a need for a requests to be routed to chosen applications, there is a need for a
standard mechanism within SIP for communicating the retargeting standard mechanism within SIP for communicating the retargeting
history of the requests. This "request history" information allows history of the requests. This "request history" information allows
the receiving application to determine hints about how and why the the receiving application to obtain information about how and why the
SIP request arrived at the application/user. SIP request arrived at the application/user.
This document defines a SIP header field, 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 for the History-Info and Contact header field parameters are defined for the History-Info and Contact
header fields to tag the method by which the target of a request is header fields to tag the method by which the target of a request is
determined. In addition, this specification defines a value for the determined. In addition, this specification defines a value for the
Privacy header field specific to the History-Info header. Privacy header field specific to the History-Info header.
The History-info header field provides a building block for The History-Info header field provides a building block for
development of SIP based applications and services. The requirements development of SIP based applications and services. The requirements
for the solution described in this specification are included in for the solution described in this specification are included in
Appendix A. Example scenarios using the History-info header field Appendix A. Example scenarios using the History-Info header field
are included in 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 specification to refer to the The term "retarget" is used in this specification to refer to the
process of a SIP entity changing a Uniform Resource Identifier (URI) process of a SIP entity changing the request-URI [RFC3261, section
in a request based on the rules for determining request targets as 7.1] in a request based on the rules for determining request targets
described in Section 16.5 of [RFC3261] and of the subsequent as described in Section 16.5 of [RFC3261] and of the subsequent
forwarding of that request as described in step 2 in section 16.6 of forwarding of that request as described in step 2 in section 16.6 of
[RFC3261]. This includes changing the Request-URI due to a location [RFC3261]. This includes changing the Request-URI due to a location
service lookup and redirect processing. This also includes internal service lookup and redirect processing. This also includes internal
(to a Proxy/SIP intermediary) changes of the URI prior to forwarding (to a Proxy/SIP intermediary) changes of the URI prior to forwarding
of the request. of the request.
The terms "location service", "forward", "redirect" and "AOR" are The terms "location service", "forward", "redirect" and "AOR" are
used consistent with the terminology in [RFC3261]. used consistent with the terminology in [RFC3261].
The terms "target user" is used in this specification as the human The terms "target user" is used in this specification as the human
skipping to change at page 6, line 29 skipping to change at page 6, line 29
requests to be routed to specific applications as defined in requests to be routed to specific applications as defined in
[RFC3261]. The motivation for capturing the request history is that [RFC3261]. The motivation for capturing the request history is that
in the process of retargeting a request, old routing information can in the process of retargeting a request, old routing information can
be forever lost. This lost information may be important history that be forever lost. This lost information may be important history that
allows elements to which the request is retargeted to process the allows elements to which the request is retargeted to process the
request in a locally defined, application-specific manner. This request in a locally defined, application-specific manner. This
document defines a mechanism for transporting the request history. document defines a mechanism for transporting the request history.
Application-specific behavior is outside the scope of this Application-specific behavior is outside the scope of this
specification. specification.
Current network applications provide the ability for elements Current network applications for other protocols provide the ability
involved with the request to obtain additional information relating for elements involved with the request to obtain additional
to how and why the request was routed to a particular destination. information relating to how and why the request was routed to a
The following are examples of such applications: particular destination. 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 detailed
"history" of who sent the email to whom and at what time "trace of the path" of the message from sender to receiver and at
what time
3. Traditional telephony services such as voicemail, call-center 3. Traditional telephony services such as voicemail, call-center
"automatic call distribution", and "follow-me" style services "automatic call distribution", and "follow-me" style services
Several of the aforementioned applications currently define Several of the aforementioned applications currently define
application-specific mechanisms through which it is possible to application-specific mechanisms through which it is possible to
obtain the necessary history information. obtain the necessary history information.
In addition, request history information could be used to enhance In addition, request history information could be used to enhance
basic SIP functionality by providing the following: basic SIP functionality by providing the following:
o Some diagnostic information for debugging SIP requests. o Some diagnostic information for debugging SIP requests.
o Capturing aliases and Globally Routable User Agent URIs (GRUUs) o Capturing aliases and Globally Routable User Agent URIs (GRUUs)
[RFC5627], which can be overwritten by a REGISTRAR or a "home [RFC5627], which can be overwritten by a registrar or a "home
proxy" (a proxy serving as the terminal point for routing an proxy" (a proxy serving as the terminal point for routing an
address-of-record) upon receipt of the initial request. address-of-record) upon receipt 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].
skipping to change at page 7, line 30 skipping to change at page 7, line 33
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.
The solution is to capture the Request-URIs as a request is The solution is to capture the Request-URIs as a request is
retargeted, in a SIP header field: History-Info. This allows for the retargeted, in a SIP header field: History-Info. This allows for the
capturing of the history of a request that would be lost with the capturing of the history of a request that would be lost with the
normal SIP processing involved in the subsequent retargeting of the normal SIP processing involved in the subsequent retargeting of the
request. request.
The History-info header field is added to a Request when a new The History-Info header field is added to a Request when a new
request is created by a UAC or forwarded by a Proxy, or when the request is created by a UAC or forwarded by a Proxy, or when the
target of a request is changed. It is possible for the target of a target of a request is changed. It is possible for the target of a
request to be changed by the same proxy/SIP Intermediary multiple request to be changed by the same proxy/SIP intermediary multiple
times (referred to as 'internal retargeting'). A SIP entity changing times (referred to as 'internal retargeting'). A SIP entity changing
the target of a request in response to a redirect also propagates any the target of a request in response to a redirect also propagates any
History-info header field from the initial request in the new History-Info header field from the initial request in the new
request. The ABNF and detailed description of the History-Info request. The ABNF and detailed description of the History-Info
header field parameters, along with examples is provided in header field parameters along with examples, is provided in
Section 5. Section 6, Section 7 and Section 8 provide the detailed Section 5. Section 6, Section 7 and Section 8 provide the detailed
handling of the History-Info header field by SIP User Agents, Proxies handling of the History-Info header field by SIP User Agents, Proxies
and Redirect Servers respectively. and Redirect Servers respectively.
This specification also defines three new SIP header field This specification also defines three new SIP header field
parameters, "rc", "mp" and "np", for the History-Info and Contact parameters, "rc", "mp" and "np", for the History-Info and Contact
header fields, to tag the method by which the target of a request is header fields, to tag the method by which the target of a request is
determined. Further detail on the use of these header field determined. Further detail on the use of these header field
parameters is provided in Section 10.4. parameters is provided in Section 10.4.
In addition, this specification defines a priv-value for the Privacy In addition, this specification defines a priv-value for the Privacy
header, "history", that applies to all the History-info header field header, "history", that requires anonymization of all the History-
entries in a Request or to a specific History-info header field hi- Info header field entries in a Request or to a specific History-Info
entry as described above. Further detail is provided in header field hi-entry as described above. Further detail is provided
Section 10.1. in Section 10.1.
5. History-Info Header Field Protocol Structure 5. History-Info Header Field Protocol Structure
The History-info header field defined in this specification defines The History-Info header field defined in this specification defines
the usage in out-of-dialog requests or initial requests for a dialog the usage in out-of-dialog requests or initial requests for a dialog
(e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and
SUBSCRIBE, etc.) and any non-100 provisional or final responses to SUBSCRIBE, etc.) and any non-100 provisional or final responses to
these requests (ISSUER-req, see Appendix A). these requests.
The following provides details for the information that is captured The following provides details for the information that is captured
in the History-Info header field entries for each target used for in the History-Info header field entries for each target used for
forwarding a request: forwarding a request:
o hi-targeted-to-uri: A mandatory parameter for capturing the o hi-targeted-to-uri: A mandatory parameter for capturing the
Request-URI for the specific request as it is forwarded. Request-URI for the specific request as it is forwarded.
o hi-index: A mandatory parameter for History-Info reflecting the o hi-index: A mandatory parameter for History-Info reflecting the
chronological order of the information, indexed to also reflect chronological order of the information, indexed to also reflect
the forking and nesting of requests. The format for this the forking and nesting of requests. The format for this
parameter is a string of digits, separated by dots to indicate the parameter is a sequance of nonnegative integers, separated by dots
number of forward hops and retargets. This results in a tree to indicate the number of forward hops and retargets. This
representation of the history of the request, with the lowest- results in a tree representation of the history of the request,
level index reflecting a branch of the tree. By adding the new with the lowest-level index reflecting a leaf. By adding the new
entries in order (i.e., following existing entries per the details entries in order (i.e., following existing entries per the details
in Section 10.3), including the index and sending the messages in Section 10.3), including the index and sending the messages
using a secure transport, the ordering of the History-info header using a secure transport, the ordering of the History-Info header
fields in the request is assured. In addition, applications may fields in the request is assured. In addition, applications may
extract a variety of metrics (total number of retargets, total extract a variety of metrics (total number of retargets, total
number of retargets from a specific branch, etc.) based upon the number of retargets from a specific branch, etc.) based upon the
index values. index values.
o hi-target-param: An optional parameter reflecting the mechanism by o hi-target-param: An optional parameter reflecting the mechanism by
which the Request URI captured in the hi-targeted-to-uri in the which the Request URI captured in the hi-targeted-to-uri in the
History-info header field value (hi-entry) was determined. This History-Info header field value (hi-entry) was determined. This
parameter contains either an "rc", "mp" or "np" header field parameter is either an "rc", "mp" or "np" header field parameter,
parameter, which is interpreted as follows: which is interpreted as follows:
"rc": The hi-targeted-to-URI represents a change in Request-URI "rc": The hi-targeted-to-URI represents a change in Request-URI
while the target user remains the same. This occurs for while the target user remains the same. This occurs for
example when user has multiple AoRs as an alias. The "rc" example when user has multiple AoRs as an alias. The "rc"
header field parameter contains the value of the hi-index in header field parameter contains the value of the hi-index in
the hi-entry with an hi-targeted-to-uri that reflects the the hi-entry with an hi-targeted-to-uri that reflects the
Request-URI that was retargeted Request-URI that was retargeted
"mp": The hi-targeted-to-URI represents a user other than the "mp": The hi-targeted-to-URI represents a user other than the
target user associated with the Request-URI in the incoming target user associated with the Request-URI in the incoming
request that was retargeted. This occurs when a request is request that was retargeted. This occurs when a request is
statically or dynamically retargeted to another user statically or dynamically retargeted to another user
represented by an AoR unassociated with the AoR of the original represented by an AoR unassociated with the AoR of the original
target user. The "mp" header field parameter contains the target user. The "mp" header field parameter contains the
value which represents the value of the hi-index in the hi- value of the hi-index in the hi-entry with an hi-targeted-to-
entry with an hi-targeted-to-uri that reflects the Request-URI uri that reflects the Request-URI that was retargeted, thus
that was retargeted, thus identifying the "mapped from" target. identifying the "mapped from" target.
"np": The hi-targeted-to-URI represents that there was no "np": The hi-targeted-to-URI represents that there was no
change in Request-URI. This would apply for example when a change in Request-URI. This would apply for example when a
proxy merely forwards a request to a next hop proxy and loose proxy merely forwards a request to a next hop proxy and loose
routing is used. routing is used. The "np" 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 copied unchanged
into the request represented by this hi-entry. That value will
usually be the hi-index of the parent hi-entry of this hi-
entry.
o Extension (hi-extension): A parameter to allow for future optional o Extension (hi-extension): A parameter to allow for future optional
extensions. As per [RFC3261], any implementation not extensions. As per [RFC3261], any implementation not
understanding an extension MUST ignore it. understanding an extension MUST ignore it.
The ABNF syntax for the History-info header field and header field The ABNF syntax [RFC5234] for the History-Info header field and
parameters is as follows: header field parameters is as follows:
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param) hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = addr-spec / name-addr hi-targeted-to-uri = addr-spec / name-addr
hi-param = hi-index / hi-target-param / hi-extension hi-param = hi-index / hi-target-param / hi-extension
index-val = 1*DIGIT *("." 1*DIGIT)
hi-index = "index" EQUAL index-val hi-index = "index" EQUAL index-val
index-val = number *("." number)
number = [ %31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val mp-param = "mp" EQUAL index-val
np-param = "np" EQUAL index-val np-param = "np" EQUAL index-val
hi-extension = generic-param hi-extension = generic-param
skipping to change at page 10, line 15 skipping to change at page 10, line 41
This document also extends the "contact-params" for the Contact This document also extends the "contact-params" for the Contact
header field as defined in [RFC3261] with the "rc", "mp" and "np" header field as defined in [RFC3261] with the "rc", "mp" and "np"
header field parameters defined above. header field parameters defined above.
In addition to the parameters defined by the ABNF, an hi-entry may In addition to the parameters defined by the ABNF, an hi-entry may
also include a Reason header field and/or a Privacy header field, also include a Reason header field and/or a Privacy header field,
which are both included in the "headers" component of the hi- which are both included in the "headers" component of the hi-
targeted-to-uri as described below: targeted-to-uri as described below:
o Reason: An optional parameter for History-Info, reflected in the o Reason: An optional parameter for History-Info, reflected in the
History-info header field by including the Reason header field History-Info header field by including the Reason header field
[RFC3326] included in the hi-targeted-to-uri. A reason is [RFC3326] included in the hi-targeted-to-uri. A reason is
included in the hi-targeted-to-uri of an hi-entry to reflect included in the hi-targeted-to-uri of an hi-entry to reflect
information received in a response to the request sent to that information received in a response to the request sent to that
URI. URI.
o Privacy: An optional parameter for History-Info, reflected in the o Privacy: An optional parameter for History-Info, reflected in the
History-Info header field values by including the Privacy Header History-Info header field values by including the Privacy Header
[RFC3323] included in the hi- targeted-to-uri or by adding the [RFC3323] included in the hi- targeted-to-uri or by adding the
Privacy header field to the request. The latter case indicates Privacy header field to the request. The latter case indicates
that the History-Info entries for the domain MUST be anonymized that the History-Info entries for all History-Info entries whose
prior to forwarding, whereas the use of the Privacy header field hi-targeted-to-uri has the same domain as the domain for which the
included in the hi-targeted-to-uri means that a specific hi-entry SIP entity processing the message is responsible MUST be
MUST be anonymized. anonymized prior to forwarding, whereas the use of the Privacy
header field included 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 included Note that since both the Reason and Privacy parameters are included
in the hi-targeted-to-uri, these fields will not be available in the in the hi-targeted-to-uri, these fields will not be available in the
case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. case that the hi-targeted-to-uri is a Tel-URI [RFC3966].
The following provides examples of the format for the History-info The following provides examples of the format for the History-Info
header field. Note that the backslash and CRLF between the fields in header field. Note that the backslash, CRLF and whitespace between
the examples below are for readability purposes only. the lines in the examples below are inserted for readability purposes
only. (But History-Info can be broken into multiple lines due to the
SWS that is part of HCOLON, COMMA and SEMI, and there can be multiple
History-Info header fields due to the rule of section 7.3 [RFC3261].)
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\ History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1.1,\ cause%3D302>;index=1.1,\
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\ <sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2;mp=1.1,\ cause%3D486>;index=1.2;mp=1.1,\
<sip:45432@192.168.0.3>;index=1.3;rc=1.2 <sip:45432@192.168.0.3>;index=1.3;rc=1.2
5.1. History-Info Header Field Example Scenario 5.1. History-Info Header Field Example Scenario
skipping to change at page 11, line 4 skipping to change at page 11, line 35
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\ <sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2;mp=1.1,\ cause%3D486>;index=1.2;mp=1.1,\
<sip:45432@192.168.0.3>;index=1.3;rc=1.2 <sip:45432@192.168.0.3>;index=1.3;rc=1.2
5.1. History-Info Header Field Example Scenario 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 proxy in her home domain (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 original target information or the
parameters in the request URI. Bob can recover that information by initial request-URI, including any parameters in the request URI.
locating the last hi-entry with an "rc" header field parameter. This Bob can recover that information by locating the last hi-entry with
"rc" header field parameter contains the index of the hi-entry an "rc" header field parameter. This "rc" header field parameter
containing the lost target information - i.e., the contains the index of the hi-entry containing the lost target
sip:bob@biloxi.example.com hi-entry with index=1.1. Note that an hi- information - i.e., the sip:bob@biloxi.example.com hi-entry with
entry is not included for the fork to sip:bob@192.0.2.7 since there index=1.1. Note that in the 200 response to Alice, an hi-entry is
was no response at the time the 200 OK is sent to Alice. not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since
biloxi.example.com had not received a response from that fork at the
time it sent the 200 OK that ultimately reached Alice.
The formatting in this scenario is for visual purposes; thus, Additional detailed scenarios are available in Appendix B.
backslash and CRLF are used between the fields for readability.
Refer to Section 5.1 for the proper formatting. Additional detailed
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 13, line 20 skipping to change at page 14, line 20
UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries
forward hi-entries received in requests at the UAS to requests being forward hi-entries received in requests at the UAS to requests being
forwarded by the UAC, as well as carrying forward hi-entries in forwarded by the UAC, as well as carrying forward hi-entries in
responses received at the UAC to the responses forwarded by the UAS, responses received at the UAC to the responses forwarded by the UAS,
subject to privacy considerations per Section 10.1. subject to privacy considerations per Section 10.1.
6.1. User Agent Client (UAC) Behavior 6.1. User Agent Client (UAC) Behavior
The UAC MUST include the "histinfo" option tag in the Supported The UAC MUST include the "histinfo" option tag in the Supported
header field in any out-of-dialog requests or initial requests for a header field in any out-of-dialog requests or initial requests for a
dialog for which the UAC would like the History-info header field in dialog for which the UAC would like the History-Info header field in
the response. When issuing a request, the UAC MUST follow the the response. When issuing a request, the UAC MUST follow the
procedures in Section 9.2. In the case of an initial request, except procedures in Section 9.2. In the case of an initial request, except
where the UAC is part of a B2BUA, there is no cache of hi- entries where the UAC is part of a B2BUA, there is no cache of hi- entries
with which to populate the History-info header field and the hi-index with which to populate the History-Info header field and the hi-index
is set to 1 per Section 10.3. When receiving a response the UAC MUST is set to 1 per Section 10.3. When receiving a response the UAC MUST
follow the procedures in Section 9.3. follow the procedures in Section 9.3.
If the UAC generates further forks of the initial request (either due
to acting on a 3xx response or internally-directed forking to
multiple destinations), the successive requests will add hi-entries
with hi-indexes of 2, 3, etc.
6.2. User Agent Server (UAS) Behavior 6.2. User Agent Server (UAS) Behavior
When receiving a request, a UAS MUST follow the procedures defined in When receiving a request, a UAS MUST follow the procedures defined in
Section 9.2. When sending a response other than a 3xx response, a Section 9.1. When sending a response other than a 3xx response, a
UAS MUST follows the procedures as defined in Section 9.4. When UAS MUST follows the procedures in Section 9.4. When sending a 3xx
sending a 3xx response, the UAS MUST follow the procedures defined response, the UAS MUST follow the procedures defined for a redirect
for a redirect server per Section 8. An application at the UAS can server per Section 8. An application at the UAS can make use of the
make use of the cached hi-entries as described in Section 11. cached hi-entries as described in Section 11.
7. Proxy/Intermediary Handling of History-Info Header Fields 7. Proxy/Intermediary Handling of History-Info Header Fields
This section describes the procedures for proxies and other SIP This section describes the procedures for proxies and other SIP
intermediaries for the handling of the History-Info header fields for intermediaries for the handling of the History-Info header fields for
each of the following scenarios: each of the following scenarios:
Receiving a Request: An intermediary MUST follow the procedures in Receiving a Request: An intermediary MUST follow the procedures in
Section 9.1 for the handling of hi-entries in incoming SIP Section 9.1 for the handling of hi-entries in incoming SIP
requests. requests.
skipping to change at page 14, line 28 skipping to change at page 15, line 32
before forwarding - i.e., a request is retargeted to a SIP entity before forwarding - i.e., a request is retargeted to a SIP entity
that is "internal" to the intermediary before the same intermediary that is "internal" to the intermediary before the same intermediary
retargets the request to an external target . A typical example retargets the request to an external target . A typical example
would be a proxy that retargets a request first to a different user would be a proxy that retargets a request first to a different user
(i.e., it maps to a different AOR) and then forwards to a registered (i.e., it maps to a different AOR) and then forwards to a registered
contact bound to the same AOR. In this case, the intermediary MUST contact bound to the same AOR. In this case, the intermediary MUST
add a hi-entry for (each of) the internal target(s) per the add a hi-entry for (each of) the internal target(s) per the
procedures in Section 9.2. The intermediary MAY include a Reason procedures in Section 9.2. The intermediary MAY include a Reason
header field in the hi-entry with the hi-targeted-to-uri that has header field in the hi-entry with the hi-targeted-to-uri that has
been retargeted as shown in the INVITE (F6) in the example in been retargeted as shown in the INVITE (F6) in the example in
Appendix B.3. Figure 1 provides an example of internal retargeting. Appendix B.3.
8. Redirect Server Handling of History-Info Header Fields 8. Redirect Server Handling of History-Info Header Fields
A redirect server MUST follow the procedures in Section 9.1 when it A redirect server MUST follow the procedures in Section 9.1 when it
receives a SIP Request. A redirect server MUST follow the procedures receives a SIP Request. A redirect server MUST follow the procedures
in Section 9.4 when it sends a SIP Response. When generating the in Section 9.4 when it sends a SIP Response. When generating the
Contact header field in a 3xx response, the redirect server MUST add Contact header field in a 3xx response, the redirect server MUST add
the appropriate "mp", "np" or "rc" header field parameter to each the appropriate "mp", "np" or "rc" header field parameter to each
Contact header field as described in Section 10.4, if applicable. Contact header field as described in Section 10.4, if applicable.
skipping to change at page 15, line 30 skipping to change at page 16, line 37
Section 10.3. Section 10.3.
The SIP entity MUST NOT include an "rc", "mp" or "np" header field The SIP entity MUST NOT include an "rc", "mp" or "np" header field
parameter. parameter.
9.2. Sending a Request with History-Info 9.2. Sending a Request with History-Info
When sending a request, a SIP entity MUST include all cached hi- When sending a request, a SIP entity MUST include all cached hi-
entries in the request. In addition, the SIP entity MUST add a new entries in the request. In addition, the SIP entity MUST add a new
hi-entry to the outgoing request, but the SIP entity MUST NOT add the hi-entry to the outgoing request, but the SIP entity MUST NOT add the
hi-entry to the outgoing request(but not the cache) populating the hi-entry to the cache at this time. The hi-entries in the outgoing
new hi-entry to the cache at this time. The new hi-entry is request's History-Info header field is the preorder of the tree of
populated as follows: hi-entries, that is, by the lexicographic ordering of the hi-indexes.
The new hi-entry is populated as follows:
hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value
of the Request-URI of the current (outgoing) request. of the Request-URI of the current (outgoing) request.
privacy: If privacy is required, the procedures of Section 10.1 MUST privacy: If privacy is required, the procedures of Section 10.1 MUST
be followed. be followed.
hi-index: The SIP entity MUST include an hi-index for the hi-entry hi-index: The SIP entity MUST include an hi-index for the hi-entry
as described in Section 10.3. as described in Section 10.3.
rc/mp: The SIP entity MUST include an "rc", "mp" or "np" header rc/mp/np: The SIP entity MUST include an "rc", "mp" or "np" header
field parameter in the hi-entry, if applicable, per the procedures field parameter in the hi-entry, if applicable, per the procedures
in Section 10.4. in Section 10.4.
9.3. Receiving a Response with History-Info or Request Timeouts 9.3. Receiving a Response with History-Info or Request Timeouts
When a SIP entity receives a non-100 response or a request times out, When a SIP entity receives a non-100 response or a request times out,
the SIP entity performs the following steps: the SIP entity performs the following steps:
Step 1: Add hi-entry to cache Step 1: Add hi-entry to cache
skipping to change at page 16, line 40 skipping to change at page 17, line 49
It is important to note that the cache does not contain hi-entries It is important to note that the cache does not contain hi-entries
for requests that have not yet received a non-100 response, so there for requests that have not yet received a non-100 response, so there
can be gaps in indices (e.g., 1.2 and 1.4 could but present but not can be gaps in indices (e.g., 1.2 and 1.4 could but present but not
1.3). 1.3).
9.4. Sending History-Info in Responses 9.4. Sending History-Info in Responses
When sending a response other than a 100, a SIP entity MUST include When sending a response other than a 100, a SIP entity MUST include
all the cached hi-entries in the response, subject to the privacy all the cached hi-entries in the response, subject to the privacy
consideration in Section 10.1.2 with the following exception: If the consideration in Section 10.1.2, and with the following exception: If
received request contained no hi-entries and there is no "histinfo" the received request contained no hi-entries and there is no
option tag in the Supported header field, the SIP entity MUST NOT "histinfo" option tag in the Supported header field, the SIP entity
include hi-entries in the response. MUST NOT include History-Info in the response.
10. Processing the History-Info Header Field 10. Processing the History-Info Header Field
The following sections describe the procedures for processing the The following sections describe the procedures for processing the
History-Info header field. These procedures are applicable to SIP History-Info header field. These procedures are applicable to SIP
entities such as Proxies/Intermediaries, Redirect Servers or User entities such as Proxies/Intermediaries, Redirect Servers or User
Agents. Agents.
10.1. Privacy in the History-Info Header Field 10.1. Privacy in the History-Info Header Field
The privacy requirements for this document are described in The privacy requirements for this document are described in
Appendix A.2. Section 10.1.1 describes the insertion of the Privacy Appendix A.2. Section 10.1.1 describes the insertion of the Privacy
header field defined in [RFC3323] to indicate the privacy to be header field defined in [RFC3323] to indicate the privacy to be
applied to the History-Info header field entries. Section 10.1.2 applied to the History-Info header field entries. Section 10.1.2
describes how to apply privacy to a request or response that is being describes how to apply privacy to a request or response that is being
forwarded, based on the presence of the Privacy header field. forwarded, based on the presence of the Privacy header field.
10.1.1. Indicating Privacy 10.1.1. Indicating Privacy
As with other SIP headers described in [RFC3323], the hi-targeted-to- As with other SIP headers described in [RFC3323], the hi-targeted-to-
uris in the History-info header field can inadvertently reveal uris in the History-Info header field can inadvertently reveal
information about the initiator of the request. Thus, the UAC needs information about the initiator of the request. Thus, the UAC needs
a mechanism to indicate that the hi-targeted-to-uris in the hi- a mechanism to indicate that the hi-targeted-to-uris in the hi-
entries need to be privacy protected. The Privacy header field is entries need to be privacy protected. The Privacy header field is
used by the UAC to indicate that privacy is to be applied to all the used by the UAC to indicate that privacy is to be applied to all the
hi-entries in the request as follows: hi-entries in the request as follows:
o If the UAC is including a Privacy header field with a priv-value o If the UAC is including a Privacy header field with a priv-value
of "header" in the request, then the UAC SHOULD NOT include a of "header" in the request, then the UAC SHOULD NOT include a
priv-value of "history" in the Privacy header field in the priv-value of "history" in the Privacy header field in the
Request. Request.
skipping to change at page 17, line 39 skipping to change at page 18, line 46
o If the UAC is including any priv-values other than "header" in the o If the UAC is including any priv-values other than "header" in the
Privacy header field, then the UAC MUST also include a priv-value Privacy header field, then the UAC MUST also include a priv-value
of "history" in the Privacy header field in the Request. of "history" in the Privacy header field in the Request.
o If the UAC is not including any priv-values in the Privacy header o If the UAC is not including any priv-values in the Privacy header
field in the request, then the UAC MUST add a Privacy header field in the request, then the UAC MUST add a Privacy header
field, with a priv-value of "history", to the request. The UAC field, with a priv-value of "history", to the request. The UAC
MUST NOT include a priv-value of "critical" in the Privacy header MUST NOT include a priv-value of "critical" in the Privacy header
field in the Request in this case. field in the Request in this case.
In addition, the History-info header field can reveal general routing In addition, the History-Info header field can reveal general routing
and diverting information within an intermediary, which the and diverting information within an intermediary, which the
intermediary wants to privacy protect. In this case, the intermediary wants to privacy protect. In this case, the
intermediary MUST set a Privacy header field to a priv-value of intermediary MUST construct a Privacy header field with the single
"history" and include the Privacy header field in the hi-targeted-to- priv-value of "history" and include the Privacy header field in the
uri, for each new hi-entry added by the intermediary, as the request hi-targeted-to-uri, for each new hi-entry created by the intermediary
is retargeted within the domain for which the SIP entity is whose hi-targeted-to-uri it wishes to privacy protect. Note that the
responsible. Note, that the hi-entries that are added to a request priv-value in the Privacy header for the incoming request does not
from the cache are excluded in this case since the appropriate necessarily influence whether the intermediary includes a Privacy
privacy was set for those hi-entries when they were originally added header field in the hi-entries. For example, even if the Privacy
to a request. The intermediary MUST NOT include any other priv- header for the incoming request contained a priv-value of "none", the
values in this Privacy header field. Note that the priv-value in the Proxy can still set a priv-value of "history" in the Privacy header
Privacy header for the incoming request does not necessarily field included in the hi-targeted-to-uri.
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
included in the hi-targeted-to-uri.
Finally, the terminator of the request may not want to reveal the Finally, the UAS may not want to reveal the final reached target to
final reached target to the originator. In this case, the terminator the originator. In this case, the UAS MUST include a Privacy header
MUST include a Privacy header field with a priv-value of "history" in field with a priv-value of "history" in the hi-targeted-to-uri in the
the hi-targeted-to-uri in the last hi-entry, in the response. As last hi-entry, in the response. As noted above, the UAS of the
noted above, the terminator of the request MUST NOT use any other request MUST NOT use any other priv-values in the Privacy header
priv-values in the Privacy header field included in the hi-entry. field included in the hi-entry.
10.1.2. Applying Privacy 10.1.2. Applying Privacy
When a request is retargeted to a URI associated with a domain for When a SIP message is forwarded to a domain for which the SIP
which the SIP intermediary is not responsible or a response is intermediary is not responsible, a Privacy Service at the boundary of
forwarded to a domain for which the SIP intermediary is not the domain applies the appropriate privacy based on the value of the
responsible, a Privacy Service at the boundary of the domain applies Privacy header field in the message header or in the "headers"
the appropriate privacy based on the value of the Privacy header component of the hi-targeted-to-uri in the individual hi-entries.
field in the message header or in the "headers" component of the hi-
targeted-to-uri in the individual hi-entries.
If there is a Privacy header field in the message header of a request If there is a Privacy header field in the message header of a request
or response, with a priv-value of "header" or "history", then all the or response, with a priv-value of "header" or "history", then all the
hi-targeted-to-uris in the hi-entries, associated with the domain for hi-targeted-to-uris in the hi-entries, associated with the domain for
which a SIP intermediary is responsible, are anonymized by the which the SIP intermediary is responsible, are anonymized by the
Privacy Service. The Privacy Service MUST change any hi-targeted-to- Privacy Service. The Privacy Service MUST change any hi-targeted-to-
uris in the hi-entries that have not been anonymized to anonymous uris in these hi-entries that have not been anonymized(evidenced by
URIs containing a domain of anonymous.invalid (e.g., their domain not being "anonymous.invalid") to anonymous URIs
containing a domain of anonymous.invalid (e.g.,
anonymous@anonymous.invalid). If there is a Privacy header field in anonymous@anonymous.invalid). If there is a Privacy header field in
the "headers" component of the hi-targeted-to-uri in the hi-entry, the "headers" component of the hi-targeted-to-uri in the hi-entries,
then the Privacy header field value MUST be removed from the hi- then the Privacy header field value MUST be removed from the hi-
entry. Once all the appropriate hi-entries have been anonymized, the entry. Once all the appropriate hi-entries have been anonymized, the
Privacy Service MUST remove the priv-value of "history" from the Privacy Service MUST remove the priv-value of "history" from the
Privacy header field in the message header of the request or Privacy header field in the message header of the request or
response. If there are no remaining priv-values in the Privacy response. If there are no remaining priv-values in the Privacy
header field, the Privacy Service MUST remove the Privacy header header field, the Privacy Service MUST remove the Privacy header
field from the request or response per [RFC3323]. field from the request or response per [RFC3323].
If there is not a Privacy header field in the message header of the If there is not a Privacy header field in the message header of the
request or response that is being forwarded, but there is a Privacy request or response that is being forwarded, but there is a Privacy
header field with a priv-value of "history" in the "headers" header field with a priv-value of "history" in the "headers"
component in any of the hi-targeted-uris in the hi-entries associated component in any of the hi-targeted-uris in the hi-entries associated
with the domain for which a SIP intermediary is responsible, then the with the domain for which a SIP intermediary is responsible, then the
Privacy Service MUST anonymize those hi-targeted-to-uris. The Privacy Service MUST update those hi-targeted-to-uris as described
Privacy Service MUST populate each of the hi-targeted-to-uris with an above. Any other priv-values in the Privacy header field in the
anonymous URI with a domain of anonymous.invalid (e.g., "headers" component of the hi-targeted-to-uris in the hi-entries MUST
anonymous@anonymous.invalid). Any other priv-values in the Privacy be ignored. In any case, the Privacy Service MUST remove the Privacy
header field in the "headers" component of the hi-targeted-to-uris in header field from the "headers" compenent of the hi-targeted-to-uris
the hi-entries MUST be ignored. In any case, the Privacy Service in the hi-entries prior to forwarding.
MUST remove the Privacy header field from the "headers" compenent of
the hi-targeted-to-uris in the hi-entries prior to forwarding.
10.2. Reason in the History-info Header Field 10.2. Reason in the History-Info Header Field
A Reason header field is added to the "headers" component in an hi- A Reason header field is added to the "headers" component in an hi-
targeted-to-uri when the hi-entry is added to the cache based upon targeted-to-uri when the hi-entry is added to the cache based upon
the receipt of a non-100 or non-2xx SIP response, as described in the receipt of a non-100 or non-2xx SIP response, as described in
Section 9.3. If the Reason header field is being added due to Section 9.3. If the Reason header field is being added due to
receipt of an explicit SIP response and the response contains any receipt of an explicit SIP response and the response contains any
Reason header fields (see [RFC3326]), then the SIP entity MUST Reason header fields (see [RFC3326]), then the SIP entity MUST
include the Reason header fields in the "headers" component of the include the Reason header fields in the "headers" component of the
hi-targeted-to-uri in the last hi-entry added to the cache, unless hi-targeted-to-uri in the last hi-entry added to the cache, unless
the hi-targeted-to-uri is a Tel-URI. If the SIP response does not the hi-targeted-to-uri is a Tel-URI. If the SIP response does not
contain a Reason header field, the SIP entity MUST include a Reason contain a Reason header field, the SIP entity MUST include a Reason
header field, containing the SIP Response Code, in the "headers" header field, containing the SIP Response Code, in the "headers"
component of the hi-targeted-to-uri in the last hi-entry added to the component of the hi-targeted-to-uri in the last hi-entry added to the
cache, unless the hi-targeted-to-uri is a Tel-URI. cache, unless the hi-targeted-to-uri is a Tel-URI.
If a request has timed out (instead of being explicitly rejected), If a request has timed out (instead of being explicitly rejected),
the SIP entity MUST include a Reason header field, containing a SIP the SIP entity MUST update the cache as if the request received a SIP
error response code of 408 "Request Timeout". error response code of 408 "Request Timeout".
A request can receive multiple non-100 non-2xx responses which carry
or imply (for responses without Reason headers, and for timeouts)
multiple, possibly duplicated, reason-values to be applied to an hi-
targeted-to-uri. In these situations, the SIP entity creating
History-Info header value would choose the appropriate Reason header
field value.
A SIP entity MAY also include a Reason header field in the "headers" A SIP entity MAY also include a Reason header field in the "headers"
component of an hi-targeted-to-uri containing the URI of a request component of an hi-targeted-to-uri containing the URI of a request
that was retargeted as a result of internal retargeting. that was retargeted as a result of internal retargeting.
If additional Reason header field parameters are defined in the If additional Reason header field parameters are defined in the
future per [RFC3326], the use of these Reason header field parameters future per [RFC3326], the use of these Reason header field parameters
for the History-Info header field MUST follow the same rules as for the History-Info header field MUST follow the same rules as
described above. described above.
10.3. Indexing in the History-Info Header Field 10.3. Indexing in the History-Info Header Field
In order to maintain ordering and accurately reflect the retargeting In order to maintain ordering and accurately reflect the retargeting
of the request, the SIP entity MUST add a hi-index to each hi-entry. of the request, the SIP entity MUST add a hi-index to each hi-entry.
Per the syntax in Section 5, the hi-index consists of a series of Per the syntax in Section 5, the hi-index consists of a series of
digits separated by dots (e.g., 1.1.2). Each dot reflects a SIP nonnegative integer separated by dots (e.g., 1.1.2). Each dot
forwarding hop. The digit following each dot reflects the order in reflects a SIP forwarding hop. The nonnegative integer following
which a request was retargeted at the hop. The highest digit at each each dot reflects the order in which a request was retargeted at the
hop reflects the number of entities to which the request has been hop. The highest nonnegative integer at each hop reflects the number
retargeted at the specific hop (i.e., the number of branches). Thus, of entities to which the request has been retargeted at the specific
the indexing results in a logical tree representation for the history hop (i.e., the number of branches) at the time that the request
of the request. represented by this hi-entry was generated. Thus, the indexing
results in a logical tree representation for the history of the
request and the hi-entries are given in the preorder of the tree.
The first index in a series of History-Info entries MUST be set to 1. The first index in a series of History-Info entries MUST be set to 1.
In the case that a SIP entity (intermediary or UAS) adds a first hi-
In the case that a SIP entity (intermediary or UAS) adds an hi-entry entry on behalf of the previous hop, the hi-index MUST be set to 1.
on behalf of the previous hop, the hi-index MUST be set to 1. For For each forward hop (i.e., each new level of indexing), the last
each forward hop (i.e., each new level of indexing), the hi-index integers of the hi-indexes of the new requests MUST be generated
MUST start at 1. An increment of 1 MUST be used for advancing to a starting at 1 and incrementing by 1 for each additional request"
new branch.
The basic rules for adding the hi-index are summarized as follows: The basic rules for adding the hi-index are summarized as follows:
1. Forwarding a request without changing the target: In the case of 1. Forwarding a request without changing the target: In the case of
a request that is being forwarded without changing the target, a request that is being forwarded without changing the target,
the hi-index reflects the increasing length of the branch. In the hi-index reflects the increasing length of the branch. In
this case, the SIP entity MUST read the value from the History- this case, the SIP entity MUST read the value from the History-
info header field in the received request and MUST add another Info header field in the received request and MUST add another
level of indexing by appending the dot delimiter followed by an level of indexing by appending the dot delimiter followed by an
initial value of 1 for the new level. For example, if the hi- initial value of 1 for the new level. For example, if the hi-
index in the last History-info header field in the received index in the last History-Info header field in the received
request is 1.1, a proxy would add a hi-entry with an hi-index of request is 1.1, a proxy would add a hi-entry with an hi-index of
1.1.1 and forward the request. 1.1.1 and forward the request.
2. Retargeting within a processing entity - 1st instance: For the 2. Retargeting within a processing entity - 1st instance: For the
first instance of retargeting within a processing entity, the SIP first instance of retargeting within a processing entity, the SIP
entity MUST calculate the hi-index as prescribed for basic entity MUST calculate the hi-index as prescribed for basic
forwarding. forwarding.
3. Retargeting within a processing entity - subsequent instance: For 3. Retargeting within a processing entity - subsequent instance: For
each subsequent retargeting of a request by the same SIP entity, each subsequent retargeting of a request by the same SIP entity,
skipping to change at page 21, line 6 skipping to change at page 22, line 15
5. Forking requests: If the request forwarding is done in multiple 5. Forking requests: If the request forwarding is done in multiple
forks (sequentially or in parallel), the SIP entity MUST set the forks (sequentially or in parallel), the SIP entity MUST set the
hi-index for each hi-entry for each forked request per the rules hi-index for each hi-entry for each forked request per the rules
above, with each new request having a unique index. Each index above, with each new request having a unique index. Each index
MUST be sequentially assigned. For example, if the index in the MUST be sequentially assigned. For example, if the index in the
last History-Info header field in the received request is 1.1, last History-Info header field in the received request is 1.1,
this processing entity would initialize its index to 1.1.1 for this processing entity would initialize its index to 1.1.1 for
the first fork, 1.1.2 for the second, and so forth (see Figure 1 the first fork, 1.1.2 for the second, and so forth (see Figure 1
for an example). Note, that in the case of parallel forking, for an example). Note, that in the case of parallel forking,
only the hi-entry corresponding to the fork is included in the only the hi-entry corresponding to the fork is included in the
request. request because no response can yet have been received for any of
the parallel forked requests.
6. Missing entity: If the request clearly has a gap in the hi-entry 6. Missing entity: If the request clearly has a gap in the hi-entry,
(e.g. by evaluating via header to the existing request history to the entity adding an hi-entry MUST add an index a nonnegative
see if it traversed a domain which doesn't exist in History-Info integer of "0" to the current index prior to adding appropriate
header field.), the entity adding an hi-entry MUST add an index a
digit of "0" to the current index prior to adding appropriate
index for the action to be taken. If the index of the last hi- index for the action to be taken. If the index of the last hi-
entry in the request received was 1.1.2 and there was a missing entry in the request received was 1.1.2 and there was a missing
hi-entry and the request was being forwarded to the next hop, the hi-entry and the request was being forwarded to the next hop, the
resulting index will be 1.1.2.0.1. resulting index will be 1.1.2.0.1.
10.4. Mechanism for Target Determination in the History-Info Header 10.4. Mechanism for Target Determination in the History-Info Header
Field Field
This specification defines two header field parameters, "rc", "mp" This specification defines two header field parameters, "rc", "mp"
and "np", indicating two mechanisms by which a new target for a and "np", indicating two mechanisms by which a new target for a
request is determined. Both parameters contain an index whose value request is determined. Both parameters contain an index whose value
is the hi-index of the hi-entry with an hi-targeted-to-uri that is the hi-index of the hi-entry with an hi-targeted-to-uri that
represents the Request-URI that was retargeted. represents the Request-URI that was retargeted.
The SIP entity MUST determine the specific parameter field to be The SIP entity MUST determine the specific parameter field to be
included in the hi-target-param, in the History-info header field, as included in the hi-target-param, in the History-Info header field, as
the targets are added to the target set per the procedures in section 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 16.5 of [RFC3261] or per section 8.1.3.4 [RFC3261] in the case of
retargeting to a contact URI received in a 3xx response. In the retargeting to a contact URI received in a 3xx response. In the
latter case, the specific header field parameter in the Contact latter case, the specific header field parameter in the Contact
header field becomes the header field parameter that is used in the header field becomes the header field parameter that is used in the
hi-entry when the request is retargeted. If the Contact header field hi-entry when the request is retargeted. If the Contact header field
does not contain an "rc", "mp" or "np" header field parameter, then does not contain an "rc", "mp" or "np" header field parameter, then
the SIP entity MUST NOT include an "rc", "mp" or "np" header field the SIP entity MUST NOT include an "rc", "mp" or "np" header field
parameter in the hi-target-param in the hi-entry when the request is parameter in the hi-target-param in the hi-entry when the request is
retargeted to a contact URI received in a 3xx response.. retargeted to a contact URI received in a 3xx response..
skipping to change at page 22, line 26 skipping to change at page 23, line 33
case the mp-value is an earlier sibling or descendant of an case the mp-value is an earlier sibling or descendant of an
earlier sibling of the hi-entry's index, that of the downstream earlier sibling of the hi-entry's index, that of the downstream
request which received the 3xx response. request which received the 3xx response.
11. Application Considerations 11. Application Considerations
History-Info provides a very flexible building block that can be used History-Info provides a very flexible building block that can be used
by intermediaries and UAs for a variety of services. Prior to any by intermediaries and UAs for a variety of services. Prior to any
application usage of the History-Info header field parameters, the application usage of the History-Info header field parameters, the
SIP entity that processes the hi-entries MUST evaluate the hi- SIP entity that processes the hi-entries MUST evaluate the hi-
entries. The SIP entity MUST determine if there are gaps in the entries. The SIP entity MUST be prepared to process effectively
indices. Gaps are possible if the request is forwarded through messages whose hi-entries show evidence of "gaps", that is,
intermediaries that do not support the History-info header field and situations that reveal that not all of the forks of the request have
are reflected by the existence of multiple hi-entries with an digit been recorded in the hi-entries. Gaps are possible if the request is
of "0" e.g. "1.1.0.1". Gaps are also possible in the case of forwarded through intermediaries that do not support the History-Info
parallel forking if there is an outstanding request at the time the header field and are reflected by the existence of hi-entries with a
SIP entity sends a response as described in Section 9.4, in which nonnegative integer of "0" e.g. "1.1.0.1". Gaps are also possible in
case the gap will not be visible as the branch responsible for the the case of parallel forking if there is an outstanding request at
gap wasn't on the path of the request received. Thus, if gaps are the time the SIP entity sends a message. Thus, if gaps are detected,
detected, the SIP entity MUST NOT treat this as an error, but SHOULD the SIP entity MUST NOT treat this as an error, but SHOULD indicate
indicate to any applications that there are gaps. The interpretation to any applications that there are gaps. The interpretation of the
of the information in the History-info header field depends upon the information in the History-Info header field depends upon the
specific application; an application might need to provide special specific application; an application might need to provide special
handling in some cases where there are gaps. handling in some cases where there are gaps.
The following describes some categories of information that The following describes some categories of information that
applications can use: applications can use:
1. Complete history information - e.g., for debug or other 1. Complete history information - e.g., for debug or other
operational and management aspects, optimization of determining operational and management aspects, optimization of determining
targets to avoid retargeting to the same URI, etc. This targets to avoid retargeting to the same URI, etc. This
information is relevant to proxies, UACs and UASs. information is relevant to proxies, UACs and UASs.
skipping to change at page 23, line 17 skipping to change at page 24, line 26
3. Hi-entry with the index that matches the value of the "mp" header 3. Hi-entry with the index that matches the value of the "mp" header
field parameter in the last hi-entry with a "mp" header field field parameter in the last hi-entry with a "mp" header field
parameter in the hi-target-param in the Request received by a UAS parameter in the hi-target-param in the Request received by a UAS
- i.e., the last Request URI that was mapped to reach the - i.e., the last Request URI that was mapped to reach the
destination. destination.
4. Hi-entry with the index that matches the value of the "rc" header 4. Hi-entry with the index that matches the value of the "rc" header
field parameter in the first hi-entry with a "rc" header field field parameter in the first hi-entry with a "rc" header field
parameter in the Request received by a UAS. Note, this would be parameter in the Request received by a UAS. Note, this would be
the original AoR if all the entities involved support the the original AoR if all the entities involved support the
History-info header field and there is absence of an "mp" header History-Info header field and there is absence of an "mp" header
field parameter prior to the "rc" header field parameter in the field parameter prior to the "rc" header field parameter in the
hi-target-param in the History-info header field. However, there hi-target-param in the History-Info header field. However, there
is no guarantee that all entities will support History-Info, thus is no guarantee that all entities will support History-Info, thus
the hi-entry that matches the value of the "rc" header field the hi-entry that matches the value of the "rc" header field
parameter of the first hi-entry with an "rc" header field parameter of the first hi-entry with an "rc" header field
parameter in the hi-target-param within the domain associated parameter in the hi-target-param within the domain associated
with the target URI at the destination is more likely to be with the target URI at the destination is more likely to be
useful. useful.
5. Hi-entry with the index that matches the value of "mp" header 5. Hi-entry with the index that matches the value of "mp" header
field parameter in the first hi-entry with an "mp" header field field parameter in the first hi-entry with an "mp" header field
parameter in the Request received by a UAS. Note, this would be parameter in the Request received by a UAS. Note, this would be
the original mapped URI if all entities supported the History- the original mapped URI if all entities supported the History-
info header field. However, there is no guarantee that all Info header field. However, there is no guarantee that all
entities will support History-Info, thus the hi-entry that entities will support History-Info, thus the hi-entry that
matches the value of the "mp" header field parameter of the first matches the value of the "mp" header field parameter of the first
hi-entry with an "mp" header field parameter within the domain hi-entry with an "mp" header field parameter within the domain
associated with the target URI at the destination is more likely associated with the target URI at the destination is more likely
to be useful. to be useful.
In many cases, applications are most interested in the information In many cases, applications are most interested in the information
within a particular domain(s), thus only a subset of the information within a particular domain(s), thus only a subset of the information
is required. is required.
skipping to change at page 24, line 5 skipping to change at page 25, line 13
example, an Automatic Call Distribution (ACD)/Call center application example, an Automatic Call Distribution (ACD)/Call center application
that utilizes the hi-entry which index matches the value of the "mp" that utilizes the hi-entry which index matches the value of the "mp"
header field parameter of the first hi-entry with an "mp" header header field parameter of the first hi-entry with an "mp" header
field parameter, may also display other agents, reflected by other field parameter, may also display other agents, reflected by other
hi-entries prior to entries with hi-target value of "rc" header field hi-entries prior to entries with hi-target value of "rc" header field
parameter, to whom the call was targeted prior to its arrival at the parameter, to whom the call was targeted prior to its arrival at the
current agent. This could allow the agent the ability to decide how current agent. This could allow the agent the ability to decide how
they might forward or reroute the call if necessary (avoiding agents they might forward or reroute the call if necessary (avoiding agents
that were not previously available for whatever reason, etc.). that were not previously available for whatever reason, etc.).
Since support for History-info header field is optional, a service Since support for History-Info header field is optional, a service
MUST define default behavior for requests and responses not MUST define default behavior for requests and responses not
containing History-Info header fields. For example, an entity may containing History-Info header fields. For example, an entity may
receive an incomplete set of hi-entries or hi-entries which are not receive an incomplete set of hi-entries or hi-entries which are not
tagged appropriately with an hi-target-param. This may not impact tagged appropriately with an hi-target-param. This may not impact
some applications (e.g., debug), however, it could require some some applications (e.g., debug), however, it could require some
applications to make some default assumptions in this case. For applications to make some default assumptions in this case. For
example, in an ACD scenario, the application could select the oldest example, in an ACD scenario, the application could select the oldest
hi-entry with the domain associated with the ACD system and display hi-entry with the domain associated with the ACD system and display
that as the original called party. Depending upon how and where the that as the original called party. Depending upon how and where the
request may have been retargeted, the complete list of agents to whom request may have been retargeted, the complete list of agents to whom
the call was targeted may not be available. the call was targeted may not be available.
12. Application Specific Usage 12. Application Specific Usage
Following are possible (non-normative) application-specific usages of
History-Info.
12.1. PBX Voicemail 12.1. PBX Voicemail
A voicemail system typically requires the original called party A voicemail system typically requires the original called party
information to determine the appropriate mailbox so an appropriate information to determine the appropriate mailbox so an appropriate
greeting can be provided and the appropriate party notified of the greeting can be provided and the appropriate party notified of the
message. message.
The original target is determined by finding the first hi-entry The original target is determined by finding the first hi-entry
tagged with "rc" and using the hi-entry referenced by the index of tagged with "rc" and using the hi-entry referenced by the index of
"rc" header field parameter as the target for determining the "rc" header field parameter as the target for determining the
skipping to change at page 25, line 21 skipping to change at page 26, line 33
Appendix A.1. Appendix A.1.
This document defines a header field for SIP. The use of the This document defines a header field for SIP. The use of the
Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to
ensure the overall confidentiality of the History-Info header fields ensure the overall confidentiality of the History-Info header fields
(SEC-req-4) is strongly RECOMMENDED. This results in History-Info (SEC-req-4) is strongly RECOMMENDED. This results in History-Info
having at least the same level of security as other headers in SIP having at least the same level of security as other headers in SIP
that are inserted by intermediaries. With TLS, History-Info header that are inserted by intermediaries. With TLS, History-Info header
fields are no less, nor no more, secure than other SIP header fields, fields are no less, nor no more, secure than other SIP header fields,
which generally have even more impact on the subsequent processing of which generally have even more impact on the subsequent processing of
SIP sessions than the History-info header field. SIP sessions than the History-Info header field.
Note that while using the SIPS scheme (as per [RFC5630]) protects Note that while using the SIPS scheme (as per [RFC5630]) protects
History-Info from tampering by arbitrary parties outside the SIP History-Info from tampering by arbitrary parties outside the SIP
message path, all the intermediaries on the path are trusted message path, all the intermediaries on the path are trusted
implicitly. A malicious intermediary could arbitrarily delete, implicitly. A malicious intermediary could arbitrarily delete,
rewrite, or modify History-Info. This specification does not attempt rewrite, or modify History-Info. This specification does not attempt
to prevent or detect attacks by malicious intermediaries. to prevent or detect attacks by malicious intermediaries.
In terms of ensuring the privacy of hi-entries, the same security In terms of ensuring the privacy of hi-entries, the same security
considerations as those described in [RFC3323] apply. Namely if the considerations as those described in [RFC3323] apply. Namely if the
skipping to change at page 26, line 44 skipping to change at page 28, line 8
14.2. Registration of "history" for SIP Privacy Header Field 14.2. Registration of "history" for SIP Privacy Header Field
This document defines a priv-value for the SIP Privacy header field: This document defines a priv-value for the SIP Privacy header field:
history The following changes have been made to history The following changes have been made to
http://www.iana.org/assignments/sip-priv-values The following has http://www.iana.org/assignments/sip-priv-values The following has
been added to the registration for the SIP Privacy header field: been added to the registration for the SIP Privacy header field:
Name Description Registrant Reference Name Description Registrant Reference
---- ----------- ---------- --------- ---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC XXXX] history Privacy requested for Mary Barnes [RFC XXXX]
History-info header mary.barnes@polycom.com History-Info header mary.barnes@polycom.com
fields(s) fields(s)
Note to RFC Editor: Please replace RFC XXXX with the RFC number of Note to RFC Editor: Please replace RFC XXXX with the RFC number of
this specification. this specification.
14.3. Registration of Header Field Parameters 14.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.
skipping to change at page 28, line 45 skipping to change at page 30, line 7
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 field parameters to capture the specific method by 1. Added header field parameters to capture the specific method by
which a target is determined to facilitate processing by users of which a target is determined to facilitate processing by users of
the History-info header field entries. A specific header field the History-Info header field entries. A specific header field
parameter is captured for each of the target URIs as the target parameter is captured for each of the target URIs as the target
set is determined (per section 16.5 of [RFC3261]). The header set is determined (per section 16.5 of [RFC3261]). The header
field parameter is used in both the History-Info and the Contact field parameter is used in both the History-Info and the Contact
header fields. 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 field, the entries are certain values of the Privacy header field, the entries 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 header fields inserted by recommendations for other SIP header fields inserted by
intermediaries. 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 field and eliminate the need to make the History-Info header field and eliminate the need to make
assumptions based upon the order of the entries and ensure that the assumptions based upon the order of the entries and ensure that the
most complete set of information is available to the applications. most complete set of information is available to the applications.
In addition, editorial changes were done to both condense and clarify In addition, editorial changes were done to both condense and clarify
the text, moving the requirements to an appendix and removing the the text, moving the requirements to an appendix and removing the
inline references to the requirements. The examples were simplified inline references to the requirements. The examples were simplified
and updated to reflect the protocol changes. Several of the call and updated to reflect the protocol changes. Several of the call
flows in the appendix were removed and put into a separate document flows in the appendix were removed and put into a separate document
that includes additional use cases that require the new header field that includes additional use cases that require the new header field
parameters. parameters.
skipping to change at page 29, line 39 skipping to change at page 30, line 50
will ignore these parameters, however, per [RFC4244] an entity will will ignore these parameters, however, per [RFC4244] an entity will
not remove this parameter from an hi-entry. not remove this parameter from an hi-entry.
As for the behavior of the entity followings have changed since the As for the behavior of the entity followings have changed since the
[RFC4244]. [RFC4244].
UAC behavior UAC behavior
1. Inclusion of option tag by UAC has changed from SHOULD to MUST. 1. Inclusion of option tag by UAC has changed from SHOULD to MUST.
2. Inclusion of hi-target-entry along with hi-index has changed rom 2. Inclusion of hi-target-entry along with hi-index has changed from
MAY/RECOMMEND to MUST/MUST. MAY/RECOMMEND to MUST/MUST.
3. Behavior surrounding the addition of hi-target-entry based on 3xx 3. Behavior surrounding the addition of hi-target-entry based on 3xx
response has changed from MAY/SHOULD to MUST. response has changed from MAY/SHOULD to MUST.
None of the behavior changes would cause any backward compatibility None of the behavior changes would cause any backward compatibility
issues. issues.
UAS behavior UAS behavior
1. Inclusion of hi-entry in response has changed from SHOULD to 1. Inclusion of hi-entry in response has changed from SHOULD to
MUST. MUST.
As the entity receiving response with hi-entry expected it with As the entity receiving response with hi-entry expected it with
SHOULD, this change will not cause any backward compatibility issues. SHOULD, this change will not cause any backward compatibility issues.
Proxy/Redirect Server behavior Proxy/Redirect Server behavior
1. Inclusion of H-I as forwarding the request has changed from 1. Inclusion of H-I as forwarding the request has changed from
SHOULD to MUST. SHOULD to MUST.
skipping to change at page 33, line 4 skipping to change at page 34, line 15
* MUST add hi-entry. [Issue: 28] * MUST add hi-entry. [Issue: 28]
* Clarify applicability to B2BUA. [Issue: 29] * Clarify applicability to B2BUA. [Issue: 29]
* Fixed text for indexing for UAC in case of 3xx. * Fixed text for indexing for UAC in case of 3xx.
9. Changed "hit" URI parameter to header field parameters: [Issues: 9. Changed "hit" URI parameter to header field parameters: [Issues:
4,40] 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
header fields. [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 field. handling of the History-Info header field.
3. Updated the Application considerations section: 3. Updated the Application considerations section:
o Included more detail with regards to how applications can make use o Included more detail with regards to how applications can make use
of the information, in particular based on the new tags. of the information, in particular based on the new tags.
o Removed privacy consideration (2nd bullet) since privacy is now o Removed privacy consideration (2nd bullet) since privacy is now
accomplished by anonymizing rather than removal of entries. accomplished by anonymizing rather than removal of entries.
Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf- Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf-
skipping to change at page 37, line 27 skipping to change at page 38, line 40
[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.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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.
18.2. Informative References 18.2. Informative References
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
skipping to change at page 40, line 42 skipping to change at page 42, 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 out going messages unless it is protected as not be included in out going 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 field for informational purposes only. They are History-Info header field for informational purposes only. They are
not 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. PBX Voicemail call flow B.1. PBX Voicemail call flow
In this example, Alice calls Bob, whose SIP client is forwarded to In this example, Alice calls Bob, whose SIP client is forwarded to
Carol. Carol does not answer the call, thus it is forwarded to a VM Carol. Carol does not answer the call, thus it is forwarded to a VM
(voicemail) server (VMS). In order to determine the appropriate (voicemail) server (VMS). In order to determine the appropriate
mailbox to use for this call, the VMS needs the original target for mailbox to use for this call, the VMS needs the original target for
the request. The original target is determined by finding the first the request. The original target is determined by finding the first
skipping to change at page 41, line 32 skipping to change at page 42, line 46
Alice example.com Bob Carol VM Alice example.com Bob Carol VM
| INVITE F1 | | | | | INVITE F1 | | | |
|------------->| | | | |------------->| | | |
| | INVITE F2 | | | | | INVITE F2 | | |
| |------------->| | | | |------------->| | |
| | | | | | | | | |
| 100 Trying | | | | | 100 Trying | | | |
|<-------------| 302 Moved Temporarily F3 | | |<-------------| 302 Moved Temporarily F3 | |
| |<-------------| | | | |<-------------| | |
| | ACK | | |
| |------------->| | |
| | | | | | | | | |
| | INVITE F4 | | | | | INVITE F4 | | |
| |--------------------------->| | | |--------------------------->| |
| | | | | | | | | |
| | 180 Ringing F5 | | | | 180 Ringing F5 | |
| |<---------------------------| | | |<---------------------------| |
| | | | | | | | | |
| 180 Ringing | | | | | 180 Ringing | | | |
|<-------------| | | | |<-------------| | | |
| | | | | | | | | |
skipping to change at page 42, line 43 skipping to change at page 44, line 12
History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1 History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1
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]
F3 302 Moved Temporarily Bob -> Example.com F3 302 Moved Temporarily Bob -> Example.com
SIP/2.0 302 Moved Temporarily SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se
;received=192.0.2.112
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>;tag=2hi-1nf
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1 History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1
Contact: <sip:carol@example.com> Contact: <sip:carol@example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
[SDP Not Shown] [SDP Not Shown]
F4 INVITE Example.com -> Carol F4 INVITE Example.com -> Carol
INVITE sip:carol@192.0.2.4 SIP/2.0 INVITE sip:carol@192.0.2.4 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK353s
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
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
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\ History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1 History-Info: <sip:carol@example.com>;index=1.2;mp=1
skipping to change at page 43, line 33 skipping to change at page 45, line 4
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1 History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2 History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
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]
F5 180 Ringing Carol -> Example.com F5 180 Ringing Carol -> Example.com
SIP/2.0 180 Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK353s
;received=192.0.2.113
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>;tag=setss3x To: Bob <sip:bob@example.com>;tag=setss3x
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\ History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1 History-Info: <sip:carol@example.com>;index=1.2;mp=1
skipping to change at page 44, line 31 skipping to change at page 46, line 4
target=sip:bob%40example.com;cause=408>;\ target=sip:bob%40example.com;cause=408>;\
index=1.3;mp=1.2 index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.6;\ History-Info: <sip:vm@192.0.2.6;\
target=sip:bob%40example.com;cause=408>;\ target=sip:bob%40example.com;cause=408>;\
index=1.3.1;rc=1.3 index=1.3.1;rc=1.3
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 200 OK VM -> Example.com F7 200 OK VM -> Example.com
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
;received=192.0.2.114
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>;tag=3dweggs To: Bob <sip:bob@example.com>;tag=3dweggs
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\ History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1 History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4?Reason=SIP%3Bcause%3D408>;\ History-Info: <sip:carol@192.0.2.4?Reason=SIP%3Bcause%3D408>;\
index=1.2.1;rc=1.2 index=1.2.1;rc=1.2
History-Info: <sip:vm@example.com;\ History-Info: <sip:vm@example.com;\
target=sip:bob%40example.com;cause=408>;\ target=sip:bob%40example.com;cause=408>;\
index=1.3;mp=1.2 index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.6;\ History-Info: <sip:vm@192.0.2.6;\
target=sip:bob%40example.com;cause=408>;\ target=sip:bob%40example.com;cause=408>;\
index=1.3.1;rc=1.3 index=1.3.1;rc=1.3
Contact: <sip:carol@example.com> Contact: <sip:vm@192.0.2.6>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
[SDP Not Shown] [SDP Not Shown]
B.2. Consumer Voicemail example call flow B.2. Consumer Voicemail example call flow
In this example, Alice calls the Bob but Bob has temporarily In this example, Alice calls the Bob but Bob has temporarily
forwarded his phone to Carol because she is his wife. Carol does not forwarded his phone to Carol because she is his wife. Carol does not
answer the call, thus it is forwarded to a VM (voicemail) server answer the call, thus it is forwarded to a VM (voicemail) server
skipping to change at page 45, line 27 skipping to change at page 47, line 4
call, the VMS needs the appropriate target for the request. The last call, the VMS needs the appropriate target for the request. The last
target is determined by finding the hi-entry referenced by the index target is determined by finding the hi-entry referenced by the index
of last hi-entry tagged with "rc" for determining the appropriate of last hi-entry tagged with "rc" for determining the appropriate
mailbox. This hi-entry is used to populate the "target" URI mailbox. This hi-entry is used to populate the "target" URI
parameter as defined in [RFC4458]. Note that some VMSs may also (or parameter as defined in [RFC4458]. Note that some VMSs may also (or
instead) use the information available in the History-Info headers instead) use the information available in the History-Info headers
for custom handling of the VM in terms of how and why the called for custom handling of the VM in terms of how and why the called
arrived at the VMS. arrived at the VMS.
Alice example.com Bob Carol VM Alice example.com Bob Carol VM
| INVITE F1 | | | | | INVITE F1 | | | |
|------------->| | | | |------------->| | | |
| | INVITE F2 | | | | | INVITE F2 | | |
| |------------->| | | | |------------->| | |
| | | | | | | | | |
| 100 Trying | | | | | 100 Trying | | | |
|<-------------| 302 Moved Temporarily F3 | | |<-------------| 302 Moved Temporarily F3 | |
| |<-------------| | | | |<-------------| | |
| | ACK | | |
| |------------->| | |
| | | | | | | | | |
| | INVITE F4 | | | | | INVITE F5 | | |
| |--------------------------->| | | |--------------------------->| |
| | | | | | | | | |
| | 180 Ringing F5 | | | | 180 Ringing F6 | |
| |<---------------------------| | | |<---------------------------| |
| | | | | | | | | |
| 180 Ringing | | | | | 180 Ringing | | | |
|<-------------| | | | |<-------------| | | |
| | | | | | | | | |
| | (timeout) | | | | (timeout) | |
| | | | | | | | | |
| | INVITE F6 | | | | | INVITE F7 | | |
| |-------------------------------------->| | |-------------------------------------->|
| | | | | | | | | |
| | 200 OK F7 | | | 200 OK F8 |
| |<--------------------------------------| | |<--------------------------------------|
| 200 OK | | | | | 200 OK | | | |
|<-------------| | | | |<-------------| | | |
| | | | | | | | | |
| ACK | | | | | ACK | | | |
|------------->| ACK | |------------->| ACK |
| |-------------------------------------->| | |-------------------------------------->|
F1 INVITE Alice -> Example.com F1 INVITE Alice -> Example.com
skipping to change at page 46, line 50 skipping to change at page 48, line 25
History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1 History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1
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]
F3 302 Moved Temporarily Bob -> Example.com F3 302 Moved Temporarily Bob -> Example.com
SIP/2.0 302 Moved Temporarily SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se
;received=192.0.2.111
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>;tag=2hi1nfo
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1 History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1
Contact: <sip:carol@example.com> Contact: <sip:carol@example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
[SDP Not Shown] [SDP Not Shown]
F4 INVITE Example.com -> Carol F4 INVITE Example.com -> Carol
INVITE sip:carol@192.0.2.4 SIP/2.0 INVITE sip:carol@192.0.2.4 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKseb1
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
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
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\ History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1 History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2 History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
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]
F5 180 Ringing Carol -> Example.com F5 180 Ringing Carol -> Example.com
SIP/2.0 180 Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKseb1
;received=192.0.2.112
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>;tag=setss3x To: Bob <sip:bob@example.com>;tag=setss3x
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\ History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc=1 index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1 History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2 History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
Contact: <sip:carol@example.com> Contact: Carol <sip:carol@192.0.2.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
[SDP Not Shown] [SDP Not Shown]
F6 INVITE Example.com -> VM F6 INVITE Example.com -> VM
INVITE sip:vm0192.0.2.6;target=sip:carol%40example.com INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKb3ss
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
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
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\ History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc index=1.1;rc
History-Info: <sip:carol@example.com?Reason=SIP%3Bcause%3D408>;\ History-Info: <sip:carol@example.com?Reason=SIP%3Bcause%3D408>;\
skipping to change at page 48, line 40 skipping to change at page 50, line 19
index=1.3.1 index=1.3.1
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 200 OK VM -> Example.com F7 200 OK VM -> Example.com
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKb3ss
;received=192.0.2.113
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=kkaz- From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>;tag=3dweggs To: Bob <sip:bob@example.com>;tag=3dweggs
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\ History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
index=1.1;rc index=1.1;rc
History-Info: <sip:carol@example.com?Reason=SIP%3Bcause%3D408>;\ History-Info: <sip:carol@example.com?Reason=SIP%3Bcause%3D408>;\
index=1.2;mp=1 index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2 History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
History-Info: <sip:vm@example.com;target=sip:carol%40example.com>;\ History-Info: <sip:vm@example.com;target=sip:carol%40example.com>;\
index=1.3;mp=1.2 index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5;target=sip:carol%40example.com>;\ History-Info: <sip:vm@192.0.2.5;target=sip:carol%40example.com>;\
index=1.3.1 index=1.3.1
Contact: <sip:carol@example.com> Contact: <sip:vm@192.0.2.6>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
[SDP Not Shown] [SDP Not Shown]
The VMS can look at the last hi-entry and find the target of the The VMS can look at the last hi-entry and find the target of the
mailbox by looking for the "target" URI parameter in the hi-entry. mailbox by looking for the "target" URI parameter in the hi-entry.
B.3. Sequentially Forking (History-Info in Response) B.3. Sequentially Forking (History-Info in Response)
skipping to change at page 51, line 42 skipping to change at page 53, line 25
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4>;index=1.1;rc=1 History-Info: <sip:bob@192.0.2.4>;index=1.1;rc=1
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 -->
F3 100 Trying example.com -> alice F3 100 Trying example.com -> alice
SIP/2.0 100 Trying SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
F4 302 Moved Temporarily Bob -> example.com F4 302 Moved Temporarily Bob -> example.com
SIP/2.0 302 Moved Temporarily SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKrs22
;received=192.0.2.111
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>;tag=hi51nfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
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>;index=1.1;rc=1 History-Info: <sip:bob@192.0.2.4>;index=1.1;rc=1
Contact: <sip:office@example.com>;mp=1 Contact: <sip:office@example.com>;mp=1
Content-Length: 0 Content-Length: 0
F5 ACK example.com -> Bob F5 ACK example.com -> Bob
ACK sip:bob@example.com SIP/2.0 ACK sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKrs22
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com> To: Bob <sip:bob@192.0.2.4>;tag=hi51nfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 ACK CSeq: 1 ACK
Content-Length: 0 Content-Length: 0
F6 INVITE example.com -> office F6 INVITE example.com -> office
INVITE sip:office@192.0.2.5 SIP/2.0 INVITE sip:office@192.0.2.5 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKzeld
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
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%3Bcause%3D302>;\ 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
skipping to change at page 53, line 5 skipping to change at page 55, line 4
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%3Bcause%3D302>;\ 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;rc=1.2 History-Info: <sip:office@192.0.2.5>;index=1.2.1;rc=1.2
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=z9hG4bKx3st Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKzeld
;received=192.0.2.113
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com>;tag=53rdds To: Bob <sip:bob@example.com>;tag=53rdds
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%3Bcause%3D302>;\ 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;rc=1.2 History-Info: <sip:office@192.0.2.5>;index=1.2.1;rc=1.2
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: Office <office@192.0.2.4>
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 192.0.2.3:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com>;tag=53rdds To: Bob <sip:bob@example.com>;tag=53rdds
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%3Bcause%3D302>;\ 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;rc=1.2 History-Info: <sip:office@192.0.2.5>;index=1.2.1;rc=1.2
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: Office <office@192.0.2.4>
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=z9hG4bKx3st Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
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
skipping to change at page 55, line 8 skipping to change at page 57, line 8
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
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=z9hG4bKx3st Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st
;received=192.0.2.114
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com>;tag=53rdds To: Bob <sip:bob@example.com>;tag=53rdds
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%3Bcause%3D302>;\ 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%3Bcause%3D408>;\ History-Info: <sip:office@192.0.2.5?Reason=SIP%3Bcause%3D408>;\
skipping to change at page 55, line 29 skipping to change at page 57, line 30
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;rc=1.3 History-Info: <sip:home@192.0.2.6>;index=1.3.1;rc=1.3
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;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>;tag=53rdds
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%3Bcause%3D302>;\ 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%3Bcause%3D408>;\ History-Info: <sip:office@192.0.2.5?Reason=SIP%3Bcause%3D408>;\
index=1.2.1>;index=1.2.1;rc=1.2 index=1.2.1>;index=1.2.1;rc=1.2
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;rc=1.3 History-Info: <sip:home@192.0.2.6>;index=1.3.1;rc=1.3
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@192.0.2.6 SIP/2.0 ACK sip:home@192.0.2.6 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st
From: Alice <sip:alice@example.com>;tag=sr3dds>; From: Alice <sip:alice@example.com>;tag=sr3dds>;
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>;tag=53rdds
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
CSeq: 1 ACK CSeq: 1 ACK
Content-Length: 0 Content-Length: 0
F14 ACK alice -> example.com F14 ACK alice -> example.com
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;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>;tag=53rdds
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.4. History-Info with Privacy Header Field B.4. 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 the History-Info has indicated that she wants Privacy associated with the History-Info
header field entries. In addition, sip:biloxi.example.com adds header field entries. In addition, sip:biloxi.example.com adds
Privacy header fields indicating that the History-info header field Privacy header fields indicating that the History-Info header field
information is anonymized outside the biloxi.example.com domain. information is anonymized outside the biloxi.example.com domain.
Note, that if the atlanta.example.com proxy had added privacy header Note, that if the atlanta.example.com proxy had added privacy header
fields to all its hi-entries, then all the hi-entries in the response fields to all its hi-entries, then all the hi-entries in the response
would be anonymous. would be anonymous.
Alice atlanta.example.com biloxi.example.com Bob Alice atlanta.example.com biloxi.example.com Bob
| | | | | | | |
| INVITE F1 | | | | INVITE F1 | | |
|--------------->| | | |--------------->| | |
| | | | | | | |
skipping to change at page 58, line 26 skipping to change at page 60, line 26
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 -->
F3 INVITE biloxi.example.com -> Bob F3 INVITE biloxi.example.com -> Bob
INVITE sip:bob@192.0.1.11 SIP/2.0 INVITE sip:bob@192.0.1.11 SIP/2.0
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKtg3s Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKtg3s
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
;received=192.0.2.111
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
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;rc=1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1;rc=1
History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1 History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1
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 -->
F4 200 OK Bob -> biloxi.example.com F4 200 OK Bob -> biloxi.example.com
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKtg3s Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKtg3s
;received=192.0.2.112
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
;received=192.0.2.111
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33 To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
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;rc=1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1;rc=1
History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1 History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1
Contact: Bob <sip:bob@192.0.1.11> Contact: Bob <sip:bob@192.0.1.11>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F5 200 OK biloxi.example.com -> atlanta.example.com F5 200 OK biloxi.example.com -> atlanta.example.com
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
;received=192.0.2.111
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33 To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
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;rc=1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1;rc=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
Contact: Bob <sip:bob@192.0.1.11> Contact: Bob <sip:bob@192.0.1.11>
skipping to change at page 62, line 26 skipping to change at page 64, line 26
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 -->
F3 INVITE biloxi.example.com -> Bob F3 INVITE biloxi.example.com -> Bob
INVITE sip:bob@192.0.1.11 SIP/2.0 INVITE sip:bob@192.0.1.11 SIP/2.0
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKeset Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKeset
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
;received=192.0.2.112
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
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;rc=1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1;rc=1
History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1 History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1
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 -->
F4 200 OK Bob -> biloxi.example.com F4 200 OK Bob -> biloxi.example.com
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKeset Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKeset
;received=192.0.2.111
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
;received=192.0.2.112
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33 To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
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;rc=1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1;rc=1
History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1 History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1
Contact: Bob <sip:bob@192.0.1.11> Contact: Bob <sip:bob@192.0.1.11>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F5 200 OK biloxi.example.com -> atlanta.example.com F5 200 OK biloxi.example.com -> atlanta.example.com
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
;received=192.0.2.112
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33 To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
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;rc=1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1;rc=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
Contact: Bob <sip:bob@192.0.1.11> Contact: Bob <sip:bob@192.0.1.11>
 End of changes. 130 change blocks. 
242 lines changed or deleted 296 lines changed or added

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