A FreePBX outbound route audit follows one failed call from the digits entered to the provider’s response. This approach helps when inbound calls still work, especially after route edits, trunk replacements, or dialing changes. Instead of rebuilding a working trunk, check which rule handled the call and what FreePBX actually sent.
The goal is a short evidence chain: dialed digits, matched route, transformed number, selected trunk, outbound identity, and final response. Each step answers a different question. Together, they reveal whether the PBX rejected the call locally or the provider refused the request.
Why Working Inbound Calls Do Not Validate Outbound Routes
Inbound and outbound calls follow different rules. A provider can deliver calls successfully while rejecting outgoing calls from the same system. Incoming service does not prove that outbound billing, destination permissions, or caller ID authorization are correct.
FreePBX also handles incoming number matching separately from outbound dial patterns. An inbound test never exercises the route that chooses an outgoing trunk. A trunk is the PBX’s connection to a carrier or another phone system.
This guide focuses on auditing the outbound decision path, rather than general trunk availability. Start here when incoming calls work and a route or provider change may explain outgoing failures.
If extension-to-extension calls also fail, investigate the local calling path first. The guide to internal extension call checks covers that separate branch.
Prepare a Controlled FreePBX Outbound Route Audit
Save a current backup and record relevant settings before editing anything. Use one extension and a known, permitted destination under your control. Avoid emergency numbers, premium-rate services, and repeated calls to unsuspecting recipients.
Build a test record with these fields:
- Call time, including time zone.
- Originating extension and exact digits entered.
- Expected route and expected trunk.
- Expected destination format and authorized caller ID.
- Observed announcement, delay, or phone display message.
- Recent changes to routes, trunks, or provider accounts.
Then place one test call. Find its call record and related Asterisk log entries. Asterisk is the calling engine beneath FreePBX. Its dialplan contains the rules that process each call.
Keep the same extension and destination while investigating. Changing several inputs makes comparisons unreliable. If the failure affects only certain number types, record a separate test for each type.
Prove Which Outbound Route Matches the Digits
Open the outbound route list and compare its order with the entered number. FreePBX evaluates routes in order; the first eligible match normally determines the route. A broad pattern above a specific route can capture calls meant for another carrier.
Inspect the entire matching rule, not just its destination pattern. A caller ID match field can restrict which originating identities qualify. Time restrictions or installed permission modules may also affect eligibility.
Common pattern symbols include:
X: any digit from zero through nine.Z: any digit from one through nine.N: any digit from two through nine.[234]: one digit from the listed set.
Wildcard patterns can match much more than intended. Do not add a catch-all route simply to make a test pass. That can open expensive destinations or bypass calling restrictions.
Confirm the selected route in the call’s dialplan trace. Do not infer it solely from the route name or screen order. Custom dialplan rules can change normal behavior.
Consult the official FreePBX documentation for field details that match your installed modules.
Track Number Normalization Through Each Stage
Number normalization converts user-entered digits into the format a provider expects. For example, a system may remove an outside-line access digit and add a country code. The correct output depends on the carrier and destination.
In an outbound route pattern, the prefix matches leading digits that FreePBX removes. The prepend field adds digits before the remaining matched number. The match pattern determines which remaining digits qualify.
Write the transformation as a short worksheet:
- Record the exact digits the phone sends to the PBX.
- Identify the prefix that the route removes.
- Record any digits that the route prepends.
- Check trunk-level number manipulation for further changes.
- Compare the final destination with the provider’s requirements.
A phone’s own dialing rules may change digits before FreePBX receives them. Likewise, duplicate transformations can add a country code twice or strip a required digit.
The outgoing SIP request provides stronger evidence than the configuration screen alone. SIP, or Session Initiation Protocol, carries call setup messages. Its Request-URI identifies the requested destination.
For failures limited to leading plus signs, use the narrower guide to international number formatting in FreePBX.
Confirm the Trunk FreePBX Actually Attempts
After matching the route, inspect its trunk sequence. Verify that the intended carrier appears first and remains enabled. An old trunk entry can survive a migration even when incoming calls use the replacement.
Next, compare the configuration with the call trace. Record each attempted trunk and its result. Do not assume FreePBX will try every listed trunk after every rejection. Failover depends on the failure cause and applicable settings.
A provider may also restrict outbound destinations, concurrent calls, account balance, or service activation. These controls can block outgoing traffic without affecting incoming delivery.
Separate registration from call authorization. Registration tells a provider how to locate an account’s endpoint; it does not authorize every outgoing request. Some trunks use source IP authorization instead.
If evidence shows an actual registration failure, follow the dedicated trunk registration diagnostic sequence. Avoid changing registration settings merely because an outbound call failed.
Check the Caller Identity the Provider Receives
A correct destination can still fail when the provider rejects the calling identity. Compare the outgoing identity with numbers the account may present. A number that receives calls is not automatically authorized on every outbound trunk.
Review extension caller ID, route overrides, trunk caller ID, and relevant identity settings. Their interaction can produce a different value from the one an administrator expects.
Inspect the SIP From header and, when applicable, P-Asserted-Identity. These fields convey calling identity, but providers differ in which values they require and trust. Some separate the authentication username from the public calling number.
Use an authorized business number for testing. Do not substitute arbitrary caller IDs or disable identity controls to bypass a rejection. Ask the provider to confirm its required format and account permissions.
Read Provider Responses in the Full Call Context
Determine whether Asterisk sent an outbound INVITE, the SIP request that starts a call. If no request left the PBX, investigate local matching, restrictions, or trunk availability first.
If a request left, identify the response source and final result:
- 401 or 407: An authentication challenge may be normal if an authenticated retry succeeds.
- 403: The responding system refused the request; confirm its reason before changing credentials.
- 404 or 484: Check destination addressing and number format against provider guidance.
- 503: Investigate service availability, capacity, and any documented retry behavior.
- No reply: Check destination resolution, transport, network delivery, and provider receipt.
Response codes alone do not prove a root cause. Preserve the reason text, call identifier, and any provider reference. A local announcement may summarize several different failures.
For trained administrators, brief SIP logging can fill evidence gaps. Confirm the channel driver and logging method first. Captures can expose phone numbers, identities, and authentication material, so limit collection and restrict access.
Validate the Repair Without Expanding Calling Access
Change only the setting that the evidence identifies. Apply the configuration through FreePBX, then repeat the original controlled test. Avoid direct edits to generated configuration files that FreePBX may overwrite.
Test representative permitted destinations and confirm that restricted destinations remain blocked. Recheck inbound calling after shared trunk changes. Use your provider’s approved procedure for emergency-service validation, never an unplanned emergency call.
Close the FreePBX outbound route audit with the corrected route, final number format, chosen trunk, and successful result. Save the rollback details and stop temporary diagnostic logging.
Professional remote assistance may help when traces conflict with settings or several trunks share complex rules. Tech Rescue Ops LLC can help isolate the failing stage while preserving working inbound service and existing calling restrictions.