diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4244.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4244.txt')
| -rw-r--r-- | doc/rfc/rfc4244.txt | 2467 |
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] + |