Summary

  • RFC 5379 mapped each SIP priv-value to particular headers and SDP fields. The token expressed requested treatment; it did not authorize a privacy service to scrub every field that looked sensitive.
  • Fields outside the target matrix could still require action for a different reason, such as an invalidated Identity signature or a Call-ID mapping that had to be restored in Replaces or Target-Dialog. The authority for that action did not come from the Privacy token.
  • The durable operating chain is: request, target classification, independent policy or protocol basis, executed mutation, preserved semantics, and observed privacy. No one link proves the others.

The well-intentioned scrubber broke the transfer

Consider a privacy gateway installed with an admirably simple instruction: if a message asks for privacy, remove or anonymize anything that could identify a person or domain. It sees Privacy:user, changes the From and Call-ID fields, notices another dialog identifier inside Replaces, rewrites that too, and removes a Route value because the host name looks revealing. The outgoing INVITE looks cleaner. The subsequent transfer fails.

The post-incident record could still look reassuring. The Privacy header was present. The gateway ran. Several fields changed. No software error was logged. Yet none of those facts proves that the gateway executed the request that the sender actually made, preserved the protocol's correlations, or delivered a private call.

RFC 5379 was written because early SIP privacy specifications left enough ambiguity for implementations to disagree about which information each privacy value covered. It did not invent another privacy system. Published in February 2010 as an Informational Independent Stream contribution, it expressly said it was describing the practical operation of mechanisms from RFC 3323, RFC 3325, and RFC 4244 and was not adding new normative behavior.

Its most important contribution was therefore not a new command. It was a boundary around old commands.

One header carried several different requests

The SIP Privacy header could contain values with different objects. user concerned information inserted by the user. header concerned network-added signaling information. session concerned information carried in the session description. id addressed P-Asserted-Identity in the RFC 3325 trust-domain mechanism. history addressed History-Info. none refused privacy treatment, while critical affected what happened when requested functions could not be supplied.

Those words did not form one ascending scale from weak to strong. They selected different surfaces. Treating them as a generic “more privacy” switch erased the distinctions that made interoperable execution possible.

RFC 5379 made the distinction concrete in a matrix. Call-ID, Call-Info, Contact, From, History-Info, In-Reply-To, Organization, P-Asserted-Identity, Record-Route, Referred-By, Reply-To, Server, Subject, User-Agent, Via, and Warning did not all receive the same treatment. Some rows called for deletion, some for not adding a field, some for anonymization, and some for no action under a particular value. Direction also mattered: a field could require treatment in a request, a response, or both.

The SDP side was narrower still. Under Privacy:session, the c, m, o, i, u, e, and p lines were the identified surfaces. Session privacy was not a warrant to improvise across every SIP header merely because the implementation associated the word “session” with the call as a whole.

The matrix turns privacy into a typed operation. A request is not enough. The executor needs the requested value, the message direction, the field type, the prescribed action, and the conditions under which that action is safe.

A blank cell was a boundary, not an invitation

RFC 5379 said that headers and parameters absent from its tables were non-targets of the listed privacy values. It then named six important examples: Identity/Identity-Info, Path, Replaces, Route, Service-Route, and Target-Dialog. They should not be anonymized or modified merely because a priv-value appears in a Privacy header.

This is a subtle limit. Some of those fields plainly can reveal information. Path may expose a visited or administrative domain. Route may name proxies. Identity-Info can refer to a signer's certificate. A system trained to equate “possibly sensitive” with “authorized to erase” will treat the list as an oversight.

But sensitivity is evidence about risk, not authority over the field. The field may carry a routing instruction, a correlation key, or integrity evidence whose operational purpose survives the user's privacy request. The request must be interpreted through the target definition, not expanded by the gateway's intuition.

Path illustrates the point. It can disclose domain information, yet it exists so a request can reach a registered user agent in a visited domain. Hiding it without a viable replacement can destroy reachability. Route is even more direct: it forces a request through a set of proxies. Arbitrary anonymization means the route no longer routes.

Service-Route belongs to the registrar-side registration mechanism, not automatically to the user's privacy scope. Replaces and Target-Dialog identify other dialogs. Their values can be sensitive, but erasing or casually anonymizing them can break transfer, pickup, or dialog-targeting behavior.

The governing question is therefore not “does this field look private?” It is “what authority applies to this field in this message, and what semantic obligation must remain true after action?”

Non-target did not mean untouchable

The opposite simplification is equally dangerous. A team might encode the non-target list as an absolute prohibition and refuse to modify those fields under any condition. RFC 5379 did not support that conclusion either.

Identity and Identity-Info show why. The historical RFC 4474 mechanism protected the From, To, Call-ID, CSeq, Date, Contact, and message body with a signature. A privacy service performing legitimate user, header, or session treatment could change protected material and thereby invalidate the signature. Identity was not a target of the Privacy value. Nevertheless, leaving a now-invalid Identity field in place would misrepresent the message. Removal could be required because integrity evidence had become false, not because the privacy request directly targeted Identity.

That distinction preserves provenance. The audit record should say: the Privacy value authorized a change to field A; that change invalidated integrity object B; the service removed B under the integrity rule. If the record merely says “Privacy:user removed Identity,” later operators cannot distinguish a valid dependency consequence from an overbroad scrubber.

The document's RFC 4474 discussion is now historical—RFC 4474 was obsoleted by RFC 8224—but the control lesson remains current. Derived evidence can become invalid when its protected inputs change. A system must revoke or regenerate the evidence for that reason, while retaining the original authority chain.

Call-ID created an obligation that outlived the triggering message

Call-ID exposes the deeper problem. When a privacy service changes a Call-ID, the act creates two versions of one dialog identity. The service must retain the old and new values and translate corresponding references across later messages. In-Reply-To, Replaces, a replaces parameter, and Target-Dialog can all carry the correlated identifier.

The later message may not contain a Privacy header at all. It may arrive from another party. The service may need to restore or translate the value anyway. That action is not a fresh execution of Privacy:user; it is payment of a state obligation created by the earlier mutation.

RFC 5379's transfer examples make the consequence visible. A privacy service changes C1 to C2 on the initial INVITE. A REFER or later INVITE then carries C1 or C2 inside Replaces. If the relevant message misses the same service, or if the service does not translate the correlated value, the replacement dialog can fail. The message remains syntactically valid while the intended operation becomes impossible.

This is why a local rewrite cannot be governed as a local event. The decision must include the future messages that will rely on the changed identifier, the path needed to observe them, the lifetime of the mapping, and the failure mode when the service is absent. A privacy action creates operational debt.

The debt also exposes an ownership problem. The component that mutates Call-ID cannot declare success merely because its own outbound message passes validation. It owns the correlation it changed until the protocol no longer depends on it. A deployment that cannot maintain that responsibility should reconsider the mutation rather than export an invisible failure to another component.

Local policy remained a separate source of authority

RFC 5379 allowed implementation and network policy to influence how target information was obscured. It also acknowledged that some sensitive non-target information might need treatment regardless of the requested level. That flexibility was not permission to rewrite the meaning of the Privacy header.

A provider may have a topology-hiding rule. A trust domain may have a rule for P-Asserted-Identity. A security service may remove invalid integrity material. A correlation engine may restore Route or dialog values after an earlier transformation. Each action can be legitimate, but each has a different issuer, purpose, scope, and failure contract.

Combining them into one “privacy applied” flag destroys accountability. If a call breaks, the operator cannot tell whether the user's request, provider policy, integrity repair, or correlation logic caused the change. If information leaks, the same flag cannot show which field was in scope or which observer still saw it.

The correct record is compositional. For every mutation, store the triggering authority, target field, before-and-after value or protected digest, dependency created, service identity, and result. A local policy should identify itself as local policy. A repair should identify the earlier transformation it repairs. The user request should remain intact as evidence of what was asked, not be made to absorb every action performed nearby.

Privacy was an outcome with an observer

A processed message can still fail the privacy objective. The target party may no longer see a caller identity while the privacy service still does. An IP address in media may disclose a location. A downstream intermediary may receive a field the implementation forgot. A signature removal may reveal that a transformation occurred. These are different exposure surfaces.

Therefore “privacy succeeded” requires an observer and a claim. Which identity or related fact was to be withheld? From which party? During which messages and media flows? What retained state could reconnect the anonymous presentation to the originator? Which logs or operational systems remained able to do so?

RFC 5379 did not promise a universal privacy verdict. Its matrix helped implementations perform specific functions consistently. The distinction is essential: protocol conformance can support an outcome without proving the outcome in every deployment.

For an operator, the strongest test is a path test, not a configuration screenshot. Capture the message before and after each privacy service. Exercise registration, initial dialog setup, responses, transfer, callback, hold, and teardown. Verify both absence of the protected disclosure at the chosen observer and continuity of the functions the user still expects.

The guideline itself had a bounded status

RFC 5379's status is part of the evidence. It was an Informational document from the Independent Stream. Its authors said the RFC 2119 language was derived from existing normative RFCs and that the document added no new normative behavior.

An implementation can use the guideline to resolve ambiguity and improve interoperability. It should not describe RFC 5379 as though it independently created every obligation in its tables. The underlying authority belongs to the relevant standards-track or extension specification, while the guideline supplies an organized reading of how the pieces fit.

Two of those historical references also moved. RFC 4244 was obsoleted by RFC 7044, and RFC 4474 was obsoleted by RFC 8224. That does not erase RFC 5379's architectural lesson. It does require current operators to follow the successor documents rather than converting a 2010 table into timeless deployment policy.

The IANA SIP Parameters registry supplies another distinct receipt: what names and values are registered. Registration supports shared syntax. It does not prove that a service implements the value, applies it correctly, maintains the correlation state, or achieves the user's privacy objective.

A receipt chain for scoped privacy

An auditable privacy service can preserve the following chain:

  • the original message, direction, and requesting party;
  • the Privacy header and each individual value;
  • the current specification governing that value;
  • the target-matrix row selected for each field;
  • any local policy applied outside the requested target;
  • the exact mutation, deletion, non-addition, or relay substitution;
  • integrity evidence invalidated or regenerated by the change;
  • identifier mappings and their required lifetime;
  • subsequent messages that consumed the mapped values;
  • routing, dialog, transfer, and media outcomes;
  • disclosure tests for each relevant observer;
  • unsupported-value and partial-failure behavior.

The chain prevents three false inferences. A token does not prove authority over every field. A mutation does not prove semantic success. A successful call does not prove that the intended information was withheld.

This is the broader governance lesson. A coordination artifact is strongest when it remains modest about what it records. The Privacy header records a request. The table records its defined scope. The service log records an attempted action. The call trace records execution. An observer-specific test records the outcome. None should be promoted into the others.