Asterisk PJSIP: Provider Caller ID (Advanced / P-Asserted-Identity) (Latest Versions)

Advanced Caller ID management on SIP trunks is one of the most misunderstood yet business-critical aspects of Asterisk telecom deployments.

Asterisk can set Caller ID values easily, but whether those values are accepted, transported, displayed, or replaced depends on:

• SIP header construction in Asterisk
• Provider caller-ID policies and anti-spoofing
• Telecom regulatory frameworks (STIR/SHAKEN, CLI enforcement)
• Network behavior and header rewriting

This article explains how Caller ID truly works on SIP trunks, how to build compliant configurations, how to debug failures, and how platforms like MYLINEHUB manage Caller ID robustly in production.

What Caller ID Really Is in SIP

Caller ID is not a single value — it lives in several SIP headers:

• From → mainstream caller identity
• P-Asserted-Identity (PAI) → trusted internal identity
• Remote-Party-ID (RPID) → legacy identity

Asterisk populates these headers based on configuration, dialplan settings, and endpoint policies. But the final value seen by PSTN or mobile recipients is controlled by the SIP provider.

Provider Anti-Spoofing Rules

Modern SIP providers enforce restrictions to prevent fraudulent CLI:

• only provider-verified DIDs can be used
• presenting a different number than the verified DID may be rejected
• providers may override CLI wholesale

Some providers use:

• CLI whitelisting
• account-level approved numbers
• dynamic CLI policy based on caller profile

If your CLI is not accepted, outbound calls may fail with:

• 403 Forbidden
• 484 Address Incomplete
• silent override (provider replaces CLI)

How Asterisk Populates Caller ID Headers

Asterisk sets CLI in two primary ways:

1. Dialplan Caller ID

same => n,Set(CALLERID(num)=1800123456)
same => n,Set(CALLERID(name)=Support)

This only modifies internal Asterisk channel variables. SIP headers may still differ unless endpoint configuration supports them (see next section).

2. Endpoint Header Control

[provider-endpoint]
type=endpoint
from_user=1800123456
from_domain=sip.provider.com
send_pai=yes
send_rpid=yes
trust_id_outbound=yes

These settings control how Asterisk maps the internal Caller ID variables onto SIP headers presented to the provider.

Which SIP Headers Matter (Real Payload)

In production, providers look at one or more of these headers:

• From → primary CLI
• P-Asserted-Identity → authoritative CLI for trusted networks
• Remote-Party-ID → older format

Asterisk can send all three if configured. Some providers require PAI to trust CLI.

International Calling Policy (STIR/SHAKEN)

In many countries (especially USA/Canada), telecom regulators require verified CLI using STIR/SHAKEN signing.

Asterisk itself does not perform STIR/SHAKEN signing — this is typically handled by the provider day to sign SIP INVITEs before passing to PSTN.

If your outbound calls are subject to STIR/SHAKEN:

• provider will reject unsigned CLI
• provider may require specific SIP headers
• provider may require per-DID token registration

MYLINEHUB Approach to CLI

In MYLINEHUB, CLI is managed at two levels:

• Dialplan / endpoint configuration — required for basic CLI values
• Provider policy orchestration — SUPPORTED for mapping correct DIDs per client/account

In outbound campaigns, MYLINEHUB:

• ensures only provider-approved DIDs are used
• reconciles caller ID values with trunk policies
• provides CLI substitution logic when multiple numbers exist

For Voice AI calls (where dynamic CLI may be needed), MYLINEHUB uses ARI rather than AMI, giving deeper control of SIP header construction.

Inbound CLI vs Outbound CLI

It’s equally important to understand:

• Inbound CLI (caller number received from provider)
• Outbound CLI (number presented to provider)

Inbound CLI can be read using:

${CALLERID(num)}

But in some cases, providers put the CLI in different SIP headers:

• From header
• P-Asserted-Identity
• Remote-Party-ID
• Diversion header

You must verify where the inbound CLI actually resides using pjsip set logger on for accurate parsing.

Common Real-World Caller ID Problems

1. Provider Rejects Outbound Call with 403

Typical cause — CLI not approved by provider.

Fix:

• Use provider-verified DID (endpoint from_user)
• Enable send_pai so provider gets trust identity

2. Call Connects but Shows Wrong CLI

Cause — provider rewrote CLI due to policy.

Fix:

• Confirm approved number list with provider
• Send PAI header

3. Anonymous CLI or “Unknown” CLI

Cause — missing identity headers or provider suppression

Fix:

• send PAI and RPID headers
• ensure endpoint supports identity

Debugging CLI Step-by-Step

1. Enable SIP Logging

pjsip set logger on

Inspect SIP INVITE for:

• From header
• P-Asserted-Identity (PAI)
• Remote-Party-ID (RPID)

2. Capture Packets with tcpdump

sudo tcpdump -i any -s 0 -w callerid_debug.pcap udp port 5060

Open in Wireshark to verify real headers sent to provider.

3. Compare Provider Response

If provider rewrites CLI:

• check provider documentation for allowed headers
• confirm whether PAI is being used

Best Practices for Advanced CLI on SIP Trunks

• Always provision and verify DID numbers with provider
• Configure from_user and from_domain
• Enable send_pai and send_rpid
• Verify header order and values via SIP logging
• Test in real PSTN scenarios (mobile + landline)

Key Takeaway

Caller ID is not just a dialplan setting — it is a collection of SIP headers that must satisfy:

• Asterisk channel configuration
• Provider anti-spoofing policies
• Telecom regulatory requirements
• Network and NAT header integrity

Advanced CLI handling requires: correct header construction, provider alignment, and real verification.