Reader setup
Before you diagnose
- Reproduce the issue with one approved synthetic destination and record its exact test window.
- Use read-only access to the VICIdial/Asterisk logs and the installed Asterisk command-line interface (CLI).
- Save the deployed file hash and current logging level before evaluating any code or verbosity change.
- Expected result
- You will tell a short channel-creation timing race from a permanently missing destination and document the smallest safe correction boundary.
- Before making changes
- Do not select a global newest channel, capture unrelated calls, or deploy a retry from this article without source-pinned review and rollback approval.
Read the race in chronological order
Fast answer: an Asterisk Local channel can be visible before its bridged SIP destination is available to an AGI (Asterisk Gateway Interface) lookup. The resulting NO DestChannel message often describes timing, not a permanently missing call leg.
Two terms carry this whole article. A Local channel is an internal Asterisk call leg that exists only inside the server; Asterisk uses one to start dialing before the real outbound leg to the carrier exists, which is exactly why a lookup can run too early. AMI is the Asterisk Manager Interface, an event stream you can read to watch calls progress, and the three events used below are DialBegin when dialing starts, Newchannel when a new call leg appears, and BridgeEnter when two legs are joined into a conversation. Reading them in timestamp order is what turns a vague failure into a measured gap.
Align the AGI timestamp with AMI (Asterisk Manager Interface) bridge, DialBegin and Newchannel events. Millisecond ordering is more useful than a later channel snapshot because the missing mapping may exist only briefly.
VICIdial's own dialplan gives this race a specific, real first step worth naming: on our ViciBox 12 lab, the very first line most call paths run is an AGI call into agi://127.0.0.1:4577/call_log, sent to the configured loopback FastAGI destination. That lookup runs early, on purpose, to log the call before anything else happens to it — which is exactly the kind of early read that can outrun a Local channel's own destination mapping if the timing shifts even slightly.
See VICIdial terminology for complete beginners: users, phones, campaigns and leads for the rest of this glossary.
The URL agi://127.0.0.1:4577/call_log is the dialplan’s destination, not proof that FastAGI binds only loopback. The retained listener capture in VICIdial hardening priorities and their limits shows FastAGI_log.pl on*:4577 at its capture time. Read the actual bind and effective firewall policy separately; neither a loopback destination nor an all-interface bind alone decides external reachability.
A timing race is a hypothesis until the actual lookup and later destination are correlated. The call_log hook’s early position alone does not prove it generated this particular NO DestChannel condition.
- Capture the Local channel name and unique ID.
- Locate DialBegin, Newchannel and BridgeEnter events for the same call.
- Measure the gap between the first lookup and destination creation.
Get a bounded existing capture or hand off the missing acquisition
Do not reconstruct a millisecond race from a later channel snapshot. Ask the Asterisk/VICIdial owner for the approved synthetic test’s existing AGI/lookup log and AMI subscriber capture from the same time window. No additional call is required to prepare this handoff.
The owner must identify the script/lookup that emitted NO DestChannel, the exact source revision and the correlation key used by that lookup. A generic call_log entry or an unrelated newest channel is not a substitute.
If no subscriber capture exists, record the acquisition prerequisite for a separately authorized future synthetic test: begin the approved read-only AMI subscriber before the call, subscribe to the required channel/dial/bridge/hangup events, capture source/receipt times privately, and end only that owned subscriber after the bounded window. Use a dedicated protected credential and event permissions; do not expose AMI publicly or turn on global debug as a shortcut.
- Before you use it
- Fill from the approved private logs/capture. Use opaque public labels; the raw trace can contain numbers and channel identifiers.
build / emitting lookup file+line / opaque call token / capture start-end / clock basislookup time+result / destination Uniqueid+creation time / Linkedid correlationbridge/hangup outcome / missing events / next evidence ownerThis sample is a template or reading aid, not a terminal command. There is no output to show.
- Success looks like
- The owner can produce a single chronological story or name the exact missing acquisition prerequisite.
- Stop if
- No existing time-aligned capture means no supported timing diagnosis and no retry implementation yet.
You should seeProceed to a bounded retry review only when the measured call-scoped timeline actually supports it.
Use a bounded mapping retry
If the destination appears immediately after the failed lookup, retry the mapping for a short bounded window. Keep the retry call-scoped and stop as soon as the unique Local leg maps to its destination.
Bounded means two concrete numbers, agreed before you write any code: a maximum attempt count and a maximum total wait, both small — the timeline above measured a gap in milliseconds, not seconds, so a retry loop that keeps trying for several seconds is not a narrow fix for this race, it is a new, slower failure mode wearing the old one's name.
Never choose the newest SIP channel globally. Concurrent calls make that shortcut unsafe and can attach optimization logic to another customer.
- Before you use it
- Use the approved private server/CLI context. These are version/count/listener observations, not chronological event acquisition.
asterisk -rx 'core show version'grep -c 'NO DestChannel' /var/log/astguiclient/*.logss -lntp 'sport = :4577'This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.
- Success looks like
- You have the build, global per-file match counts and actual bind at this instant. A wildcard bind is distinct from the configured loopback destination.
- Stop if
- A missing command, denied read or no existing event capture remains a precise owner handoff. manager show eventq is not a historical stream and is absent in newer Asterisk releases.
Prove the fix under concurrent calls
A single successful call is not enough. Run a controlled set with overlapping Local channels and confirm every mapping retains its own unique identifier.
Watch answer, bridge, hangup and recording behavior. The retry must close only the observed timing gap and must not change routing or disposition semantics.
Local channel names are not guaranteed unique-looking to a human at a glance — several can share the same base extension and differ only in a trailing sequence number. A retry that matches on the visible name instead of the channel's own unique identifier can silently pair the wrong two legs together the moment two calls overlap, which is a worse failure than the one you started with because it fails quietly instead of loudly.
- Test answered, busy, no-answer and early-hangup outcomes.
- Confirm no cross-call destination mapping appears.
- Keep a rollback copy and the exact deployed hash.
Rollback by hash and document the remaining unknowns
If a reviewed retry changes routing, call correlation, recording, disposition or CPU/log behavior, restore the exact prior file through configuration management and repeat the synthetic baseline. Do not hand-edit a second guess into the running dialer.
Record the source revision, old and new hashes, observed timing range, test outcomes and unsupported call paths. A lab timing result does not prove every carrier, Asterisk release or concurrent production pattern.
Name the unknowns explicitly rather than letting a passing lab test stand in for them: a different Asterisk release may schedule the same AGI lookup at a different point in its own dialplan processing, a busier production server may widen the observed gap under load instead of narrowing it, and a carrier with a slower initial response can change which side of the race a given call lands on. Write down which of these you have not yet tested, not just which you have.
- Restore the approved prior hash rather than reconstructing it from memory.
- Repeat answered, rejected, no-answer and overlapping synthetic calls.
- Escalate when correlation remains ambiguous or the destination never exists.
Checks and sources
What was checked
- The timeline procedure distinguishes required acquisition from a completed diagnosis. No new AMI subscription, call, code retry or concurrency test was executed.
- The retained wildcard FastAGI listener capture is point-in-time evidence only; the dialplan destination does not certify its bind or firewall reachability.
- An illustrative timing example is not promoted to an observed gap; source-pinned retry review remains conditional on a real correlated capture.
Primary references
Sources
- Local ChannelAsterisk · accessed September 23, 2026
- Asterisk Gateway Interface (AGI)Asterisk · accessed September 23, 2026
- Asterisk Manager Interface (AMI)Asterisk · accessed September 23, 2026
- call_log end_time NULL for Local channels + Recording channel not hanging up after disposition for manual callsVICIdial forum · accessed September 23, 2026
- Asterisk18 manager event queue implementationAsterisk project · accessed November 7, 2026
- Asterisk23.5 manager event-queue removalAsterisk project · accessed November 7, 2026