Dead air and fake answers: collect carrier evidence before changing AMD

AMD and FAS are two different failures

AMD, or Answering Machine Detection, is Asterisk's automatic check, in the first second or two after a call connects, for whether a human or a machine answered. FAS, or false answer supervision, is a separate and carrier-side problem entirely: a carrier's switch reporting a call as answered before anyone, human or machine, has actually picked up.

These are two different failures, and the forum report that prompted this guide conflates them in its own title — worth separating here so you diagnose the right one instead of assuming AMD broke just because a carrier changed.

A VICIdial forum thread reports over 40 percent of connected calls coming back as dead air or an answering machine, with AMD already on, right after a carrier change — asking, in effect, whether the carrier is the problem or AMD is.

Both failures share the same post-answer window

VICIdial marks a call PU, meaning "Call Picked Up," the instant the carrier sends the Answer signal — its own status reference is explicit that this happens "before the call is sent on to an agent." AMD then listens against that same post-answer window to decide whether a human or a machine picked up.

An early Answer signal can start answer-based timing before a person picks up. Billing depends on the carrier agreement and its records. AMD observes the available audio; a dead-air status alone cannot prove the carrier sent Answer early.

This is why the complaint reads as one thing and can be two: a rising dead-air or machine share costs you both ways, in agent time spent on calls that were never truly live and in per-minute charges for connections that only exist on the carrier's own meter. Telling which side actually caused a given call's outcome is the entire point of the split below.

Choose the next hypothesis from evidence

A carrier change is a time marker, not a likelihood ranking. Compare comparable leads and the same window across available routes. Work through signaling, media, list mix and AMD evidence separately.

• Signaling hypothesis: an answer timestamp precedes known test-endpoint pickup; collect both sides before calling it FAS.
• Media hypothesis: received audio is absent or one-way; compare SDP/RTP direction and timing with the network owner.
• List hypothesis: routes carried leads of different age or prior-attempt history; match cohorts before comparing shares.
• AMD hypothesis: authorized labeled greetings disagree with classifications under the same route/settings; use the separate AMD test procedure.

Query the official status split this triage depends on

VICIdial maps ADAIR to AMD’s NOAUDIODATA cause. That is not the same observation as receiving audio frames containing initial silence. AMD can return MACHINE when initial silence exceeds initialSilence, so AA/AM/AL do not prove that a recorded machine greeting was heard. They record classification/handling stages; identify AMDCAUSE and the media direction before assigning cause.

Count these statuses over the same campaign/window, then compare validated carrier groups. A split is an investigation clue; it does not establish false answer supervision, a human greeting or the absence of received RTP.

SELECT status, COUNT(*) AS calls FROM vicidial_log WHERE campaign_id = '<CAMPAIGN_ID>' AND call_date BETWEEN '<START_DATETIME>' AND '<END_DATETIME>' AND status IN ('ADAIR','AA','AM','AL') GROUP BY status;

Break the same split down by carrier

The example below derives a label from the channel name. Naming conventions vary and hyphens can occur in endpoint names, so confirm the derived label against your routing configuration before treating it as a carrier ID. Also check whether the join produces more than one carrier-log row per call; duplicates inflate counts.

SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(vcl.channel, '-', 1), '/', -1) AS carrier_id, SUM(vl.status = 'ADAIR') AS dead_air, SUM(vl.status IN ('AA','AM','AL')) AS amd_classified, COUNT(*) AS total_calls FROM vicidial_carrier_log vcl JOIN vicidial_log vl ON vl.uniqueid = vcl.uniqueid WHERE vl.campaign_id = '<CAMPAIGN_ID>' AND vl.call_date BETWEEN '<START_DATETIME>' AND '<END_DATETIME>' GROUP BY carrier_id;

Hold the list constant while you compare routes

Before treating a carrier-level difference as proof, confirm the two routes were actually carrying the same list, or at least comparable ones, during the window you queried. A route that happened to carry an older, more-worked list will show a higher machine and dead-air share for reasons that have nothing to do with the carrier, which is exactly the confusion the second ranked cause above describes.

Compare an existing period where both routes handled comparable leads. A new split would change live routing and needs a separate, authorized test plan; this guide does not direct that change.

Confirm what your installed AMD actually supports

One read-only check confirms what your installed Asterisk actually supports for AMD, rather than assuming its arguments from a version used somewhere else.

asterisk -rx 'core show application AMD'

Route the evidence, do not reach for a setting

Share a validated route comparison and relevant timestamps with the carrier and your telephony administrator. Investigate signaling and media on both sides; ADAIR counts alone do not prove a carrier fault.

Route AMD-classified evidence instead to Tune AMD without burning good leads, this library's dedicated AMD-tuning guide, which covers building a labelled corpus and testing a candidate setting safely; this guide does not repeat that method here. If dial pacing itself turns out to be a contributing factor, Optimize VICIdial dial ratios and AMD for better connection rates covers measuring and adjusting that separately.

Repeat the same comparison after the dispute or the tuning change

Repeat the same grouped query, by status and by carrier, over a comparable later window once the carrier dispute or the AMD-tuning guide's own change has actually taken effect.

• The ADAIR share for the previously affected carrier has moved back toward its earlier baseline.
• Record the AA/AM/AL share and other changes in the same period; a change in the share alone does not establish which change caused it.
• Record the dates of relevant changes and avoid assigning causation from timing alone.

When to stop and hand this to someone else

Escalate rather than re-running the same query hoping for a different answer when the carrier disputes your evidence outright, when an AMD change already made through a proper canary test itself raises the false-machine rate, or when the same pattern reproduces across multiple carriers at once — that last one in particular points back at your own configuration, not at any one carrier.