Summary

  • RFC 3323 treated privacy as a relationship between an identity, an observer and an intermediary: a caller could be anonymous to the destination while still known to a privacy service or authentication system.
  • Its critical preference made failure explicit: if requested privacy could not be provided, the request should be rejected rather than forwarded with an identity unexpectedly exposed.

The intermediary knew what it concealed

The recommended anonymous From form looked decisive: an Anonymous display name paired with the reserved anonymous SIP domain. It stopped an ordinary destination from learning the caller’s reusable address of record from that field. Yet a SIP dialog needed more than a From value. Contact and Via carried functional routing information. SDP could disclose an address for session traffic. Authentication commonly revealed identity to at least one party. A direct end-to-end exchange could not hide the participants’ network addresses from each other.

RFC 3323 therefore described several different privacy relationships. A user might hide identity from the destination but disclose it to intermediaries. Another might conceal information from some intermediaries while sending protected identity material to the final recipient. A third might seek concealment from both. None of these states can be represented honestly by a single anonymous=true flag.

Network-provided privacy required a logical privacy service. The user entrusted an intermediary to remove or rewrite identifying headers and, for session privacy, to stand in the media path. The service gained operational power because it retained the knowledge or reachability that it hid from someone else. Anonymous to the callee could therefore mean identifiable to the service provider.

A preference was not proof of execution

The new Privacy header could request header, session or user functions. header asked a service to obscure fields such as Via and Contact that a user agent could not simply falsify without breaking routing. session asked an intermediary to conceal the apparent source of session traffic. user asked the network to perform user-level grooming that the endpoint could not provide itself.

Those tokens recorded intent. They did not prove that a capable service received the message, that the service was configured correctly, or that legal and operational conditions allowed it to comply. RFC 3323 explicitly warned that privacy requests might go unfulfilled because of legal constraints, unimplemented features, misconfiguration or exceptional conditions.

The critical value supplied fail-closed semantics for requests. If the requested functions could not be provided, the request should be rejected. Silence was not success. Forwarding an unprotected call after a critical privacy failure would invert the user’s preference: the attempt to communicate privately would become the event that disclosed identity.

The opposite value, none, also protected intent. It instructed a privacy service to apply no privacy functions even if a provisioned profile or default would ordinarily do so, and intermediaries were forbidden to remove or alter it. RFC 3323 therefore recognized that automatic anonymization could be as incorrect as missing anonymization when it contradicted the user’s explicit choice.

Security ended before the trusted service

The document strongly recommended a direct protected path, such as TLS, to the privacy service. Without it, information could leak before reaching the actor meant to conceal it, or an intermediate proxy could remove the request for privacy. Transport protection to the service reduced that exposure and allowed certificate inspection. It did not make the service unable to see what it processed.

Session privacy made the trust boundary sharper. An intermediary that rewrote SDP and relayed media could mask the user’s network address from the peer, but unencrypted session traffic could then be visible to the anonymizer. Privacy from the destination and confidentiality from the service were separate properties. A mechanism that improved one could increase dependence on the other.

Recipients and proxies also retained the right to reject unidentified originators. The specification balanced a user’s ability to conceal identity against another actor’s ability to refuse an anonymous request. Privacy preference did not become authority to force acceptance.

RFC 3325, published alongside this work, addressed asserted identity inside trusted networks. Later identity and history specifications changed other parts of SIP’s evidence surface. Their coexistence reinforces the central distinction: an identity can be authenticated or asserted to one observer while deliberately withheld from another. The observer, trust domain, processing step and time all belong in the claim.

RFC 3323’s historical lesson is consequently architectural rather than cosmetic. Replacing a name with “Anonymous” was only the visible edge. The real system redistributed knowledge and routing responsibility. Privacy succeeded only when the correct intermediary received the request, performed the promised transformation and failed safely when it could not.

Sources