Asterisk Dial returns early, reports the wrong status or never answers

Capture one invocation as a channel and event timeline

Record timestamp, installed Asterisk branch, calling channel and identifiers, loaded context and priority, exact redacted Dial arguments, timeout, options, every created outbound channel, provisional events, final responses, first answer, bridge membership, hangups, application return, immediate variables and caller-visible outcome. Protect credentials, private numbers and message payloads.

Classify the symptom before changing configuration: no channel created, early CHANUNAVAIL, CONGESTION, BUSY, NOANSWER or CANCEL, unexpected ANSWER, missing or surprising timing, only one parallel contact attempted, answered call without media, or no expected next priority.

Prove the installed application and loaded invocation

Check the running system’s local Dial help and prove that the active dialplan entered the expected context, extension and priority. Compare the runtime arguments with the generated or source configuration, including empty argument positions and option case.

A correct source file, endpoint object or GUI screen does not prove that this channel executed that invocation. If syntax, loaded target or installed contract differs, correct that first boundary before changing endpoints, timeouts or NAT settings.

Follow requested resources into actual outbound channels

For every requested resource, determine whether Dial created an outbound channel and attach its exact name and identifier to contact selection, DNS or transport resolution and the emitted request. With PJSIP_DIAL_CONTACTS(), keep the generated dial string and resulting channel set separate from the endpoint’s contact inventory.

If no correct channel exists, investigate resource construction, endpoint or AoR association, contact reachability and channel-driver errors. If a channel exists, continue with that leg’s signaling; registration or an OPTIONS response alone does not prove INVITE success.

Compare timeout and status with the leg evidence

Mark application entry, first ringing or progress, each final response, answer and return. Then capture DIALSTATUS and timing variables immediately on the calling channel. A timeout that expires without answer, a channel-construction failure, caller cancellation and a remote final response are different endings even when the user reports “it returned early.”

For parallel legs, do not expect one application status to preserve each losing result. Use the per-channel hangup-cause keys and the corresponding protocol exchange. A translated cause may be less specific than the original SIP response.

Audit handlers, answer and continuation on their real owners

For B(), prove caller-channel entry and Return(). For b(), prove one invocation on each created callee before dialing. For U(), prove called-channel execution after answer and before bridge. A missing Return() or a handler that changes channel state can break the surrounding call flow.

If the call answers but the next priority is absent, identify which party hung up, which channel survived and whether g, F(), G() or a channel-owned after-bridge destination was actually configured. Do not expect code after Dial to run on a channel that has already ended.

Fix one proved boundary and retest signaling through media

Correct only the first demonstrated divergence: loaded syntax, resource, contact selection, channel creation, handler ownership, timeout, endpoint response, answer handling, bridge ownership, continuation option or result branch. Preserve rollback and stop temporary protocol logging after the bounded capture.

Repeat one authorized success and the relevant expected failure. Confirm created channels, response, answer, bridge, bidirectional media, teardown, immediate status and next priority independently. No host, module, dialplan, channel, endpoint, trunk, packet, bridge, media stream or live call was inspected or tested for this diagnostic.

Prove dynamic target construction first

If Dial receives ${DIALGROUP(name)}, use the DIALGROUP diagnostic to prove list ownership, exact readback and contact expansion before tracing Dial behavior.