RFC 7044
An Extension to the Session Initiation Protocol (SIP) for Request History Information
RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information 💖
okay bestie, so this is RFC 7044 🎀 It's a Standards Track document from February 2014, written by M. Barnes (Polycom), F. Audet (Skype), S. Schubert (NTT), J. van Elburg (Detecon International Gmbh), and C. Holmberg (Ericsson). It has ISSN 2070-1721 and it obsoletes RFC 4244 🫶 That's the main thing to know from the title block. It's basically the glow-up for how SIP tracks where a request has been.
Internet Engineering Task Force (IETF) M. Barnes
Request for Comments: 7044 Polycom
Obsoletes: 4244 F. Audet
Category: Standards Track Skype
ISSN: 2070-1721 S. Schubert
NTT
J. van Elburg
Detecon International Gmbh
C. Holmberg
Ericsson
February 2014Abstract ✨
okay so the big idea here is a standard way to capture the history info attached to a SIP request 📞 This is what unlocks a bunch of enhanced services, because the receiving side can see how and why a request landed at a specific application or user. The document defines an optional SIP header field called History-Info for recording that history in requests. It also adds header field parameters for History-Info and Contact so the method used to determine a request's target gets tagged 🏷️ On top of that, there's a new value for the Privacy header field that anonymizes the values in History-Info. And yes, this one officially obsoletes RFC 4244 💅
Status of This Memo 🦋
this is an Internet Standards Track document, which means it's real, official stuff. It's a product of the Internet Engineering Task Force (IETF) and represents the community's consensus 🌸 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741. For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7044.
Copyright Notice 🌈
the legal bit, but make it cute 💅 Copyright (c) 2014 belongs to the IETF Trust and the people listed as authors, and all rights are reserved. The document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions. Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per that same license.
This document may also contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. Some of that material's copyright holders may not have let the IETF Trust allow modifications outside the IETF Standards Process. So unless you get a proper license from those holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🫶
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. History-Info Header Field Protocol Structure . . . . . . . . 7
5.1. History-Info Header Field Example Scenario . . . . . . . 10
6. User Agent Handling of the History-Info Header Field . . . . 12
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . 12
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . 12
6.3. Back-to-Back User Agent (B2BUA) Behavior . . . . . . . . 12
7. Proxy/Intermediary Handling of History-Info Header Fields . . 13
8. Redirect Server Handling of History-Info Header Fields . . . 13
9. Handling of History-Info Header Fields in Requests and
Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14
9.2. Sending a Request with History-Info . . . . . . . . . . . 14
9.3. Receiving a Response with History-Info or Request
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 15
9.4. Sending History-Info in Responses . . . . . . . . . . . . 16
10. Processing the History-Info Header Field . . . . . . . . . . 16
10.1. Privacy in the History-Info Header Field . . . . . . . . 16
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 16
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 17
10.2. Reason in the History-Info Header Field . . . . . . . . 18
10.3. Indexing in the History-Info Header Field . . . . . . . 19
10.4. Mechanism for Target Determination in the History-Info
Header Field . . . . . . . . . . . . . . . . . . . . . . 21
11. Application Considerations . . . . . . . . . . . . . . . . . 22
12. Application-Specific Usage . . . . . . . . . . . . . . . . . 24
12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . 24
12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14.1. Registration of New SIP History-Info Header Field . . . 26
14.2. Registration of "history" for SIP Privacy Header Field . 27
14.3. Registration of Header Field Parameters . . . . . . . . 27
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28
16.1. Backwards Compatibility . . . . . . . . . . . . . . . . 29
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . 31
17.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Request History Requirements . . . . . . . . . . . . 33
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 34
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . 351. Introduction ✨
lots of services that SIP is expected to support need to figure out why and how a SIP request got to a particular application 🔍 Some examples are sessions sent to call centers through "click to talk" SIP Uniform Resource Locators (URLs) on a web page, "call history/logging"-style services inside call management software for SIP user agents (UAs), and calls to voicemail servers 📱 SIP already gives you retargeting so requests can get routed to the apps you want. But SIP doesn't have a standard way to pass along the retargeting history, and that's the gap. This request history lets the receiving application learn how and why the request reached it 💜
so this document defines a SIP header field called History-Info, which is the standard mechanism for capturing request history so networks and end-users get loads of services 🦋 It also defines SIP header field parameters for History-Info and Contact to tag the method used to determine a request's target. The spec adds a value, "history", for the Privacy header field, and it defines a SIP option tag, "histinfo" 🎀
The History-Info header field is a building block for SIP-based apps and services 🧚 The requirements for this solution are in Appendix A, and example scenarios using History-Info are in [CALLFLOWS] 🌟
2. Conventions and Terminology 🎀
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 [RFC2119] 💅 These are the official requirement words, so pay attention to them.
"retarget" is the term for a SIP entity changing the Request-URI (Section 7.1 of [RFC3261]) in a request. It happens based on the rules for determining request targets in Section 16.5 of [RFC3261], and then the request gets forwarded as described in step 2 in Section 16.6 of [RFC3261]. That includes changing the Request-URI because of a location service lookup or redirect processing. It also covers internal changes to the URI inside a proxy/SIP intermediary before the request is forwarded 🔁
"location service", "forward", "redirect", and "AOR" (address-of-record) are used the same way as in [RFC3261] 🫶
"target user" means the human user tied to one or more particular AORs, in case that human has multiple aliases 👑
the references to the "domain for which the SIP entity/proxy/intermediary is responsible" line up with, and mean the same thing as, how [RFC3261] uses that terminology. Using History-Info in architectures or models outside the context of [RFC3261] is out of scope for this spec 🌸
3. Background ✨
SIP already gives you retargeting, which lets SIP requests get routed to specific applications, as defined in [RFC3261]. Here's the catch: when a request gets retargeted, the old routing info can be gone forever 😭. That lost info can be really important history, because it lets the elements the request gets retargeted to handle it in a locally defined, application-specific way. This document defines a mechanism for carrying that request history 🎀. Application-specific behavior is outside the scope of this specification, so that part is up to each app.
Other protocols already have apps that let the elements involved with a request find out how and why it got routed to a particular destination. A few examples, because they're iconic 💅:
- Web "referral" applications, where an app inside a web server figures out that a visitor came to the site through an "associate" site that earns a "referral" commission for sending that traffic 🛍️.
- Email relaying, where the recipient gets a detailed "trace of the path" of the message from the sender to the receiver, including the time of each relay 📬.
- Traditional telephony services like voicemail, call-center "automatic call distribution", and "follow me"-style services 📞.
Several of these apps already have their own mechanisms for getting the history info they need.
Request history info could also make basic SIP functionality better by providing:
- Some diagnostic information for debugging SIP requests 🔍.
- Capturing aliases and Globally Routable User Agent URIs (GRUUs) [RFC5627], which can be overwritten by a registrar or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record) upon receipt of the initial request 🧚.
- Facilitating the use of limited use addresses (minted on demand) and sub-addressing 🦋.
- Preserving service-specific URIs that can be overwritten by a downstream proxy, such as those defined in [RFC3087], and control of network announcements and Interactive Voice Response (IVR) with a SIP URI [RFC4240] 🌈.
4. Overview 🌸
The main thing request history info does is let the proxies and user agents (UAs) involved in processing a request know about the history or progress of that request 👑. The solution is to capture the Request-URIs, as a request gets retargeted, in a SIP header field called History-Info. That way, you keep the history of a request that would otherwise be lost during the normal SIP processing involved in retargeting it 💅.
The History-Info header field gets added to a request when a new request is created by a User Agent Client (UAC) or forwarded by a proxy, or when the target of a request changes. The same proxy or SIP intermediary can change a request's target multiple times, which is called 'internal retargeting' 🔁. A SIP entity that changes the target of a request in response to a redirect also carries along any History-Info header field from the initial request into the new request 🫶. The ABNF and detailed description of the History-Info header field parameters, along with examples, are in Section 5. Sections 6, 7, and 8 cover how SIP user agents, proxies, and redirect servers handle the History-Info header field in detail 💖.
This specification also defines three new SIP header field parameters, "rc", "mp", and "np", for the History-Info and Contact header fields. They tag the method by which the target of a request is determined 🏷️. You can find more on these header field parameters in Section 5.
It also defines a priv-value for the Privacy header, "history". It requires anonymization of all the History-Info header field entries in a request, or of a specific History-Info header field value (hi-entry), as described below 🙈. More detail is in Section 10.1.
Last but not least, a SIP option tag, "histinfo", is defined. Section 6.1 describes how to use this option tag ✨.
5. History-Info Header Field Protocol Structure 🎀
The History-Info header field defined in this specification covers usage in out-of-dialog requests or initial requests for a dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.), plus any non-100 provisional or final responses to those requests 💅.
Here's what gets captured in the History-Info header field entries for each target used when a request is forwarded:
hi-targeted-to-uri: A mandatory parameter for capturing the Request-URI for the specific request as it is forwarded 🎯.hi-index: A mandatory parameter for History-Info reflecting the chronological order of the information, indexed to reflect the forking and retargeting of requests 🌳. The format is a sequence of nonnegative integers separated by dots, showing the number of forward hops and retargets. This makes a tree representation of the request's history, with the lowest-level index being a leaf 🍃. By adding the new entries in chronological order (that is, after the existing entries per the details in Section 10.3), including the index, and by sending the messages over a secure transport, the ordering of the History-Info header fields in the request is assured 🔐. Applications can also pull out a bunch of metrics from the index values, like the total number of retargets or the total number of retargets from a specific branch 📊.hi-target-param: An optional parameter showing the mechanism by which the Request-URI captured in the hi-targeted-to-uri of the History-Info header field value (hi-entry) was determined. It's either an "rc", "mp", or "np" header field parameter, and each one is interpreted like this 🧩:"rc": The hi-targeted-to-URI represents a change in Request-URI, while the target user stays the same. This happens, for example, when the user has multiple AORs as an alias 👯. The "rc" header field parameter holds the value of the hi-index in the hi-entry whose hi-targeted-to-uri reflects the Request-URI that was retargeted."mp": The hi-targeted-to-URI represents a user other than the target user associated with the Request-URI in the incoming request that was retargeted. This happens when a request is statically or dynamically retargeted to another user represented by an AOR that isn't associated with the AOR of the original target user 🔀. The "mp" header field parameter holds the value of the hi-index in the hi-entry whose hi-targeted-to-uri reflects the Request-URI that was retargeted, which identifies the "mapped from" target."np": The hi-targeted-to-URI represents that there was no change in the Request-URI. This applies, for example, when a proxy just forwards a request to a next-hop proxy and loose routing is used 🫧. The "np" header field parameter holds the value of the hi-index in the hi-entry whose hi-targeted-to-uri reflects the Request-URI that was copied unchanged into the request represented by this hi-entry. That value will usually be the hi-index of this hi-entry's parent hi-entry.
- Extension (hi-extension): A parameter that allows for future optional extensions 🌱. As per [RFC3261], any implementation not understanding an extension MUST ignore it 🙅.
The ABNF syntax [RFC5234] for the History-Info header field and its header field parameters goes like this:
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = name-addr
hi-param = hi-index / hi-target-param / hi-extension
hi-index = "index" EQUAL index-val
index-val = number *("." number)
number = [ %x31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val
np-param = "np" EQUAL index-val
hi-extension = generic-paramThe ABNF definitions for "generic-param", "name-addr", "HCOLON", "COMMA", "SEMI", and "EQUAL" come from [RFC3261] 📚.
This document also extends the "contact-params" for the Contact header field, as defined in [RFC3261], with the "rc", "mp", and "np" header field parameters defined above 💜.
Besides the parameters in the ABNF, an hi-entry can also include a Reason header field and/or a Privacy header field. Both get included in the "headers" component of the hi-targeted-to-uri, as described below 🎀:
- Reason: An optional parameter for History-Info, reflected in the History-Info header field by including the Reason header field [RFC3326] in the hi-targeted-to-uri. A reason is included in the hi-targeted-to-uri of an hi-entry to reflect information received in a response to the request sent to that URI 📝.
- 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", as defined in this document. That can be done either inside the hi-targeted-to-uri or by adding the Privacy header field with a priv-value of "history" to the request 🕵️. The first case means that all the History-Info entries whose hi-targeted-to-uri has the same domain as the domain the SIP entity processing the message is responsible for MUST be anonymized prior to forwarding. The second case, where the Privacy header field is included in the hi-targeted-to-uri, means that a specific hi-entry MUST be anonymized 🫣.
Heads up, bestie: since both the Reason and Privacy parameters live in the hi-targeted-to-uri, those fields won't be available when the hi-targeted-to-uri is a Tel-URI [RFC3966] 📞💀.
Here are some examples of the History-Info header field format. The backslashes, CRLFs, and whitespace between the lines in these examples are only there for readability 👀. History-Info can be split across multiple lines thanks to the SWS (sep whitespace) that's part of HCOLON, COMMA, and SEMI, and there can be multiple History-Info header fields because of the rule in Section 7.3 of [RFC3261]. More detailed examples are in [CALLFLOWS] 🦋.
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1.1,\
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2;mp=1.1,\
<sip:45432@192.168.0.3>;index=1.3;rc=1.25.1. History-Info Header Field Example Scenario ✨
okay so this is an illustrative example of how History-Info gets used 🎀 (it's a teaching example, not a rule, but it shows the whole vibe)
Alice (sip:alice@atlanta.example.com) calls Bob (sip:bob@biloxi.example.com) 📞 Alice's proxy in her home domain (sip:atlanta.example.com) forwards the request to Bob's proxy (sip:biloxi.example.com). When the request lands at sip:biloxi.example.com, it does a location service lookup for bob@biloxi.example.com and swaps the target of the request for Bob's Contact URIs from normal SIP registration. So Bob is contacted on a PC client AND a phone at the same time 💻📱, and he answers on the PC client. iconic multitasking, Bob 💅
The big takeaway here is that without History-Info, Bob would basically "lose" the original target info, aka the initial Request-URI, including any parameters in it 😭 But he can recover it by finding the last hi-entry with an "rc" header field parameter 🕵️♀️ That "rc" parameter holds the index of the hi-entry that has the lost target info, which in this case is the sip:bob@biloxi.example.com hi-entry with index=1.1. Also, notice that the 200 response to Alice doesn't include an hi-entry for the fork to sip:bob@192.0.2.7 (index 1.1.1), because biloxi.example.com hadn't gotten a response from that fork yet when it sent the 200 OK that ended up reaching Alice. not me being like "wait, why not" 🙈
More detailed examples live in [CALLFLOWS] 📚
Note: This example uses loose routing procedures.
Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone
| | | | |
| INVITE sip:bob@biloxi.example.com;p=x | |
|--------------->| | | |
| Supported: histinfo | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| | | | |
| | INVITE sip:bob@biloxi.example.com;p=x |
| |--------------->| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| | | | |
| | | INVITE sip:bob@192.0.2.3|
| | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | | INVITE sip:bob@192.0.2.7|
| | |-------------------------->|
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.7>;index=1.1.2;rc=1.1
| | | 200 | |
| | |<---------------| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | 200 | | |
| |<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | | Proxy Cancels INVITE |
| | |<=========================>|
| 200 | | | |
|<---------------| | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| ACK | | | |
|--------------->| ACK | | |
| |--------------->| ACK | |
| | |--------------->| | Figure 1: Basic Call6. User Agent Handling of the History-Info Header Field 🎀
okay this section is all about the processing specific to UAs, which means User Agent Clients (UACs), User Agent Servers (UASs), and Back-to-Back User Agents (B2BUAs) 🫶 each one has its own job for the History-Info header.
6.1. User Agent Client (UAC) Behavior 📤
The UAC MUST include the "histinfo" option tag in the Supported header field in any out-of-dialog requests or initial requests for a dialog for which the UAC would like the History-Info header field in the response. When issuing a request, the UAC MUST follow the procedures in Section 9.2. In the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi-entries to populate the History-Info header field with, so the hi-index is set to 1 per Section 10.3. When receiving a response, the UAC MUST follow the procedures in Section 9.3.
If the UAC generates further forks of the initial request (either because it acted on a 3xx response or because of internally directed forking to multiple destinations), the successive requests add hi-entries with hi-indexes of 2, 3, etc. 🌈
6.2. User Agent Server (UAS) Behavior 📥
When receiving a request, a UAS MUST follow the procedures defined in Section 9.2. When sending a response other than a 3xx response, a UAS MUST follows the procedures defined in Section 9.4. When sending a 3xx response, the UAS MUST follow the procedures defined for a redirect server per Section 8. An application at the UAS can make use of the cached hi-entries as described in Section 11. 💅
6.3. Back-to-Back User Agent (B2BUA) Behavior 🔁
A B2BUA MAY follow the behavior of a SIP intermediary, per Section 7, as an alternative to following the behavior of a UAS per Section 6.2 or a UAC per Section 6.1. When it acts as an intermediary, a B2BUA carries forward hi-entries received in requests at the UAS to requests being forwarded by the UAC, and also carries forward hi-entries in responses received at the UAC to the responses forwarded by the UAS, subject to privacy considerations per Section 10.1. the B2BUA is lowkey doing a lot of carrying 🧚
7. Proxy/Intermediary Handling of History-Info Header Fields 🦋
this section covers the procedures for proxies and other SIP intermediaries when they handle the History-Info header fields, for each of these scenarios:
- Receiving a Request: An intermediary MUST follow the procedures in Section 9.1 for the handling of hi-entries in incoming SIP requests.
- Sending a Request: For each outgoing request relating to a target in the target set, the intermediary MUST follow the procedures of Section 9.2.
- Receiving a Response or Timeout: An intermediary MUST follow the procedures of Section 9.3 when a SIP response is received or a request times out.
- Sending a Response: An intermediary MUST follow the procedures of Section 9.4 for the handling of the hi-entries when sending a SIP response.
sometimes an intermediary retargets a request more than once before forwarding it 👀 So the request gets retargeted to a SIP entity that is "internal" to the intermediary first, and then the same intermediary retargets it to an external target. A typical example is a proxy that first retargets a request to a different user (so it maps to a different AOR), and then forwards it to a registered contact bound to that same AOR. In this case, the intermediary MUST add an hi-entry for (each of) the internal target(s) per the procedures in Section 9.2. The intermediary MAY include a Reason header field in the hi-entry with the hi-targeted-to-uri that has been retargeted. Note that this is shown in the INVITE (F6) in the example entitled "Sequentially Forking (History-Info in Response)" in [CALLFLOWS] 🎬
8. Redirect Server Handling of History-Info Header Fields 🧭
a redirect server MUST follow the procedures in Section 9.1 when it receives a SIP request, and MUST follow the procedures in Section 9.4 when it sends a SIP response. When generating the Contact header field in a 3xx response, the redirect server MUST add the appropriate "mp", "np", or "rc" header field parameter to each Contact header field as described in Section 10.4, if applicable. ✨
9. Handling of History-Info Header Fields in Requests and Responses 💌
this section is the procedures for SIP entities handling the History-Info header field in SIP requests and responses. it's the core of the whole thing, so pay attention bestie 🤓
9.1. Receiving a Request 📨
When receiving a request, a SIP entity MUST keep a copy of the hi-entries from the incoming request. This document describes that copy as a cache containing the hi-entries associated with the request. The hi-entries MUST be added to the cache in the order in which they were received in the request.
If the Request-URI of the incoming request does not match the hi-targeted-to-uri in the last hi-entry (aka the previous SIP entity that sent the request did not include a History-Info header field), the SIP entity MUST add an hi-entry to the end of the cache, on behalf of the previous SIP entity. This is done as follows, before moving on to Section 9.2.
- The SIP entity MUST set the hi-targeted-to-uri to the value of the Request-URI in the incoming request. If the Request-URI is a Tel-URI, it SHOULD be transformed into a SIP URI (per Section 19.1.6 of [RFC3261]) before being added as an hi-targeted-to-uri.
- If privacy is required, the SIP entity MUST follow the procedures of Section 10.1.
- The SIP entity MUST set the hi-index parameter as described in Section 10.3.
- The SIP entity MUST NOT include an "rc", "mp", or "np" header field parameter.
9.2. Sending a Request with History-Info 📤✨
When sending a request, a SIP entity MUST include all the hi-entries from the cache that was created per Section 9.1. On top of that, the SIP entity MUST add a new hi-entry to the outgoing request, but it MUST NOT add that hi-entry to the cache at this time. The hi-entries in the outgoing request's History-Info header field represent the preorder of the tree of hi-entries, meaning they're ordered by the lexicographic ordering of the hi-indexes 🌳 The new hi-entry gets populated like this:
- hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value of the Request-URI of the current (outgoing) request. If the Request-URI is a Tel-URI, it SHOULD be transformed into a SIP URI (per Section 19.1.6 of [RFC3261]) before being added as an hi-targeted-to-uri.
- privacy: If privacy is required, the procedures of Section 10.1 MUST be followed.
- hi-index: The SIP entity MUST include an hi-index for the hi-entry as described in Section 10.3.
- rc/mp/np: The SIP entity MUST include an "rc", "mp", or "np" header field parameter in the hi-entry, if applicable, per the procedures in Section 10.4. 🫶
9.3. Receiving a Response with History-Info or Request Timeouts ✨
okay so this is the part where a SIP entity gets a response that isn't a 100 🙈 or the request just times out, and it has to update its cache. there are three steps, and bestie, they're kind of iconic 💅
Step 1: Add hi-entry to cache 🌸
The SIP entity MUST add the hi-entry that was added to the request that received the non-100 response or timed out to the cache, if it was not already cached. The hi-entry MUST be added to the cache in ascending order as indicated by the values in the hi-index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but before 1.2.2 or 1.3). Order matters, babe 📈
Step 2: Add Reason header field 🦋
If the response is not a 100 or 2xx response, the SIP entity adds one or more Reason header fields to the hi-targeted-to-uri in the (newly) cached hi-entry reflecting the SIP response code in the non-100 or non-2xx response, per the procedures of Section 10.2. It's giving "tag it with the reason" energy 🎀
Step 3: Add additional hi-entries 🧚
The SIP entity MUST also add to the cache any hi-entries received in the response that are not already in the cache. This can happen when the entity that generated the non-100 response retargeted the request before generating the response. As per Step 1, the hi-entries MUST be added to the cache in ascending order as indicated by the values in the hi-index parameters of the hi-entries. so organized, I'm obsessed 😭
Now, a little heads-up 👀 The cache (and the request or response) does not contain hi-entries for requests that haven't gotten a non-100 response yet, so there can be gaps in indices (e.g., 1.2 and 1.4 could be present but not 1.3). Gaps are normal, not a bug. Main character energy 💜
Also, if a request went through one or more intermediaries that don't support RFC 4244 or this document, there can be duplicate indices (because of forking) 🍓 Those get added to the right spot in the cache in the order they were received. ✨
9.4. Sending History-Info in Responses 💌
When a SIP entity sends a response other than a 100, it MUST include all the cached hi-entries in the response, subject to the privacy consideration in Section 10.1.2. There's one exception 🙈 If the received request contained no hi-entries and there is no "histinfo" option tag in the Supported header field, the SIP entity MUST NOT include History-Info in the response. no History-Info, no problem, periodt 💅
10. Processing the History-Info Header Field 👑
These subsections describe how to process the History-Info header field. The procedures apply to SIP entities like proxies/intermediaries, redirect servers, or user agents. So basically, if you're a SIP box in the middle of things, this is your guide 🫶
10.1. Privacy in the History-Info Header Field 🔒
The privacy requirements for this document are described in Appendix A.2. Section 10.1.1 covers inserting the Privacy header field (defined in [RFC3323]) to show what privacy applies to the History-Info header field entries. Section 10.1.2 covers how to apply privacy to a request or response being forwarded, based on whether the Privacy header field is there. It's a whole privacy arc 🌈
10.1.1. Indicating Privacy 🎀
As with other SIP headers described in [RFC3323], the hi-targeted-to-uris in the History-Info header field can accidentally reveal info about who started the request. So the UAC needs a way to say "hey, these hi-targeted-to-uris need privacy protection." The UAC uses the Privacy header field to say that privacy applies to all the hi-entries in the request, like this:
- If the UAC includes a
Privacyheader field with a priv-value of"header"in the request, then the UAC SHOULD NOT include a priv-value of"history"in thePrivacyheader field in the request. - If the UAC includes any priv-values other than
"header"in thePrivacyheader field, then the UAC MUST also include a priv-value of"history"in thePrivacyheader field in the request. - If the UAC doesn't include any priv-values in the
Privacyheader field in the request, then the UAC MUST add aPrivacyheader field, with a priv-value of"history", to the request. In this case, the UAC MUST NOT include a priv-value of"critical"in thePrivacyheader field in the request.
Also, the History-Info header field can reveal general routing and diverting info inside an intermediary that the intermediary wants to keep private 🙊 In that case, the intermediary MUST construct a Privacy header field with the single priv-value of "history", and include it in the hi-targeted-to-uri for each new hi-entry the intermediary created whose hi-targeted-to-uri it wants to protect. Note that the priv-value in the Privacy header of the incoming request doesn't necessarily decide whether the intermediary includes a Privacy header field in the hi-entries. For example, even if the incoming request's Privacy header had a priv-value of "none", the proxy can still set a priv-value of "history" in the Privacy header field inside the hi-targeted-to-uri.
Finally, the UAS might not want to reveal the final target to the originator 🥺 In that case, the UAS MUST include a Privacy header field with a priv-value of "history" in the hi-targeted-to-uri in the last hi-entry, in the response. As noted above, the UAS of the request MUST NOT use any other priv-values in the Privacy header field included in the hi-entry. Only "history", no extras 💖
10.1.2. Applying Privacy 🌸
When a SIP message is forwarded to a domain the SIP intermediary isn't responsible for, a Privacy Service at the edge of that domain applies the right privacy. It bases this on the Privacy header field value in the message header, or in the "headers" component of the hi-targeted-to-uri in the individual hi-entries.
If there's a Privacy header field in the message header of a request or response, with a priv-value of "header" or "history", then all the hi-targeted-to-uris (in the hi-entries for the domain the SIP intermediary is responsible for) get anonymized by the Privacy Service. The Privacy Service MUST change any hi-targeted-to-uris in these hi-entries that haven't been anonymized (shown by their domain not being "anonymous.invalid") to anonymous URIs with a domain of anonymous.invalid, as recommended in Section 4.1.1.3 of [RFC3323]. As defined in Section 4.1.1.2 of [RFC3323], the recommendations of [RFC3261] for anonymizing the URI Username SHOULD be followed (i.e., "anonymous" in the user portion of the URI). If there's a Privacy header field in the "headers" component of the hi-targeted-to-uri in the hi-entries, then the Privacy header field value MUST be removed from the hi-entry. Once all the right hi-entries are anonymized, the Privacy Service MUST remove the priv-value of "history" from the Privacy header field in the message header of the request or response. If there are no priv-values left in the Privacy header field, the Privacy Service MUST remove the Privacy header field from the request or response per [RFC3323]. Clean, right? ✨
If there's no Privacy header field in the message header of the request or response being forwarded, but there's a Privacy header field with a priv-value of "history" in the "headers" component of any of the hi-targeted-uris in the hi-entries for the domain a SIP intermediary is responsible for, then the Privacy Service MUST update those hi-targeted-to-uris as described above. Any other priv-values in the Privacy header field in the "headers" component of the hi-targeted-to-uris in the hi-entries MUST be ignored. In any case, the Privacy Service MUST remove the Privacy header field from the "headers" component of the hi-targeted-to-uris in the hi-entries before forwarding. Clean-up crew, all the way 🧹💅
10.2. Reason in the History-Info Header Field 🧚
A Reason header field gets added when a hi-entry is added to the cache because a SIP response came back that's neither a 100 nor a 2xx response, as described in Section 9.3. The SIP entity MUST include a Reason header field, containing the SIP Response Code, in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. On top of that, if the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST also include those Reason header fields in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache. Reason headers, all in the right place 🎀
If a request has timed out (instead of being explicitly rejected), the SIP entity MUST update the cache as if the request had received a SIP error response code of 408 "Request Timeout". Timeouts get treated like a 408, no drama ⏰
A request can get multiple responses that are neither 100 nor 2xx responses, and those can carry (or, for responses without Reason headers and for timeouts, imply) multiple, possibly duplicated, reason-values to apply to an hi-targeted-to-uri. In these situations, the SIP entity creating the History-Info header value would choose the appropriate Reason header field value. The creator gets to pick the right one, so trust the process 🫶
A SIP entity MAY also include a Reason header field (in the "headers" component of an hi-targeted-to-uri) that contains the URI of a request that was retargeted as a result of internal retargeting. Optional but iconic 🌈
If additional Reason header field parameters are defined in the future per [RFC3326], the use of those Reason header field parameters for the History-Info header field MUST follow the same rules as described above. Future-proofing, babe, that's the vibe ✨
10.3. Indexing in the History-Info Header Field ✨
okay bestie, the hi-index is how we keep everything in order 🦋 The SIP entity MUST add an hi-index to each hi-entry. Per the syntax in Section 5, it's a series of nonnegative integers separated by dots, like 1.1.2 💖 Each dot is one SIP forwarding hop. The number right after each dot tells you the order the request got retargeted at that hop. The highest number at each hop is how many entities the request got retargeted to there (aka the number of branches) when that hi-entry was made 🌸 So the indexing builds a logical tree, and the hi-entries show up in preorder of that tree. it's giving family tree 🌳
The first index in a series of History-Info entries MUST be set to 1. If a SIP entity (intermediary or UAS) adds a first hi-entry on behalf of the previous hop, the hi-index MUST be set to 1 too. For each forward hop (aka each new level of indexing), the last integers of the new requests' hi-indexes MUST be generated starting at 1 and going up by 1 for each additional request ✨
Here are the basic rules, bestie 💅
- Forwarding a request without changing the target: the hi-index shows the branch getting longer. The SIP entity MUST read the value from the History-Info header field in the received request and MUST add another level of indexing by appending the dot delimiter followed by an initial value of 1 for the new level. For example, if the hi-index in the last History-Info header field in the received request is
1.1, a proxy adds an hi-entry with an hi-index of1.1.1and forwards the request 🧚 - Retargeting within a processing entity, first instance: for the first retargeting inside a processing entity, the SIP entity MUST calculate the hi-index the same way it does for basic forwarding 🎀
- Retargeting within a processing entity, subsequent instance: for each later retargeting by the same SIP entity, it MUST calculate and add the hi-index for each new branch by incrementing the rightmost value from the hi-index in the last hi-entry. Following the example above, the next request forwarded by that same SIP entity would have
1.1.2💜 - Retargeting based upon a response: when the retargeting happens because of a specific response (like a 302), the SIP entity MUST calculate the hi-index as in rule 3. The rightmost value of the hi-index MUST be incremented, because a new branch gets created ✨ For example, if the hi-index in the History-Info header field of the sent request is
1.2and the response is a 302, the hi-index for the new hi-targeted-to-URI is1.3🦋 - Forking requests: if the request gets forwarded in multiple forks (sequentially or in parallel), the SIP entity MUST set the hi-index for each hi-entry of each forked request using the rules above, and every new request gets its own unique index. Each index MUST be sequentially assigned. For example, if the index in the last History-Info header field in the received request is
1.1, this processing entity starts its index at1.1.1for the first fork,1.1.2for the second, and so on 👑 (See Figure 1 for an example.) Heads up: with parallel forking, only the hi-entry for that fork goes in the request, because no response can have come back yet for any of the parallel forked requests 🙈 - Missing entry: if the request clearly has a gap in the hi-entry (the last hi-entry and the Request-URI differ), the entity adding an hi-entry MUST add a single index with a value of
0(the nonnegative integer zero) before adding the appropriate index for the action being taken. For example, if the index of the last hi-entry in the received request was1.1.2, there's a missing hi-entry, and the request is being forwarded to the next hop, the resulting index will be1.1.2.0.1😭
When a proxy that doesn't support History-Info forks requests, different entities can end up generating hi-entries with the same index. Each entity that supports History-Info gets a forked request with the same hi-index, and each one adds.0before its own index. So in the example above, each next-hop entity generates an hi-index of1.1.2.0.1🫶
10.4. Mechanism for Target Determination in the History-Info Header Field 🌈
This spec defines three header field parameters: rc, mp, and np 🍓 The rc and mp parameters tell you how a request's new target was figured out. The np parameter means the target didn't change. Every parameter holds an index, and that index is the hi-index of the hi-entry whose hi-targeted-to-uri is the Request-URI that got retargeted.
The SIP entity MUST determine which specific parameter goes in the hi-target-param of the History-Info header field, as targets are added to the target set. That follows the procedures in Section 16.5 of [RFC3261], or Section 8.1.3.4 of [RFC3261] when it's retargeting to a Contact URI from a 3xx response. In that second case, the specific header field parameter in the Contact header field is the one the hi-entry uses when the request is retargeted. If the Contact header field doesn't have an rc or mp header field parameter, the SIP entity MUST NOT include an rc or mp header field parameter in the hi-target-param of the hi-entry when retargeting to that Contact URI from a 3xx response. Why? The redirect server is the only one that knows how the target got determined 🕵️♀️ Also, np doesn't apply to redirection at all, fyi.
Based on the criteria below, the SIP entity (intermediary or redirect server) picks which header field parameter (rc, mp, or np) to use 💅
rc: the Request-URI changed, but the target user from the original Request-URI (before retargeting) was kept.mp: the target came from a mapping to a user other than the target user tied to the Request-URI being retargeted.np: the target didn't change, and the associated Request-URI stayed the same.
There are two ways the mp parameter can come about, and they're kinda different 🦋
- The receiving entity did the mapping on its own authority. In that case, the mp-value is the parent index of the hi-entry's index.
- The mapping happened because a 3xx response was received. In that case, the mp-value is an earlier sibling of the hi-entry's index, or a descendant of an earlier sibling. The index is the one for the downstream request that got the 3xx response ✨
11. Application Considerations ✨
okay so History-Info is literally such a flexible building block 🧱 that intermediaries and UAs can use it for a whole bunch of services 💅. Before any application touches the History-Info header field parameters, the SIP entity that processes the hi-entries MUST evaluate them and check whether there are any gaps 🕳️. The SIP entity MUST be prepared to handle messages whose hi-entries show evidence of "gaps", which are situations that reveal not all of the forks of the request were recorded in the hi-entries 😭. Gaps happen when the request goes through intermediaries that don't support the History-Info header field, and you can spot them by hi-entries with a nonnegative integer of 0, like 1.1.0.1 👀. Gaps can also show up with parallel forking if there's an outstanding request when the SIP entity sends a message. And gaps can even introduce duplicate values for the hi-index when a proxy that doesn't support History-Info forks a request 🙈. If gaps are detected, the SIP entity MUST NOT treat this as an error, but it SHOULD indicate to any applications that there are gaps. The interpretation of the info in the History-Info header field depends on the specific application, so an application might need some special handling where there are gaps 🌸.
Here are some categories of info that applications can use 🦋:
- Complete history information, e.g., for debugging or other operational and management aspects, optimization of determining targets to avoid retargeting to the same URI, etc. This info is relevant to proxies, UACs, and UASs 🧚.
- Hi-entry with the index that matches the value of the
rcheader field parameter in the last hi-entry with anrcheader field parameter in the request received by a UAS, i.e., the last AOR that was retargeted to a contact based on an AOR-to-contact binding 🎯. - Hi-entry with the index that matches the value of the
mpheader field parameter in the last hi-entry with anmpheader field parameter in the hi-target-param in the request received by a UAS, i.e., the last Request-URI that was mapped to reach the destination 📍. - Hi-entry with the index that matches the value of the
rcheader field parameter in the first hi-entry with anrcheader field parameter in the request received by a UAS. Note that this would be the original AOR if all the entities involved support theHistory-Infoheader field and there is an absence of anmpheader field parameter prior to thercheader field parameter in the hi-target-param in theHistory-Infoheader field. However, there's no guarantee that all entities will support History-Info, so the hi-entry that matches the value of thercheader field parameter of the first hi-entry with anrcheader field parameter in the hi-target-param within the domain associated with the target URI at the destination is more likely to be useful 💖. - Hi-entry with the index that matches the value of the
mpheader field parameter in the first hi-entry with anmpheader field parameter in the request received by a UAS. Note that this would be the original mapped URI if all entities supported theHistory-Infoheader field. However, there's no guarantee that all entities will support History-Info, so the hi-entry that matches the value of thempheader field parameter of the first hi-entry with anmpheader field parameter within the domain associated with the target URI at the destination is more likely to be useful 🫶.
In many cases, applications care most about the info within one or more particular domains, so only a subset of the info is required 🎀.
Some applications can use multiple types of info at once 👑. For example, an Automatic Call Distribution (ACD) / call center application that uses the hi-entry with an index that matches the value of the mp header field parameter in the first hi-entry with an mp header field parameter can also display other agents. Those agents are reflected by hi-entries prior to hi-entries with an rc header field parameter, and they're the ones the call was targeted to before it reached the current agent. This could let the agent decide how to forward or reroute the call if necessary, like avoiding agents who weren't available for whatever reason, etc. Iconic multitasking 💅✨.
Since support for the History-Info header field is optional, a service MUST define default behavior for requests and responses that don't contain History-Info header fields 🙃. For example, an entity may receive an incomplete set of hi-entries, or hi-entries that aren't tagged appropriately with an hi-target-param, in the case of entries added by entities that only comply with RFC 4244. This may not impact some applications (e.g., debug), but it could require some applications to make some default assumptions in this case. For example, in an ACD scenario, the application could select the oldest hi-entry with the domain associated with the ACD system and display that as the original called party 🧐. Depending on how and where the request may have been retargeted, the complete list of agents the call was targeted to may not be available 💀.
12. Application-Specific Usage 🎀
The following are possible (non-normative) application-specific usages of History-Info 🌈.
12.1. PBX Voicemail 📞
A voicemail system (VMS) typically needs the original called party info to figure out the right mailbox, so an appropriate greeting can be provided and the appropriate party gets notified of the message 💌.
The original target is determined by finding the first hi-entry tagged with rc, then using the hi-entry referenced by the index of the rc header field parameter as the target for determining the appropriate mailbox. This hi-entry is used to populate the target URI parameter as defined in [RFC4458]. The VMS can look at the last hi-entry and find the target of the mailbox by looking at the URI entry in the target URI parameter in the hi-entry 🔍.
This example usage doesn't work properly when forwarding happens before the call reaches the company 🙅♀️. In that case, you don't pick the first hi-entry with an rc value. You need to pick the first hi-entry with an rc value following an mp entry. Further detail for this example can be found in the call flow entitled "PBX Voicemail Example" in [CALLFLOWS] 📖.
Note that if there's no entry tagged with rc, a VMS can follow the procedures, as defined in [RFC4458], for the "Interaction with Request History Information" 🧩.
12.2. Consumer Voicemail 📱
The voicemail system in this environment typically needs the last called party info to figure out the right mailbox, so an appropriate greeting can be provided and the appropriate party gets notified of the message 💜.
The last target is determined by finding the hi-entry referenced by the index of the last hi-entry tagged with rc, which is used to figure out the appropriate mailbox. This hi-entry is used to populate the target URI parameter as defined in [RFC4458]. The VMS can look at the last hi-entry and find the target of the mailbox by looking for the target URI parameter in the hi-entry. Further detail for this example can be found in the call flow entitled "Consumer Voicemail Example" in [CALLFLOWS] ✨.
In the case where there's no entry tagged with rc, a VMS can follow the procedures, as defined in [RFC4458], for the "Interaction with Request History Information" 🌸.
13. Security Considerations 🔐
The security requirements for this specification are specified in Appendix A.1. Pay attention to this one, bestie 👀.
This document defines a header field for SIP. Using the Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the overall confidentiality of the History-Info header fields (SEC-req-4) is strongly RECOMMENDED 🔒. If TLS is NOT used, the intermediary MUST ensure that the messages are only sent within an environment that's secured by other means, or that the messages don't leave the intermediary's domain 🚧. This means History-Info has at least the same level of security as other headers in SIP that are inserted by intermediaries. With TLS, History-Info header fields are no less, nor no more, secure than other SIP header fields, which generally have even more impact on the subsequent processing of SIP sessions than the History-Info header field 💅.
Note that while using the SIPS scheme (as per [RFC5630]) 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 🚨.
When it comes to keeping hi-entries private, the same security considerations as those described in [RFC3323] apply 🕵️♀️. The Privacy Service that's defined in [RFC3323] MUST also support the new Privacy header field priv-value of history, and it anonymizes hi-entries in the case of a priv-value of header, as described in Section 10.1.2. Not optional, periodt 🙅♀️.
14. IANA Considerations 📋
IANA registrations have been implemented or updated as detailed in the following subsections 🗂️.
This document obsoletes [RFC4244] but uses the same SIP header field name, Privacy header field, and Option tag. References to [RFC4244] in the IANA "Session Initiation Protocol (SIP) Parameters" registry (<http://www.iana.org/assignments/sip-parameters>) have been replaced with references to this document 🔄.
14.1. Registration of New SIP History-Info Header Field 🦋
This document defines a SIP header field name, History-Info, and an option tag, histinfo. The following updates have been made to <http://www.iana.org/assignments/sip-parameters> 💖.
The following row has been updated in the "Header Fields" sub-registry:
Header Name Compact Form Reference
----------- ------------ ---------
History-Info none [RFC7044]The following has been updated in the "Option Tags" sub-registry:
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header field, [RFC7044]
this option tag indicates the UAC supports
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.14.2. Registration of "history" for SIP Privacy Header Field 🎀
okay bestie, this is the part where we register a brand new priv-value 💅 This document defines a priv-value for the SIP Privacy header field: history ✨ The updates below were made to the "SIP Privacy Header Field Values" sub-registry at <http://www.iana.org/assignments/sip-parameters> for the SIP Privacy header field:
Privacy
Type Description Registrant Reference
------ ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC7044]
History-Info header mary.ietf.barnes@gmail.com
field(s)14.3. Registration of Header Field Parameters 🦋
this spec adds some new SIP header field parameters 🫶 They go into the "Header Field Parameters and Parameter Values" sub-registry at <http:/www.iana.org/assignments/sip-parameters> (yes, that single slash is how it's written, not my typo 😭):
Header Field Parameter Name Predefined Values Reference
------------- -------------- ----------------- ---------
History-Info mp No [RFC7044]
History-Info rc No [RFC7044]
History-Info np No [RFC7044]
Contact mp No [RFC7044]
Contact rc No [RFC7044]
Contact np No [RFC7044]15. Acknowledgements 💜
Jonathan Rosenberg et al. made the document that brought in extra use cases, which is what made the new header parameters necessary for capturing how a Request-URI gets determined 🧚 The authors want to shout out the constructive feedback from Ian Elz, Paul Kyzivat, John Elwell, Hadriel Kaplan, Marianne Mohali, Brett Tate, and Dale Worley 🙌 John Elwell also dropped excellent suggestions on document structure, and Dan Romascanu did the Gen-ART review ✨
Mark Watson, Cullen Jennings, and Jon Peterson put serious input into the early work that led to [RFC4244] 👑 The authors also thank Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Sebastien Garcin for their constructive feedback on [RFC4244] 🌸
The authors also appreciate the significant input from Rohan Mahy on some of the normative parts of the ABNF for [RFC4244], especially security and the index (both whether it was needed and what format it should take) 🔥
16. Changes from RFC 4244 🌈
okay so the tea is that this RFC replaces [RFC4244] ☕
Deployment experience with [RFC4244] over the years showed a bunch of issues, so this update was warranted 🙈
- In order to make [RFC4244] work in "real life", you have to make "assumptions" about how History-Info gets used. For example, lots of implementations filter out a bunch of entries and only keep specific ones, like the first and last redirection. Since vendors use different rules, this causes big interoperability issues 💀
- [RFC4244] is overly permissive and evasive about recording entries, which causes interoperability issues 😭
- The examples in the call flows had errors and were confusing because they often assumed "loose routing" 🙃
- [RFC4244] has a lot of repetitive and unclear text because it mixes requirements in with the solution 📝
- [RFC4244] gratuitously mandates TLS on every hop. No existing implementation enforces this rule. Whether to use TLS is a general SIP issue, not an issue with [RFC4244] per se 🔐
- [RFC4244] doesn't include clear procedures for delivering current target URI information to the UAS when the Request-URI is replaced with a contact 🎯
- [RFC4244] doesn't allow for marking History-Info entries so user agents can process them easily 🦋
Here's the rundown of the functional changes between this spec and [RFC4244] ✨
- Added header field parameters to capture the specific method by which a target is determined, to make life easier for users of the History-Info header field entries. A specific header field parameter is captured for each of the target URIs as the target set is determined (per Section 16.5 of [RFC3261]). The header field parameter is used in both the History-Info and the Contact header fields 💖
- Added a way to indicate a gap in History-Info by adding a nonnegative integer of "0" 🍓
- Instead of recommending that entries be removed for certain values of the Privacy header field, the entries are anonymized 🕶️
- Updated the security section to match the security recommendations for other SIP header fields inserted by intermediaries 🛡️
- Removed Appendix B ("Voicemail"), since a separate call flow document is being published as a companion to this one 🎀
The first two changes are meant to make application usage of the History-Info header field easier, get rid of the need to make assumptions based on the order of the entries, and make sure the most complete set of information is available to applications 🧚
Also, the editorial changes condensed and clarified the text, moved the requirements to an appendix, and removed the inline references to the requirements. The examples were simplified and updated to reflect the protocol changes. Several of the call flows in the appendix got moved into a separate document that includes extra use cases needing the new header field parameters 📚
16.1. Backwards Compatibility 🫶
this spec is backwards compatible because [RFC4244] allows for new optional parameters 🙌 It adds an optional SIP header field parameter to the History-Info and Contact header fields. Entities that haven't implemented this spec will ignore these parameters. However, per [RFC4244], an entity will not remove these parameters from an hi-entry. While entities compliant to this document and [RFC4244] must be able to recognize gaps in the hi-entries, this document requires that an index of "0" be used in this case. By comparison, [RFC4244] recommended (but did not require) the use of "1". However, since the ABNF in [RFC4244] defines the index as a DIGIT, "0" would be a valid value. So an [RFC4244] implementation should not have an issue if it receives hi-entries added by intermediaries compliant to this document ✨
As for the behavior of the UACs, UASs, and intermediaries, these additional normative changes were made:
UAC behavior
- Inclusion of option tag by UAC has changed from SHOULD to MUST.
- Inclusion of hi-target-entry along with hi-index has changed from MAY/RECOMMEND to MUST/MUST.
- Behavior surrounding the addition of hi-target-entry based on a 3xx response has changed from MAY/SHOULD to MUST.
None of these behavior changes will cause any backward or forward compatibility issues 🦋
UAS behavior
- Inclusion of hi-entry in response has changed from SHOULD to MUST.
Since the entity receiving the response with hi-entry expected it with SHOULD, this change won't cause any backward compatibility issues 💅
Proxy/redirect server behavior
- Inclusion of the History-Info header field when forwarding the request has changed from SHOULD to MUST.
- Association of Reason with timeout/internal reason has changed from MAY to MUST.
- Inclusion of hi-index has changed from RECOMMENDED to MUST.
- Inclusion of hi-entries in the response has changed from SHOULD to MUST.
None of the above behavior changes impact backwards compatibility, since they only strengthen normative behavior to improve interoperability 🌸
In cases where an entity compliant to this document receives a request containing hi-entries that are compliant only to RFC 4244 (i.e., the hi-entries don't contain any of the new header field parameters), the entity MUST NOT add any of the new header field parameters to the hi-entries. The hi-entries MUST be cached and forwarded like any other entries, as specified in Section 9.1. Just like entities compliant to RFC 4244, applications must be able to function when information is missing, as specified in Section 11 🚨
17. References 📚
17.1. 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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC
4244, November 2005.17.2. Informative References 🔎
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable
User Agent URIs (GRUUs) in the Session Initiation
Protocol (SIP)", RFC 5627, October 2009.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
using SIP Request-URI", RFC 3087, April 2001.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC
4458, April 2006.
[CALLFLOWS] Barnes, M., Audet, F., Schubert, S., Elburg, H., and C.
Holmberg, "Session Initiation Protocol (SIP) History-Info
Header Call Flow Examples", Work in Progress, November
2013.A. Request History Requirements 🎀
Okay bestie, this list is the wishlist for a "Request History" capability, and every item matters 📝
CAPABILITY-req: The "Request History" capability lets proxies and UAs handling a request know about the history/progress of that request 🦋 It's already kind of built in when a retarget happens because of a SIP redirect, but it's still deemed useful for non-redirect retargeting scenarios too, and that's so real 💅GENERATION-req: "Request History" info gets generated when the request is retargeted ✨- A. Sometimes more than one retarget can happen inside the same proxy, which is giving multitasking 🧚 A proxy MUST also generate "Request History" information for the 'internal retargeting'.
- B. An entity (UA or proxy) retargeting in response to a redirect or REFER MUST include any "Request History" information from the redirect/REFER in the new request 🫶
ISSUER-req: A UA or a proxy can generate "Request History" info, and it can be passed in both requests and responses 🌸CONTENT-req: The "Request History" info for each occurrence of retargeting shall include the following 💜- A. the new URI or address the request is in the process of being retargeted to
- B. the URI or address the request was retargeted from, and whether the retarget URI was an AOR
- C. the mechanism by which the new URI or address was determined
- D. the reason for the Request-URI or address modification
- E. chronological ordering of the "Request History" information (so it stays in order, periodt 👑)
REQUEST-VALIDITY-req: "Request History" applies to requests not sent within an early or established dialog, like INVITE, REGISTER, MESSAGE, and OPTIONS 📬BACKWARDS-req: "Request History" info may be passed from the generating entity backwards towards the UAC. This is needed so services can inform the calling party about dialog establishment attempts 📞FORWARDS-req: "Request History" info may also be included by the generating entity in the request, if it's forwarded onwards 🚀
A.1. Security Requirements
Okay, security time, and this one is serious 🔐 The "Request History" info is inserted by a network element that's retargeting a request, so it's a slightly different problem from the basic SIP header problem and needs specific consideration. It's recognized that these security requirements can be generalized to a basic requirement of being able to secure information that's inserted by proxies.
The potential security problems include the following:
- A rogue application could insert a bogus Request History-Info entry, either by adding an additional
hi-entryas a result of retargeting or by entering invalid information 😱 - A rogue application could rearrange the "Request History" information to change the nature of the end application or to mislead the receiver of the information 💀
- 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:
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 🔍SEC-req-2: The ordering of the "Request History" information must be preserved at each instance of retargeting 📋SEC-req-3: The entity receiving the information conveyed by the "Request History" must be able to authenticate the entity providing the request 🪪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.
A.2. Privacy Requirements
Since the Request-URI that gets captured could inadvertently reveal information about the originator, there are general privacy requirements that MUST be met 🫣
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's retargeted 🎭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 🧾PRIV-req-3: "Request History" information subject to privacy shall not be included in outgoing messages unless it is protected as described in [RFC3323] 🛡️
Authors' Addresses
- Mary Barnes
- Polycom
- TX
- US
- EMail:
mary.ietf.barnes@gmail.com
- Francois Audet
- Skype
- EMail:
francois.audet@skype.net
- Shida Schubert
- NTT
- EMail:
shida@ntt-at.com
- Hans Erik van Elburg
- Detecon International Gmbh
- Sternengasse 14-16
- Cologne
- Germany
- EMail:
ietf.hanserik@gmail.com
- Christer Holmberg
- Ericsson
- Hirsalantie 11, Jorvas
- Finland
- EMail:
christer.holmberg@ericsson.com
📦 where this page comes from
- ietf: rfc7044 2014-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms