Understanding P-Asserted-Identity (PAI) and Remote-Party-ID (RPID) for Caller ID Privacy and Trust

Overview

Key takeaways

• P-Asserted-Identity (PAI) is defined by RFC 3325 as the standard mechanism for passing verified identities within a trusted domain.
• Remote-Party-ID (RPID) is an obsolete draft standard still broadly used in legacy Cisco, Asterisk, and older PBX implementations.
• The From header defines presentation identity (what the user sees), whereas PAI and RPID carry authenticated identity verified by the network.
• The Privacy header (RFC 3323) works alongside PAI to signal downstream nodes to mask presentation identity on egress to untrusted networks.
• Session Border Controllers (SBCs) must enforce Trust Domain boundaries by stripping PAI or RPID headers when routing traffic to untrusted peers.

Prerequisites

• Basic knowledge of SIP request structure (INVITE) and standard headers like From, To, and Contact.
• Understanding of SIP network topology, including proxy servers, softswitches, and Session Border Controllers (SBCs).

Guide

1. section #1

   Presentation Identity vs. Network-Asserted Identity In traditional SIP routing, the From header serves two distinct purposes: routing identification and caller display. However, because end-user devices can easily manipulate the From header, it cannot be trusted for billing, emergency service routing, or legal identity assertion. To solve this, SIP architecture decouples the presentation identity (what the destination device renders on screen) from the network-asserted identity (the cryptographically or administratively verified caller ID guaranteed by the originating network). The From header is retained for presentation, while dedicated headers like P-Asserted-Identity or Remote-Party-ID carry the authenticated identity across trusted network segments.

2. section #2

   P-Asserted-Identity (PAI) and RFC 3325 Architecture Defined in RFC 3325, P-Asserted-Identity (PAI) allows entities in a Trust Domain (Spec-T) to pass authenticated identity information. An originating SIP proxy verifies the user via Digest Authentication or IP ACLs, injects the PAI header into the SIP INVITE, and passes it upstream. A PAI header contains a SIP or TEL URI and an optional display name. Multiple PAI headers can exist in a single message if the entity carries both a SIP URI and a TEL URI. Because PAI relies on explicit trust between administrative domains, proxies inside the trust domain accept the PAI value without re-authenticating the endpoint.

   sipcopy

   INVITE sip:+15559876543@example.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.10.1:5060;branch=z9hG4bK776asdhds
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
   To: <sip:+15559876543@example.com>
   Call-ID: a84b2e718a8b8405@192.168.10.1
   CSeq: 314159 INVITE
   P-Asserted-Identity: "Jane Doe" <sip:+15550199@example.com>
   P-Asserted-Identity: tel:+15550199
   Privacy: id
   Content-Type: application/sdp

3. section #3

   The Privacy Header and Anonymity Mechanics User privacy preferences are managed via RFC 3323 Privacy headers in conjunction with PAI. When a user requests Caller ID blocking, the UA or originating proxy sets the From header display to "Anonymous" and the URI to an invalid address (e.g., sip:anonymous@anonymous.invalid). The actual identity is preserved inside the PAI header, and a 'Privacy: id' or 'Privacy: full' header is attached. Intermediate proxies within the trust domain use the PAI for routing and billing. When the call reaches the egress SBC exiting the trust domain, the SBC reads the Privacy header, strips the PAI header completely, and sends only the anonymous From header to the untrusted PSTN gateway or external carrier.

   sipcopy

   /* Example Privacy header directives */
   Privacy: id          ; Requests hiding network-asserted identity
   Privacy: header      ; Requests hiding non-essential headers
   Privacy: session     ; Requests hiding session metadata (SDP)
   Privacy: none        ; Explicitly requests no privacy enforcement

4. section #4

   Remote-Party-ID (RPID) Legacy Implementation Before RFC 3325 standardized PAI, draft-ietf-sip-privacy defined the Remote-Party-ID (RPID) header. While the draft expired without becoming an RFC, RPID was widely implemented by vendors like Cisco, Digium (Asterisk), and various softswitch providers. RPID embeds identity, privacy instructions, and screening statuses directly within parameters of a single header line using key-value pairs such as 'party=calling', 'privacy=full', and 'screen=yes'. While functional, RPID is considered legacy and should be converted to PAI at network boundaries whenever modern SIP interconnects are deployed.

   sipcopy

   /* Common RPID formats */
   Remote-Party-ID: "John Smith" <sip:5551234@10.0.0.1>;party=calling;screen=yes;privacy=full
   Remote-Party-ID: <sip:+15551234567@carrier.com;user=phone>;party=called;screen=no;privacy=off

5. section #5

   Trust Domains and SBC Boundary Management A Trust Domain consists of a set of SIP nodes that agree on security policies and explicitly trust one another to assert identity correctly. Maintaining security requires strict enforcement at the perimeter using Session Border Controllers (SBCs). Incoming messages from untrusted networks (such as public SIP trunks or remote UAs) must have any existing PAI or RPID headers stripped or overwritten to prevent header spoofing. Conversely, outgoing messages leaving the Trust Domain to an untrusted destination must have PAI/RPID headers stripped if the Privacy header requests anonymity, ensuring sensitive internal network topology and subscriber data remain protected.

6. section #6

   Comparing PAI vs. RPID Understanding the core differences between PAI and RPID is critical when designing inter-provider trunking and troubleshooting caller ID issues across multi-vendor PBX environments. The following comparison highlights structural and operational distinctions.

   textcopy

   +-----------------------+----------------------------------+----------------------------------+
   | Feature               | P-Asserted-Identity (PAI)         | Remote-Party-ID (RPID)           |
   +-----------------------+----------------------------------+----------------------------------+
   | Standardization       | IETF Standard (RFC 3325)          | Expired IETF Draft               |
   | Privacy Handling      | Separate 'Privacy' header        | Embedded parameter (privacy=)    |
   | Screening Status      | Handled by proxy logic           | Embedded parameter (screen=)     |
   | Multiple Identities   | Multiple PAI headers supported   | Single header line preferred     |
   | Direction Support     | Originating / Network-asserted   | Supports party=calling / called  |
   | Carrier Support       | Modern Tier-1 Carrier standard   | Legacy Enterprise / Internal PBX |
   +-----------------------+----------------------------------+----------------------------------

Further reading

• RFC 3325 - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
• RFC 3323 - A Privacy Mechanism for the Session Initiation Protocol (SIP)
• draft-ietf-sip-privacy-04 - SIP Extensions for Caller Identity and Privacy
• RFC 7315 - Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for 3GPP