FreePBX outbound caller ID: identity precedence and carrier acceptance

Define policy by call type and callback outcome

For ordinary extension calls, shared-line or reception calls, externally forwarded calls, privacy cases, failover and emergency calls, record the organization-controlled number that may be presented and the destination a callback must reach. Keep public number, display name, privacy state, asserted network identity and emergency location as separate policy fields.

A local extension label is not automatically an authorized public identity, and a destination display is not proof of the number or header sent by the PBX. Assign the provider and emergency-program owner for each identity before changing a trunk-wide option.

Resolve FreePBX precedence for the selected call

Capture the extension Outbound CID and Emergency CID, the matched outbound route's Route CID and Override Extension state, and the selected trunk's Outbound CallerID and CID Options. Sangoma's Core API describes extension outbound CID as overriding the common trunk identity and Emergency CID as overriding other caller-ID settings on an emergency route. The route and trunk guides document additional route and Force Trunk CID boundaries.

Do not turn those statements into one unconditional ladder. Emergency routes, forwarded identities, intra-company handling, an enabled route override and Force Trunk CID create different branches. Prove the route and trunk used by one call before interpreting a field that was not active.

Keep route selection and identity selection separate

First prove the entered number, normalized number, matched outbound route and selected trunk. Then record which identity inputs were eligible on that path. A correct caller-ID field on a lower-priority route cannot affect a call intercepted by an earlier route, and changing identity cannot repair a dial-pattern or trunk-selection failure.

Use one authorized destination and a control extension. If every extension shows one identity, inspect a shared route or trunk override. If only one route, forwarded call or failover path differs, compare that branch without editing every extension.

Compare managed policy, loaded endpoint and outbound INVITE

After Submit and Apply Config, inspect the managed values, bounded generated policy, loaded PJSIP endpoint and one outbound INVITE. Preserve From, P-Asserted-Identity, Remote-Party-ID, Privacy and Diversion only when present, with redaction that keeps a stable investigative mapping. Saved GUI state, loaded endpoint controls and packet evidence are distinct.

Asterisk documents send_pai, send_rpid and trust_id_outbound as separate endpoint options. The last controls whether private identification details are sent; it is not permission to assert any public number. Change a header option only when the selected carrier's current requirements and the observed missing or wrong header support it.

Separate carrier authorization, acceptance and destination display

When the egress INVITE contains the intended organization-controlled identity, retain the provider response, timestamp and provider call identifier. Confirm which numbers the account may present, which header carries network identity, how privacy or diversion is expressed and whether the carrier rewrites the number or name.

A rejected INVITE, an accepted call and the destination's displayed number or name are three different results. A downstream database or receiving network can alter presentation after the carrier accepted the call. Do not keep changing FreePBX once the evidence places the mismatch beyond its egress boundary.

Treat forwarding, failover and emergency identity as separate acceptance paths

An externally forwarded call creates a new outbound leg and may try to present the original caller, which can be outside the numbers authorized on the trunk. Use the provider-supported forwarding and Diversion policy, then confirm the callback destination. Repeat ordinary and forwarded cases on each approved failover trunk because authorization and header rules can differ.

For emergency calling, Sangoma documents a dedicated emergency route and gives an extension Emergency CID precedence over the Route CID. Identity does not itself prove the registered dispatchable location. Use the provider and responsible authority's coordinated validation process; never place an unarranged emergency call or copy an ordinary business number into an emergency field as a shortcut.

Change one owner and preserve rollback

Correct only the demonstrated extension, route, trunk or PJSIP policy owner through supported FreePBX controls. Preserve the previous value, Apply Config result, loaded endpoint and packet evidence, then repeat the same authorized call. Add a control extension, forwarding or privacy case when in scope and every permitted failover trunk.

Use the paired diagnostic when the number is wrong or rejected. Record the final PBX egress, carrier result, destination presentation and callback behavior without representing one layer as end-to-end proof. This guide is documentation-derived and no PBX, provider or call was tested.

Place Set CallerID before downstream precedence

A Set CallerID destination can change channel name and number inside a call flow, but outbound extension, route, trunk, privacy and provider policy may still act later. Preserve the value at each boundary instead of treating the module as the final owner.

Do not treat ordinary caller ID as Bulk Solutions emergency identity proof

Bulk Solutions documents specific accepted E911 number formats and a 922 verification route. The Bulk Solutions emergency-calling diagnostic compares the exact transmitted identity with the provisioned callback number and address before any live operator test.