summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4244.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4244.txt')
-rw-r--r--doc/rfc/rfc4244.txt2467
1 files changed, 2467 insertions, 0 deletions
diff --git a/doc/rfc/rfc4244.txt b/doc/rfc/rfc4244.txt
new file mode 100644
index 0000000..ba5d242
--- /dev/null
+++ b/doc/rfc/rfc4244.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group M. Barnes, Ed.
+Request for Comments: 4244 Nortel
+Category: Standards Track November 2005
+
+
+ An Extension to the Session Initiation Protocol (SIP)
+ for Request History Information
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document defines a standard mechanism for capturing the history
+ information associated with a Session Initiation Protocol (SIP)
+ request. This capability enables many enhanced services by providing
+ the information as to how and why a call arrives at a specific
+ application or user. This document defines a new optional SIP
+ header, History-Info, for capturing the history information in
+ requests.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Overview ...................................................2
+ 1.2. Conventions Used in This Document ..........................3
+ 1.3. Background: Why define a Generic "Request History"
+ capability? ................................................3
+ 2. "Request History" Requirements ..................................4
+ 2.1. Security Requirements ......................................6
+ 2.2. Privacy Requirements .......................................7
+ 3. Request History Information Description .........................7
+ 3.1. Optionality of History-Info ................................8
+ 3.2. Securing History-Info ......................................8
+ 3.3. Ensuring the Privacy of History-Info .......................9
+ 4. Request History Information Protocol Details ....................9
+ 4.1. Protocol Structure of History-Info ........................10
+ 4.2. Protocol Examples .........................................11
+ 4.3. Protocol Usage ............................................12
+
+
+
+Barnes Standards Track [Page 1]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ 4.3.1. User Agent Client (UAC) Behavior ...................12
+ 4.3.2. User Agent Server (UAS) Behavior ...................13
+ 4.3.3. Proxy Behavior .....................................13
+ 4.3.4. Redirect Server Behavior ...........................18
+ 4.4. Security for History-Info .................................18
+ 4.5. Example Applications Using History-Info ...................19
+ 4.5.1. Example with Privacy Header for Entire
+ Request at Proxy2 ..................................21
+ 4.5.2. Example with Privacy Header for Specific
+ URI (UA4) at Proxy2 ................................22
+ 5. Application Considerations .....................................24
+ 6. Security Considerations ........................................25
+ 7. IANA Considerations ............................................25
+ 7.1. Registration of New SIP History-Info Header ...............25
+ 7.2. Registration of "history" for SIP Privacy Header ..........26
+ 8. Normative References ...........................................26
+ 9. Informative References .........................................26
+ 10. Acknowledgements ..............................................26
+ 11. Contributors' Addresses .......................................27
+ Appendix. Example Scenarios........................................28
+ Appendix A. Sequentially forking (History-Info in Response).....28
+ Appendix B. Voicemail...........................................34
+ Appendix C. Automatic Call Distribution Example.................39
+ Appendix D. Session via Redirect and Proxy Servers..............41
+
+1. Introduction
+
+1.1. Overview
+
+ Many services that SIP is anticipated to support require the ability
+ to determine why and how the call arrived at a specific application.
+ Examples of such services include (but are not limited to) sessions
+ initiated to call centers via "click to talk" SIP Uniform Resource
+ Locators (URLs) on a web page, "call history/logging" style services
+ within intelligent "call management" software for SIP User Agents
+ (UAs), and calls to voicemail servers. Although SIP implicitly
+ provides the redirect/retarget capabilities that enable calls to be
+ routed to chosen applications, there is currently no standard
+ mechanism within SIP for communicating the history of such a request.
+ This "request history" information allows the receiving application
+ to determine hints about how and why the call arrived at the
+ application/user.
+
+ This document defines a new SIP header, History-Info, to provide a
+ standard mechanism for capturing the request history information to
+ enable a wide variety of services for networks and end-users. The
+ History-Info header provides a building block for development of new
+ services.
+
+
+
+Barnes Standards Track [Page 2]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ Section 1.3 provides additional background motivation for the Request
+ History capability. Section 2 identifies the requirements for a
+ solution, with Section 3 providing an overall description of the
+ solution.
+
+ Section 4 provides the details of the additions to the SIP protocol.
+ Example uses of the new header are included in Section 4.5, with
+ additional scenarios included in the Appendix.
+
+ Section 5 summarizes the application considerations identified in the
+ previous sections. Section 6 summarizes the security solution.
+
+1.2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.3. Background: Why define a Generic "Request History" capability?
+
+ SIP implicitly provides redirect/retarget capabilities that enable
+ calls to be routed to specific applications as defined in [RFC3261].
+ The term 'retarget' will be used henceforth in this document to refer
+ to the process of a Proxy Server/User Agent Client (UAC) changing a
+ Uniform Resource Identifier (URI) in a request and thus changing the
+ target of the request. This term is chosen to avoid associating this
+ request history only with the specific SIP Redirect Server capability
+ that provides for a response to be sent back to a UAC requesting that
+ the UAC should retarget the original request to an alternate URI.
+ The rules for determining request targets as described in Section
+ 16.5 of [RFC3261] are consistent with the use of the retarget term in
+ this document.
+
+ The motivation for the request history is that in the process of
+ retargeting, old routing information can be forever lost. This lost
+ information may be important history that allows elements to which
+ the call is retargeted to process the call in a locally defined,
+ application-specific manner. The proposal in this document is to
+ provide a mechanism for transporting the request history. It is not
+ proposing any application-specific behavior for a Proxy or UA upon
+ receipt of the information. Indeed, such behavior should be a local
+ decision for the recipient application.
+
+ Current network applications provide the ability for elements
+ involved with the call to exchange additional information relating to
+ how and why the call was routed to a particular destination. The
+ following are examples of such applications:
+
+
+
+
+Barnes Standards Track [Page 3]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ 1. Web "referral" applications, whereby an application residing
+ within a web server determines that a visitor to a website has
+ arrived at the site via an "associate" site that will receive some
+ "referral" commission for generating this traffic
+
+ 2. Email forwarding whereby the forwarded-to user obtains a "history"
+ of who sent the email to whom and at what time
+
+ 3. Traditional telephony services such as voicemail, call-center
+ "automatic call distribution", and "follow-me" style services
+
+ Several of the aforementioned applications currently define
+ application-specific mechanisms through which it is possible to
+ obtain the necessary history information.
+
+ In addition, request history information could be used to enhance
+ basic SIP functionality by providing the following:
+
+ o Some diagnostic information for debugging SIP requests. (Note that
+ the diagnostic utility of this mechanism is limited by the fact
+ that its use by entities that retarget is optional.)
+
+ o A stronger security solution for SIP. A side effect is that each
+ proxy that captures the "request history" information in a secure
+ manner provides an additional means (without requiring signed keys)
+ for the original requestor to be assured that the request was
+ properly retargeted.
+
+2. "Request History" Requirements
+
+ The following list constitutes a set of requirements for a "Request
+ History" capability.
+
+ 1) CAPABILITY-req: The "Request History" capability provides a
+ capability to inform proxies and UAs involved in processing a
+ request about the history/progress of that request. Although this
+ is inherently provided when the retarget is in response to a SIP
+ redirect, it is deemed useful for non-redirect retargeting
+ scenarios, as well.
+
+ 2) OPTIONALITY-req: The "Request History" information is optional.
+
+ 2.1) In many cases, it is anticipated that whether the history is
+ added to the Request would be a local policy decision
+ enforced by the specific application; thus, no specific
+ protocol element is needed.
+
+
+
+
+
+Barnes Standards Track [Page 4]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ 2.2) Due to the capability being "optional" from the SIP protocol
+ perspective, the impact to an application of not having the
+ "Request History" must be described. Applicability
+ guidelines to be addressed by applications using this
+ capability must be provided as part of the solution to these
+ requirements.
+
+ 3) GENERATION-req: "Request History" information is generated when
+ the request is retargeted.
+
+ 3.1) In some scenarios, it might be possible for more than one
+ instance of retargeting to occur within the same Proxy. A
+ proxy should also generate Request History information for
+ the 'internal retargeting'.
+
+ 3.2) An entity (UA or proxy) retargeting in response to a redirect
+ or REFER should include any Request History information from
+ the redirect/REFER in the new request.
+
+ 4) ISSUER-req: "Request History" information can be generated by a UA
+ or proxy. It can be passed in both requests and responses.
+
+ 5) CONTENT-req: The "Request History" information for each
+ occurrence of retargeting shall include the following:
+
+ 5.1) The new URI or address to which the request is in the process
+ of being retargeted,
+
+ 5.2) The URI or address from which the request was retargeted,
+
+ 5.3) The reason for the Request-URI or address modification,
+
+ 5.4) Chronological ordering of the Request History information.
+
+ 6) REQUEST-VALIDITY-req: Request History is applicable to requests
+ not sent within an established dialog (e.g., INVITE, REGISTER,
+ MESSAGE, and OPTIONS).
+
+ 7) BACKWARDS-req: Request History information may be passed from the
+ generating entity backwards towards the UAC. This is needed to
+ enable services that inform the calling party about the dialog
+ establishment attempts.
+
+ 8) FORWARDS-req: Request History information may also be included by
+ the generating entity in the request, if it is forwarded onwards.
+
+
+
+
+
+
+Barnes Standards Track [Page 5]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+2.1. Security Requirements
+
+ The Request History information is being inserted by a network
+ element retargeting a Request, resulting in a slightly different
+ problem than the basic SIP header problem, thus requiring specific
+ consideration. It is recognized that these security requirements can
+ be generalized to a basic requirement of being able to secure
+ information that is inserted by proxies.
+
+ The potential security problems include the following:
+
+ 1) A rogue application could insert a bogus Request History entry
+ either by adding an additional entry as a result of retargeting or
+ entering invalid information.
+
+ 2) A rogue application could re-arrange the Request History
+ information to change the nature of the end application or to
+ mislead the receiver of the information.
+
+ 3) A rogue application could delete some or all of the Request
+ History information.
+
+ Thus, a security solution for "Request History" must meet the
+ following requirements:
+
+ 1) SEC-req-1: The entity receiving the Request History must be able
+ to determine whether any of the previously added Request History
+ content has been altered.
+
+ 2) SEC-req-2: The ordering of the Request History information must be
+ preserved at each instance of retargeting.
+
+ 3) SEC-req-3: The entity receiving the information conveyed by the
+ Request History must be able to authenticate the entity providing
+ the request.
+
+ 4) SEC-req-4: To ensure the confidentiality of the Request History
+ information, only entities that process the request should have
+ visibility to the information.
+
+ It should be noted that these security requirements apply to any
+ entity making use of the Request History information, either by
+ retargeting and capturing the information, or as an application
+ making use of the information received in either a Request or
+ Response.
+
+
+
+
+
+
+Barnes Standards Track [Page 6]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+2.2. Privacy Requirements
+
+ Since the Request-URI that is captured could inadvertently reveal
+ information about the originator, there are general privacy
+ requirements that MUST be met:
+
+ 1) PRIV-req-1: The entity retargeting the Request must ensure that it
+ maintains the network-provided privacy (as described in [RFC3323])
+ associated with the Request as it is retargeted.
+
+ 2) PRIV-req-2: The entity receiving the Request History must maintain
+ the privacy associated with the information.
+
+ In addition, local policy at a proxy may identify privacy
+ requirements associated with the Request-URI being captured in the
+ Request History information.
+
+ 3) PRIV-req-3: Request History information subject to privacy
+ requirements shall not be included in outgoing messages unless it
+ is protected as described in [RFC3323].
+
+3. Request History Information Description
+
+ The fundamental functionality provided by the request history
+ information is the ability to inform proxies and UAs involved in
+ processing a request about the history or progress of that request
+ (CAPABILITY-req). The solution is to capture the Request-URIs as a
+ request is forwarded in a new header for SIP messages: History-Info
+ (CONTENT-req). This allows for the capturing of the history of a
+ request that would be lost with the normal SIP processing involved in
+ the subsequent forwarding of the request. This solution proposes no
+ changes in the fundamental determination of request targets or in the
+ request forwarding as defined in Sections 16.5 and 16.6 of the SIP
+ protocol specification [RFC3261].
+
+ The History-Info header can appear in any request not associated with
+ an established dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and
+ OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req) and any
+ valid response to these requests (ISSUER-req).
+
+ The History-Info header is added to a Request when a new request is
+ created by a UAC or forwarded by a Proxy, or when the target of a
+ request is changed. The term 'retarget' is introduced to refer to
+ this changing of the target of a request and the subsequent
+ forwarding of that request. It should be noted that retargeting only
+ occurs when the Request-URI indicates a domain for which the
+ processing entity is responsible. In terms of the SIP protocol, the
+ processing associated with retargeting is described in Sections 16.5
+
+
+
+Barnes Standards Track [Page 7]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ and 16.6 of [RFC3261]. As described in Section 16.5 of [RFC3261], it
+ is possible for the target of a request to be changed by the same
+ proxy multiple times (referred to as 'internal retargeting' in
+ Section 2), as the proxy MAY add targets to the target set after
+ beginning Request Forwarding. Section 16.6 of [RFC3261] describes
+ Request Forwarding. It is during this process of Request Forwarding
+ that the History Information is captured as an optional, additional
+ header field. Thus, the addition of the History-Info header does not
+ impact fundamental SIP Request Forwarding. An entity (UA or proxy)
+ changing the target of a request in response to a redirect or REFER
+ SHOULD also propagate any History-Info header from the initial
+ Request in the new request (GENERATION-req, FORWARDS-req).
+
+3.1. Optionality of History-Info
+
+ The History-Info header is optional in that neither UAs nor Proxies
+ are required to support it. A new Supported header, "histinfo", is
+ included in the Request to indicate whether the History-Info header
+ is returned in Responses (BACKWARDS-req). In addition to the
+ "histinfo" Supported header, local policy determines whether or not
+ the header is added to any request, or for a specific Request-URI,
+ being retargeted. It is possible that this could restrict the
+ applicability of services that make use of the Request History
+ Information to be limited to retargeting within domain(s) controlled
+ by the same local policy, or between domain(s) which negotiate
+ policies with other domains to ensure support of the given policy, or
+ services for which complete History Information isn't required to
+ provide the service (OPTIONALITY-req). All applications making use
+ of the History-Info header MUST clearly define the impact of the
+ information not being available and specify the processing of such a
+ request.
+
+3.2. Securing History-Info
+
+ This document defines a new header for SIP. The use of the Transport
+ Layer Security (TLS) protocol [RFC2246] as a mandatory mechanism to
+ ensure the overall confidentiality of the History-Info headers (SEC-
+ req-4) is strongly RECOMMENDED. This results in History-Info having
+ at least the same level of security as other headers in SIP that are
+ inserted by intermediaries. If TLS is not available for the
+ connection over which the request is being forwarded, then the
+ request MUST NOT include the History-Info header or the request MUST
+ be redirected to the client, including the History-Info header, so
+ that the request can be retargeted by the client.
+
+ With the level of security provided by TLS (SEC-req-3), the
+ information in the History-Info header can thus be evaluated to
+ determine if information has been removed by evaluating the indices
+
+
+
+Barnes Standards Track [Page 8]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ for gaps (SEC-req-1, SEC-req-2). It would be up to the application
+ to define whether it can make use of the information in the case of
+ missing entries.
+
+ Note that while using the SIPS scheme protects History-Info from
+ tampering by arbitrary parties outside the SIP message path, all the
+ intermediaries on the path are trusted implicitly. A malicious
+ intermediary could arbitrarily delete, rewrite, or modify History-
+ Info. This specification does not attempt to prevent or detect
+ attacks by malicious intermediaries.
+
+3.3. Ensuring the Privacy of History-Info
+
+ Since the History-Info header can inadvertently reveal information
+ about the requestor as described in [RFC3323], the Privacy header
+ SHOULD be used to determine whether an intermediary can include the
+ History-Info header in a Request that it receives and forwards
+ (PRIV-req-2) or that it retargets (PRIV-req-1). Thus, the History-
+ Info header SHOULD NOT be included in Requests where the requestor
+ has indicated a priv-value of Session- or Header-level privacy.
+
+ In addition, the History-Info header can reveal general routing
+ information, which may be viewed by a specific intermediary or
+ network, to be subject to privacy restrictions. Thus, local policy
+ MAY also be used to determine whether to include the History-Info
+ header at all, whether to capture a specific Request-URI in the
+ header, or whether it be included only in the Request as it is
+ retargeted within a specific domain (PRIV-req-3). In the latter
+ case, this is accomplished by adding a new priv-value, history, to
+ the Privacy header [RFC3323] indicating whether any or a specific
+ History-Info header(s) SHOULD be forwarded.
+
+ It is recognized that satisfying the privacy requirements can impact
+ the functionality of this solution by overriding the request to
+ generate the information. As with the optionality and security
+ requirements, applications making use of History-Info SHOULD address
+ any impact this may have or MUST explain why it does not impact the
+ application.
+
+4. Request History Information Protocol Details
+
+ This section contains the details and usage of the proposed new SIP
+ protocol elements. It also discusses the security aspects of the
+ solution.
+
+
+
+
+
+
+
+Barnes Standards Track [Page 9]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+4.1. Protocol Structure of History-Info
+
+ History-Info is a header field as defined by [RFC3261]. It is an
+ optional header field and MAY appear in any request or response not
+ associated with a dialog or which starts a dialog. For example,
+ History-Info MAY appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS,
+ SUBSCRIBE, and PUBLISH and any valid responses, plus NOTIFY requests
+ that initiate a dialog.
+
+ This document adds the following entry to Table 2 of [RFC3261]. The
+ additions to this table are also provided for extension methods at
+ the time of publication of this document. This is provided as a
+ courtesy to the reader and is not normative in any way.
+
+ Header field where proxy ACK BYE CAN INV OPT REG MSG
+ ------------ ----- ----- --- --- --- --- --- --- ---
+ History-Info amdr - - - o o o o
+
+ SUB NOT REF INF UPD PRA PUB
+ --- --- --- --- --- --- ---
+ History-Info amdr o o o - - - o
+
+ The History-Info header carries the following information, with the
+ mandatory parameters required when the header is included in a
+ request or response:
+
+ o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for
+ capturing the Request-URI for the specific Request as it is
+ forwarded.
+
+ o Index (hi-index): A mandatory parameter for History-Info
+ reflecting the chronological order of the information, indexed to
+ also reflect the forking and nesting of requests. The format for
+ this parameter is a string of digits, separated by dots to
+ indicate the number of forward hops and retargets. This results
+ in a tree representation of the history of the request, with the
+ lowest-level index reflecting a branch of the tree. By adding
+ the new entries in order (i.e., following existing entries per
+ the details in Section 4.3.3.1), including the index and securing
+ the header, the ordering of the History-Info headers in the
+ request is assured (SEC-req-2). In addition, applications may
+ extract a variety of metrics (total number of retargets, total
+ number of retargets from a specific branch, etc.) based upon the
+ index values.
+
+ o Reason: An optional parameter for History-Info, reflected in the
+ History-Info header by including the Reason Header [RFC3326]
+ escaped in the hi-targeted-to-uri. A reason is not included for
+
+
+
+Barnes Standards Track [Page 10]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ a hi-targeted-to-uri when it is first added in a History-Info
+ header, but rather is added when the retargeting actually occurs.
+ Note that this does appear to complicate the security problem;
+ however, retargeting only occurs when the hi-targeted-to-uri
+ indicates a domain for which the processing entity is
+ responsible. Thus, it would be the same processing entity that
+ initially added the hi-targeted-to-URI to the header that would
+ be updating it with the Reason.
+
+ o Privacy: An optional parameter for History-Info, reflected in the
+ History-Info header field values by including the Privacy Header
+ [RFC3323] with a priv-value of "history" escaped in the hi-
+ targeted-to-uri or by adding the Privacy header with a priv-value
+ of "history" to the Request. The use of the Privacy Header with
+ a priv-value of "history" indicates whether a specific or all
+ History-Info headers should not be forwarded.
+
+ o Extension (hi-extension): An optional parameter to allow for
+ future optional extensions. As per [RFC3261], any implementation
+ not understanding an extension should ignore it.
+
+ The following summarizes the syntax of the History-Info header, based
+ upon the standard SIP syntax [RFC3261]:
+
+ History-Info = "History-Info" HCOLON
+ hi-entry *(COMMA hi-entry)
+
+ hi-entry = hi-targeted-to-uri *( SEMI hi-param )
+
+ hi-targeted-to-uri= name-addr
+
+ hi-param = hi-index / hi-extension
+
+ hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
+
+ hi-extension = generic-param
+
+4.2. Protocol Examples
+
+ The following provides some examples of the History-Info header.
+ Note that the backslash and CRLF between the fields in the examples
+ below are for readability purposes only.
+
+ History-Info:<sip:UserA@ims.example.com?Reason=SIP%3B\
+ cause%3D302>;index=1;foo=bar
+
+ History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B \
+ cause%3D302>; index=1.1,
+
+
+
+Barnes Standards Track [Page 11]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ <sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
+ cause%3D486>;index=1.2,
+ <sip:45432@vm.example.com>;index=1.3
+
+4.3. Protocol Usage
+
+ This section describes the processing specific to UAs and Proxies for
+ the History-Info header, the "histinfo" option tag, and the priv-
+ value of "history". As discussed in Section 1.3, the fundamental
+ objective is to capture the target Request-URIs as a request is
+ forwarded. This allows for the capturing of the history of a request
+ that would be lost due to subsequent (re)targeting and forwarding.
+ To accomplish this for the entire history of a request, either the
+ UAC must capture the Request-URI in a History-Info header in the
+ initial request or a proxy must add a History-Info header with both a
+ hi-entry for the Request-URI in the initial request and a hi-entry
+ for the target Request-URI as the request is forwarded. The basic
+ processing is for each entity forwarding a request to add a hi-entry
+ for the target Request-URI, updating the index and adding the Reason
+ as appropriate for any retargeted Request-URI.
+
+4.3.1. User Agent Client (UAC) Behavior
+
+ The UAC SHOULD include the "histinfo" option tag in the Supported
+ header in any request not associated with an established dialog for
+ which the UAC would like the History-Info header in the response. In
+ addition, the UAC MAY improve the diagnostic utility of its request
+ by adding a History-Info header, using the Request-URI of the request
+ as the hi-target-to-uri and initializing the index to the RECOMMENDED
+ value of 1 in the hi-entry. As a result, intermediaries and the UAS
+ will know at least the original Request-URI, and if the Request-URI
+ was modified by a previous hop.
+
+ In the case where the request is routed to a redirect server and the
+ UAC receives a 3xx response with a Contact header, the UAC MAY
+ maintain the previous hi-entry(s) in the request. In this case, the
+ reason header SHOULD be associated with the hi-targeted-to-uri in the
+ previous (last) hi-entry, as described in Section 4.3.3.1.2. A new
+ hi-entry MAY then be added for the URI from the Contact header (which
+ becomes the new Request-URI). In this case, the index is created by
+ reading and incrementing the value of the index from the previous
+ hi-entry, thus following the same rules as those prescribed for a
+ proxy in retargeting, described in Section 4.3.3.1.3. An example of
+ this scenario can be found in Appendix D.
+
+ A UAC that does not want the History-Info header added due to privacy
+ considerations SHOULD include a Privacy header with a priv-value(s)
+ of "session", "header", or "history" in the request.
+
+
+
+Barnes Standards Track [Page 12]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ With the exception of the processing of a 3xx response described
+ above, the processing of the History-Info header received in the
+ Response is application specific and outside the scope of this
+ document. However, the validity of the information SHOULD be ensured
+ prior to any application usage. For example, the entries MAY be
+ evaluated to determine gaps in indices, which could indicate that an
+ entry has been maliciously removed or removed for privacy reasons.
+ Either way, an application MAY want to be aware of potentially
+ missing information.
+
+4.3.2. User Agent Server (UAS) Behavior
+
+ The processing of the History-Info header by a UAS in a Request
+ depends upon local policy and specific applications at the UAS that
+ might make use of the information. Prior to any application usage of
+ the information, the validity SHOULD be ascertained. For example,
+ the entries MAY be evaluated to determine gaps in indices, which
+ could indicate that an entry has been maliciously removed or removed
+ for privacy reasons. Either way, an application MAY want to be aware
+ of potentially missing information.
+
+ If the "histinfo" option tag is received in a request, the UAS SHOULD
+ include any History-Info received in the request in the subsequent
+ response.
+
+4.3.3. Proxy Behavior
+
+ The inclusion of the History-Info header in a Request does not alter
+ the fundamental processing of proxies for determining request targets
+ as defined in Section 16.5 of [RFC3261]. Whether a proxy adds the
+ History-Info header or a new hi-entry as it forwards a Request
+ depends upon the following considerations:
+
+ 1. Whether the Request contains the "histinfo" option tag in the
+ Supported header.
+ 2. Whether the proxy supports the History-Info header.
+ 3. Whether the Request contains a Privacy header with a priv-value
+ of "session", "header", or "history".
+ 4. Whether any History-Info header added for a proxy/domain should
+ go outside that domain. An example being the use of the
+ History-Info header within the specific domain in which it is
+ retargeted, however, policies (for privacy, user and network
+ security, etc.) would prohibit the exposure of that information
+ outside that domain. To accommodate such a scenario, a proxy
+ MAY insert the Privacy header with a priv-value of "history"
+ when the request is being forwarded within the same domain. An
+ example of such an application is provided in Appendix C.
+
+
+
+
+Barnes Standards Track [Page 13]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ 5. Whether a hi-entry is added for a specific Request-URI due to
+ local privacy policy considerations. A proxy MAY add the
+ Privacy header with a priv-value of "history" associated with
+ the specific hi-targeted-to-uri.
+
+ An example policy would be a proxy that only adds the History-Info
+ header if the "histinfo" option tag is in the Supported header.
+ Other proxies may have a policy that they always add the header, but
+ never forward it outside a particular domain, accomplishing this by
+ adding a Privacy header with a priv-value of "history" to each hi-
+ entry to allow the information to be collected for internal
+ retargeting only.
+
+ Each application making use of the History-Info header SHOULD address
+ the impacts of the local policies on the specific application (e.g.,
+ what specification of local policy is optimally required for a
+ specific application and any potential limitations imposed by local
+ policy decisions).
+
+ Consistent with basic SIP processing of optional headers, proxies
+ SHOULD maintain the History-Info header(s), received in messages
+ being forwarded, independent of whether local policy supports
+ History-Info.
+
+ The specific processing by proxies for adding the History-Info
+ headers in Requests and Responses, to accommodate the considerations
+ outlined above, is described in detail in the following sections.
+
+4.3.3.1. Adding the History-Info Header to Requests
+
+ Upon evaluation of the considerations under which the History-Info
+ header is to be included in requests (e.g., no Privacy header
+ overriding inclusion, local policy supports, etc.), detailed in
+ Section 4.3.3, a proxy SHOULD add a hi-entry as it forwards a
+ Request. Section 16.6 of [RFC3261] defines the steps to be followed
+ as the proxy forwards a Request. Step 5 prescribes the addition of
+ optional headers. Although this would seem the appropriate step for
+ adding the History-Info header, the interaction with Step 6,
+ "Postprocess routing information", and the impact of a strict route
+ in the Route header could result in the Request-URI being changed;
+ thus, adding the History-Info header between Steps 8 (adding Via
+ header) and 9 (adding Content-Length) is RECOMMENDED. Note that in
+ the case of loose routing, the Request-URI does not change during the
+ forwarding of a Request; thus, the capturing of History-Info for such
+ a request would result in duplicate Request-URIs with different
+ indices. The hi-entry MUST be added following any hi-entry received
+ in the request being forwarded. Additionally, if a request is
+ received that doesn't include a History-Info header, the proxy MAY
+
+
+
+Barnes Standards Track [Page 14]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ add a History-Info header with a hi-entry preceding the one being
+ added for the current request being forwarded. The index for this
+ hi-entry is RECOMMENDED to start at 1. The following subsections
+ define the details of creating the information associated with each
+ hi-entry.
+
+4.3.3.1.1. Privacy in the History-Info Header
+
+ If there is a Privacy header in the request with a priv-value of
+ "session", "header", or "history", a hi-entry MAY be added, if the
+ request is being forwarded to a Request-URI associated with a domain
+ for which the processing entity is responsible (and provided local
+ policy supports the History-Info header, etc.). If a request is
+ being forwarded to a Request-URI associated with a domain for which
+ the proxy is not responsible and there is a Privacy header in the
+ request with a priv-value of "session", "header", or "history", the
+ proxy SHOULD remove any hi-entry(s) prior to forwarding, depending
+ upon local policy and whether the proxy might know a priori that it
+ can rely on a downstream privacy service to apply the requested
+ privacy.
+
+ For the scenario where there is no Privacy header in the request and
+ the request is being forwarded to a Request-URI associated with the
+ domain(s) for which this entity is responsible, there are several
+ additional considerations:
+
+ o If there is no local policy associated with privacy, then a hi-
+ entry MAY be added to the Request.
+
+ o If the proxy's local policies, per consideration 4 in section
+ 4.3.3, indicate that the History-Info header should not be
+ forwarded beyond the domain for which this intermediary is
+ responsible, then a Privacy header with a priv-value of "history"
+ SHOULD be associated with each hi-entry added by that proxy in
+ this scenario.
+
+ o If the proxy's policy, per consideration 5 in Section 4.3.3,
+ indicates that History-Info for a specific Request-URI should not
+ be forwarded beyond the domain for which this intermediary is
+ responsible, then a Privacy header with a priv-value of "history"
+ SHOULD be associated with the specific hi-entry, for that
+ specific hi-targeted-to-uri, added by that proxy in this
+ scenario.
+
+ If a request is being forwarded to a Request-URI associated with a
+ domain for which the proxy is not responsible and local policy
+ requires privacy associated with any, or with specific, hi-entries it
+
+
+
+
+Barnes Standards Track [Page 15]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ has added, any hi-entry with a priv-value of "history" SHOULD be
+ removed prior to forwarding.
+
+4.3.3.1.2. Reason in the History-Info Header
+
+ For retargets that are the result of an explicit SIP response, a
+ Reason MUST be associated with the hi-targeted-to-uri. If the SIP
+ response does not include a Reason header, the SIP Response Code that
+ triggered the retargeting MUST be included as the Reason associated
+ with the hi-targeted-to-uri that has been retargeted. If the
+ response contains a non-SIP Reason header (e.g., Q.850), it MUST be
+ captured as an additional Reason associated with the hi-targeted-to-
+ uri that has been retargeted, along with the SIP Response Code. If
+ the Reason header is a SIP reason, then it MUST be used as the Reason
+ associated with the hi-targeted-to-uri rather than the SIP response
+ code.
+
+ For retargets as a result of timeouts or internal events, a Reason
+ MAY be associated with the hi-targeted-to-uri that has been
+ retargeted.
+
+ The addition of the Reason should occur prior to the forwarding of
+ the request (which may add a new hi-entry with a new hi-targeted-to-
+ uri) as it is associated with the hi-targeted-to-uri that has been
+ retargeted, since it reflects the reason why the Request to that
+ specific URI was not successful.
+
+4.3.3.1.3. Indexing in the History-Info Header
+
+ In order to maintain ordering and accurately reflect the nesting and
+ retargeting of the request, an index MUST be included along with the
+ Targeted-to-URI being captured. Per the syntax in Section 4.1, the
+ index consists of a dot-delimited series of digits (e.g., 1.1.2).
+ Each dot reflects a hop or level of nesting; thus, the number of hops
+ is determined by the total number of dots. Within each level, the
+ integer reflects the number of peer entities to which the request has
+ been routed. Thus, the indexing results in a logical tree
+ representation for the history of the Request. It is recommended
+ that for each level of indexing, the index start at 1. It is
+ recommended that an increment of 1 is used for advancing to a new
+ branch.
+
+ The basic rules for adding the index are summarized as follows:
+
+ 1. Basic Forwarding: In the case of a Request that is being
+ forwarded, the index is determined by adding another level of
+ indexing since the depth/length of the branch is increasing. To
+ accomplish this, the proxy reads the value from the History-Info
+
+
+
+Barnes Standards Track [Page 16]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ header in the received request, if available, and adds another
+ level of indexing by appending the dot delimiter followed by an
+ initial index for the new level RECOMMENDED to be 1. For
+ example, if the index in the last History-Info header field in
+ the received request is 1.1, this proxy would initialize its
+ index to 1.1.1 and forward the request.
+
+ 2. Retargeting within a Proxy - 1st instance: For the first
+ instance of retargeting within a Proxy, the calculation of the
+ index follows that prescribed for basic forwarding.
+
+ 3. Retargeting within a Proxy - subsequent instance: For each
+ subsequent retargeting of a request by the same proxy, another
+ branch is added. With the index for each new branch calculated
+ by incrementing the last/lowest digit at the current level, the
+ index in the next request forwarded by this same proxy,
+ following the example above, would be 1.1.2.
+
+ 4. Retargeting based upon a Response: In the case of retargeting
+ due to a specific response (e.g., 302), the index would be
+ calculated per rule 3. That is, the lowest/last digit of the
+ index is incremented (i.e., a new branch is created), with the
+ increment RECOMMENDED to be 1. For example, if the index in the
+ History-Info header of the received request was 1.2, then the
+ index in the History-Info header field for the new hi-targeted-
+ to-URI would be 1.3.
+
+ 5. Retargeting the request in parallel (forking): If the request
+ forwarding is done in parallel, the index MUST be captured for
+ each forked request per the rules above, with each new Request
+ having a unique index. The only difference in the messaging for
+ this scenario and the messaging produced per basic proxy
+ retargeting in rules 2 and 3 is these forwarded requests do not
+ have History-Info entries associated with their peers. The
+ proxy builds the subsequent response (or request) using the
+ aggregated information associated with each of those requests
+ and including the header entries in the order indicated by the
+ indexing. Responses are processed as described in Section 16.7
+ of [RFC3261] with the aggregated History-Info entries processed
+ similar to Step 7 "Aggregate Authentication Header Field
+ Values". Section 4.5 provides an example of a parallel request
+ scenario, highlighting this indexing mechanism.
+
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 17]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+4.3.3.2. Processing History-Info in Responses
+
+ A proxy that receives a Request with the "histinfo" option tag in the
+ Supported header, and depending upon a local policy supporting the
+ capture of History-Info, SHOULD return captured History-Info in
+ subsequent, provisional, and final responses to the Request, subject
+ to the following considerations for privacy:
+
+ o If the response is being forwarded to a Request-URI associated
+ with a domain for which the proxy is not responsible and there
+ was a Privacy header, in the request received by the proxy, with
+ a priv-value of "session", "header", or "history", the proxy MUST
+ remove the History-Info header (i.e., all hi-entries) prior to
+ forwarding.
+
+ o If a request is being forwarded to a Request-URI associated with
+ a domain for which the proxy is not responsible and local policy
+ requires privacy associated with any or all hi-entry(s) it has
+ added, any hi-entry with a priv-value of "history" MUST be
+ removed prior to forwarding.
+
+ o If a proxy receives a response from another intermediary
+ associated with a domain for which it is responsible, including
+ hi-entry(s) with privacy headers, and that response is to be
+ forwarded to a domain for which it is not responsible, then those
+ hi-entry(s) MUST be removed.
+
+ The processing of History-Info in responses follows the methodology
+ described in Section 16.7 of [RFC3261], with the processing of
+ History-Info headers adding an additional step, just before Step 9,
+ "Forwarding the Response".
+
+4.3.4. Redirect Server Behavior
+
+ A redirect server SHOULD NOT add any new History-Info, as that would
+ be done by the entity receiving the 3xx response. However, a
+ redirect server MAY include History-Info in responses by adding any
+ History-Info headers received in a request to a subsequent response.
+
+4.4. Security for History-Info
+
+ As discussed in Section 3, the security requirements are met by
+ recommending the use of TLS (a basic SIP requirement per [RFC3261])
+ for hop-by-hop security. If TLS is not available on the connection
+ over which a request containing a History-Info header is being
+ forwarded, then either of the following two options MUST be
+ implemented:
+
+
+
+
+Barnes Standards Track [Page 18]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ o The History-Info header MUST be removed prior to forwarding the
+ request, or
+ o The request MUST be redirected, including the History-Info header
+ in the response, to allow the UAC to securely issue the request,
+ including the History-Info header.
+
+4.5. Example Applications Using History-Info
+
+ This scenario highlights an example where the History-Info in the
+ response is primarily of use in not retrying routes that have already
+ been tried by another proxy. Note that this is just an example and
+ that there may be valid reasons why a Proxy would want to retry the
+ routes, and thus, this would likely be a local proxy or even user-
+ specific policy.
+
+ UA1 sends a call to Bob to proxy 1. Proxy 1 forwards the request to
+ Proxy 2. Proxy 2 sends the requests in parallel and tries several
+ places (UA2, UA3, and UA4) before sending a response to Proxy 1 that
+ all the places are busy. Proxy 1, without the History-Info, would
+ try some of the same places (e.g., UA3) based upon registered
+ contacts for Bob, before completing at UA5. However, with the
+ History-Info, Proxy 1 determines that UA3 has already received the
+ invite; thus, the INVITE goes directly to UA5.
+
+ Section 4.5.1 provides this same scenario using one of the privacy
+ mechanisms, with Proxy2 (P2) adding the Privacy header indicating
+ that the History-Info header is not to be propagated outside P2's
+ domain. This scenario highlights the potential functionality lost
+ with the use of "history" privacy in the Privacy header for the
+ entire request and the need for careful consideration on the use of
+ privacy for History-Info.
+
+ Section 4.5.2 also provides the same scenario using one of the
+ privacy mechanisms, however, due to local policy at Proxy2, only one
+ of the Request-URIs (UA4) in the History-Info contains a priv-value
+ of "history", thus allowing some optimized functionality in the
+ routing of the request, but still maintaining privacy for specific
+ URIs.
+
+ The formatting in these scenarios is for visual purposes; thus,
+ backslash and CRLF are used between the fields for readability and
+ the headers in the URI are not shown properly formatted for escaping.
+ Refer to Section 4.2 examples for the proper formatting. Additional
+ detailed scenarios are available in the appendix.
+
+
+
+
+
+
+
+Barnes Standards Track [Page 19]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
+
+ | | | | | | |
+ |--INVITE -->| | | | | |
+ | |-INVITE->| | | | |
+ Supported: histinfo
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1
+ | | | | | | |
+ | | |-INVITE>| | | |
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>;index=1.1,
+ <sip:User2@UA2.example.com>;index=1.1.1
+ | | | | | | |
+ | | |-----INVITE ---->| | |
+ History-Info:<sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User3@UA3.example.com>;index=1.1.2
+ | | | | | | |
+ | | |-------INVITE------------>| |
+ History-Info:<sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>;index=1.1,
+ <sip:User4@UA4.example.com>;index=1.1.3
+
+ /* All Responses from the INVITEs indicate non-success/non-
+ availability*/
+ | | | | | | |
+ | |<-480 ---| | | | |
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User2@UA2.example.com?Reason=SIP;\
+ cause=408;text="RequestTimeout">;index=1.1.1,
+ <sip:User3@UA3.example.com?Reason=SIP; \
+ cause=487;text="Request Terminated">; index=1.1.2,
+ <sip:User4@UA4.example.com?Reason=SIP;\
+ cause=603;text="Decline">; index=1.1.3
+ | | | | | | |
+ /* Upon receipt of the response, P1 determines another route for the
+ INVITE, but finds that it matches a route already attempted
+ (e.g., UA3), thus the INVITE is only forwarded to UA5, where
+ the session is successfully established */
+ | | | | | | |
+ | |----------------INVITE --------------------->|
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User2@UA2.example.com?Reason=SIP;cause=408;\
+ text="RequestTimeout">;index=1.1.1,
+ <sip:User3@UA3.example.com?Reason=SIP;cause=487;\
+
+
+
+Barnes Standards Track [Page 20]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ text="Request Terminated">; index=1.1.2,
+ <sip:User4@UA4.example.com?Reason=SIP;cause=603;\
+ text="Decline">; index=1.1.3
+ <sip:User5@UA5.example.com>;index=1.2
+ | | | | | | |
+ | |<-----200 OK---------------------------------|
+ |<--200 OK---| | | | | |
+ | | | | | | |
+ |--ACK --------------------------------------------------->|
+
+4.5.1. Example with Privacy Header for Entire Request at Proxy2
+
+ UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
+
+ | | | | | | |
+ |--INVITE -->| | | | | |
+ | |-INVITE->| | | | |
+ Supported: histinfo
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>;index=1.1
+ | | | | | | |
+ | | |-INVITE>| | | |
+ Privacy: history
+ History-Info:<sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>;index=1.1,
+ <sip:User2@UA2.example.com>;index=1.1.1
+ | | | | | | |
+ | | |-----INVITE ---->| | |
+ Privacy: history
+ History-Info:<sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User3@UA3.example.com>;index=1.1.2
+ | | | | | | |
+ | | |-------INVITE------------>| |
+ Privacy: history
+ History-Info:<sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>;index=1.1,
+ <sip:User4@UA4.example.com>;index=1.1.3
+
+ /* All Responses from the INVITEs indicate non-success/non-
+ availability and only the initial, received History-Info entries
+ are NOT returned to P1 due to the Privacy header value.*/
+ | | | | | | |
+ | |<-480 ---| | | | |
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1
+ | | | | | | |
+ /* Upon receipt of the response, P1 determines another route for the
+
+
+
+Barnes Standards Track [Page 21]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ INVITE, including UA3, which was attempted by P2, but due to
+ Privacy P1 is not aware of this, so UA3 is re-attempted prior to
+ forwarding the INVITE to UA5, where the session is successfully
+ established */
+ | | | | | | |
+ | |--------------INVITE ----->| | |
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User3@UA3.example.com>; index=1.2
+ | | | | | | |
+ | |<-- 486 -------------------| | |
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User3@UA3.example.com>; index=1.2
+ | | | | | | |
+ | |----------------INVITE --------------------->|
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User3@UA3.example.com?Reason=SIP;cause=486;\
+ text="Busy Here">;index=1.2,
+ <sip:User5@UA5.example.com>;index=1.3
+ | | | | | | |
+ | |<-----200 OK---------------------------------|
+ |<--200 OK---| | | | | |
+ | | | | | | |
+ |--ACK --------------------------------------------------->|
+
+4.5.2. Example with Privacy Header for Specific URI (UA4) at Proxy2
+
+ UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
+
+ | | | | | | |
+ |--INVITE -->| | | | | |
+ | |-INVITE->| | | | |
+ Supported: histinfo
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1
+ | | | | | | |
+ | | |-INVITE>| | | |
+ History-Info:<sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>;index=1.1,
+ <sip:User2@UA2.example.com>;index=1.1.1
+ | | | | | | |
+ | | |-----INVITE ---->| | |
+ History-Info:<sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>;index=1.1,
+ <sip:User3@UA3.example.com>;index=1.1.2
+ | | | | | | |
+
+
+
+Barnes Standards Track [Page 22]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ | | |-------INVITE------------>| |
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>;index=1.1,
+ <sip:User4@UA4.example.com?\
+ Privacy=history>; index=1.1.3
+
+ /* All Responses from the INVITEs indicate non-success/non-
+ availability. The History-Info associated with UA4 is not returned
+ in the response due to the privacy header associated with that URI */
+ | | | | | | |
+ | |<-480 ---| | | | |
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User2@UA2.example.com?Reason=SIP;\
+ cause=408;text="RequestTimeout">;index=1.1.1,
+ <sip:User3@UA3.example.com?Reason=SIP; \
+ cause=487;text="Request Terminated">; index=1.1.2,
+ | | | | | | |
+ /* Upon receipt of the response, P1 determines another route for the
+ INVITE, but finds that it matches a route already attempted
+ (e.g., UA3), thus the INVITE is only forwarded to UA5, where
+ the session is successfully established */
+ | | | | | | |
+ | |----------------INVITE --------------------->|
+ History-Info: <sip:Bob@P1.example.com>;index=1,
+ <sip:Bob@P2.example.com>; index=1.1,
+ <sip:User2@UA2.example.com?Reason=SIP;cause=408;\
+ text="RequestTimeout">;index=1.1.1,
+ <sip:User3@UA3.example.com?Reason=SIP;cause=487;\
+ text="Request Terminated">; index=1.1.2,
+ <sip:User5@UA5.example.com>;index=1.2
+ | | | | | | |
+ | |<-----200 OK---------------------------------|
+ |<--200 OK---| | | | | |
+ | | | | | | |
+ |--ACK --------------------------------------------------->|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 23]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+5. Application Considerations
+
+ As seen by the example scenarios in the appendix, History-Info
+ provides a very flexible building block that can be used by
+ intermediaries and UAs for a variety of services. As such, any
+ services making use of History-Info must be designed with the
+ following considerations:
+
+ 1) History-Info is optional; thus, a service MUST define default
+ behavior for requests and responses not containing History-Info
+ headers.
+ 2) History-Info may be impacted by privacy considerations.
+ Applications requiring History-Info need to be aware that if
+ Header-, Session-, or History-level privacy is requested by a UA
+ (or imposed by an intermediary) that History-Info may not be
+ available in a request or response. This would be addressed by an
+ application in the same manner as the previous consideration by
+ ensuring there is reasonable default behavior should the
+ information not be available.
+ 3) History-Info may be impacted by local policy. Each application
+ making use of the History-Info header SHOULD address the impacts
+ of the local policies on the specific application (e.g., what
+ specification of local policy is optimally required for a specific
+ application and any potential limitations imposed by local policy
+ decisions). Note that this is related to the optionality and
+ privacy considerations identified in 1 and 2 above, but goes
+ beyond that. For example, due to the optionality and privacy
+ considerations, an entity may receive only partial History-Info
+ entries; will this suffice? Note that this would be a limitation
+ for debugging purposes, but might be perfectly satisfactory for
+ some models whereby only the information from a specific
+ intermediary is required.
+ 4) The security associated with the History-Info header requires the
+ use of TLS. In the case of TLS not being available for a
+ connection over which a request is being forwarded, the History-
+ Info header may be removed from a request. The impact of lack of
+ having the information depends upon the nature of the specific
+ application (e.g., Is the information something that appears on a
+ display or is it processed by automata which could have negative
+ impacts on the subsequent processing of a request?). It is
+ suggested that the impact of an intermediary not supporting the
+ security recommendations should be evaluated by the application to
+ ensure that the impacts have been sufficiently addressed by the
+ application.
+
+
+
+
+
+
+
+Barnes Standards Track [Page 24]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+6. Security Considerations
+
+ The threat model and related security and privacy requirements for
+ the History-Info header are described in Sections 2.1 and 2.2 of this
+ document. Sections 3.2, 3.3, and 4.4 provide normative
+ recommendations related to security and privacy fulfilling these
+ requirements. The use of TLS is mandated between the entities (i.e.,
+ UAC to Proxy, Proxy to Proxy, and Proxy to UAS) that use the
+ History-Info header. The appropriate handling of a request in the
+ case that TLS is not available for a specific connection is described
+ in Section 5.
+
+ With TLS, History-Info headers are no less, nor no more, secure than
+ other SIP headers, which generally have even more impact on the
+ subsequent processing of SIP sessions than the History-Info header.
+
+7. IANA Considerations
+
+7.1. Registration of New SIP History-Info Header
+
+ This document defines a new SIP header field name: History-Info and a
+ new option tag: histinfo.
+
+ The following changes have been made to
+ http:///www.iana.org/assignments/sip-parameters
+
+ The following row has been added to the header field section:
+
+ Header Name Compact Form Reference
+ ----------- ------------ ---------
+ History-Info none [RFC4244]
+
+ The following has been added to the Options Tags section:
+
+ Name Description Reference
+ ---- ----------- ---------
+ histinfo When used with the Supported header, [RFC4244]
+ this option tag indicates support
+ for the History Information to be
+ captured for requests and returned in
+ subsequent responses. This tag is not
+ used in a Proxy-Require or Require
+ header field since support of
+ History-Info is optional.
+
+
+
+
+
+
+
+Barnes Standards Track [Page 25]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+7.2. Registration of "history" for SIP Privacy Header
+
+ This document defines a new priv-value for the SIP Privacy header:
+ history
+
+ The following changes have been made to
+ http://www.iana.org/assignments/sip-priv-values
+
+ The following has been added to the registration for the SIP Privacy
+ header:
+
+ Name Description Registrant Reference
+ ---- ----------- ---------- ---------
+ history Privacy requested for Mary Barnes [RFC4244]
+ History-Info header(s) mary.barnes@nortel.com
+
+8. Normative References
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
+ Header Field for the Session Initiation Protocol (SIP)",
+ RFC 3326, December 2002.
+
+ [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
+ Initiation Protocol (SIP)", RFC 3323, November 2002.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+9. Informative References
+
+ [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
+ K. Summers, "Session Initiation Protocol (SIP) Basic Call
+ Flow Examples", BCP 75, RFC 3665, December 2003.
+
+10. Acknowledgements
+
+ The editor would like to acknowledge the constructive feedback
+ provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell,
+ Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng,
+ Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger,
+
+
+
+Barnes Standards Track [Page 26]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and
+ Sebastien Garcin.
+
+ The editor would like to acknowledge the significant input from Rohan
+ Mahy on some of the normative aspects of the ABNF, particularly
+ around the need for and format of the index and around the security
+ aspects.
+
+11. Contributors' Addresses
+
+ Cullen, Mark, and Jon contributed to the development of the initial
+ requirements.
+
+ Cullen and Mark provided substantial input in the form of email
+ discussion in the development of the initial version of the
+ individual solution document.
+
+ Cullen Jennings
+ Cisco Systems
+ 170 West Tasman Dr
+ MS: SJC-21/3
+
+ Phone: +1 408 421 9990
+ EMail: fluffy@cisco.com
+
+
+ Jon Peterson
+ NeuStar, Inc.
+ 1800 Sutter Street, Suite 570
+ Concord, CA 94520
+ USA
+
+ Phone: +1 925-363-8720
+ EMail: Jon.Peterson@NeuStar.biz
+
+
+ Mark Watson
+ Digital Fountain
+ 39141 Civic Center Drive Suite 300
+ Fremont, CA 94538
+ U.S.A.
+
+ EMail: mark@digitalfountain.com
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 27]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+Appendix. Example Scenarios
+
+ The scenarios in Appendices A-D provide sample use cases for the
+ History-Info header for informational purposes only. They are not
+ intended to be normative and the formatting is for visual purposes;
+ thus, the headers in the URI are not shown properly formatted for
+ escaping. Refer to Section 4.2 examples with the proper formatting.
+
+Appendix A. Sequentially Forking (History-Info in Response)
+
+ This scenario highlights an example where the History-Info in the
+ response is useful to an application or user that originated the
+ request.
+
+ Alice at UA1 sends a call to Bob via Proxy1. Proxy1 sequentially
+ tries several places (UA2, UA3 and UA4) unsuccessfully before sending
+ a response to Alice.
+
+ This scenario is provided to show that by providing the History-Info
+ to UA1, the end-user or an application at UA1 could make a decision
+ on how best to attempt finding Bob. Without this mechanism, UA1
+ might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a
+ third manual attempt at reaching Bob. With this mechanism, either
+ the end-user or application could know that Bob is busy on his home
+ phone and is physically not in the office. If there were an
+ alternative address for Bob known to this end-user or application,
+ that hasn't been attempted, then either the application or the end-
+ user could attempt that. The intent here is to highlight an example
+ of the flexibility of this mechanism that enables applications well
+ beyond SIP as it is certainly well beyond the scope of this document
+ to prescribe detailed applications.
+
+ In this scenario, since UA1 has not included the original Request-URI
+ in the INVITE, the proxy adds a hi-entry to capture the original
+ Request-URI to provide the complete set of information, as discussed
+ in Section 4.3.3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 28]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ UA1 Proxy1 UA2 UA3 UA4
+ | | | | |
+ |-INVITE F1->| | | |
+ | | | | |
+ | |--INVITE F2------>| | |
+ |<--100 F3---| | | |
+ | |<-302 F4----------| | |
+ | | | | |
+ | |-------INVITE F5 --------->| |
+ | | | | |
+ | |<-------180 F6 ------------| |
+ |<---180 F7--| | | |
+ | . . |---retransmit INVITE ----->| |
+ | | | | |
+ | | ( timeout ) | | |
+ | | | | |
+ | |------INVITE F8 ------------------->|
+ |<--100 F9 --| | | |
+ | | | | |
+ | |<-486 F10 --------------------------|
+ | | | | |
+ | |-- ACK F11------------------------->|
+ |<--486 F12--| | | |
+ | | | | |
+ |--ACK F13-->| | | |
+ | | | | |
+
+ Message Details
+
+ F1 INVITE UA1 ->Proxy1
+
+ INVITE sip:UserA@example.com SIP/2.0
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Contact: Alice <sip:User1@example.net>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=UserA 2890844526 2890844526 IN IP4 client.example.net
+ s=Session SDP
+ c=IN IP4 192.0.2.3
+ t=0 0
+ m=audio 49170 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+
+
+Barnes Standards Track [Page 29]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ /*Client for UA1 prepares to receive data on port 49170
+ from the network. */
+
+ F2 INVITE Proxy1 ->UA2
+
+ INVITE sip:UserA@ims.example.com SIP/2.0
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=1
+ Via: SIP/2.0/UDP example.net:5060
+ Record-Route: <sip:UserA@example.com>
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ History-Info: <sip:UserA@example.com>; index=1,
+ <sip:UserA@ims.example.com>; index=1.1
+ Contact: Alice <sip:User1@example.net>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=UserA 2890844526 2890844526 IN IP4 client.example.net
+ s=Session SDP
+ c=IN IP4 192.0.2.3
+ t=0 0
+ m=audio 49170 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ F3 100 Trying Proxy1 ->UA1
+
+ SIP/2.0 100 Trying
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ F4 302 Moved Temporarily UA2 ->Proxy1
+
+ SIP/2.0 302 Moved Temporarily
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=1
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>;tag=3
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Contact: <sip:UserB@example.com>
+ Content-Length: 0
+
+
+
+Barnes Standards Track [Page 30]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ F5 INVITE Proxy1 -> UA3
+
+ INVITE sip:UserB@example.com SIP/2.0
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=2
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ History-Info: <sip:UserA@example.com>; index=1,
+ <sip:UserA@ims.example.com?Reason=SIP;\
+ cause=302; text="Moved Temporarily">; index=1.1,
+ <sip:UserB@example.com>;index=1.2
+ CSeq: 1 INVITE
+ Contact: Alice <sip:User1@example.net>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=User1 2890844526 2890844526 IN IP4 client.example.net
+ s=Session SDP
+ c=IN IP4 192.0.2.3
+ t=0 0
+ m=audio 49170 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ F6 180 Ringing UA3 ->Proxy1
+
+ SIP/2.0 180 Ringing
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>;tag=5
+ Call-ID: 12345600@example.net
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ F7 180 Ringing Proxy1 -> UA1
+
+ SIP/2.0 180 Ringing
+ SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ /* User B is not available. INVITE is sent multiple
+ times until it times out. */
+
+
+
+
+Barnes Standards Track [Page 31]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ /* The proxy forwards the INVITE to UA4 after adding the
+ additional History Information entry. */
+
+ F8 INVITE Proxy1 -> UA4
+
+ INVITE sip:UserC@example.com SIP/2.0
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=3
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ History-Info: <sip:UserA@example.com>; index=1,
+ <sip:UserA@ims.example.com?Reason=SIP;\
+ cause=302; text="Moved Temporarily">;index=1.1,
+ <sip:UserB@example.com?Reason=SIP;cause=480;\
+ text="Temporarily Unavailable" >;index=1.2,
+ <sip:UserC@example.com>;index=1.3
+ CSeq: 1 INVITE
+ Contact: Alice <sip:User1@example.net>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=User1 2890844526 2890844526 IN IP4 client.example.net
+ s=Session SDP
+ c=IN IP4 192.0.2.3
+ t=0 0
+ m=audio 49170 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ F9 100 Trying Proxy1 ->UA1
+
+ SIP/2.0 100 Trying
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ F10 486 Busy Here UA4 -> Proxy1
+
+ SIP/2.0 486 Busy Here
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=3
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+
+
+
+Barnes Standards Track [Page 32]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ F11 ACK Proxy1 -> UA4
+
+ ACK sip:UserC@example.com SIP/2.0
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 ACK
+ Content-Length: 0
+
+ /* The proxy forwards the 486 to Alice after adding the
+ associated History Information entries from the series of
+ INVITES */
+
+ F12 486 Busy Here Proxy1 -> UA1
+
+ SIP/2.0 486 Busy Here
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ History-Info: <sip:UserA@example.com>; index=1,
+ <sip:UserA@ims.example.com?Reason=SIP;\
+ cause=302; text="Moved Temporarily">;index=1.1,
+ <sip:UserB@example.com?Reason=SIP;cause=480;\
+ text="Temporarily Unavailable" >;index=1.2,
+ <sip:UserC@example.com>;index=1.3
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ F13 ACK Alice -> Proxy 1
+
+ ACK sip:UserA@example.com SIP/2.0
+ Via: SIP/2.0/UDP example.net:5060
+ From: Alice <sip:User1@example.net>
+ To: Bob <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 ACK
+ Content-Length: 0
+
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 33]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+Appendix B. Voicemail
+
+ This scenario highlights an example where the History-Info in the
+ request is primarily of use by an edge service (e.g., voicemail
+ server). It should be noted that this isn't intended to be a
+ complete specification for this specific edge service as it is quite
+ likely that additional information is needed by the edge service.
+ History-Info is just one building block that this service makes use
+ of.
+
+ UA1 called UA A, which had been forwarded to UA B, which forwarded to
+ a UA VM (voicemail server). Based upon the retargeted URIs and
+ Reasons (and other information) in the INVITE, the VM server makes a
+ policy decision about what mailbox to use, which greeting to play,
+ etc.
+
+ UA1 Proxy UA-A UA-B UA-VM
+
+ | | | | |
+ |--INVITE F1-->| | | |
+ | | | | |
+ | |--INVITE F2-->| | |
+ |<--100 F3-----| | | |
+ | |<-302 F4------| | |
+ | | | | |
+ | |--------INVITE F5---------->| |
+ | | | | |
+ | |<--------180 F6-------------| |
+ |<---180 F7----| | | |
+ | . . . | | | |
+ | |------retransmit INVITE---->| |
+ | . . . | | | |
+ | | (timeout) | |
+ | | | | |
+ | |-------INVITE F8---------------------->|
+ | | | | |
+ | |<-200 F9-------------------------------|
+ | | | | |
+ |<-200 F10-----| | | |
+ | | | | |
+ |--ACK F11-------------------------------------------->|
+
+
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 34]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ Message Details
+
+ INVITE F1 UA1->Proxy
+
+ INVITE sip:UserA@example.com SIP/2.0
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Contact: BigGuy <sip:User1@example.net>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+ v=0
+ o=UserA 2890844526 2890844526 IN IP4 client.example.net
+ s=Session SDP
+ c=IN IP4 192.0.2.3
+ t=0 0
+ m=audio 49170 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ /*Client for UA1 prepares to receive data on port 49170
+ from the network. */
+
+ INVITE F2 Proxy->UA-A
+
+ INVITE sip:UserA@ims.example.com SIP/2.0
+ Via: SIP/2.0/UDPims.example.com:5060;branch=1
+ Via: SIP/2.0/UDP example.net:5060
+ Record-Route: <sip:UserA@example.com>
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ History-Info: <sip:UserA@ims.example.com>; index=1
+ Contact: BigGuy <sip:User1@example.net>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=UserA 2890844526 2890844526 IN IP4 client.example.net
+ s=Session SDP
+ c=IN IP4 192.0.2.3
+ t=0 0
+ m=audio 49170 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ 100 Trying F3 Proxy->UA1
+
+
+
+Barnes Standards Track [Page 35]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ SIP/2.0 100 Trying
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ 302 Moved Temporarily F4 UserA->Proxy
+ SIP/2.0 302 Moved Temporarily
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=1
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy<sip:UserA@example.com>;tag=3
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Contact: <sip:UserB@example.com>
+ Content-Length: 0
+
+ INVITE F5 Proxy-> UA-B
+
+ INVITE sip:UserB@example.com SIP/2.0
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=2
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ History-Info: <sip:UserA@ims.example.com?Reason=SIP;\
+ cause=302; text="Moved Temporarily">; index=1,
+ <sip:UserB@example.com>;index=2
+ CSeq: 1 INVITE
+ Contact: BigGuy <sip:User1@example.net>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=User1 2890844526 2890844526 IN IP4 client.example.net
+ s=Session SDP
+ c=IN IP4 192.0.2.3
+ t=0 0
+ m=audio 49170 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ 180 Ringing F6 UA-B ->Proxy
+
+ SIP/2.0 180 Ringing
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+
+
+
+Barnes Standards Track [Page 36]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ To: LittleGuy <sip:UserA@example.com>;tag=5
+ Call-ID: 12345600@example.net
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ 180 Ringing F7 Proxy-> UA1
+
+ SIP/2.0 180 Ringing
+ SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Content-Length: 0
+
+ /* User B is not available. INVITE is sent multiple
+ times until it times out. */
+
+ /* The proxy forwards the INVITE to UA-VM after adding the
+ additional History Information entry. */
+
+ INVITE F8 Proxy-> UA-VM
+
+ INVITE sip:VM@example.com SIP/2.0
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=3
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy <sip:UserA@example.com>
+ Call-Id: 12345600@example.net
+ History-Info:<sip:UserA@ims.example.com?Reason=SIP;\
+ cause=302; text="Moved Temporarily">;index=1,
+ <sip:UserB@example.com?Reason=SIP;cause=480;\
+ text="Temporarily Unavailable" >;index=2,
+ <sip:VM@example.com>;index=3
+ CSeq: 1 INVITE
+ Contact: BigGuy <sip:User1@example.net>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=User1 2890844526 2890844526 IN IP4 client.example.net
+ s=Session SDP
+ c=IN IP4 192.0.2.3
+ t=0 0
+ m=audio 49170 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ 200 OK F9
+
+
+
+Barnes Standards Track [Page 37]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ SIP/2.0 200 OK UA-VM->Proxy
+
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=3
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy <sip:UserA@example.com>;tag=3
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Contact: TheVoiceMail <sip:VM@example.com>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=UserA 2890844527 2890844527 IN IP4 vm.example.com
+ s=Session SDP
+ c=IN IP4 192.0.2.4
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ 200 OK F10 Proxy->UA1
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/UDP ims.example.com:5060;branch=3
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy <sip:UserA@example.com>;tag=3
+ Call-Id: 12345600@example.net
+ CSeq: 1 INVITE
+ Contact: TheVoiceMail <sip:VM@example.com>
+ Content-Type: application/sdp
+ Content-Length: <appropriate value>
+
+ v=0
+ o=UserA 2890844527 2890844527 IN IP4 vm.example.com
+ s=Session SDP
+ c=IN IP4 192.0.2.4
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ ACK F11 UA1-> UA-VM
+
+ ACK sip:VM@example.com SIP/2.0
+ Via: SIP/2.0/UDP example.net:5060
+ From: BigGuy <sip:User1@example.net>
+ To: LittleGuy<sip:UserA@example.com>;tag=3
+ Call-Id: 12345600@example.net
+
+
+
+Barnes Standards Track [Page 38]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ CSeq: 1 ACK
+ Content-Length: 0
+
+ /* RTP streams are established between UA1 and
+ UA-VM. UA-VM starts announcement for UA1 */
+
+Appendix C. Automatic Call Distribution Example
+
+ This scenario highlights an example of an Automatic Call Distribution
+ service, where the agents are divided into groups based upon the type
+ of customers they handle. In this example, the Gold customers are
+ given higher priority than Silver customers, so a Gold call would get
+ serviced even if all the agents servicing the Gold group (ACDGRP1)
+ were busy, by retargeting the request to the Silver Group. Upon
+ receipt of the call at the agent assigned to handle the incoming
+ call, based upon the History-Info header in the message, the
+ application at the agent can provide an indication that this is a
+ Gold call, from how many groups it might have overflowed before
+ reaching the agent, etc. and thus can be handled appropriately by the
+ agent.
+
+ For scenarios whereby calls might overflow from the Silver to the
+ Gold, clearly the alternate group identification, internal routing,
+ or actual agent that handles the call SHOULD not be sent to UA1.
+ Thus, for this scenario, one would expect that the Proxy would not
+ support the sending of the History-Info in the response, even if
+ requested by the calling UA.
+
+ As with the other examples, this is not prescriptive of how one would
+ do this type of service but an example of a subset of processing that
+ might be associated with such a service. In addition, this example
+ is not addressing any aspects of Agent availability, which might also
+ be done via a SIP interface.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 39]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2
+
+ | | | | |
+ |--INVITE F1-->| | | |
+ Supported:histinfo
+ | | | | |
+ | |--INVITE F2-->| | |
+ Supported:histinfo
+ History-Info: <sip:Gold@example.com>; index=1
+ History-Info: <sip:ACDGRP1@example.com>; index=1.1
+ | | | | |
+ | |<-302 F3------| | |
+ Contact: <sip:ACDGRP2@ACD.com>
+ | | | | |
+ | |--------INVITE F4---------->| |
+ History-Info: <sip:Gold@example.com>; index=1
+ History-Info: <sip:ACDGRP1@example.com>; index=1.1
+ History-Info: <sip:ACDGRP2@example.com>; index=1.2
+ | | | | |
+ | | | | |
+ | | | |INVITE F5>|
+ History-Info: <sip:Gold@example.com>; index=1
+ History-Info: <sip:ACDGRP1@example.com>; index=1.1
+ History-Info: <sip:ACDGRP2@example.com>; index=1.2
+ | | | | |
+ | | | |<-200 F6--|
+ | | | | |
+ | |<-200 F7--------------------| |
+ History-Info: <sip:Gold@example.com>; index=1
+ History-Info: <sip:ACDGRP1@example.com>; index=1.1
+ History-Info: <sip:ACDGRP2@example.com>; index=1.2
+ |<-200 F8------| | | |
+ < No History-Info included in the response due to Local Policy>
+ | | | | |
+ |--ACK F9--------------------------------------------->|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 40]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+Appendix D. Session via Redirect and Proxy Servers
+
+ In this scenario, Alice places a call to Bob using first a Redirect
+ server then a Proxy Server. The INVITE message is first sent to the
+ Redirect Server. The Server returns a 302 Moved Temporarily response
+ (F2) containing a Contact header with Bob's current SIP address.
+ Alice then generates a new INVITE with Bob's current SIP address
+ included in another History-Info entry. The INVITE is then sent to
+ Bob via the Proxy Server, with Bob receiving the complete History
+ information; the call then proceeds normally. The complete call flow
+ for this scenario, without the use of History-Info, is described in
+ Section 3.6 of the SIP Basic Call Flow Examples [RFC3665].
+
+ Alice Redirect Server Proxy 3 Bob
+ | | | |
+ | INVITE F1 | | |
+ |--------------->| | |
+ | 302 F2 | | |
+ |<---------------| | |
+ | ACK F3 | | |
+ |--------------->| | |
+ | INVITE F4 | |
+ |-------------------------------->| INVITE F5 |
+ | 100 F6 |--------------->|
+
+ Message Details
+
+ F1 INVITE Alice -> Redirect Server
+
+ INVITE sip:bob@biloxi.example.com SIP/2.0
+ Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
+ Max-Forwards: 70
+ From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
+ To: Bob <sip:bob@biloxi.example.com>
+ Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
+ CSeq: 1 INVITE
+ History-Info: <sip:bob@biloxi.example.com>; index=1
+ Contact: <sip:alice@client.atlanta.example.com>
+ Content-Length: 0
+
+ F2 302 Moved Temporarily Redirect Proxy -> Alice
+
+ SIP/2.0 302 Moved Temporarily
+ Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
+ ;received=192.0.2.1
+ From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
+ To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
+ Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
+
+
+
+Barnes Standards Track [Page 41]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ CSeq: 1 INVITE
+ History-Info: <sip:bob@biloxi.example.com>; index=1
+ Contact: <sip:bob@chicago.example.com;transport=tcp>
+ Content-Length: 0
+
+ F3 ACK Alice -> Redirect Server
+
+ ACK sip:bob@biloxi.example.com SIP/2.0
+ Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
+ Max-Forwards: 70
+ From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
+ To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
+ Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
+ CSeq: 1 ACK
+ Content-Length: 0
+
+ F4 INVITE Alice -> Proxy 3
+
+ INVITE sip:bob@chicago.example.com SIP/2.0
+ Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
+ Max-Forwards: 70
+ From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
+ To: Bob <sip:bob@biloxi.example.com>
+ Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
+ CSeq: 2 INVITE
+ History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
+ text="Moved Temporarily">; index=1,
+ <sip:bob@chicago.example.com>; index=2
+ Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
+ Content-Length: 0
+
+ F5 INVITE Proxy 3 -> Bob
+
+ INVITE sip:bob@client.chicago.example.com SIP/2.0
+ Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
+ Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
+ ;received=192.0.2.1
+ Max-Forwards: 69
+ Record-Route: <sip:ss3.chicago.example.com;lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
+ To: Bob <sip:bob@biloxi.example.com>
+ Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
+ CSeq: 2 INVITE
+ History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
+ text="Moved Temporarily">; index=1,
+ <sip:bob@chicago.example.com>; index=2,
+ <sip:bob@client.chicago.example.com>; index=2.1
+ Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
+
+
+
+Barnes Standards Track [Page 42]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+ Content-Length: 0
+
+ Detailed Call Flow continues per section 6.3 in [RFC3665].
+
+Editor's Address
+
+ Mary Barnes
+ Nortel
+ 2201 Lakeside Blvd
+ Richardson, TX USA
+
+ Phone: 1-972-684-5432
+ EMail: mary.barnes@nortel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes Standards Track [Page 43]
+
+RFC 4244 SIP Request History Information November 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Barnes Standards Track [Page 44]
+