VoIP.info Troubleshooting

Caller ID is missing or wrong

Trace calling, connected and redirecting identity across FreePBX policy, Asterisk channel state, SIP headers and carrier treatment.

Reviewed 2026-10-14Current Asterisk res_pjsip, party-ID, CALLERID and BLACKLIST references; FreePBX Blacklist 17.0.1.2 release/17.0 metadata and current source; plus FreePBX 17 on Debian 12 reviewed October 11, 2026; Sangoma GUI 13 screen guidance is version-scoped, and no PBX, carrier, blacklist rule or live call was inspected or testedIntermediateDocumentation based · not lab tested

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.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.