Cause 8
Congestion (circuits busy) in Asterisk
Congestion is a capacity statement about your side, not a rejection from the far end. Every channel on the trunk was already in use, or a resource limit was hit, and the call had nowhere to go.
What it looks like in the log
[2026-08-17 16:44:02] VERBOSE[24915][C-00003a07] pbx.c: Executing [s@outbound:14] Congestion("PJSIP/1004-00001d99", "") in new stack
[2026-08-17 16:44:02] VERBOSE[24915][C-00003a07] app_dial.c: Congestion (circuits busy)What it means
This is Q.850 cause 8. It is worth separating from the failures it resembles: a 486 Busy is the far end telling you a person is occupied, and a 404 is the far end not knowing the number. Congestion is your own system saying it ran out of room.
That makes it one of the few call failures where nothing at the destination is wrong and no amount of investigating the callee will help.
Most common causes
-
01The trunk's concurrent-call limit was reached
The straightforward case. The account permits a fixed number of simultaneous calls and this one arrived above it.
-
02A local channel or resource limit
Limits configured on the endpoint, on the group, or on the system as a whole all produce congestion when hit.
-
03Leaked channels holding capacity
Channels that are not being torn down accumulate and consume the limit without carrying any conversation. The signature is congestion at call volumes well below the cap.
-
04A carrier-side cap expressed locally
Some trunks return 503 when at capacity, which the dialplan then converts to congestion. In that case the limit is theirs, not yours.
-
05A burst rather than sustained load
Capacity problems that appear only at predictable moments - the top of the hour, a campaign start - are burst-shaped and need headroom rather than a higher average.
How to tell which one it is
Compare the number of calls actually active at that timestamp against the configured limit. If active calls are near the cap, the congestion is genuine and the fix is capacity. If they are nowhere near it, something is holding channels that should have been released.
A channel count that never returns to zero during quiet hours is the clearest evidence of a leak, and it is visible in a day's log without any additional instrumentation.
How to fix it
-
Check the limit against real concurrency
Establish what the cap is and what the peak actually was before buying more capacity.
-
Look for channels that never hang up
A channel with no hangup and no events for a long period is holding capacity. These are also the calls that make log analysis harder, so finding them pays twice.
-
Route congestion to an alternate trunk
Branching on
DIALSTATUS=CONGESTIONto a second carrier converts a hard failure into a slightly more expensive call. -
Add headroom for bursts
If the failures cluster at specific times, size for the peak rather than the average, or smooth the burst at its source.