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.

If a carrier's switch sends that Answer signal early, VICIdial has no way to know the line was not actually live yet: it starts billing and starts the AMD clock on what is, at that moment, genuine silence. AMD can only classify what it hears; it has no way to tell a carrier's early Answer signal apart from a real one.

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.

Rank the likely causes before changing any AMD setting

Work through these in order, especially the second, which is easy to skip past.

• Most likely, matching a carrier or route change: carrier-side false or early answer supervision, exactly the pattern the forum report above describes right after a switch change.
• Second: list or lead quality inflating genuine machine detections — compare the same list across two routes at the same time, not the same route before and after a date, since a stale or already-worked list can look like a machine-detection problem on its own.
• Third: AMD's own listening parameters no longer match the new carrier's audio path, codec, or latency, which can genuinely shift how often AMD calls a real human a machine.
• Fourth, worth ruling out on its own: genuine network-level dead air — one-way or no-way audio unrelated to AMD entirely, which no AMD setting will ever fix because AMD is not the layer that is broken.

Query the official status split this triage depends on

VICIdial's own status reference gives the exact split this guide relies on: ADAIR is "Dead Air Auto, for AMD NOAUDIODATA calls" — meaning AMD found no usable audio to classify at all, genuine silence rather than any kind of greeting. AA, AM and AL are the separate family of statuses AMD assigns when it did hear something and judged it a machine, at different points in handling that call.

Run this with your read-only account, invoked as `mysql --defaults-extra-file=/etc/vicidial-readonly.cnf -e "<statement>"`, for the full suspect window first, before splitting by carrier.

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

VICIdial does not store a carrier_id directly on the call log, but vicidial_carrier_log's own channel column carries it in the channel name itself, since the PJSIP or SIP endpoint name configured for that carrier is exactly what appears there.

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.

Where possible, split the same list across both routes for one short comparison window rather than trusting a historical difference between two lists that were never really equivalent.

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

There is no configuration change in this guide, deliberately: the evidence above tells you which of two different next steps applies, and each belongs to a different owner. Route ADAIR-heavy evidence, isolated to one carrier, to that carrier's account team or your billing dispute process — this is a signalling problem on their side of the call, not a setting on yours.

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.
• The AA/AM/AL share, if that was the finding, moved only after a change made through the AMD-tuning guide's own tested process, not before it.
• You can name the exact date of whatever change you now attribute the improvement to.

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.