Define the intended identity
Write an identity policy for each call type before editing a trunk: ordinary staff calls, shared reception calls and calls forwarded to external numbers. For every type, name the outbound number the organization controls and the expected return-call destination. A desk extension name is not automatically an appropriate public identity.
The official customization article includes older macro-based examples. This guide uses the supported GUI policy controls and trace comparison; it does not transplant those macros into a FreePBX 17 dialplan.
Locate the override boundary
Inspect the extension outbound caller-ID setting, the matching outbound route and the selected trunk. The documented trunk option Force Trunk CID imposes the configured trunk identity; Allow Any CID permits identity from other modules. Verify the installed module behavior instead of assuming every visible field wins in all circumstances.
Start with one extension and one ordinary destination. If all users incorrectly display the same number, look for a shared override before editing every extension. If only one route behaves differently, compare that route and its trunk sequence.
Compare the PBX and carrier evidence
Capture one authorized test call at the PBX egress and note the selected trunk, timestamp and Call-ID. Compare the relevant identity headers with the carrier’s documented requirements. Ask the provider which numbers are authorized and how it handles asserted identity or forwarding. Do not enable a guessed header option simply because another provider uses it.
If the PBX sends the intended number but the receiving party sees something else, retain that boundary evidence. Destination name display may involve separate carrier handling; changing an extension display name is not an end-to-end name-delivery guarantee.
Handle forwarding deliberately
An externally forwarded call creates a new outbound leg. Its original caller’s number may be outside the numbers your trunk is authorized to present. Establish the provider-supported forwarding identity policy, then test both an internal call and a forwarded external call.
Document what the receiving employee sees and what number a callback reaches. A policy that makes forwarded calls connect but sends callbacks to an unstaffed mailbox still fails the operational requirement.
Verify failover and preserve special routes
Repeat the test over each permitted failover trunk. An identity accepted on the primary carrier may be rejected or rewritten on the secondary. Keep the observed result beside the trunk’s source documentation and account configuration.
Handle emergency routing through the carrier’s supported provisioning and coordinated verification process. Do not use a general caller-ID experiment to overwrite a location-specific emergency configuration or place unarranged emergency test calls. Roll back the narrow setting changed if an ordinary-call regression appears.
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.