CHANUNAVAIL
DIALSTATUS CHANUNAVAIL in Asterisk and FreePBX
CHANUNAVAIL is Asterisk saying it could not even build the channel. No INVITE was sent, no far end was consulted, and no SIP response came back - the call failed before it left the building.
What it looks like in the log
[2026-08-17 15:03:44] VERBOSE[19442][C-000021a7] app_dial.c: Called PJSIP/12025550143@trunk-main
[2026-08-17 15:03:44] VERBOSE[19442][C-000021a7] pbx.c: Executing [s@macro-dialout:12] NoOp("PJSIP/1001-0000551a", "Dial status is 'CHANUNAVAIL'") in new stack
What it means
When Dial() returns CHANUNAVAIL, the channel driver was asked to create a channel to a destination and could not. That is a different class of failure from a rejected call: there is no SIP conversation to read, because none took place.
This matters for diagnosis, because it means the answer is not in the SIP trace. It is in the state of the trunk or endpoint at that moment, and in whatever the channel driver logged immediately before the Dial line.
On FreePBX, this is the failure behind the announcement callers actually hear: "All circuits are busy now, please try your call again later." FreePBX plays it when every trunk on an outbound route has failed, and CHANUNAVAIL is the most common status underneath it. If the trunks failed on capacity rather than reachability, you are looking at Congestion instead - the log tells you which.
CHANUNAVAIL is also app_dial's catch-all: busy maps to BUSY, capacity to CONGESTION, a ring with no pickup to NOANSWER, and every other hangup cause lands here. That makes ${HANGUPCAUSE} worth reading whenever CHANUNAVAIL appears - it holds the specific Q.850 cause the channel driver reported, which is more precise than the status itself.
Most common causes
-
01The trunk is not registered
A registration-based trunk that has lost its registration cannot originate. Asterisk knows this before trying and reports it as unavailable.
-
02The endpoint has no reachable contact
For an extension, no registered contact means no channel. This overlaps with 480, but arrives as CHANUNAVAIL when the failure is at channel creation rather than at INVITE time.
-
03A typo in the technology or trunk name
A dial string naming a trunk that does not exist -
PJSIP/number@trunk-mian- produces CHANUNAVAIL rather than a syntax error, because Asterisk simply cannot find the named resource. -
04The channel driver is not loaded
Dialling
SIP/on a box wherechan_sipis not loaded, which is now the default on current Asterisk versions, fails exactly this way. -
05A network path that is down
If the trunk host is unreachable at the IP level, channel creation fails outright rather than timing out on a SIP transaction.
How to tell which one it is
Read the lines immediately before the Dial in the same call. The channel driver almost always logs something more specific - an unresolvable host, an endpoint with no contacts, a module that is not loaded - and that line is the actual diagnosis. CHANUNAVAIL is the summary; the cause is one or two lines above it.
Then check the exact trunk name in the dial string against the configured endpoints. A name that is close but not identical is the most commonly missed cause because it reads correctly at a glance.
How to fix it
-
Confirm the trunk registration state
For registration-based trunks, check that the registration was up at the timestamp on the call, not merely that it is up now.
pjsip show registrationsat the CLI shows the current state; on FreePBX the same view is under Reports → Asterisk Info. -
Match the dial string to the endpoint name exactly
Compare character for character against
pjsip show endpoints. Underscores, hyphens and case all matter. -
Check the channel driver is loaded
On modern Asterisk,
chan_sipis deprecated and frequently absent. Dial strings inherited from an older config need converting toPJSIP/. -
Handle CHANUNAVAIL in the dialplan
Branching on
DIALSTATUS=CHANUNAVAILto an alternate trunk turns a dead call into a failover, and makes the condition visible in reporting.