draft-ietf-sipcore-rfc4244bis-05.txt   draft-ietf-sipcore-rfc4244bis-06.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: October 29, 2011 S. Schubert Expires: April 3, 2012 S. Schubert
NTT NTT
J. van Elburg J. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
April 27, 2011 Oct 2011
An Extension to the Session Initiation Protocol (SIP) for Request An Extension to the Session Initiation Protocol (SIP) for Request
History Information History Information
draft-ietf-sipcore-rfc4244bis-05.txt draft-ietf-sipcore-rfc4244bis-06.txt
Abstract Abstract
This document defines a standard mechanism for capturing the history This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP) information associated with a Session Initiation Protocol (SIP)
request. This capability enables many enhanced services by providing request. This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific the information as to how and why a SIP request arrives at a specific
application or user. This document defines an optional SIP header application or user. This document defines an optional SIP header
field, History-Info, for capturing the history information in field, History-Info, for capturing the history information in
requests. The document also defines SIP header field parameters for requests. The document also defines SIP header field parameters for
the History-Info and Contact header fields to tag the method by which the History-Info and Contact header fields to tag the method by which
the target of a request is determined. In addition, this document the target of a request is determined. In addition, this
defines a value for the Privacy header field specific to the History- specification defines a value for the Privacy header field specific
Info header field. This document obsoletes RFC 4244. to 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 October 29, 2011. This Internet-Draft will expire on April 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 22 skipping to change at page 3, line 22
5.1. History-Info Header Field Example Scenario . . . . . . . . 10 5.1. History-Info Header Field Example Scenario . . . . . . . . 10
6. User Agent Handling of the History-Info Header Field . . . . . 13 6. User Agent Handling of the History-Info Header Field . . . . . 13
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13
7. Proxy/Intermediary Handling of History-Info Header Fields . . 13 7. Proxy/Intermediary Handling of History-Info Header Fields . . 13
8. Redirect Server Handling of History-Info Header Fields . . . . 14 8. Redirect Server Handling of History-Info Header Fields . . . . 14
9. Handling of History-Info Header Fields in Requests and 9. Handling of History-Info Header Fields in Requests and
Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14
9.2. Sending a Request with History-Info . . . . . . . . . . . 15 9.2. Sending a Request with History-Info . . . . . . . . . . . 15
9.3. Receiving a Response with History-Info or Request 9.3. Receiving a Response with History-Info or Requet
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 15 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.4. Sending History-Info in Responses . . . . . . . . . . . . 16 9.4. Sending History-Info in Responses . . . . . . . . . . . . 16
10. Processing the History-Info Header Field . . . . . . . . . . . 16 10. Processing the History-Info Header Field . . . . . . . . . . . 16
10.1. Privacy in the History-Info Header Field . . . . . . . . . 17 10.1. Privacy in the History-Info Header Field . . . . . . . . . 17
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18
10.2. Reason in the History-info Header Field . . . . . . . . . 19 10.2. Reason in the History-info Header Field . . . . . . . . . 19
10.3. Indexing in the History-Info Header Field . . . . . . . . 19 10.3. Indexing in the History-Info Header Field . . . . . . . . 19
10.4. Indicating the Mechanism by which the Target was 10.4. Mechanism for Target Determination in the History-Info
Determined . . . . . . . . . . . . . . . . . . . . . . . . 21 Header Field . . . . . . . . . . . . . . . . . . . . . . . 21
11. Application Considerations . . . . . . . . . . . . . . . . . . 21 11. Application Considerations . . . . . . . . . . . . . . . . . . 22
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 24
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Registration of New SIP History-Info Header Field . . . . 24 12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 24
13.2. Registration of "history" for SIP Privacy Header Field . . 25 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13.3. Registration of Header Field Parameters . . . . . . . . . 25 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 14.1. Registration of New SIP History-Info Header Field . . . . 26
15. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 26 14.2. Registration of "history" for SIP Privacy Header Field . . 26
15.1. Backwards compatibility . . . . . . . . . . . . . . . . . 28 14.3. Registration of Header Field Parameters . . . . . . . . . 27
16. Changes since last Version . . . . . . . . . . . . . . . . . . 28 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28
17.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 29
17.2. Informative References . . . . . . . . . . . . . . . . . . 35 17. Changes since last Version . . . . . . . . . . . . . . . . . . 30
Appendix A. Request History Requirements . . . . . . . . . . . . 35 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 36 18.1. Normative References . . . . . . . . . . . . . . . . . . . 37
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 37 18.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix B. Example call flows . . . . . . . . . . . . . . . . . 38 Appendix A. Request History Requirements . . . . . . . . . . . . 38
B.1. Sequentially Forking (History-Info in Response) . . . . . 38 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 39
B.2. History-Info with Privacy Header Field . . . . . . . . . . 45 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 40
B.3. Privacy for a Specific History-Info Entry . . . . . . . . 47 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 40
B.1. PBX Voicemail call floww . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 B.2. Consumer Voicemail example call flow . . . . . . . . . . . 45
B.3. Sequentially Forking (History-Info in Response) . . . . . 49
B.4. History-Info with Privacy Header Field . . . . . . . . . . 56
B.5. Privacy for a Specific History-Info Entry . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
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
skipping to change at page 5, line 26 skipping to change at page 5, line 26
standard mechanism within SIP for communicating the retargeting standard mechanism within SIP for communicating the retargeting
history of the requests. This "request history" information allows history of the requests. This "request history" information allows
the receiving application to determine hints about how and why the the receiving application to determine hints about how and why the
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 document 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 document 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 document to refer to the process The term "retarget" is used in this specification to refer to the
of a SIP entity changing a Uniform Resource Identifier (URI) in a process of a SIP entity changing a Uniform Resource Identifier (URI)
request based on the rules for determining request targets as in a request based on the rules for determining request targets as
described in Section 16.5 of [RFC3261] and of the subsequent 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 "terget user" is used in this specification as the human
user associated with particular AoR or AoRs (in case the human user
has multiple alias).
The references to "domain for which the SIP entity/Proxy/Intermediary The references to "domain for which the SIP entity/Proxy/Intermediary
is responsible" are consistent with and intended to convey the same is responsible" are consistent with and intended to convey the same
context as the usage of that terminology in [RFC3261]. The context as the usage of that terminology in [RFC3261]. The
applicability of History-Info to architectures or models outside the applicability of History-Info to architectures or models outside the
context of [RFC3261] is outside the scope of this specification. context of [RFC3261] is outside the scope of this specification.
3. Background 3. Background
SIP implicitly provides retargeting capabilities that enable SIP SIP implicitly provides retargeting capabilities that enable SIP
requests to be routed to specific applications as defined in requests to be routed to specific applications as defined in
skipping to change at page 7, line 6 skipping to change at page 7, line 8
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 home proxy upon receipt [RFC5627], which can be overwritten by a REGISTRAR or a "home
of the initial request. proxy" (a proxy serving as the terminal point for routing an
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].
4. Overview 4. Overview
skipping to change at page 7, line 40 skipping to change at page 7, line 43
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 two new SIP header field parameters, This specification also defines three new SIP header field
"rc" and "mp", for the History-Info and Contact header fields, to tag parameters, "rc", "mp" and "np", for the History-Info and Contact
the method by which the target of a request is determined. Further header fields, to tag the method by which the target of a request is
detail on the use of these header field parameters is provided in determined. Further detail on the use of these header field
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 applies to all the History-info header field
entries in a Request or to a specific History-info header field hi- entries in a Request or to a specific History-info header field hi-
entry as described above. Further detail is provided in entry as described above. Further detail is provided in
Section 10.1. Section 10.1.
5. History-Info Header Field Protocol Structure 5. History-Info Header Field Protocol Structure
The History-info header field can appear in any request not The History-info header field defined in this specification defines
associated with an early or established dialog (e.g., INVITE, the usage in out-of-dialog requests or initial requests for a dialog
REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and
and any non-100 provisional or final responses to these requests SUBSCRIBE, etc.) and any non-100 provisional or final responses to
(ISSUER-req, see Appendix A). these requests (ISSUER-req, see Appendix A).
The following provides details for the information that is captured The following provides details for the information that is captured
in the History-Info header field entry (hi-entry) for each target in the History-Info header field entries for each target used for
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 string of digits, separated by dots to indicate the
number of forward hops and retargets. This results in a tree number of forward hops and retargets. This results in a tree
representation of the history of the request, with the lowest- representation of the history of the request, with the lowest-
skipping to change at page 8, line 37 skipping to change at page 8, line 39
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
hi-entry was determined. This parameter contains either an "rc" History-info header field value (hi-entry) was determined. This
or "mp" header field parameter, which is interpreted as follows: parameter contains either an "rc", "mp" or "np" header field
parameter, which is interpreted as follows:
"rc": The hi-targeted-to-URI is a contact bound to an AOR in an
abstract location service, that AOR being the Request-URI that
was retargeted. The AOR-to-contact binding has been placed
into the location service by a SIP Registrar that received a
SIP REGISTER request. The "rc" header field parameter contains
the value of the hi-index in the hi-entry with an
hi-targeted-to- uri that reflects the Request-URI that was
retargeted
"rc": The hi-targeted-to-URI represents a change in Request-URI
while the target user remains the same. This occurs for
example when user has multiple AoRs as an alias. The "rc"
header field parameter contains the value of the hi-index in
the hi-entry with an hi-targeted-to-uri that reflects the
Request-URI that was retargeted
"mp": The hi-targeted-to-URI represents a user other than the "mp": The hi-targeted-to-URI represents a user other than the
user associated with the Request-URI in the incoming request target user associated with the Request-URI in the incoming
that was retargeted. This occurs when a request is statically request that was retargeted. This occurs when a request is
or dynamically retargeted to another user. The "mp" header statically or dynamically retargeted to another user
field parameter contains the value of the hi-index in the hi- represented by an AoR unassociated with the AoR of the original
target user. The "mp" header field parameter contains the
value which represents the value of the hi-index in the hi-
entry with an hi-targeted-to-uri that reflects the Request-URI entry with an hi-targeted-to-uri that reflects the Request-URI
that was retargeted, thus identifying the "mapped from" target. that was retargeted, thus identifying the "mapped from" target.
"np": The hi-targeted-to-URI represents that there was no
change in Request-URI. This would apply for example when a
proxy merely forwards a request to a next hop proxy and loose
routing is used.
o Extension (hi-extension): A parameter to allow for future optional o Extension (hi-extension): A parameter to allow for future optional
extensions. As per [RFC3261], any implementation not extensions. As per [RFC3261], any implementation not
understanding an extension MUST ignore it. understanding an extension MUST ignore it.
The ABNF syntax for the History-info header field and header field The ABNF syntax for the History-info header field and header field
parameters is as follows: parameters is as follows:
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param) hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = name-addr hi-targeted-to-uri = 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) index-val = 1*DIGIT *("." 1*DIGIT)
hi-index = "index" EQUAL index-val hi-index = "index" EQUAL index-val
hi-target-param = rc-param / mp-param hi-target-param = rc-param / mp-param / 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
hi-extension = generic-param hi-extension = generic-param
The ABNF definitions for "generic-param" and "name-addr" are from The ABNF definitions for "generic-param" and "name-addr" are from
[RFC3261]. [RFC3261].
This document also extends the "contact-params" for the Contact This document also extends the "contact-params" for the Contact
header field as defined in [RFC3261] with the "rc" and "mp" header header field as defined in [RFC3261] with the "rc", "mp" and "np"
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
skipping to change at page 10, line 18 skipping to change at page 10, line 32
History-Info header field values by including the Privacy Header History-Info header field values by including the Privacy Header
[RFC3323] included in the hi- targeted-to-uri or by adding the [RFC3323] included in the hi- targeted-to-uri or by adding the
Privacy header field to the request. The latter case indicates Privacy header field to the request. The latter case indicates
that the History-Info entries for the domain MUST be anonymized that the History-Info entries for the domain MUST be anonymized
prior to forwarding, whereas the use of the Privacy header field prior to forwarding, whereas the use of the Privacy header field
included in the hi-targeted-to-uri means that a specific hi-entry included in the hi-targeted-to-uri means that a specific hi-entry
MUST be anonymized. MUST be anonymized.
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]. In such case that the hi-targeted-to-uri is a Tel-URI [RFC3966].
cases, the Tel-URI SHOULD be transformed into a SIP URI per section
19.1.6 of [RFC3261].
The following provides examples of the format for the History-info The following provides examples of the format for the History-info
header field. Note that the backslash and CRLF between the fields in header field. Note that the backslash and CRLF between the fields in
the examples below are for readability purposes only. the examples below are for readability purposes only.
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar
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\
skipping to change at page 12, line 13 skipping to change at page 12, line 13
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 |
| |--------------->| | | | |--------------->| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | | History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| | | | | | | | | |
| | | INVITE sip:bob@192.0.2.3| | | | INVITE sip:bob@192.0.2.3|
| | |--------------->| | | | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1 | History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | | | | | | |
| | | INVITE sip:bob@192.0.2.7| | | | INVITE sip:bob@192.0.2.7|
| | |-------------------------->| | | |-------------------------->|
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.7>;index=1.1.2;rc=1.1 | History-Info: <sip:bob@192.0.2.7>;index=1.1.2;rc=1.1
| | | 200 | | | | | 200 | |
| | |<---------------| | | | |<---------------| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1 | History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | | | | | | |
| | 200 | | | | | 200 | | |
| |<---------------| | | | |<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1 | History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | | | | | | |
| | | Proxy Cancels INVITE | | | | Proxy Cancels INVITE |
| | |<=========================>| | | |<=========================>|
| | | | | | | | | |
| 200 | | | | | 200 | | | |
|<---------------| | | | |<---------------| | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3;index=1.1.1;rc=1.1 | History-Info: <sip:bob@192.0.2.3;index=1.1.1;rc=1.1
| | | | | | | | | |
| ACK | | | | | ACK | | | |
|--------------->| ACK | | | |--------------->| ACK | | |
| |--------------->| ACK | | | |--------------->| ACK | |
| | |--------------->| | | | |--------------->| |
Figure 1: Basic Call Figure 1: Basic Call
6. User Agent Handling of the History-Info Header Field 6. User Agent Handling of the History-Info Header Field
skipping to change at page 13, line 19 skipping to change at page 13, line 19
alternative to following the behavior of a UAS per Section 6.2 and a alternative to following the behavior of a UAS per Section 6.2 and a
UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries
forward hi-entries received in requests at the UAS to 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 new or out-of-dialog request for which the UAC header field in any out-of-dialog requests or initial requests for a
would like the History-info header field in the response. When dialog for which the UAC would like the History-info header field in
issuing a request, the UAC MUST follow the procedures in Section 9.2. the response. When issuing a request, the UAC MUST follow the
Note that in the case of an initial request, except where the UAC is procedures in Section 9.2. In the case of an initial request, except
part of a B2BUA, there is no cache of hi-entries with which to where the UAC is part of a B2BUA, there is no cache of hi- entries
populate the History-info header field and the hi-index is set to 1 with which to populate the History-info header field and the hi-index
per Section 10.3. When receiving a response the UAC MUST follow the is set to 1 per Section 10.3. When receiving a response the UAC MUST
procedures in Section 9.3. follow the procedures in Section 9.3.
6.2. User Agent Server (UAS) Behavior 6.2. User Agent Server (UAS) Behavior
When receiving a request, a UAS MUST follow the procedures defined in When receiving a request, a UAS MUST follow the procedures defined in
Section 9.2. When sending a response other than a 3xx response, a Section 9.2. When sending a response other than a 3xx response, a
UAS MUST follows the procedures as defined in Section 9.4. When UAS MUST follows the procedures as defined in Section 9.4. When
sending a 3xx response, the UAS MUST follow the procedures defined sending a 3xx response, the UAS MUST follow the procedures defined
for a redirect server per Section 8. An application at the UAS can for a redirect server per Section 8. An application at the UAS can
make use of the cached hi-entries as described in Section 11. make use of the cached hi-entries as described in Section 11.
7. Proxy/Intermediary Handling of History-Info Header Fields 7. Proxy/Intermediary Handling of History-Info Header Fields
This section describes the procedures for proxies and other SIP This section describes the procedures for proxies and other SIP
intermediaries for the handling of the History-Info header fields for intermediaries for the handling of the History-Info header fields for
each of the following scenarios: each of the following scenarios:
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.
Sending a Request: For each outgoing request relating to a target Sending a Request: For each outgoing request relating to a target in
in the target set, the intermediary MUST follow the procedures of the target set, the intermediary MUST follow the procedures of
Section 9.2. Section 9.2.
Receiving a Response or Timeout: An intermediary MUST follow the Receiving a Response ot Timeout: An intermediary MUST follow the
procedures of Section 9.3 when a SIP response is received or a procedures of Section 9.3 when a SIP response is received or a
request times out. request times out.
Sending a Response: An intermediary MUST follow the procedures of Sending a Response: An intermediary MUST follow the procedures of
Section 9.4 for the handling of the hi-entries when sending a SIP Section 9.4 for the handling of the hi-entries when sending a SIP
response. response.
In some cases, an intermediary may retarget a request more than once In some cases, an intermediary may retarget a request more than once
before forwarding - i.e., a request is retargeted to a SIP entity before forwarding - i.e., a request is retargeted to a SIP entity
that is "internal" to the intermediary before the same intermediary that is "internal" to the intermediary before the same intermediary
retargets the request to an external target . A typical example retargets the request to an external target . A typical example
would be a proxy that retargets a request first to a different user would be a proxy that retargets a request first to a different user
(i.e., it maps to a different AOR) and then forwards to a registered (i.e., it maps to a different AOR) and then forwards to a registered
contact bound to the same AOR. In this case, the intermediary MUST contact bound to the same AOR. In this case, the intermediary MUST
add an hi-entry for (each of) the internal target(s) per the add 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.1. Figure 1 provides an example of internal retargeting. Appendix B.3. Figure 1 provides an example of internal retargeting.
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 target header field parameter to each Contact header the appropriate "mp", "np" or "rc" header field parameter to each
field as described in Section 10.4, if applicable. Contact header field as described in Section 10.4, if applicable.
9. Handling of History-Info Header Fields in Requests and Responses 9. Handling of History-Info Header Fields in Requests and Responses
This section describes the procedures for SIP entities for the This section describes the procedures for SIP entities for the
handling of the History-Info header field in SIP requests and handling of the History-Info header field in SIP requests and
responses. responses.
9.1. Receiving a Request 9.1. Receiving a Request
When receiving a request, a SIP entity MUST create a cache containing When receiving a request, a SIP entity MUST create a cache containing
the hi-entries associated with the request. The hi-entries MUST be the hi-entries associated with the request. The hi-entries MUST be
added to the cache in the order in which they were received in the added to the cache in the order in which they were received in the
request. request.
If the Request-URI of the incoming request does not match the hi- If the Request-URI of the incoming request does not match the hi-
targeted-to-uri in the last hi-entry (i.e., the previous SIP entity targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
that sent the request did not include a History-Info header field), that sent the request did not include a History-Info header field),
the SIP entity MUST add an hi-entry to end of the cache, on behalf of the SIP entity MUST add a hi-entry to end of the cache, on behalf of
the previous SIP entity, as follows: the previous SIP entity, as follows:
o The SIP entity MUST set the hi-targeted-to-uri to the value of the The SIP entity MUST set the hi-targeted-to-uri to the value of the
Request-URI in the incoming request. Request-URI in the incoming request. If the Request-URI is a Tel-
URI, it SHOULD be transformed into a SIP URI per section 19.1.6 of
[RFC3261] before being added as a hi-targted-to-uri.
o If privacy is required, the SIP entity MUST follow the procedures If privacy is required, the SIP entity MUST follow the procedures
of Section 10.1. of Section 10.1.
o The SIP entity MUST set the hi-index parameter as described in The SIP entity MUST set the hi-index parameter as described in
Section 10.3. Section 10.3.
o The SIP entity MUST NOT include an "rc" or "mp" 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
new hi-entry to the cache at this time. The new hi-entry is new hi-entry to the cache at this time. The new hi-entry is
populated as follows: populated as follows:
hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value
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 privacy: If privacy is required, the procedures of Section 10.1 MUST
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" or "mp" header field rc/mp: The SIP entity MUST include an "rc", "mp" or "np" header
parameter in the hi-entry, if applicable, per the procedures in field parameter in the hi-entry, if applicable, per the procedures
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 Requet 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
The SIP entity MUST add the hi-entry that was added to the request The SIP entity MUST add the hi-entry that was added to the request
that received the response or timed out to the cache, if it was that received the non-100 response or timed out to the cache, if
not already cached. The hi-entry MUST be added to the cache in it was not already cached. The hi-entry MUST be added to the
ascending order as indicated by the values in the hi-index cache in ascending order as indicated by the values in the hi-
parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2
before 1.2.2 or 1.3). but before 1.2.2 or 1.3).
Step 2: Add Reason header field Step 2: Add Reason header field
The SIP entity adds one or more Reason header fields to the hi- The SIP entity adds one or more Reason header fields to the hi-
targeted-to-uri in the (newly) cached hi-entry per the procedures targeted-to-uri in the (newly) cached hi-entry reflecting the SIP
of Section 10.2, except in the case of a 2xx response. response code in the non-100 response, per the procedures of
Section 10.2.
Step 3: Add additional hi-entries Step 3: Add additional hi-entries
The SIP entity MUST also add to the cache any hi-entries received The SIP entity MUST also add to the cache any hi-entries received
in the response that are not already in the cache. This situation in the response that are not already in the cache. This situation
can occur when the entity that generated the response retargeted can occur when the entity that generated the non-100 response
the request before generating the response. As per Step 1, the retargeted the request before generating the response. As per
hi-entries MUST be added to the cache in ascending order as Step 1, the hi-entries MUST be added to the cache in ascending
indicated by the values in the hi-index parameters of the hi- order as indicated by the values in the hi-index parameters of the
entries hi-entries
It is important to note that the cache does not contain hi-entries It is important to note that the cache does not contain hi-entries
for requests that have not yet received a non-100 response, so there for requests that have not yet received a non-100 response, so there
can be gaps in indices (e.g., 1.2 and 1.4 could but present but not can be gaps in indices (e.g., 1.2 and 1.4 could but present but not
1.3). 1.3).
9.4. Sending History-Info in Responses 9.4. Sending History-Info in Responses
When sending a response other than a 100, a SIP entity MUST include When sending a response other than a 100, a SIP entity MUST include
all the cached hi-entries in the response, subject to the privacy all the cached hi-entries in the response, subject to the privacy
skipping to change at page 19, line 33 skipping to change at page 19, line 33
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 include a Reason header field, containing a SIP
error response code of 408 "Request Timeout". error response code of 408 "Request Timeout".
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 new protocol values for Reason headers are specified in the future If additional Reason header field parameters are defined in the
per [RFC3326], the use of these Reason headers for the History-Info future per [RFC3326], the use of these Reason header field parameters
header field MUST follow the same rules as described above. for the History-Info header field MUST follow the same rules as
described above.
10.3. Indexing in the History-Info Header Field 10.3. Indexing in the History-Info Header Field
In order to maintain ordering and accurately reflect the retargeting In order to maintain ordering and accurately reflect the retargeting
of the request, the SIP entity MUST add an hi-index to each hi-entry. of the request, the SIP entity MUST add 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 digits separated by dots (e.g., 1.1.2). Each dot reflects a SIP
forwarding hop. The digit following each dot reflects the order in forwarding hop. The digit following each dot reflects the order in
which a request was retargeted at the hop. The highest digit at each which a request was retargeted at the hop. The highest digit at each
hop reflects the number of entities to which the request has been hop reflects the number of entities to which the request has been
retargeted at the specific hop (i.e., the number of branches). Thus, retargeted at the specific hop (i.e., the number of branches). Thus,
the indexing results in a logical tree representation for the history the indexing results in a logical tree representation for the history
of the request. of the request.
The first index in a series of History-Info entries MUST be set to 1. The first index in a series of History-Info entries MUST be set to 1.
skipping to change at page 20, line 19 skipping to change at page 20, line 21
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 an 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,
the SIP entity MUST calculate and add the hi-index for each new the SIP entity MUST calculate and add the hi-index for each new
branch by incrementing the rightmost value from the hi-index in branch by incrementing the rightmost value from the hi-index in
the last hi-entry. Per the example above, the hi-index in the the last hi-entry. Per the example above, the hi-index in the
next request forwarded by this same SIP entity would be 1.1.2. next request forwarded by this same SIP entity would be 1.1.2.
4. Retargeting based upon a Response: In the case of retargeting due 4. Retargeting based upon a Response: In the case of retargeting due
to a specific response (e.g., 302), the SIP entity MUST calculate to a specific response (e.g., 302), the SIP entity MUST calculate
the hi-index calculated per rule 3. That is, the rightmost value the hi-index calculated per rule 3. That is, the rightmost value
of the hi-index MUST be incremented (i.e., a new branch is of the hi-index MUST be incremented (i.e., a new branch is
created). For example, if the hi-index in the History-Info created). For example, if the hi-index in the History-Info
header of the sent request is 1.2 and the response to the request header field of the sent request is 1.2 and the response to the
is a 302, then the hi-index in the History-Info header field for request is a 302, then the hi-index in the History-Info header
the new hi-targeted- to-URI would be 1.3. field for the new hi-targeted- to-URI would be 1.3.
5. Forking requests: If the request forwarding is done in multiple 5. Forking requests: If the request forwarding is done in multiple
forks (sequentially or in parallel), the 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.
10.4. Indicating the Mechanism by which the Target was Determined 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
see if it traversed a domain which doesn't exist in History-Info
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-
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
resulting index will be 1.1.2.0.1.
This specification defines two header field parameters, "rc" and 10.4. Mechanism for Target Determination in the History-Info Header
"mp", indicating two mechanisms by which a new target for a request Field
is determined. Both parameters contain an index whose value is the
hi-index of the hi-entry with an hi-targeted-to-uri that represents This specification defines two header field parameters, "rc", "mp"
the Request-URI that was retargeted. and "np", indicating two mechanisms by which a new target for a
request is determined. Both parameters contain an index whose value
is the hi-index of the hi-entry with an hi-targeted-to-uri that
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 parameter field in the Contact latter case, the specific header field parameter in the Contact
header becomes the header field parameter that is used in the hi- header field becomes the header field parameter that is used in the
target-param in the hi-entry when the request is retargeted. If the hi-entry when the request is retargeted. If the Contact header field
Contact header field does not contain an "rc" or "mp" header field does not contain an "rc", "mp" or "np" header field parameter, then
parameter, then the SIP entity MUST NOT include an "rc" or "mp" the SIP entity MUST NOT include an "rc", "mp" or "np" header field
header field parameter in the hi-target-param in the hi-entry when parameter in the hi-target-param in the hi-entry when the request is
the request is retargeted to a contact URI received in a 3xx retargeted to a contact URI received in a 3xx response..
response.
The SIP entity (intermediary or redirect server) determines the The SIP entity (intermediary or redirect server) determines the
specific header field parameter ("rc" or "mp") to be used based on specific header field parameter ("rc", "mp" or "np") to be used based
the criteria defined in Section 5 (hi-target-param) for each of the on the following criteria:
header field parameters.
o "rc": The Request-URI has changed while retaining the target user
associated with the original Request-URI prior to retargeting.
o "mp": The target was determined based on a mapping to a user other
than the target user associated with the Request-URI being
retargeted.
o "np": The target hasn't changed and associated Request-URI
remained the same.
Note that there are two scenarios by which the "mp" header field Note that there are two scenarios by which the "mp" header field
parameter can be derived. parameter can be derived.
o The mapping was done by the receiving entity on its own authority, o The mapping was done by the receiving entity on its own authority,
in which case the mp-value is the parent index of the hi-entry's in which case the mp-value is the parent index of the hi-entry's
index. index.
o The mapping was done due to receiving a 3xx response, in which o The mapping was done due to receiving a 3xx response, in which
case the mp-value is an earlier sibling or descendant of an case the mp-value is an earlier sibling or descendant of an
skipping to change at page 22, line 8 skipping to change at page 22, line 29
11. Application Considerations 11. Application Considerations
History-Info provides a very flexible building block that can be used History-Info provides a very flexible building block that can be used
by intermediaries and UAs for a variety of services. Prior to any by intermediaries and UAs for a variety of services. Prior to any
application usage of the History-Info header field parameters, the application usage of the History-Info header field parameters, the
SIP entity that processes the hi-entries MUST evaluate the hi- SIP entity that processes the hi-entries MUST evaluate the hi-
entries. The SIP entity MUST determine if there are gaps in the entries. The SIP entity MUST determine if there are gaps in the
indices. Gaps are possible if the request is forwarded through indices. Gaps are possible if the request is forwarded through
intermediaries that do not support the History-info header field and intermediaries that do not support the History-info header field and
are reflected by the existence of multiple hi-entries with an index are reflected by the existence of multiple hi-entries with an digit
of "1". Gaps are also possible in the case of parallel forking if of "0" e.g. "1.1.0.1". Gaps are also possible in the case of
there is an outstanding request at the time the SIP entity sends a parallel forking if there is an outstanding request at the time the
response as described in Section 9.4. Thus, if gaps are detected, SIP entity sends a response as described in Section 9.4, in which
the SIP entity MUST NOT treat this as an error, but SHOULD indicate case the gap will not be visible as the branch responsible for the
to any applications that there are gaps. The interpretation of the gap wasn't on the path of the request received. Thus, if gaps are
information in the History-info header field depends upon the detected, the SIP entity MUST NOT treat this as an error, but SHOULD
indicate to any applications that there are gaps. The interpretation
of 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.
2. Hi-entry with the index that matches the value of the "rc" header 2. Hi-entry with the index that matches the value of the "rc" header
field parameter in the last hi-entry with an "rc" header field field parameter in the last hi-entry with a "rc" header field
parameter in the Request received by a UAS - i.e., the last AOR parameter in the Request received by a UAS - i.e., the last AOR
that was retargeted to a contact based on an AOR-to-contact that was retargeted to a contact based on an AOR-to-contact
binding in an abstract location service. binding.
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 an "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 an "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" parameter of the the hi-entry that matches the value of the "rc" header field
first hi-entry with an "rc" parameter in the hi-target-param parameter of the first hi-entry with an "rc" header field
within the domain associated with the target URI at the parameter in the hi-target-param within the domain associated
destination is more likely to be useful. with the target URI at the destination is more likely to be
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.
Some applications may use multiple types of information. For Some applications may use multiple types of information. For
example, an Automatic Call Distribution (ACD)/Call center application example, an Automatic Call Distribution (ACD)/Call center application
that utilizes the hi-entry whose 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 an "rc" header field parameter, to hi-entries prior to entries with hi-target value of "rc" header field
whom the call was targeted prior to its arrival at the current agent. parameter, to whom the call was targeted prior to its arrival at the
This could allow the agent the ability to decide how they might current agent. This could allow the agent the ability to decide how
forward or reroute the call if necessary (avoiding agents that were they might forward or reroute the call if necessary (avoiding agents
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. Security Considerations 12. Application Specific Usage
The security requirements for this document are specified in 12.1. PBX Voicemail
A voicemail system typically requires the original called party
information to determine the appropriate mailbox so an appropriate
greeting can be provided and the appropriate party notified of the
message.
The original target is determined by finding the first hi-entry
tagged with "rc" and using the hi-entry referenced by the index of
"rc" header field parameter as the target for determining the
appropriate mailbox. This hi-entry is used to populate the "target"
URI parameter as defined in [RFC5246] The VMS can look at the last
hi-entry and find the target of the mailbox by looking at the URI
entry in the "target" URI parameter in the hi-entry. For example
call flow please refer to the Appendix B.1.
This example usage does not work properly in the presence of
forwarding that takes place before the call reaches the company in
that case not the first hi-entry with an rc value, but the first hi-
entry with an rc value following an mp entry needs to be picked.
12.2. Consumer Voicemail
The voicemail system in these environment typically requires the last
called party information to determine the appropriate mailbox so an
appropriate greeting can be provided and the appropriate party
notified of the message.
The last target is determined by finding the hi-entry referenced by
the index of last hi-entry tagged with "rc" for determining the
appropriate mailbox. This hi-entry is used to populate the "target"
URI parameter as defined in [RFC5246]. 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. For example call flow please
refer to the Appendix B.2.
13. Security Considerations
The security requirements for this specification are specified in
Appendix A.1. Appendix A.1.
This document defines a header for SIP. The use of the Transport This document defines a header field for SIP. The use of the
Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to
overall confidentiality of the History-Info headers (SEC-req-4) is ensure the overall confidentiality of the History-Info header fields
strongly RECOMMENDED. This results in History-Info having at least (SEC-req-4) is strongly RECOMMENDED. This results in History-Info
the same level of security as other headers in SIP that are inserted having at least the same level of security as other headers in SIP
by intermediaries. With TLS, History-Info headers are no less, nor that are inserted by intermediaries. With TLS, History-Info header
no more, secure than other SIP headers, which generally have even fields are no less, nor no more, secure than other SIP header fields,
more impact on the subsequent processing of SIP sessions than the which generally have even more impact on the subsequent processing of
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
entity requesting privacy wants to ensure privacy is applied to the entity requesting privacy wants to ensure privacy is applied to the
hi-entries, a Privacy Service that supports both [RFC3323] and this hi-entries, a Privacy Service that supports both [RFC3323] and this
specification is REQUIRED in the entity's domain, so that the privacy specification is REQUIRED in the entity's domain, so that the privacy
can be applied, as described in Section 10.1.2, when a request or can be applied, as described in Section 10.1.2, when a request or
response leaves the domain. response leaves the domain.
13. IANA Considerations 14. IANA Considerations
This document requires several IANA registrations detailed in the This document requires several IANA registrations detailed in the
following sections. following sections.
This document obsoletes [RFC4244] but uses the same SIP header field This document obsoletes [RFC4244] but uses the same SIP header field
name and option tag. The IANA registry needs to update the name and option tag. The IANA registry needs to update the
references to [RFC4244] with [RFCXXXX]. references to [RFC4244] with [RFC XXXX].
13.1. Registration of New SIP History-Info Header Field 14.1. Registration of New SIP History-Info Header Field
This document defines a SIP header field name: History-Info and an This document defines a SIP header field name: History-Info and an
option tag: histinfo. The following changes have been made to option tag: histinfo. The following changes have been made to
http:///www.iana.org/assignments/sip-parameters The following row has http:///www.iana.org/assignments/sip-parameters The following row has
been added to the header field section:. been added to the header field section:.
The following row has been added to the header field section: The following row has been added to the header field section:
Header Name Compact Form Reference Header Name Compact Form Reference
----------- ------------ --------- ----------- ------------ ---------
History-Info none [RFCXXXX] History-Info none [RFC XXXX]
The following has been added to the Options Tags section: The following has been added to the Options Tags section:
Name Description Reference Name Description Reference
---- ----------- --------- ---- ----------- ---------
histinfo When used with the Supported header, [RFCXXXX] histinfo When used with the Supported header field, [RFC XXXX]
this option tag indicates the UAC this option tag indicates the UAC
supports the History Information to be supports the History Information to be
captured for requests and returned in captured for requests and returned in
subsequent responses. This tag is not subsequent responses. This tag is not
used in a Proxy-Require or Require used in a Proxy-Require or Require
header field since support of header field since support of
History-Info is optional. History-Info is optional.
Note to RFC Editor: Please replace RFCXXXX with the RFC number of Note to RFC Editor: Please replace RFC XXXX with the RFC number of
this specification. this specification.
13.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 [RFCXXXX] 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.
13.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.
Header Field Parameter Name Predefined Reference Header Field Parameter Name Predefined Reference
Values Values
_____________________________________________________________________ _____________________________________________________________________
History-Info mp No [RFC xxxx] History-Info mp No [RFC xxxx]
History-Info rc No [RFC xxxx] History-Info rc No [RFC xxxx]
History-Info np No [RFC xxxx]
Contact mp No [RFC xxxx] Contact mp No [RFC xxxx]
Contact rc No [RFC xxxx] Contact rc No [RFC xxxx]
Contact np No [RFC xxxx]
Note to RFC Editor: Please replace RFC XXXX with the RFC number of Note to RFC Editor: Please replace RFC XXXX with the RFC number of
this specification. this specification.
14. Acknowledgements 15. Acknowledgements
Jonathan Rosenberg et al produced the document that provided Jonathan Rosenberg et al produced the document that provided
additional use cases precipitating the requirement for the new header additional use cases precipitating the requirement for the new header
parameters to capture the method by which a Request URI is parameters to capture the method by which a Request URI is
determined. The authors would like to acknowledge the constructive determined. The authors would like to acknowledge the constructive
feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel
Kaplan and Dale Worley. John Elwell provided excellent suggestions Kaplan and Dale Worley. John Elwell provided excellent suggestions
in terms of document structure. in terms of document structure.
Mark Watson, Cullen Jennings and Jon Peterson provided significant Mark Watson, Cullen Jennings and Jon Peterson provided significant
skipping to change at page 26, line 31 skipping to change at page 28, line 5
Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony
Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin
Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and
Sebastien Garcin in the development of [RFC4244]. Sebastien Garcin in the development of [RFC4244].
The editor would like to acknowledge the significant input from Rohan The editor would like to acknowledge the significant input from Rohan
Mahy on some of the normative aspects of the ABNF for [RFC4244], Mahy on some of the normative aspects of the ABNF for [RFC4244],
particularly around the need for and format of the index and around particularly around the need for and format of the index and around
the security aspects. the security aspects.
15. Changes from RFC 4244 16. Changes from RFC 4244
This RFC replaces [RFC4244]. This RFC replaces [RFC4244].
Deployment experience with [RFC4244] over the years has shown a Deployment experience with [RFC4244] over the years has shown a
number of issues, warranting an update: number of issues, warranting an update:
o In order to make [RFC4244] work in "real life", one needs to make o In order to make [RFC4244] work in "real life", one needs to make
"assumptions" on how History-Info is used. For example, many "assumptions" on how History-Info is used. For example, many
implementations filter out many entries, and only leave specific implementations filter out many entries, and only leave specific
entries corresponding, for example, to first and last redirection. entries corresponding, for example, to first and last redirection.
skipping to change at page 27, line 36 skipping to change at page 29, line 7
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 headers inserted by intermediaries. recommendations for other SIP header fields inserted by
intermediaries.
The first 2 changes are intended to facilitate application usage of The first 2 changes are intended to facilitate application usage of
the History-info header 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 that includes additional use cases that require the new header field
parameters. parameters.
15.1. Backwards compatibility 16.1. Backwards compatibility
This specification is backwards compatible since [RFC4244] allows for This specification is backwards compatible since [RFC4244] allows for
the addition of new optional parameters. This specification adds an the addition of new optional parameters. This specification adds an
optional SIP header field parameter to the History-Info and Contact optional SIP header field parameter to the History-Info and Contact
headers. Entities that have not implemented this specification MUST header fields. Entities that have not implemented this specification
ignore these parameters, however, per [RFC4244] an entity MUST NOT will ignore these parameters, however, per [RFC4244] an entity will
remove this parameter from an hi-entry. not remove this parameter from an hi-entry.
16. Changes since last Version As for the behavior of the entity followings have changed since the
[RFC4244].
UAC behavior
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
MAY/RECOMMEND to MUST/MUST.
3. Behavior surrounding the adddition of hi-target-entry based on
3xx response has changed from MAY/SHOULD to MUST.
None of the behavior changes would cause any backward compatibility
issues.
UAS behavior
1. Inclusion of hi-entry in response has changed from SHOULD to
MUST.
As the entity receiving response with hi-entry expected it with
SHOULD, this change will not cause any backward compatibility issues.
Proxy/Redirect Server behavior
1. Inclusion of H-I as forwarding the request has changed from
SHOULD to MUST.
2. Association of Reason with time-out/internal reason has changed
from MAY to MUST.
3. Inclusion of hi-index has changed from RECOMMENDED to MUST.
4. Inclusion of hi-entries in response has changed from SHOULD to
MUST.
None of the behavior changes will cause any backward compatibility
issues as entity interacting with the updated code, expects the
values set by the revised behavior anyway.
17. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from 04 to 05: Changes from 04 to 05:
1. Lots of editorial corrections/clarifications per John Elwell's 1. Lots of editorial corrections/clarifications per John Elwell's
comment. comment.
2. Updated Reason header section 10.2 to be consistent (i.e., 2. Updated Reason header section 10.2 to be consistent (i.e.,
skipping to change at page 29, line 7 skipping to change at page 31, line 19
2. Removing the use of "escape" when describing the handling of the 2. Removing the use of "escape" when describing the handling of the
Privacy and Reason header fields. Privacy and Reason header fields.
3. Clarification of TEL URIs in terms of not having a Privacy or 3. Clarification of TEL URIs in terms of not having a Privacy or
Reason header field in the hi-targeted-to-uri. Reason header field in the hi-targeted-to-uri.
Changes from 02 to 03: Changes from 02 to 03:
1. Lots of editorial: 1. Lots of editorial:
2.
A. Reorganized sections similar to the RFC 4244 order - i.e., A. Reorganized sections similar to the RFC 4244 order - i.e.,
introduce header field parameters and syntax first, then introduce header field parameters and syntax first, then
describe how the functional entities use the header. This describe how the functional entities use the header field.
removes redundant (and often inconsistent) text describing This removes redundant (and often inconsistent) text
the parameters. describing the parameters.
B. Expanded use of "header" to "header field" B. Expanded use of "header" to "header field"
C. More precision in terms of "escaping" of the Privacy and C. More precision in terms of "escaping" of the Privacy and
Reason headers in the hi-targeted-to-uri (versus Reason headers in the hi-targeted-to-uri (versus
"adding"/"setting"/etc. them to the hi-entry). "adding"/"setting"/etc. them to the hi-entry).
D. Consistent use of parameter names (i.e., hi-entry versus D. Consistent use of parameter names (i.e., hi-entry versus
entry, hi-target versus target, etc.) entry, hi-target versus target, etc.)
E. Moved item 6 in the Index section to the section on Response E. Moved item 6 in the Index section to the section on Response
handling handling
F. Removed last remaining vestiges of inline references to F. Removed last remaining vestiges of inline references to
requirements. requirements.
2. Clarifications of functionality/applicability including: 3. Clarifications of functionality/applicability including:
4.
A. which messages may contain History-Info A. which messages may contain History-Info
B. removing security text with regards to being able to figure B. removing security text with regards to being able to figure
out if there are missing entries when using TLS (issue #44) out if there are missing entries when using TLS (issue #44)
C. More complete information on the new header field parameters C. More complete information on the new header field parameters
as they relate to the hi-target parameter. as they relate to the hi-target parameter.
D. Changed wording from passive to active for normative D. Changed wording from passive to active for normative
statements in many cases and removed superfluous normative statements in many cases and removed superfluous normative
language. language.
3. Rewrite of the Privacy section to address issues and splitting 5. Rewrite of the Privacy section to address issues and splitting
into the setting of the Privacy header fields and the processing/ into the setting of the Privacy header fields and the processing/
application of the privacy header field priv-values. application of the privacy header field priv-values.
4. Rewrite of the Reason header field section - simplifying the text 6. Rewrite of the Reason header field section - simplifying the text
and adding back the RFC 4244 text with regards to the use of the and adding back the RFC 4244 text with regards to the use of the
Reason header field in cases of internal retargeting. Reason header field in cases of internal retargeting.
Changes from 01 to 02: Changes from 01 to 02:
1. Editorial nits/clarifications. [Issues: 1,6,17,18,21- 1. Editorial nits/clarifications. [Issues: 1,6,17,18,21-
23,25,26,30-33,35-37,39,40] 23,25,26,30-33,35-37,39,40]
2. Removing extraneous 4244 text - e.g., errors in flows, 2. Removing extraneous 4244 text - e.g., errors in flows,
"stronger" security, "session" privacy. [Issues: 3,5,7,11 ] "stronger" security, "session" privacy. [Issues: 3,5,7,11 ]
skipping to change at page 30, line 33 skipping to change at page 32, line 47
language. language.
8. Clarifications for UAC processing: 8. Clarifications for UAC processing:
* 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 parameters: [Issues:4,40] 9. Changed "hit" URI parameter to header field parameters: [Issues:
4,40]
* Added index to all target header parameters. [Issues: 41] * Added index to all target header parameters. [Issues: 41]
* Updated all the relevant sections documenting setting and use * Updated all the relevant sections documenting setting and use
of new header parameters. [Issue: 40] of new header parameters. [Issue: 40]
10. Updated/clarified privacy handling. [Issue: 16] 10. Updated/clarified privacy handling. [Issue: 16]
11. Updated Redirect Server section to allow adding History-info 11. Updated Redirect Server section to allow adding History-info
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]
skipping to change at page 31, line 13 skipping to change at page 33, line 28
Changes from 00 to 01: Changes from 00 to 01:
1. Moved examples (except first) in appendix to a new 1. Moved examples (except first) in appendix to a new
(informational) document. (informational) document.
2. Updated UAS and UAC sections to clarify and expand on the 2. Updated UAS and UAC sections to clarify and expand on the
handling of the History-info header field. handling of the History-info header field.
3. Updated the Application considerations section: 3. Updated the Application considerations section:
4. o Included more detail with regards to how applications can make use
of the information, in particular based on the new tags.
* Included more detail with regards to how applications can make
use of the information, in particular based on the new tags.
* Removed privacy consideration (2nd bullet) since privacy is o Removed privacy consideration (2nd bullet) since privacy is now
now accomplished by anonymizing rather than removal of accomplished by anonymizing rather than removal of entries.
entries.
Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf- Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf-
sipcore-4244bis-00: sipcore-4244bis-00:
1. Added a new SIP/SIPS URI parameter to tag the URIs as they are 1. Added a new SIP/SIPS URI parameter to tag the URIs as they are
added to the target list and those returned in the contact header added to the target list and those returned in the contact header
in a 3xx response. in a 3xx response.
2. Updated description of "target" parameter to use the new URI 2. Updated description of "target" parameter to use the new URI
parameter value in setting the value for the parameter. parameter value in setting the value for the parameter.
skipping to change at page 32, line 25 skipping to change at page 34, line 40
3. Added section on backwards compatibility, as well as added the 3. Added section on backwards compatibility, as well as added the
recognition and handling of requests that do not support this recognition and handling of requests that do not support this
specification in the appropriate sections. specification in the appropriate sections.
4. Updated redirect server/3xx handling to support the new 4. Updated redirect server/3xx handling to support the new
parameters - i.e., the redirecting entity must add the new hi- parameters - i.e., the redirecting entity must add the new hi-
entry since the proxy does not have access to the information as entry since the proxy does not have access to the information as
to how the Contact was determined. to how the Contact was determined.
5. Added section on normative differences between this document and 5. Added section on normative differences between this specification
RFC 4244. and RFC 4244.
6. Restructuring of document to be more in line with current IETF 6. Restructuring of document to be more in line with current IETF
practices. practices.
7. Moved Requirements section into an Appendix. 7. Moved Requirements section into an Appendix.
8. Fixed ABNF to remove unintended ordering requirement on hi-index 8. Fixed ABNF to remove unintended ordering requirement on hi-index
that was introduced in attempting to illustrate it was a that was introduced in attempting to illustrate it was a
mandatory parameter. mandatory parameter.
skipping to change at page 34, line 43 skipping to change at page 37, line 8
4. Added hi-target parameter values to HI header to ABNF and 4. Added hi-target parameter values to HI header to ABNF and
protocol description, as well as defining proxy, UAC and UAS protocol description, as well as defining proxy, UAC and UAS
behavior for the parameter. behavior for the parameter.
5. Simplified example call flow in section 4.5. Moved previous call 5. Simplified example call flow in section 4.5. Moved previous call
flow to appendix. flow to appendix.
6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new 6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new
parameter. parameter.
17. References 18. References
17.1. Normative References 18.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
skipping to change at page 35, line 22 skipping to change at page 37, line 34
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC4244] Barnes, M., "An Extension to the Session Initiation [RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244, Protocol (SIP) for Request History Information", RFC 4244,
November 2005. November 2005.
17.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
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009. Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
using SIP Request-URI", RFC 3087, April 2001. using SIP Request-URI", RFC 3087, April 2001.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005. Media Services with SIP", RFC 4240, December 2005.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
Appendix A. Request History Requirements Appendix A. Request History Requirements
The following list constitutes a set of requirements for a "Request The following list constitutes a set of requirements for a "Request
History" capability. History" capability.
1. CAPABILITY-req: The "Request History" capability provides a 1. CAPABILITY-req: The "Request History" capability provides a
capability to inform proxies and UAs involved in processing a capability to inform proxies and UAs involved in processing a
request about the history/progress of that request. Although request about the history/progress of that request. Although
this is inherently provided when the retarget is in response to a this is inherently provided when the retarget is in response to a
SIP redirect, it is deemed useful for non-redirect retargeting SIP redirect, it is deemed useful for non-redirect retargeting
scenarios, as well. scenarios, as well.
2. GENERATION-req: "Request History" information is generated when 2. GENERATION-req: "Request History" information is generated when
the request is retargeted. the request is retargeted.
A. In some scenarios, it might be possible for more than one A. In some scenarios, it might be possible for more than one
instance of retargeting to occur within the same Proxy. A instance of retargeting to occur within the same proxy. A
proxy MUST also generate Request History information for the proxy MUST also generate Request History information for the
'internal retargeting'. 'internal retargeting'.
B. An entity (UA or proxy) retargeting in response to a redirect B. An entity (UA or proxy) retargeting in response to a redirect
or REFER MUST include any Request History information from or REFER MUST include any Request History information from
the redirect/REFER in the new request. the redirect/REFER in the new request.
3. ISSUER-req: "Request History" information can be generated by a 3. ISSUER-req: "Request History" information can be generated by a
UA or proxy. It can be passed in both requests and responses. UA or proxy. It can be passed in both requests and responses.
skipping to change at page 38, line 22 skipping to change at page 40, line 46
not be included in ougoing messages unless it is protected as not be included in ougoing messages unless it is protected as
described in [RFC3323]. described in [RFC3323].
Appendix B. Example call flows Appendix B. Example call flows
The scenarios in this section provide sample use cases for the The scenarios in this section provide sample use cases for the
History-info header 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. Sequentially Forking (History-Info in Response) B.1. PBX Voicemail call floww
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
(voicemail) server (VMS). In order to determine the appropriate
mailbox to use for this call, the VMS needs the original target for
the request. The original target is determined by finding the first
hi-entry tagged with "rc" and using the hi-entry referenced by the
index of "rc" header field parameter as the target for determining
the appropriate mailbox. This hi-entry is used to populate the
"target" URI parameter as defined in [RFC4458]. The reason
associated with the first hi-entry tagged with "rc" (i.e., 302) could
be used to provide a customized voicemail greeting and is used to
populate the "cause" URI parameter as defined in [RFC4458]. Note
that some VMSs may also (or instead) use the information available in
the History-Info headers for custom handling of the VM in terms of
how and why the call arrived at the VMS.
Furthermore it is the proxy forwarding the call to VMS that
determines the target of the voicemail, it is the proxy that sets the
target of voicemail which is also the entity that utilizes RFC4244bis
to find the target which is usually based on local policy installed
by the user or an administrator.
Alice example.com Bob Carol VM
| INVITE F1 | | | |
|------------->| | | |
| | INVITE F2 | | |
| |------------->| | |
| | | | |
| 100 Trying | | | |
|<-------------| 302 Moved Temporarily F3 | |
| |<-------------| | |
| | | | |
| | INVITE F4 | | |
| |--------------------------->| |
| | | | |
| | 180 Ringing F5 | |
| |<---------------------------| |
| | | | |
| 180 Ringing | | | |
|<-------------| | | |
| | | | |
| | (timeout) | |
| | | | |
| | INVITE F6 | | |
| |-------------------------------------->|
| | | | |
| | 200 OK F7 |
| |<--------------------------------------|
| 200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |-------------------------------------->|
F1 INVITE Alice -> Example.com
INVITE sip:bob@example.com
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Contact: Alice <sip:alice@192.0.2.3>
Content-Length: <appropriate value>
[SDP Not Shown]
F2 INVITE Example.com -> Bob
INVITE sip:bob@192.0.2.5 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F3 302 Moved Temporarily Bob -> Example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5>; index=1.1;rc=1
Contact: <sip:carol@example.com>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F4 INVITE Example.com -> Carol
INVITE sip:carol@192.0.2.4 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=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
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F5 180 Ringing Carol -> Example.com
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>;tag=setss3x
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=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
Contact: <sip:carol@example.com>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F6 INVITE Example.com -> VM
INVITE sip:vm0192.0.2.6;target=sip:bob@example.com;cause=408
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4?Reason%3BSIP%3Dcause%3B408>;\
index=1.2.1;rc=1.2
History-Info: <sip:vm@example.com;\
target=sip:bob@example.com;cause=408>\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.6;\
target=sip:bob@example.com;cause=408>\
index=1.3.1;rc=1.3
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F7 200 OK VM -> Example.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>;tag=3dweggs
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4?Reason%3BSIP%3Dcause%3B408>;\
index=1.2.1;rc=1.2
History-Info: <sip:vm@example.com;\
target=sip:bob@example.com;cause=408>\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.6;\
target=sip:bob@example.com;cause=408>\
index=1.3.1;rc=1.3
Contact: <sip:carol@example.com>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
B.2. Consumer Voicemail example call flow
In this example, Alice calls the Bob but Bob has temporarily
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
(VMS). In order to determine the appropriate mailbox to use for this
call, the VMS needs the appropriate target for the request. The last
target is determined by finding the hi-entry referenced by the index
of last hi-entry tagged with "rc" for determining the appropriate
mailbox. This hi-entry is used to populate the "target" URI
parameter as defined in [RFC4458]. Note that some VMSs may also (or
instead) use the information available in the History-Info headers
for custom handling of the VM in terms of how and why the called
arrived at the VMS.
Alice example.com Bob Carol VM
| INVITE F1 | | | |
|------------->| | | |
| | INVITE F2 | | |
| |------------->| | |
| | | | |
| 100 Trying | | | |
|<-------------| 302 Moved Temporarily F3 | |
| |<-------------| | |
| | | | |
| | INVITE F4 | | |
| |--------------------------->| |
| | | | |
| | 180 Ringing F5 | |
| |<---------------------------| |
| | | | |
| 180 Ringing | | | |
|<-------------| | | |
| | | | |
| | (timeout) | |
| | | | |
| | INVITE F6 | | |
| |-------------------------------------->|
| | | | |
| | 200 OK F7 |
| |<--------------------------------------|
| 200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |-------------------------------------->|
F1 INVITE Alice -> Example.com
INVITE sip:bob@example.com
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Contact: Alice <sip:alice@192.0.2.3>
Content-Length: <appropriate value>
[SDP Not Shown]
F2 INVITE Example.com -> Bob
INVITE sip:bob@192.0.2.5 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5>;index=1.1;rc=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F3 302 Moved Temporarily Bob -> Example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5>; index=1.1;rc=1
Contact: <sip:carol@example.com>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F4 INVITE Example.com -> Carol
INVITE sip:carol@192.0.2.4 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=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
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F5 180 Ringing Carol -> Example.com
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>;tag=setss3x
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=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
Contact: <sip:carol@example.com>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F6 INVITE Example.com -> VM
INVITE sip:vm0192.0.2.6;target=sip:carol@example.com
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc
History-Info: <sip:carol@example.com?Reason%3BSIP%3Dcause%3B408>;\
index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
History-Info: <sip:vm@example.com;target=sip:carol@example.com>;\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5;\target=sip:carol@example.com>;\
index=1.3.1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
F7 200 OK VM -> Example.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: Bob <sip:bob@example.com>;tag=3dweggs
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.5?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc
History-Info: <sip:carol@example.com?Reason%3BSIP%3Dcause%3B408>;\
index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
History-Info: <sip:vm@example.com;target=sip:carol@example.com>;\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5;\target=sip:carol@example.com>;\
index=1.3.1
Contact: <sip:carol@example.com>
Content-Type: application/sdp
Content-Length: <appropriate vlue>
[SDP Not Shown]
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.
B.3. Sequentially Forking (History-Info in Response)
This scenario highlights an example where the History-Info in the This scenario highlights an example where the History-Info in the
response is useful to an application or user that originated the response is useful to an application or user that originated the
request. request.
Alice sends a call to Bob via sip:example.com. The proxy sip: Alice sends a call to Bob via sip:example.com. The proxy sip:
example.com sequentially tries Bob on a SIP UA that has bound a example.com sequentially tries Bob on a SIP UA that has bound a
contact with the sip:bob@example.com AOR, and then several alternate contact with the sip:bob@example.com AOR, and then several alternate
addresses (Office and Home) unsuccessfully before sending a response addresses (Office and Home) unsuccessfully before sending a response
to Alice. The hi-entry containing the initial contact is the hi- to Alice. The hi-entry containing the initial contact is the hi-
entry just prior to the first hi-entry tagged with an "rc" header entry just prior to the first hi-entry tagged with an "rc" header
field parameter. In this example, the Office and Home are not the field parameter. In this example, the Office and Home are not the
same AOR as sip:bob@example.com, but rather different AORs that have same AOR as sip:bob@example.com, but rather different AORs that have
been configured as alternate addresses for Bob in the proxy. In been configured as alternate addresses for Bob in the proxy. In
other words, Office and Bob are not bound through SIP Registration other words, Office and Bob are not bound through SIP Registration
with Bob's AOR. This type of arrangement is common for example when with Bob's AOR. This type of arrangement is common for example when
a "routing" rule to a PSTN number is manually configured in a Proxy. a "routing" rule to a PSTN number is manually configured in a proxy.
These hi-entries are identified by the index contained in the hi- These hi-entries are identified by the index contained in the hi-
target-param "mp" header field parameter in the hi-entries. target-param "mp" header field parameter in the hi-entries.
This scenario illustrates that by providing the History-Info to This scenario illustrates that by providing the History-Info to
Alice, the end-user or an application at Alice could make a decision Alice, the end-user or an application at Alice could make a decision
on how best to attempt finding Bob without sending multiple requests on how best to attempt finding Bob without sending multiple requests
to the same destination. Upon receipt of the response containing the to the same destination. Upon receipt of the response containing the
History-Info entries, the Request URIs for the History-Info entries History-Info entries, the Request URIs for the History-Info entries
tagged with "mp" header field parameter are extracted. Those tagged with "mp" header field parameter are extracted. Those
Request-URIs can be compared to other URIs (if any) that might be Request-URIs can be compared to other URIs (if any) that might be
skipping to change at page 40, line 8 skipping to change at page 51, line 8
| |<-----------------------------------| | |<-----------------------------------|
| 486 Busy Here F12 | | 486 Busy Here F12 |
|<-----------| ACK F13 | |<-----------| ACK F13 |
| |----------------------------------->| | |----------------------------------->|
| ACK F14 | | | ACK F14 | |
|----------->| | |----------->| |
Message Details Message Details
F1 INVITE alice -> example.com F1 INVITE alice -> example.com
INVITE sip:alice@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
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
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>
skipping to change at page 41, line 21 skipping to change at page 52, line 21
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 192.0.2.4 -> Bob F5 ACK 192.0.2.4 -> Bob
ACK sip:home@example.com SIP/2.0 ACK sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060 Via: SIP/2.0/TCP proxy.example.com:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
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.3.com SIP/2.0 INVITE sip:office@192.0.2.5 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP%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 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=2 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com>;tag=5 To: Bob <sip:bob@example.com>;tag=5
Supported: histinfo Supported: histinfo
Call-ID: 12345600@example.com Call-ID: 12345600@example.com
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP%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 History-Info: <sip:office@192.0.2.5>;index=1.2.1;rc=1.2
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
F8 180 Ringing example.com -> alice F8 180 Ringing example.com -> alice
SIP/2.0 180 Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/TCP example.com:5060 Via: SIP/2.0/TCP example.com:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP%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 History-Info: <sip:office@192.0.2.5>;index=1.2.1;rc=1.2
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
F9 INVITE example.com -> home F9 INVITE example.com -> home
INVITE sip:home@192.0.2.6 SIP/2.0 INVITE sip:home@192.0.2.6 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP%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 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 History-Info: <sip:home@192.0.2.6>;index=1.3.1;rc=1.3
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: Alice <sip:alice@192.0.2.3> Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F10 100 Trying home -> example.com F10 100 Trying home -> example.com
SIP/2.0 100 Trying SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3
skipping to change at page 44, line 18 skipping to change at page 55, line 18
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP%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 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 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 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
History-Info: <sip:bob@example.com>;index=1 History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.4?Reason=SIP%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 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 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@example.com SIP/2.0 ACK sip:home@192.0.2.6 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060 Via: SIP/2.0/TCP proxy.example.com:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
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 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Route: <sip:proxy.example.com;lr> Route: <sip:proxy.example.com;lr>
CSeq: 1 ACK CSeq: 1 ACK
Content-Length: 0 Content-Length: 0
B.2. History-Info with Privacy Header 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 sip:bob@biloxi.example.com;p=x | | INVITE F1 | | |
|--------------->| | | |--------------->| | |
| Supported: histinfo | | | | | |
| Privacy: History | | | | INVITE F2 | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | |--------------->| |
| | | | | | | |
| | INVITE sip:bob@biloxi.example.com;p=x | | | INVITE F3 |
| |--------------->| | | | |--------------->|
| History-Info: <sip:anonymous@anonymous.invalid>;index=1 | | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | | | 200 F4 |
| | | | | | |<---------------|
| | | INVITE sip:bob@192.0.2.3 | | | |
| | |--------------->| | | 200 F5 | |
| History-Info: <sip:anonymous@anonymous.invalid>;index=1 | |<---------------| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | | | |
| History-Info: <sip:bob@192.0.2.3?Privacy=history>;index=1.1.1;rc=1.1 | 200 F6 | | |
| | | | |<---------------| | |
| | | 200 | | | | |
| | |<---------------| | ACK | | |
| History-Info: <sip:anonymous@anonymous.invalid>;index=1 |--------------->| ACK | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | |--------------->| ACK |
| History-Info: <sip:bob@192.0.2.3?Privacy=history>;index=1.1.1;rc=1.1 | | |--------------->|
| | | |
| | 200 | |
| |<---------------| |
| History-Info: <sip:anonymous@anonymous.invalid>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc=1.1
| | | |
| 200 | | |
|<---------------| | |
| History-Info: <sip:anonymous@anonymous.invalid>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc=1.1
| | | |
| ACK | | |
|--------------->| ACK | |
| |--------------->| ACK |
| | |--------------->|
Figure 2: Example with Privacy Header Fields Figure 2: Example with Privacy Header Fields
B.3. Privacy for a Specific History-Info Entry Message Details
This example provides a basic call scenario similar to Appendix B.2, F1 INVITE alice -> atlanta.example.com
INVITE sip:bob@biloxi.example.com;p=x SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo
Privacy: History
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F2 INVITE atlanta.example.com -> biloxi.example.com
INVITE sip:bob@biloxi.example.com;p=x SIP/2.0
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:anonymous@anonymous.invalid>;index=1
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1;rc=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F3 INVITE biloxi.example.com -> Bob
INVITE sip:bob@192.0.1.11 SIP/2.0
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=5
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
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@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F4 200 OK Bob -> biloxi.example.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=5
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
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@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1
Contact: Bob <sip:bob@192.0.1.11>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F5 200 OK biloxi.example.com -> atlanta.example.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
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:anonymous@anonymous.invalid>>;index=1.1.1;rc=1.1
Contact: Bob <sip:bob@192.0.1.11>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F6 200 OK atlanta.example.com -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
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:anonymous@anonymous.invalid>>;index=1.1.1;rc=1.1
Contact: Bob <sip:bob@192.0.1.11>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
B.5. Privacy for a Specific History-Info Entry
This example provides a basic call scenario similar to Appendix B.4,
however, due to local policy at sip:biloxi.example.com, only the however, due to local policy at sip:biloxi.example.com, only the
final hi-entry in the History-Info, which is Bob's local URI, final hi-entry in the History-Info, which is Bob's local URI,
contains a privacy header field with a priv-value of "history", thus contains a privacy header field with a priv-value of "history", thus
providing Alice with some information about the history of the providing Alice with some information about the history of the
request, but anonymizing Bob's local URI. request, but anonymizing Bob's local URI.
Alice atlanta.example.com biloxi.example.com Bob Alice atlanta.example.com biloxi.example.com Bob
| | | | | | | |
| INVITE sip:bob@biloxi.example.com;p=x | | INVITE F1 | | |
|--------------->| | | |--------------->| | |
| Supported: histinfo | | | | | |
| | | | | | INVITE F2 | |
| | INVITE sip:bob@biloxi.example.com;p=x | |--------------->| |
| |--------------->| | | | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | | | INVITE F3 |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | | |--------------->|
| | | | | | | |
| | | INVITE sip:bob@192.0.2.3 | | | 200 F4 |
| | |--------------->| | | |<---------------|
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | | 200 F5 | |
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1 | |<---------------| |
| | | | | | | |
| | | 200 | | 200 F6 | | |
| | |<---------------| |<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | ACK | | |
| History-Info: <sip:bob@192.0.2.3?Privacy=history>;index=1.1.1;rc=1.1 |--------------->| ACK | |
| | | | | |--------------->| ACK |
| | 200 | | | | |--------------->|
| |<---------------| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc=1.1
| | | |
| 200 | | |
|<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:anonymous@anynymous.invalid>;index=1.1.1;rc=1.1
| | | |
| ACK | | |
|--------------->| ACK | |
| |--------------->| ACK |
| | |--------------->|
Figure 3: Example with Privacy Header Field for Specific URI Figure 3: Example with Privacy Header Field for Specific URI
Message Details
F1 INVITE alice -> atlanta.example.com
INVITE sip:bob@biloxi.example.com;p=x SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F2 INVITE atlanta.example.com -> biloxi.example.com
INVITE sip:bob@biloxi.example.com;p=x SIP/2.0
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
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.1;rc=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F3 INVITE biloxi.example.com -> Bob
INVITE sip:bob@192.0.1.11 SIP/2.0
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=5
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
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.1;rc=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>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F4 200 OK Bob -> biloxi.example.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=5
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
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.1;rc=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>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F5 200 OK biloxi.example.com -> atlanta.example.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
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.1;rc=1
History-Info: <sip:anonymous@anonymous.invalid>>;index=1.1.1;rc=1.1
Contact: Bob <sip:bob@192.0.1.11>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F6 200 OK atlanta.example.com -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
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.1;rc=1
History-Info: <sip:anonymous@anonymous.invalid>>;index=1.1.1;rc=1.1
Contact: Bob <sip:bob@192.0.1.11>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Polycom Polycom
TX TX
US US
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
Francois Audet Francois Audet
Skype Skype
Email: francois.audet@skype.net Email: francois.audet@skype.net
Shida Schubert Shida Schubert
NTT NTT
Email: shida@agnada.com Email: shida@ntt-at.com
Hans Erik van Elburg Hans Erik van Elburg
Detecon International Gmbh Detecon International Gmbh
Oberkasseler str. 2 Oberkasseler str. 2
Bonn, Bonn,
Germany Germany
Email: ietf.hanserik@gmail.com Email: ietf.hanserik@gmail.com
Christer Holmberg Christer Holmberg
Ericsson Ericsson
 End of changes. 128 change blocks. 
321 lines changed or deleted 1026 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/