Name the identity and the broken leg
Record whether the symptom is the calling number, displayed name, privacy treatment, connected party after answer, redirecting party after forwarding or a STIR/SHAKEN result. These are different evidence objects. A signed Identity header does not replace From or P-Asserted-Identity, and it does not guarantee a receiving phone's display.
Capture direction, source extension, route, trunk, destination, timestamp, call identifier and the exact expected authorized number. Compare at least two destinations before concluding that a local display name or a carrier database is universally wrong.
Resolve the FreePBX precedence before changing headers
Start with the extension or user's intended outbound identity, then the selected route and trunk. Sangoma's PBX GUI 13 outbound-route guide documents a Route CID, an Override Extension control and exceptions for an extension Emergency CID on an emergency route, forced trunk identity and forwarded-call identities. Those precedence rules are useful evidence, but the guide's screenshots and field positions are not an exact map of every current FreePBX 17 module build.
Record the winning value instead of changing several layers at once. Never copy an arbitrary From, P-Asserted-Identity or Remote-Party-ID recipe from another provider; the carrier can require an authorized number and specific privacy or diversion treatment.
Inspect loaded PJSIP policy and the first outbound INVITE
Use core show version and pjsip show endpoint <endpoint> to preserve the loaded Asterisk version and endpoint state. In the current res_pjsip reference, send_pai, send_rpid, trust_id_inbound, trust_id_outbound, send_diversion, caller ID and privacy are separate endpoint controls; their defaults and effects must not be collapsed into one caller-ID switch.
In a bounded authorized trace, compare channel caller ID with the first outbound INVITE's From, P-Asserted-Identity, Remote-Party-ID, Privacy, Diversion or History-Info, and Identity headers when present. A correct PBX channel value, correct SIP header, accepted carrier identity and destination display are four separate checkpoints.
Trust inbound asserted identity only at a defined boundary
Asterisk documents trust_id_inbound as the decision to accept identity from P-Asserted-Identity or Remote-Party-ID; otherwise the configured endpoint caller ID is used. Enable that trust only for an authenticated or explicitly trusted upstream boundary. An internet source's asserted header is not authoritative merely because it parses.
Capture the inbound number and name before the dialplan, after any normalization or privacy handling, and at the called endpoint. This separates provider presentation, PBX transformation and phone-directory display without weakening identity controls to make one call look correct.
Keep caller, connected and redirecting parties separate
Asterisk's party-ID documentation distinguishes caller ID at initial call setup, connected-line identity that can change at answer or during transfer, and redirecting information used for diversion. Its CALLERID, CONNECTEDLINE and REDIRECTING functions therefore describe different parties and call phases.
For forwarding or transfer, compare the inbound leg, PBX channel state and new outbound leg. Whether the next carrier accepts the original caller, a business number or a diversion identity is a provider-policy question. A correct original calling number does not prove the connected or redirecting identity is correct.
Verify legitimate presentation and escalate with evidence
Retest one authorized ordinary call, two destinations and only the privacy, forwarding or transfer cases that the business actually uses. Preserve timestamps, call identifiers, selected route, endpoint state and the relevant SIP headers. If the PBX sends the intended authorized identity but the receiver sees something else, that evidence lets the carrier distinguish authorization, signing, transit and destination-display handling.
Keep emergency identity on its own approved path. Sangoma documents an Emergency Route CID and a per-extension Emergency CID precedence for remote users; verify the provider-registered address, authorized number and provider-approved test method without placing an unauthorized emergency call. Never use spoofed identities as a diagnostic shortcut.
Do not turn attestation or verification into a display promise
The Asterisk STIR/SHAKEN guide keeps the channel caller number, SIP From or asserted identity, signed PASSporT, certificate authority, verification result, call policy and destination display as separate checkpoints. An attestation letter is not a reputation score or a guarantee of the final handset label.
Keep blacklist matching separate from caller identity
A FreePBX Blacklist entry matches the number the inbound path evaluates; it does not authenticate the caller. The blacklist diagnostic preserves number, presentation, route hook, Asterisk match and destination separately so spoofing, reassignment, privacy and normalization do not become one caller-ID diagnosis.
Separate original caller from the connected and forwarded party
If the wrong number appears only after answer, forwarding or transfer, use the Asterisk connected-line diagnostic. It traces channel party state, loaded PJSIP policy, UPDATE or re-INVITE signaling and the endpoint display before changing caller ID.
Narrow a FreePBX caller-name enrichment failure
When the caller number arrives but the name is missing, wrong or stale, use the FreePBX lookup diagnostic to trace the selected route, source and optional cache before changing carrier identity.
Do not equate a From parameter with verified caller identity
Use the PJSIP_HEADER_PARAM guide when a documented From parameter is required, while keeping caller ID, asserted identity, attestation and carrier acceptance separate.
Inspect an explicit FreePBX Set CallerID transition
If the call flow contains Set CallerID, use the module-specific diagnostic to compare the saved rule, generated context, channel value and first downstream rewrite before changing SIP identity policy.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk: Manipulating Party ID Information ↗
- Asterisk: current res_pjsip configuration reference ↗
- Sangoma: Outbound Routes Module User Guide ↗
- Sangoma: Set up Emergency Service (E911) calling requirements ↗
- Asterisk: STIR/SHAKEN ↗
- Asterisk 22 res_stir_shaken reference ↗
- Asterisk 22 res_pjsip endpoint reference ↗
- Asterisk 22 STIR_SHAKEN dialplan function ↗
- Asterisk 22 PJSIPHangup application ↗
- RFC 8224: authenticated identity management in SIP ↗
- RFC 8225: PASSporT ↗
- Sangoma Blacklist module user guide ↗
- Sangoma Blacklist GraphQL APIs ↗
- FreePBX Blacklist release/17.0 metadata ↗
- FreePBX Blacklist release/17.0 inbound-route hook ↗
- FreePBX Blacklist release/17.0 class and dialplan source ↗
- Asterisk BLACKLIST dialplan function ↗
- Asterisk CALLERID dialplan function ↗
- Asterisk party-ID interception routines ↗
- Asterisk 22 CONNECTEDLINE function ↗
- Asterisk 22 REDIRECTING function ↗
- Asterisk PJSIP_ENDPOINT function ↗
- Asterisk Dial application ↗
- Asterisk Queue application ↗
- Asterisk NewConnectedLine AMI event ↗
- FreePBX CallerID Lookup metadata — release/17.0 ↗
- FreePBX CallerID Lookup generated dialplan — release/17.0 ↗
- FreePBX CallerID Lookup configuration and inbound-route hook — release/17.0 ↗
- Asterisk internal database ↗
- Asterisk PJSIP_HEADER_PARAM dialplan function ↗
- Asterisk PJSIP_HEADER dialplan function ↗
- Asterisk pre-dial handlers ↗
- Asterisk PJSIP_PARSE_URI_FROM dialplan function ↗
- Asterisk CHANNEL dialplan function ↗
- RFC 3261: SIP ↗
- Sangoma FreePBX Set CallerID module ↗
- FreePBX Set CallerID release/17.0 repository ↗
- FreePBX Set CallerID release/17.0 metadata ↗
- FreePBX Set CallerID release/17.0 generated dialplan ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.