VoIP.info Troubleshooting

Outbound VoIP calls fail: locate the broken call leg

Classify one failed call, then follow the exact digits through the phone, PBX route, attempted trunk, remote response, answer and media.

Reviewed 2026-10-30Current Sangoma outbound-route guidance, current Asterisk Dial and troubleshooting documentation, and SIP standards reviewed October 5, 2026; no phone, PBX, carrier or live call testIntermediateDocumentation based · not lab tested

Classify one failure before changing the trunk

Record the source device and selected account, digits entered, timestamp, Call-ID and exact user-visible result. Separate no request leaving the phone, local PBX rejection, no outbound channel, remote SIP rejection, ringing without answer, answer without two-way audio and an established call that later drops. Those outcomes have different evidence owners.

Use one permitted destination and only purposeful comparisons: the same number from another authorized extension, another allowed destination in the same class, or an internal call. One international destination failing is not evidence that every outbound route or trunk is down. Do not use an emergency number as an ordinary test destination.

Inbound and outbound routing are separate
Inbound calls use called-number matching to reach an extension, queue or IVR. Outbound calls use dialed-number rules to choose a permitted trunk.

A working outbound call does not prove inbound number routing. Diagnose the direction and the matching rule independently.

Prove the phone-to-PBX leg and received digits

If no INVITE reaches the PBX, inspect the active line, endpoint dial plan, Send behavior, interdigit timeout and provisioning result. A registered icon does not prove that the dial action selected that account or transmitted the displayed digits. Preserve the Request-URI and From identity when the INVITE does arrive.

Confirm which endpoint Asterisk identified and the loaded context where routing begins. An authorization or dialplan failure on this first leg cannot be repaired by rotating carrier credentials. Continue with the focused registered phone cannot call investigation when the fault remains before trunk selection.

Follow route order, transformation and trunk attempts

Identify the exact FreePBX outbound route that matched, the digits it received, any removed prefix or prepended digits, and its configured trunk sequence. Sangoma documents that matching dial patterns select a route and that the listed trunks are attempted in order until a call completes. A configured trunk is not proof that this call reached it.

Preserve every attempted channel and the number sent at each boundary. A broad earlier route may intercept the call; a fallback trunk may require different normalization, caller identity, emergency treatment or commercial authorization. If no carrier request leaves the PBX, use the outbound-route investigation before changing upstream settings.

Separate local channel outcome from the remote response

Asterisk Dial() attempts one or more requested channels and exposes DIALSTATUS; per-channel hangup-cause information can preserve additional results. BUSY, CONGESTION and CHANUNAVAIL are summaries, not interchangeable root causes. Correlate them with channel creation, the outbound SIP transaction and the party that generated the final response.

If an INVITE reaches the carrier, retain the complete final response, any Retry-After and the carrier call identifier. Number format, destination permission, authorized caller ID, registration or IP-auth state, account policy, concurrent-call entitlement and a genuinely busy remote party require different remedies. A 403 does not prove an incorrect password, and FreePBX's all-circuits-busy announcement is not a measured capacity result. The Asterisk hangup-cause guide provides the per-channel method: retain every HANGUPCAUSE_KEYS() entry, its technology and translated cause, the application-level DIALSTATUS and the original SIP exchange instead of assigning one final value to every attempted trunk.

Continue through answer and media instead of stopping at ringback

A provisional response or audible ringback does not prove answer, billing state or media. Record the final response, ACK, answered bridge, negotiated SDP on each PBX leg, received RTP and decoded two-way audio. If the far end answers but one or both parties cannot hear, preserve the successful signaling path and move to the relevant media diagnostic rather than reopening route matching.

If the call drops later, record elapsed time and the in-dialog request or timeout that ended it. Registration, outbound routing, answer, media and session continuity are separate acceptance stages.

Repair one owner and verify policy as well as success

Correct the narrow demonstrated owner: phone digit handling, endpoint identity, loaded route, number normalization, trunk selection, reachability, authentication, caller identity, carrier permission or media path. Keep a rollback record and disable temporary PJSIP logging after the authorized reproduction. SIP traces can contain phone numbers, addresses and authentication material, so redact shared extracts.

Retest the original permitted destination, a neighboring allowed case and a deliberately prohibited class. Confirm the selected trunk, displayed caller identity, answer, bidirectional audio and normal hangup. No phone, PBX, route, trunk, carrier account, number, permission, response, call, media stream, emergency workflow, price, capacity, availability or compatibility was inspected or tested for this guide.

Asterisk CLI — bounded outbound-call correlation
core show version
pjsip show endpoint <source-extension>
pjsip show endpoint <selected-trunk>
pjsip set logger on
# Place one authorized call; retain the Call-ID, matched route, attempted channel and final response.
pjsip set logger off

Continue an answered Zen call into the media path

If the Zen leg answers but audio is missing, use the Zen media diagnostic to resolve SDP, RTP direction and codec evidence after outbound routing has succeeded.

Check SIPTRUNK source identity after an authentication-mode change

A SIPTRUNK IP-authenticated trunk accepts outbound traffic only from its stored public address, while registration mode uses a challenge exchange. The mode-mismatch diagnostic separates source-address rejection, credential failure, route failure and later call handling.

Keep SIP.US outbound gateway recovery separate from inbound failover

SIP.US gateway selection can move one trunk between provider edges, while DID secondary assignment and PSTN Backup affect inbound treatment. The SIP.US failover diagnostic records those paths and their capacity separately.

Keep Bulk Solutions emergency destinations out of ordinary-call guesswork

Bulk Solutions documents separate 911 and 922 destinations plus exact emergency caller-number formats. The Bulk Solutions emergency diagnostic traces the chosen trunk, SIP identities, response and database readback without using 911 as a generic test call.

Do not confuse Flowroute inbound PSTN forwarding with trunk egress

Flowroute describes a number inbound route as an outbound PSTN call to the destination, while ordinary customer-originated outbound access uses a separate interconnection path. The Flowroute diagnostic records the correct leg and result.

Diagnose Twilio silence or 403 at the first provider boundary

Use the Twilio termination diagnostic to prove the Request-URI, selected address, source IP, challenge flow and exact rejection before changing dial plans, caller ID or account permissions.

Start with the issued IP Telecom trunk profile

The reviewed public pages do not publish a complete IP Telecom authentication, proxy or caller-identity profile. Use the provider record to compare the exact handoff, loaded PBX object, request identity, response and later media before changing unrelated defaults.

Start with the issued Clearfly voice-group profile

The reviewed public pages do not publish one Clearfly authentication, proxy or caller-identity profile. Use the provider record to compare the exact handoff, loaded PBX object, request identity, response and later media.

Start with the current Redcentric handoff

The reviewed public pages do not publish one Redcentric authentication, proxy or identity profile. Use the provider record to compare the issued handoff, DNS, loaded PBX or SBC object, request, response, destination answer and media.

Start with the selected CommPeak account method

CommPeak documents password and IP-based SIP accounts. Use the provider record to compare portal state, DNS, source address or challenge, PBX route, caller identity, request, response, destination answer and media.

Identify which Voximplant leg failed

The Voximplant provider record separates the originating PBX or application leg, scenario logic, external SIP or PSTN leg, authentication, identity, response and media so a scenario failure is not treated as a carrier conclusion.

Separate TelVox caller-ID lookup from carrier presentation

The TelVox Connect provider record keeps lookup response, allowed-ID enforcement, default fallback, outbound SIP identity, carrier acceptance and destination display distinct—especially when the five-second lookup fails.

Trace VoIP Much digits, identity and channel scope

The VoIP Much diagnostic records normalization, Request-URI, presented identity, provider response and paid-channel state; invalid-number retries can themselves contribute to source blocking.

Trace VoIPline caller identity and concurrent-call scope

The VoIPline diagnostic records normalized digits, valid allocated caller identity, selected route, response and channel state.

Check the SignalWire credential handler and Send As identity

The SignalWire workflow separates profile-default, passthrough, block-PSTN and resource handling from PBX routing and downstream rejection.

Do not repair Telnyx inbound routing in the Outbound Voice Profile

The Outbound Voice Profile controls outbound association, destinations and limits; it is not the number-to-Connection relationship for inbound delivery. Use the Telnyx diagnostic for the inbound path.

Keep Bandwidth outbound realm credentials outside inbound routing

A valid Bandwidth realm and SIP credential authenticate outbound calls; they do not prove a number’s inbound route configuration. Use the Bandwidth diagnostic for the inbound path.

Preserve MicroSIP Request-URI and PAI separately

MicroSIP 3.22.19 documents a fix where P-Asserted-Identity could replace the originally dialed extension. The MicroSIP diagnostic records entered digits, dial-plan result, Request-URI, From, PAI, PBX route and final response without assuming the release note explains the call.

Use a working didlogic outbound call only as a bounded control

Outbound success proves one egress path at one time. The didlogic inbound-DID diagnostic traces the separate inbound number path.

Keep Bulk Solutions digest evidence separate from inbound routing

If challenges loop, preserve the authenticated retry and any account-specific registration requirement. The provider diagnostic keeps that branch separate from a missing inbound DID.

Trace the 8x8 outbound source and challenge

The 8x8 X Series diagnostic follows one INVITE through approved address identity, authentication, provider response and media.

Follow the Nextiva outbound route and identity

The Nextiva diagnostic records normalization, route pattern, selected trunk, presented identity, capacity and provider response.

Keep Intermedia portal caller ID conditional

The Intermedia provider guide records the PBX-emitted identity and provider result because portal caller ID applies only when the phone system sends none.

Trace the OnSIP 000 flag after route selection

The OnSIP diagnostic keeps prefixing, registration, authentication, caller identity and destination policy separate.

Trace DIDforSale authorization, format and account policy in order

The DIDforSale diagnostic separates termination enablement, source or credential identity, digits, international state and limits.

Trace Zadarma authorization and caller identity in order

The Zadarma diagnostic separates credentials or confirmed source, From, P-Asserted-Identity and the first response.

Check Voxbeam public source and route prefix in order

The Voxbeam diagnostic reconstructs one outbound Request-URI after proving source authorization.

Check GoTrunk source or credential identity before dialing rules

The GoTrunk diagnostic finds the first provider response before changing normalization or route selection.

Trace the Voximplant scenario-created destination leg

The Voximplant diagnostic assigns separate identifiers, responses and media evidence to every created leg.

Check registration inventory without treating it as authorization proof

The AMI list diagnostic stops at the first inventory, transition or signaling divergence.

Compare customer outbound distribution with Colt inbound routing

The Colt-specific diagnostic keeps direction-specific control and evidence distinct.

Keep Gamma outbound identity and capacity independent

The Gamma-specific diagnostic checks identity, responses, channels and media without borrowing inbound rules.

Diagnose Bandwidth realm and registration boundaries

The Bandwidth outbound diagnostic finds the first mismatch before secrets or firewall rules are changed.

Verify Commio source IP and prefix before changing credentials

The Commio diagnostic finds the first mismatch in source, prefix, profile, identity or media.

Verify LES.NET outbound permission and identity first

The LES.NET diagnostic finds the earliest mismatch in selected trunk, permission, identity, response or media.

Check Wavix identity, E.164 digits and limits independently

The Wavix diagnostic finds the earliest mismatch across trunk, identity, digits, response, layered limits and media.

Read FreeSWITCH gateway lifecycle before changing the route

The gateway-down diagnostic separates registration state, ping reachability, route selection, upstream response and media.

Trace the One NZ selected trunk and source identity

The One NZ SIP diagnostic preserves the route, Request-URI, presented identity, response sequence, channel state and result.

Trace the selected 2degrees trunk and identity

The 2degrees SIP diagnostic preserves route, Request-URI, presented identity, response sequence, capacity and result.

Trace the selected Vocus trunk and identity

The Vocus SIP Voice diagnostic preserves route, Request-URI, presented identity, response sequence, capacity and result.

Trace the selected Superloop trunk and identity

The Superloop diagnostic preserves route, request, presented identity, response and result.

Trace the selected Enreach route and identity

The Enreach diagnostic preserves canonical number, route priority, trunk, identity and responses.

Separate MetTel caller identity from routing

The MetTel SIP trunk diagnostic preserves authorized identity, selected trunk, provider acceptance and downstream presentation.

Separate NUSO fraud signals from call routing

The NUSO diagnostic preserves selected trunk, identity, monitoring window, provider response and destination result.

Separate Telesystem capacity from route rejection

The Telesystem diagnostic preserves total and directional controls, active calls, local resources and first response.

Separate TPx capacity from route rejection

The TPx diagnostic preserves ordered paths, active calls, local resources and the first response.

Separate Lingo capacity from route rejection

The Lingo diagnostic preserves ordered paths, pool and burst state, local resources and the first response.

Separate Voyant capacity from caller-ID rejection

The Voyant diagnostic preserves elastic policy, local resources, assigned identity and the first response.

Separate Windstream capacity from route failure

The Windstream diagnostic preserves entitlement, local resources, access state and the first response.

Separate Granite bursting from route failure

The Granite diagnostic preserves base entitlement, burst policy, local resources, access state and first response.

Separate FirstLight access and admission failures

The FirstLight diagnostic preserves channel entitlement, local resources, access state, identity and first response.

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.