The problem these headers solve
SIP's From header is set by whoever places the call, and nothing stops it saying anything at all. That is fine inside your own network and useless the moment a carrier has to decide whether to believe you — which is exactly why setting caller ID on a trunk so often has no effect.
The industry's answer is a separate header carrying an identity that a trusted network element has verified, rather than one the caller simply claimed. That header is P-Asserted-Identity, defined in RFC 3325.
What P-Asserted-Identity is
PAI carries a URI — commonly a SIP URI — and an optional display name. It may contain up to two values: one SIP/SIPS URI and one tel URL, which is how a call can assert both a SIP identity and a telephone number.
The critical part is who puts it there. Trusted proxy servers insert the header after authenticating the user. It is not a claim by the caller; it is an assertion by a network element that has already verified who the caller is. That distinction is the entire value of the mechanism.
P-Asserted-Identity: "Jane Smith" <sip:441632960111@example.com>
P-Asserted-Identity: <tel:+441632960111>Trust domains
PAI only means anything inside a Trust Domain — a network of SIP servers with previously agreed policies for how identity information is generated, transported and used. Every node in that domain complies with a specification RFC 3325 calls Spec(T), covering authentication methods, security mechanisms and privacy handling.
The practical consequence: PAI is only trustworthy between parties that have agreed to trust each other. A PAI header arriving from the open internet asserts nothing, because there is no agreement behind it. This is why your carrier will happily accept PAI from you under contract while ignoring identical headers from a stranger.
It also explains the behaviour that frustrates people most. When your carrier replaces the number you set, they are enforcing their side of exactly this arrangement — they will assert on the wider network only what they have verified belongs to you. Sending a PAI for a number you do not own does not change that; it just gets overwritten.
P-Preferred-Identity
Where a user legitimately has several identities — a direct line and a main switchboard number, say — P-Preferred-Identity lets them indicate which one should be asserted.
Two rules matter. It is a hint, not a binding directive: the proxy decides. And it is sent to trusted proxies only — the proxy must remove it before forwarding the message onward. It never travels beyond the trust boundary.
So the pattern is: the endpoint expresses a preference with P-Preferred-Identity, the trusted proxy validates it, strips it, and inserts an authoritative P-Asserted-Identity in its place.
Privacy: withholding the number
PAI and caller-ID withholding interact through the Privacy header. When a user includes the id privacy token, proxies must remove all P-Asserted-Identity header fields before forwarding to elements that are not trusted.
P-Asserted-Identity: <tel:+441632960111>
Privacy: idThe identity still travels within the trust domain — so the network knows who called, for billing, tracing and emergency services — but it is stripped at the boundary before reaching an untrusted party. That is precisely the behaviour a withheld number should have: private from the callee, not anonymous to the network.
Without an explicit privacy request, what happens depends on the trust domain's own policies.
Remote-Party-ID
RPID is the older header that solved the same problem before PAI was standardised. It carries similar information with its own parameters for privacy and screening.
It was never a full standard in the way PAI is, but it persists because a great deal of deployed equipment speaks it. In practice you will meet carriers that want PAI, carriers that want RPID, and a few that want both. There is no way to deduce which — ask, rather than experimenting, because the failure mode is a call that connects with the wrong number displayed rather than an error you can debug.
Sending these from Asterisk
For PJSIP, PAI is enabled per endpoint:
[trunk-carrier]
type=endpoint
send_pai=yes
trust_id_outbound=yes
Add send_rpid=yes where the carrier wants Remote-Party-ID instead. trust_id_outbound governs whether Asterisk will send identity information that has been marked private — leave it off unless the trunk genuinely is inside your trust domain.
On the inbound side, trust_id_inbound decides whether Asterisk believes identity headers arriving from that peer. Only enable it for peers you actually trust, because turning it on for an internet-facing endpoint means accepting whatever identity a stranger asserts.
The identity itself still comes from CALLERID() in the dialplan — these settings control which headers carry it and whether it is trusted, not what it contains.
Diagnosing identity problems
Watch the actual headers rather than reasoning about the config:
asterisk -rvvv
pjsip set logger onThen check, in order:
- Is PAI being sent at all? If not,
send_paiis off or the endpoint is not the one you think. - Does PAI match the number you intended? If it is right on the wire but wrong on the far end's display, the carrier is overriding it — which is a commercial question about which numbers are authorised on your account, not a configuration one.
- Is a Privacy header present unexpectedly? A stray
Privacy: idwill get your identity stripped at the boundary and presented as withheld. - Does the carrier want RPID instead? Sending only PAI to a carrier that reads only RPID produces a call with no usable identity.
Frequently asked questions
What is the difference between From and P-Asserted-Identity?
From is set by the caller and can say anything. PAI is inserted by a trusted proxy after authenticating the user, so it represents a verified identity rather than a claim.
Why does my carrier ignore the caller ID I set?
Because assertion only carries weight inside a trust domain. Carriers assert onward only numbers they have verified belong to your account, and substitute anything else. Register the number with them rather than trying to configure around it.
Should I send PAI or RPID?
Whichever your carrier expects — some want PAI, some RPID, some both. Ask, because the failure presents as a wrong number displayed rather than a clear error.
How do I withhold caller ID with PAI?
Include Privacy: id. Proxies must strip all P-Asserted-Identity headers before forwarding to untrusted elements, so the identity stays within the network but is not presented to the callee.