SIP Header Privacy in VoIP: P-Asserted-Identity and Anonymization

Have you ever wondered why your phone number shows up as "Anonymous" on a call, yet the carrier still knows exactly who paid for it? That disconnect is the heart of VoIP security and identity management. It’s not magic; it’s a carefully engineered dance between two specific mechanisms defined in internet standards: P-Asserted-Identity and the SIP Privacy Header.

If you are setting up a VoIP system, managing an IMS network, or just trying to understand why your calls are getting rejected by certain carriers, understanding these headers is non-negotiable. Getting them wrong means either exposing user data unnecessarily or breaking legitimate call flows because downstream servers don't trust your identity.

What Is P-Asserted-Identity (PAI)?

To get this right, we first need to look at how identity works inside a trusted network. In the world of Session Initiation Protocol (SIP), the standard way to say "this user has been authenticated and verified" is through a header called P-Asserted-Identity (often shortened to PAI). This mechanism was defined in RFC 3325, published back in 2002 by the IETF.

Think of PAI as a digital passport stamp. When a user logs into their VoIP provider, the server authenticates them. Instead of sending the raw password or credentials with every single request, the server inserts the PAI header into subsequent SIP messages. It tells other servers in that same administrative domain: "We have already checked this person's ID. You can trust it."

The structure of this header is strict. According to RFC 3325, a PAI header must contain exactly one URI. However, there is a common pattern where you might see two PAI headers in a single message. If that happens, one MUST be a sip: or sips: URI (like sip:[email protected]) and the other MUST be a tel: URI (like tel:+1234567890). This dual-identity approach allows services to use the SIP address for routing logic while using the E.164 telephone number for billing or display purposes.

Here is a concrete example of what this looks like in a SIP INVITE request traveling between trusted proxies:

P-Asserted-Identity: <sip:[email protected]>
P-Asserted-Identity: <tel:+15551234567>

Crucially, PAI is only valid within a trust domain. A trust domain is a group of SIP entities-proxies, application servers, registrars-that have a pre-established agreement about how identities are generated and used. Once a message leaves this domain and heads toward the public internet or another carrier, the PAI header usually gets stripped out unless specific inter-carrier agreements exist.

The Role of P-Preferred-Identity (PPI)

You will often hear PAI mentioned alongside its sibling, P-Preferred-Identity (PPI). While PAI is inserted by the network after authentication, PPI is suggested by the user agent (the phone or softphone) before authentication happens.

Imagine a user has multiple numbers associated with their account-a mobile number and a landline number. The device can send a PPI header to tell the network which identity it prefers to be asserted. For example:

P-Preferred-Identity: <tel:+15559876543>

The network then takes this preference, verifies the user, and converts it into a PAI header if the policy allows it. Later updates, specifically RFC 5876 (published around 2010), expanded when these headers could be used. Originally, they were mostly limited to INVITE requests. Now, thanks to RFC 5876, they can also appear in UPDATE, REGISTER, MESSAGE, and PUBLISH methods, ensuring consistent identity handling across different types of signaling.

Understanding the SIP Privacy Header

So, PAI handles the "who are you" part inside the trusted walls. But what about the "keep me private" part? That’s where the Privacy Header comes in. Defined in RFC 3323, this header allows a user agent to request specific levels of anonymity from the network.

When a user wants to hide their identity, their device sends a SIP request with a Privacy header containing a priv-value. These values dictate exactly what the network should hide. Here are the most common ones you’ll encounter:

• id: Requests privacy for third-party asserted identity. This is the big one. It tells the network to strip out PAI headers before the message leaves the trust domain.
• user: Requests privacy for user-configurable headers (less common today).
• header: Requests anonymization of all headers containing private information, such as From, Contact, and Call-ID.
• session: Requests hiding of session-level details, primarily IP addresses in the SDP body, often by routing media through a relay so the recipient doesn’t see the caller’s real IP.
• none: No privacy requested.
• critical: Indicates that if the requested privacy cannot be provided, the request should fail rather than proceed without privacy.

In modern deployments, Privacy:id is the most frequently used value. It provides a clear signal to the edge of the network: "Hide my verified identity from anyone outside our trusted circle."

How Anonymization Works in Practice

Let’s walk through a real-world scenario. Alice wants to call Bob, but she wants her number to appear as "Anonymous" on his screen. However, her carrier still needs to know it’s Alice for billing and lawful intercept purposes.

1. Authentication: Alice’s device registers with her carrier’s SIP proxy. The proxy authenticates her credentials.
2. Request Generation: Alice places a call. Her device sends an INVITE request. It sets the From header to something generic, like From: "Anonymous" <sip:[email protected]>. It also includes Privacy:id.
3. Internal Routing: Inside the carrier’s trusted network, the proxy adds a P-Asserted-Identity header with Alice’s real, verified number: P-Asserted-Identity: <tel:+15551234567>. Internal services use this for billing.
4. Edge Processing: As the request approaches the boundary of the trust domain (heading toward Bob’s carrier), a privacy service checks the Privacy:id header. Per RFC 3323 and RFC 5379 guidelines, it must delete the P-Asserted-Identity header.
5. External Transmission: The message leaves the network. Bob’s carrier receives an INVITE with an anonymous From header and no PAI. They present "Anonymous" to Bob.

This separation is vital. It ensures that user privacy is respected externally while maintaining operational integrity internally. Without PAI, the network would have no reliable way to track who is making the call once the From header is anonymized.

Common Pitfalls and Configuration Mistakes

Even though these standards have been around since the early 2000s, misconfigurations are incredibly common. Here are three major issues that break VoIP privacy setups:

Another frequent headache involves the From header. Some developers assume that setting From to "Anonymous" is enough. But if the downstream carrier requires a verified identity for anti-fraud measures (a growing trend in 2025-2026 due to robocall regulations), the call might get dropped. The solution isn't to expose the PAI publicly, but to ensure proper inter-carrier signaling protocols (like STIR/SHAKEN in North America) are layered on top, or that the terminating carrier accepts anonymous calls from your specific trunk.

Future Outlook: Beyond Basic Privacy

As we move further into the late 2020s, the landscape of VoIP identity is evolving. While RFC 3325 and RFC 3323 remain active and un-obsoleted, newer frameworks are emerging. The industry is seeing a shift toward more granular control and stricter enforcement of identity provenance.

Modern IMS (IP Multimedia Subsystem) platforms, like those from Metaswitch or Oracle, treat PAI and Privacy headers as configurable features within broader VoLTE TAS (Telephony Application Server) environments. Administrators can now define policies based on subscriber preferences. For instance, a corporate user might always want their number displayed, while a personal user might default to Privacy:id.

Furthermore, the rise of WebRTC and browser-based calling introduces new challenges. Browsers often handle SIP signaling differently, sometimes stripping headers automatically for security reasons. Developers integrating WebRTC with traditional SIP networks must pay close attention to how PAI is injected and preserved, often requiring custom middleware to bridge the gap between browser privacy models and carrier-grade identity assertion.

Summary of Best Practices

To wrap things up, here is your checklist for implementing robust SIP header privacy:

• Trust Domain Boundaries: Clearly define where your trust domain ends. Configure edge devices to strip PAI/PPI headers when exiting this zone.
• Use Privacy:id: This is the standard way to request identity anonymity. Avoid older priv-values like session or user unless you have a specific legacy requirement.
• Preserve Routing Headers: Never strip Route, Path, or Service-Route headers during anonymization. They are essential for call delivery.
• Validate PAI Structure: Ensure any PAI headers you generate comply with RFC 3325 (single URI, or one SIP + one TEL).
• Test with Real Carriers: Lab tests often pass, but real-world carriers may reject calls with malformed privacy headers. Always test end-to-end.

By mastering the interplay between P-Asserted-Identity and the Privacy header, you ensure that your VoIP infrastructure respects user privacy without sacrificing the reliability and accountability required by modern telecommunications networks.