FreePBX says all circuits are busy after an outbound dial

Do not read the announcement as a carrier capacity measurement

The recording follows an unsuccessful dial path; it does not by itself prove that the carrier has no physical circuits or that concurrent-call capacity is exhausted. Asterisk Dial can finish with statuses such as CHANUNAVAIL, CONGESTION or BUSY for different conditions. Start with one failed destination, extension and timestamp.

Compare an internal call, another permitted external destination and another extension only when each comparison has a clear purpose. If every endpoint hears the recording, look for a shared route, trunk or upstream boundary before editing individual phones.

Confirm the route and number transformation

Use the FreePBX outbound-route order and dial patterns to identify the route that matched. Record the digits received from the phone, any removed prefix or prepended digits, and the number sent toward the first trunk. Sangoma documents that the route's trunk sequence is tried in its configured order.

A trunk listed in the interface is not proof that this call selected it. Follow the live call evidence and note each attempted trunk. If the expected route never runs, continue with the outbound-route investigation instead of resetting carrier credentials.

Separate local channel failure from a remote response

If Asterisk cannot create a usable outbound channel, inspect the loaded PJSIP endpoint, address-of-record or registration relationship and the exact dial target. CHANUNAVAIL can include an unreachable peer or nonexistent location; the word alone is not a complete root cause.

If an INVITE leaves the PBX, preserve the final SIP response and carrier call identifier. Authentication, authorized caller identity, number format, destination permissions, account state, call-start limits and a real remote busy condition require different remedies. Do not translate every 403, 404, 486 or 503 into congestion. For multiple or sequential attempts, follow the hangup-cause guide: new Dial() calls do not automatically clear stored per-channel causes, and several different SIP responses can map to the same Asterisk cause or application status.

Correlate the call without exposing secrets

For a short authorized reproduction, correlate the FreePBX log path with the Asterisk call identifier and, when needed, a narrowly timed PJSIP logger capture. Asterisk's troubleshooting guidance documents pjsip set logger on; its logging guidance also requires disabling temporary debug output after reproduction.

SIP traces can include phone numbers, network addresses and authentication material. Restrict the capture, redact shared extracts and turn logging back off. For custom dialplan analysis, DIALSTATUS and per-channel HANGUPCAUSE data can retain different layers of the result; do not assume a translated cause preserves every detail of the original SIP exchange.

Repair one boundary and verify the surrounding policy

Correct the narrow failure: route order or normalization, the loaded trunk object, reachability, authentication, caller identity, destination permission or provider-side state. Submit and apply supported FreePBX changes, keep a rollback record and repeat the same call.

Verify which trunk completed the call, two-way audio, caller identity and hangup. Also test a deliberately prohibited destination so the repair has not widened toll access. If a fallback trunk was involved, confirm its formatting, emergency-calling limits and charges separately.

Audit the caller-facing failure treatment after preserving the cause

Once the selected route, attempted trunks, SIP result, DIALSTATUS and HANGUPCAUSE are preserved, use the Route Congestion Messages guide to verify the default, intra-company or emergency prompt branch without treating that audio as capacity proof.