FreePBX outbound caller ID is wrong or rejected: trace the active owner

Classify the symptom and bind it to one call

Record whether the wrong element is public number, display name, privacy, forwarded caller, emergency identity or an explicit rejection. Capture source extension, entered and normalized destination, timestamp and timezone, matched route, selected trunk, channel, SIP Call-ID, response and displayed result. A CDR label or handset display is not proof of the identity on the provider-facing INVITE.

Compare one authorized ordinary call from the same extension and one control extension. Keep the original inbound identity and the new outbound leg separate for forwarding. Do not begin with a trunk-wide header change.

Prove route and trunk before caller-ID precedence

Trace route order, dial-pattern match, number transformation and trunk sequence. A caller-ID field on a route or trunk that did not handle the call cannot explain the result. Record any failover advance and the specific response that caused it because the alternate trunk can enforce different identity authorization.

Only after selection is proved, capture extension Outbound CID and Emergency CID, route CID and Override Extension, trunk Outbound CallerID and CID Options. Preserve blanks, names, numbers and privacy markers exactly while protecting personal data.

Resolve the active FreePBX identity branch

Sangoma documents extension outbound CID, route override behavior, Force Trunk CID and emergency precedence, but the result depends on call type and selected controls. Determine whether this is an ordinary, intra-company, forwarded, privacy or emergency call and identify the field that should own that branch.

If all users share the same wrong number, inspect a shared route or Force Trunk CID. If one extension differs, inspect its managed identity. If only forwarding fails, inspect foreign-CID and Diversion handling. If only emergency calling differs, stop ordinary troubleshooting and use the emergency owner and approved test plan.

Compare loaded PJSIP policy with the outbound INVITE

After a supported Submit and Apply Config, compare the loaded endpoint and one redacted packet or trace. Record From, P-Asserted-Identity, Remote-Party-ID, Privacy and Diversion only when they exist. Asterisk exposes send_pai, send_rpid and trust_id_outbound independently; trust_id_outbound concerns private identification details, not blanket authority to send arbitrary public identity.

Correct the first demonstrated difference between managed, generated, loaded and transmitted state. Do not edit generated files as a durable fix or enable every identity header to see which one a carrier accepts.

Place carrier authorization and presentation after PBX egress

If the egress INVITE is wrong, repair the active FreePBX owner. If it is correct, preserve the complete provider response and call identifier and ask which account numbers and headers are authorized, how privacy or forwarding is represented and whether number or name rewriting occurs.

A carrier rejection, accepted call and final destination display are separate outcomes. Receiving-network databases can affect name presentation. Do not attribute a remote display-name record to the local extension field without provider-path evidence.

Protect emergency identity and location

Sangoma's emergency guidance uses a dedicated route, Route CID and per-extension Emergency CID, with the extension value taking precedence when defined. The displayed calling number does not establish the registered dispatchable location or callback handling. Preserve provider provisioning and location records as a separate evidence set.

Do not place an unarranged emergency call, replace an emergency identity during an ordinary caller-ID experiment or infer location readiness from an accepted INVITE. Use the provider and local authority's coordinated test method and maintain an independent fallback.

Retest the same branch and one control path

Change one demonstrated owner, retain rollback values, Apply Config through FreePBX and repeat the same authorized call. Then test a control extension, forwarded and privacy cases when in scope, and every approved failover trunk. Record egress headers, provider result, destination presentation and callback outcome separately.

If the same evidence does not change, roll back and reopen the earlier boundary rather than layering another override. This diagnostic is documentation-derived; no PBX, route, trunk, provider account, header, identity, emergency service or live call was tested.

Prove Set CallerID before resolving outbound ownership

When a Set CallerID destination precedes the outbound leg, verify its channel transition with the module diagnostic. Then continue through route, trunk, egress signaling and provider authorization without merging the two boundaries.