FreePBX outbound route mismatch: digits, order, trunk attempts and response proof

Bind the symptom to one caller and digit string

Record the extension or application that originated the call, digits entered, exact time, expected route and trunk, destination class and actual result. Compare one known-good destination from the same caller and the same destination from another authorized caller when policy allows. A handset dial plan, softphone normalization, feature code, follow-me path or application can change digits before FreePBX sees them.

Inspect the digits at the PBX boundary. Keep entered digits, SIP Request-URI, caller identity and any account code separate. Do not reset carrier credentials or edit trunk media settings until a route actually selects that trunk.

Inbound and outbound routing are separate

Prove route precedence and the first matching pattern

FreePBX evaluates outbound routes in priority order and uses their dial patterns to determine eligible calls. Preserve the loaded route order, route type, time constraints and every matching pattern. A broad earlier route can take a number intended for a later route; a route name does not affect matching.

Write one concrete transformation from the received digits through prepend, prefix removal and match pattern to the number presented to the selected trunk. Do not spread normalization across the phone, route and trunk unless each owner and intermediate result is documented.

Separate permission, emergency and time controls from number matching

A syntactically matching number can still be excluded by extension routing, Class of Service, caller-ID constraints, time conditions or other installed policy modules. Inspect the modules actually present and the generated result rather than assuming a default FreePBX installation. A policy rejection is not a carrier authentication failure.

Keep emergency routes, emergency caller identity and notifications under their dedicated approved procedure. Sangoma's examples place emergency routing first, but the exact plan, destination and test method remain jurisdiction- and provider-specific. Never use a live emergency call as a routine route test.

Trace the ordered trunk attempts rather than the final announcement

Sangoma documents a trunk sequence for a matched route. Record which trunk FreePBX attempted first, the digits and identity sent, the response or local failure, and whether policy advanced to another trunk. Ordered attempts do not prove load balancing, number portability, equivalent emergency behavior or established-call failover.

Preserve Asterisk's channel result, DIALSTATUS, hangup cause and the original SIP response separately. The broad all-circuits-busy announcement can follow authentication, authorization, number, policy, transport or capacity failures; it is not itself a capacity measurement.

Interpret the carrier boundary only after the local route is proven

Once FreePBX selects the intended trunk and sends the expected Request-URI, inspect the remote response, response owner and provider correlation identifier. Outbound caller-ID permission, destination coverage, account status, fraud controls, emergency-address policy and call-start limits can reject a locally correct route. A 4xx, 5xx or 6xx response must remain attached to the exact request and responder.

Keep answer, ringback, bridge and media outside the route-selection verdict. A 2xx response does not by itself prove audible two-way media, while a route failure has already occurred if the expected trunk was never attempted.

Validate allowed, denied and unaffected cases

After the supported apply step, inspect the loaded route and test the repaired number class, an allowed control, a deliberately denied destination and each authorized caller class. Verify the selected trunk and transformed digits, not merely ringback or a recorded announcement. Use the carrier's approved non-live procedure for emergency validation.

Rollback the authoritative FreePBX settings if route order, permissions or a control call regresses, then prove the prior state again. Record received digits, matched route and pattern, transformation, caller policy, trunk attempts, remote result, change and rollback. No extension, application, policy module, PBX, route, trunk, carrier account, destination, emergency workflow, call or media path was inspected or tested for this guide.

Start earlier when another module supplied the external number

If the outbound digits came from a Misc Destination, use the Misc Destination diagnostic to prove the selecting consumer and handoff before evaluating route order and trunk attempts.