An Extension to the Session Initiation Protocol (SIP) for Request History Information
obsoletes
- rfc-4244 — An Extension to the Session Initiation Protocol (SIP) for Request History Information
Extracted elements (28)
Rather than removing hi-entries when privacy is requested (as RFC 4244 recommended), RFC 7044 anonymizes them. This preserves the structural information (number of hops, branching) while hiding sensitive URI content, allowing applications to still detect gaps and retargeting patterns without revealing user identity.
RFC 7044 changes several normative levels from RFC 4244 from SHOULD/MAY to MUST (e.g., UAC inclusion of histinfo, proxy forwarding of History-Info, inclusion in responses) to improve interoperability. RFC 4244's blanket TLS mandate was removed as overspecified; instead, History-Info security is treated the same as other intermediary-inserted SIP headers.
The 'rc', 'mp', and 'np' header field parameters were added in RFC 7044 (absent in RFC 4244) because deployment showed that implementations were making incompatible assumptions about which hi-entries were relevant (e.g., filtering to first/last redirection). Explicit tagging of the target-determination mechanism eliminates the need for such guesswork and reduces interoperability issues.
RFC 7044 is backwards compatible with RFC 4244 because RFC 4244 allows optional parameters and its ABNF permits '0' as a valid DIGIT. Entities compliant only to RFC 4244 will ignore the new 'rc', 'mp', 'np' parameters but MUST NOT remove them. An RFC 7044 entity receiving RFC 4244-only hi-entries MUST NOT add new parameters to those entries.
When a request traverses an intermediary that does not support History-Info, a gap appears in the hi-entry sequence. Such gaps are indicated by inserting a '0' integer (e.g., 1.1.2.0.1). Additionally, non-supporting proxies can cause duplicate hi-index values when forking; entities MUST handle duplicate indices without treating them as errors.
A B2BUA MAY follow the behavior of a SIP intermediary (Section 7) instead of strict UAC/UAS behavior, carrying forward hi-entries from received requests into forwarded requests and from received responses into forwarded responses, subject to privacy constraints.
A redirect server MUST follow Section 9.1 on receiving a request and Section 9.4 on sending a response, and MUST add the appropriate 'mp', 'np', or 'rc' parameter to each Contact header field in a 3xx response where applicable.
A SIP entity MUST add an hi-index to each hi-entry following these rules: forwarding without target change appends '.1' to the current index; subsequent forks by the same entity increment the rightmost integer; the first index is always 1; and a gap (missing entry) is represented by inserting '.0' before the new index.
A SIP entity MUST include an 'rc', 'mp', or 'np' header field parameter in an hi-entry, if applicable, based on whether the Request-URI changed with same target user (rc), mapped to a different user (mp), or was forwarded unchanged (np). The parameter value is the hi-index of the retargeted parent entry.
A UAC MUST include the 'histinfo' option tag in the Supported header field in any out-of-dialog or initial dialog request for which it wants History-Info returned in the response.
Applications MUST evaluate hi-entries for gaps (indicated by a '0' in the index or duplicate indices from non-supporting intermediaries). Gaps MUST NOT be treated as errors; applications SHOULD indicate gap presence to higher-layer logic.
If the UAC includes priv-values other than 'header' in the Privacy header, it MUST also include 'history'. If no Privacy header is included at all, the UAC MUST add one with 'history'. If 'header' is included, the UAC SHOULD NOT also include 'history'.
On receiving a non-100 response or a request timeout, a SIP entity MUST (Step 1) add the hi-entry for the timed-out/responded request to the cache, (Step 2) add a Reason header field to that hi-entry unless the response is 2xx, and (Step 3) add any hi-entries from the response not already in the cache, all in ascending hi-index order.
The Privacy Service MUST anonymize hi-targeted-to-uris for the responsible domain when a 'header' or 'history' priv-value is present in the message-level Privacy header, changing unanonymized URIs to '[email protected]'. After anonymizing, the Privacy Service MUST remove the 'history' priv-value and, if no priv-values remain, the Privacy header field itself.
When a non-100, non-2xx response is received, the SIP entity MUST include a Reason header field containing the SIP response code in the hi-targeted-to-uri of the last cached hi-entry. If a request times out, the entity MUST treat this as a 408 response for Reason purposes.
When receiving a request, a SIP entity MUST keep a copy (cache) of all hi-entries from the incoming request in the order received. If the Request-URI does not match the last cached hi-targeted-to-uri, the entity MUST add an hi-entry on behalf of the previous hop before proceeding.
When sending a non-100 response, a SIP entity MUST include all cached hi-entries in the response, subject to privacy constraints. If the received request contained no hi-entries and no 'histinfo' in Supported, the entity MUST NOT include History-Info in the response.
When sending a request, a SIP entity MUST include all cached hi-entries plus a new hi-entry for the current outgoing Request-URI, with hi-targeted-to-uri set to the outgoing Request-URI, the correct hi-index, and the appropriate rc/mp/np parameter. The new hi-entry MUST NOT be added to the cache until a non-100 response is received.
The hi-targeted-to-uri values can reveal retargeting paths and user identities. The Privacy Service defined in RFC 3323 MUST also support the 'history' priv-value and anonymize hi-entries by replacing user-portion with 'anonymous' and domain with 'anonymous.invalid'. Privacy header fields embedded in hi-targeted-to-uris MUST be removed after processing.
The 'histinfo' SIP option tag is defined. A UAC includes it in the Supported header field to signal willingness to receive History-Info in responses. It is never used in Require or Proxy-Require because History-Info support is optional.
The History-Info header field captures the Request-URIs as a SIP request is retargeted, preserving routing history that would otherwise be lost. Each entry (hi-entry) contains a mandatory hi-targeted-to-uri (the Request-URI at that hop) and a mandatory hi-index (chronological ordering reflecting forking and retargeting).
The 'history' priv-value for the SIP Privacy header field is defined. When present in the message header, it directs the Privacy Service to anonymize all hi-targeted-to-uris in hi-entries belonging to the responsible domain. When present inside the hi-targeted-to-uri headers component of a specific hi-entry, only that entry is anonymized.
Three header field parameters — rc, mp, and np — tag how a target was determined. 'rc' means the Request-URI changed but the target user is the same (alias/contact binding); 'mp' means retargeting mapped to a different user (call forward); 'np' means the Request-URI was copied unchanged (loose routing). Each parameter value is the hi-index of the parent hi-entry.
IANA SIP Parameters registry updated: (1) 'History-Info' added to Header Fields sub-registry with no compact form; (2) 'histinfo' added to Option Tags sub-registry; (3) 'history' added to SIP Privacy Header Field Values sub-registry; (4) parameters 'mp', 'rc', 'np' added for both History-Info and Contact header fields in the Header Field Parameters sub-registry. All reference RFC 7044.
Three threat classes exist: (1) rogue insertion of bogus hi-entries, (2) rearrangement of history information to mislead receivers, and (3) deletion of history entries. Mitigations rely on secure transport (TLS/SIPS) and trust in path intermediaries; no cryptographic signing of individual entries is defined.
TLS is strongly RECOMMENDED to ensure confidentiality of History-Info header fields. Without TLS, the intermediary MUST ensure messages remain within a secured environment or do not leave its domain. Malicious intermediaries on the path could arbitrarily delete, rewrite, or insert hi-entries; this specification does not attempt to prevent or detect such attacks.
The hi-index tree tracks forwarding state: index '1' is the root (initial request). Each new forwarding hop appends a level (e.g., 1 → 1.1 → 1.1.1). Parallel forks at the same hop increment the last digit (1.1.1, 1.1.2, ...). A response triggers caching the outgoing hi-entry; a timeout triggers caching with a synthetic 408 Reason. Gaps from non-supporting intermediaries are marked with a '0' segment.
The History-Info header field ABNF: `History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)`, where each hi-entry is a name-addr followed by optional hi-param (hi-index, hi-target-param, or hi-extension). The hi-index is a dot-separated sequence of nonneg integers (e.g., 1.1.2); hi-target-param is one of rc, mp, or np, each carrying an index-val reference.