Summary

  • RFC 3323 treated privacy as selective concealment from particular parties, not as a promise that a SIP request carried no identifying information.
  • Its privacy service could hide headers yet remain necessary to restore dialog routing state; the trust boundary moved, rather than vanished.

Anonymity had an audience

In 2002, SIP privacy was not a single switch between “identified” and “anonymous.” RFC 3323 defined privacy in terms of information withheld from one or more parties in a dialog. A caller might want the destination not to see a real name while still allowing a trusted service to know who initiated the request. Another deployment might conceal network details from the user-facing recipient. The audience mattered as much as the field.

That distinction explains the document’s otherwise counterintuitive example: an anonymous From value did not mean that the request could contain no usable address. The specification recommended anonymous.invalid for an anonymous SIP URI, but the dialog still needed a route by which in-dialog requests could reach the right endpoint. A message could hide a person-facing identity and retain operationally necessary Contact, Via, Record-Route, or session information. Privacy was a controlled view over protocol state, not erasure of that state.

The service that hid information had to remember it

RFC 3323 separated user-level privacy from network-provided privacy. The Privacy header could request user, header, or session treatment; none prohibited the service from applying privacy actions, while critical made unavailable requested treatment a reason to fail the request rather than silently weaken it. Those tokens expressed policy intent. They did not authenticate the caller, authorize a call, encrypt media, or establish that every intermediary honored the request.

Header privacy exposed the mechanism’s operating cost. A privacy service could act as a back-to-back user agent, remove or rewrite identifying headers, replace a Contact address with its own, and preserve the original routing values locally. When later dialog messages returned, it had to restore the information needed to continue the exchange. The recipient saw less; the service held more state and became a privileged intermediary. This was not anonymity from the service.

Session privacy was more demanding still: it required a B2BUA and a media middlebox or traffic anonymizer. Because that service became part of the communication path, RFC 3323 cautioned against session privacy without end-to-end media protection such as SRTP. The warning is architectural, not a claim that deployments universally used SRTP or that the RFC measured privacy outcomes.

Privacy changed the control surface

The RFC’s lasting historical point is that hiding an identifier can increase dependence on the component that performs the hiding. A service must decide what to strip, retain, rewrite, and restore; it must also be trusted with the dialog’s continuation state. The document therefore made the privacy service an explicit control point instead of pretending that a header edit alone delivered anonymity.

RFC 3261 supplies the SIP dialog and route-set context. RFC 3325 later specifies asserted identity inside a trusted network, and expressly does not define a general identity model across trust domains. These documents address adjacent boundaries, not a universal privacy solution. RFC 3323 does not prove adoption, interoperability, or protection against every observer. It shows a design choice: reduce what one party learns while preserving enough protocol state for the call to continue—and name the intermediary that must make that bargain work.

Sources