Summary

  • SIP History-Info preserves the Request-URIs that supporting intermediaries expose as an initial request is retargeted or forked. Its dot-separated indexes form an ordered tree; rc, mp and np classify changes to a contact, a different target user or only the next hop.
  • The tree is optional, can contain legacy or inferred gap entries, can omit branches that were still pending, and can be anonymized for legitimate privacy. TLS protects signaling against outsiders but does not make every trusted intermediary truthful.
  • A defensible routing decision therefore needs the header plus the rule, actor, lookup input, branch state, privacy transformation, downstream transaction and observed service outcome. The history can explain a detour; it cannot authorize one.

A complete-looking answer to the wrong question

Imagine a regulated support number that is supposed to remain inside one approved service group. A complaint arrives: the caller reached an external contractor. Operations retrieves a SIP trace. Its History-Info entries form a clean tree from the published number, through a corporate address, to the contractor's application. The dashboard labels the route “verified” because every index parses and the last target returned 200.

The trace may be genuine and still fail to answer the dispute.

It shows which Request-URIs participating systems placed in the history visible at that observation point. It does not show which administrator activated the forwarding rule, whether the underlying directory was current, whether the enterprise approved that contractor, whether another branch was hidden or still pending, whether a privacy service removed a target, whether an on-path intermediary rewrote an entry, whether media reached a person, or whether the contractor delivered the promised service.

The error is not using the header. The error is making it speak for decisions outside its scope.

RFC 7044 defines History-Info as an optional SIP extension for request history. It captures how and why an initial or out-of-dialog request arrived at a destination by preserving Request-URIs that ordinary retargeting would otherwise overwrite. The mechanism is narrow. Its restraint is what makes it useful.

The address that disappears when routing works

Under RFC 3261, a proxy performs target determination and forwards a request toward the result. A location service can resolve a public address to a registered device. A redirect can point the client or proxy elsewhere. A PBX can apply a forwarding rule. Each new Request-URI tells the next hop where the request is going now. Without another record, it does not necessarily tell that hop where the request was aimed before.

RFC 7044 calls the relevant operation retargeting: an entity changes the Request-URI according to its target-determination rules and forwards the request. History-Info saves the prior targeted-to URIs so later applications can reconstruct more of the path.

That distinction matters. The proxy's running rule chose the next target. The header recorded an account of the choice. The IETF specified the grammar. The IANA SIP registry allocated History-Info, the histinfo option tag, the history privacy value and the rc, mp and np parameters. Neither registration nor syntax approved the local forwarding policy.

The scope is also bounded. History-Info concerns initial or out-of-dialog requests. It is not a universal ledger for every message after a dialog exists. A call record that combines the invitation, later in-dialog signaling, RTP, recording, agent state and charging into one “history” has built an application model. RFC 7044 supplies one component of that model, not the whole.

A tree whose numbers are positions, not clocks

Every history entry has a targeted-to URI and an hi-index. The index is a sequence of nonnegative integers separated by dots. A descendant extends its parent's index. Forked requests become sibling positions. The list is emitted in preorder so a recipient can rebuild the branching shape.

This is more expressive than a flat forwarding list. A linear list can make two simultaneous branches look like two consecutive policy decisions. The tree preserves that both descended from a common target.

Yet an index is not a timestamp. It does not measure latency, establish which independent clock acted first, or prove that a branch with a later lexical position completed later. Multiple header fields may carry portions of the same ordered list. A collector that treats the digits as time has manufactured evidence.

The three mechanism parameters add a second kind of structure:

  • rc says the Request-URI changed while the target user stayed the same, as when an address-of-record resolves to a contact or alias;
  • mp says the request was mapped to a different target user or address-of-record;
  • np says the next hop changed while the Request-URI did not, as with loose routing.

Their values point back into the tree. They are descriptions by the inserting node, not verdicts. rc does not prove that two identities belong to the same accountable person. mp does not prove that the mapping was permitted. np does not attest that the next hop was trustworthy. Well-formed classification and legitimate authority are different questions.

Why a valid tree can be incomplete

Support for the extension is optional. The histinfo option tag is advertised in Supported; RFC 7044 does not use it with Require or Proxy-Require to compel every hop. A request can cross a node that does not know the extension, a boundary that filters it, or an older implementation that preserves RFC 4244 entries without the newer mechanism parameters.

Legacy forwarding has a deliberate limit. A node must not invent rc, mp or np for a decision it did not observe. Missing parameters may therefore mean old or partial evidence, not “no retargeting.”

RFC 7044 also addresses an observable gap. If a recipient sees an incoming Request-URI that differs from the final history entry, it adds an entry on behalf of the previous entity. It can record that the target changed. It cannot state the missing entity's mechanism, because it did not witness the rule. A gap entry is an honest lower-confidence fact.

Forking introduces another incompleteness. The RFC shows a branch returning 200 while a sibling is still pending. The successful response cannot carry a future result from the unresolved branch. A trace captured from the winner may be correct and still omit activity known at the forking proxy.

Privacy can hide more. RFC 4244's older examples show that when an upstream participant cannot see a private branch, it may retry a target it does not know was already attempted. This is not an argument against privacy. It is proof that applications need safe defaults for partial history.

The right claim is therefore specific: “At this observation point, this message contained this ordered set of entries.” The wrong claim is global: “This is every place the request went.”

Reason explains a response, not the institution

History entries can carry Reason information in the URI headers component. RFC 3326 defines SIP and Q.850 reason namespaces and allows multiple protocol reasons. RFC 7044 uses the information for relevant non-success responses and timeouts.

That can explain a routing branch. One target reported busy; another timed out; the request moved on. The value still has limits. A protocol cause is not a human motive. It does not prove why a policy selected that target, whether the response was truthful, whether a customer asked to be forwarded, or why the business service failed. Recipients may ignore Reason for protocol processing, and an unprotected value can be altered or removed.

The RFC 7044 errata registry lists a Reported technical question about exactly which response classes should receive Reason information. It also contains Reported indexing and cross-reference items, plus Rejected records. “Reported” is not “Verified.” Implementers should test the peers they operate and preserve the registry status rather than silently turning a proposal into the standard.

Privacy changes the visible truth on purpose

Routing history can reveal personal devices, alternate identities, internal departments, voicemail destinations and network topology. RFC 3323 explains why SIP privacy often needs intermediary help: routing elements add information that an endpoint cannot remove before those elements use it.

RFC 7044 adds Privacy: history. Protection can cover the relevant history or a particular entry. A domain can protect internal routing even if the incoming request said no privacy was required. A receiving user agent can prevent the originator from learning the final target. A boundary privacy service can replace a URI with an anonymous address under anonymous.invalid before the data leaves.

Anonymization is not automatically tampering in the pejorative sense. It can be correct execution of a privacy policy. It does mean a downstream auditor has a deliberately reduced view. The evidence should say which boundary transformed the entry, under which policy, and what protected mapping exists for authorized review. It should not call the visible list exhaustive.

Privacy authority and routing authority are separate. The system allowed to conceal an internal destination is not necessarily the system allowed to choose that destination. Combining both actions into one “route normalized” event prevents accountability for either.

TLS secures a path of trusted editors

RFC 7044 strongly recommends TLS, or use within a secure environment. SIPS can stop arbitrary off-path parties from modifying the message under the SIP trust model. It cannot make every on-path intermediary honest.

The header receives the same protection as other SIP headers: no more and no less. Intermediaries read it because they must append or transform it. A malicious or compromised intermediary on the trusted path can delete, reorder or rewrite entries. RFC 7044 says the mechanism does not prevent or detect such behavior.

“The call used TLS” and “the history is an end-to-end attestation” are therefore different claims. A serious record preserves the TLS peer, certificate result, trust domain, message fingerprint and observation point for each copy. It also reconciles the header with logs on both sides of important boundaries.

This is a familiar governance problem. Transport security protects the channel between accountable systems. It does not decide whether each accountable system is entitled to make the statement it transmits.

The application decides which part of the tree matters

RFC 7044 warns applications not to assume complete support and requires them to define behavior for missing or incomplete data. It also notes that different services may need different entries.

A PBX and a consumer voicemail service can choose different rc positions to identify the relevant called party. If a request was forwarded before it reached the enterprise, a naive “first rc is our user” rule can select an identity outside the company. RFC 4458 shows the same application boundary for voicemail: target and cause information may be found in the current Request-URI or in History-Info depending on support and routing.

No universally correct selector follows from the tree alone. The application must declare its purpose, the domains it trusts, its handling of gaps and privacy, and the policy used when entries disagree.

This local interpretation is not a defect. It is the minimum-specification discipline Heng Lu describes: share enough structure for interoperation, then leave ordinary future decisions with the participants who possess the context and bear the result. The danger begins when a local selector is hidden and marketed as the protocol's own conclusion.

An evidence chain that can survive a dispute

Start with the message, not the dashboard summary. Preserve the method, incoming and outgoing Request-URI, Call-ID, CSeq, Via branch, timestamp, observation point and a controlled fingerprint of the header bytes.

Preserve the tree exactly as received and exactly as emitted: entry order, hi-index, URI, rc/mp/np reference, Reason, privacy marker, legacy status, parse result and any gap inserted on behalf of another node. Never fill a missing mechanism with a guess.

Then record the decision that the header does not carry: target-rule ID and version, lookup source and result, redirect response, candidate set, selected target, fallback order, branch creation and actor. Bind the service identity and tenant to the administrator or delegated process that owned the rule. Record activation, approval and emergency override.

Keep trust and privacy as their own layer. Which domain received and sent the message? Which TLS peer was authenticated? Which privacy request applied? Which service anonymized what? Where is the protected mapping, who may access it and for how long?

Execution and outcome complete the chain: each branch transaction, response, timeout, CANCEL, selected branch, B2BUA leg map, dialog creation, media, reached application, recording, charging and complaint result.

Useful contradictions must remain visible. A winner can omit a known sibling. An rc claim can conflict with a tenant boundary. A Reason can disagree with downstream application logs. A syntactically perfect B2BUA history can lack a leg mapping. A 200 can coexist with failed media. The system that flattens these conflicts into “route verified” has given itself authority by compression.

Sources