Vicidial AMD not working? 9 causes and the fix for each

When Vicidial operators say “AMD is not working,” they mean one of four things: real people are being dropped as machines, voicemails are reaching agents, everything comes back NOTSURE, or detection takes so long that the human already hung up. The symptom is easy to see in your reports. The cause almost never is, because Vicidial’s detection is two systems stacked on each other — Asterisk’s app_amd producing the verdict, and Vicidial’s campaign settings deciding what to do with it — and the failure is just as often in the second layer, the carrier path, or the list itself as in amd.conf.

This guide walks the nine failure patterns we see most on production Vicidial servers, in the order you should check them. Each one lists the symptom, the cause, and the fix that actually resolves it — not the forum advice that makes the number move without making the problem stop. If you want the variable-by-variable reference first, the amd.conf cheat sheet has it.

The 9 causes at a glance

Causes 1–3: the verdict itself is wrong

1. Humans marked as machines

The classic signature: your drop rate looks great, agents are “productive,” but conversions sag and nobody can say why. The cause lives in three thresholds working together. maximum_number_of_words at the default of 3 classifies any answer longer than three words as a machine — and real receptionists answer with six to ten. after_greeting_silence at 800 ms fires the machine verdict the instant a human pauses to think. And initial_silence below 1000 ms drops cell-phone users whose handset latency delays first audio past the window.

Fix: set maximum_number_of_words=5 (6 if your lists include business lines), leave after_greeting_silence at 800 ms or slightly above, and never run initial_silence under 1500 ms on consumer lists. Then verify with the audit in cause 7 — threshold changes shift the boundary, they do not remove it.

2. Voicemails passed to agents

The mirror image. Agents sit through 20-second voicemail greetings because detection said HUMAN. Two amd.conf causes: maximum_number_of_words raised so high to protect humans that even scripted greetings score as speech, and greeting set long enough that a voicemail’s opening line fits inside the “human greeting” window. There is also a carrier cause that no amd.conf value touches: false-answer supervision, covered in cause 4.

Fix: bring maximum_number_of_words back to 4 as a starting point and pull greeting to 1500 ms or below. If machines still leak through on one carrier specifically, that is FAS, and the fix is acoustic detection or a different route — not more threshold surgery. The carrier false-answers guide explains that failure mode in detail.

3. Everything comes back NOTSURE

NOTSURE is not a fuzzy verdict; it is a timeout. Asterisk ran total_analysis_time (default 5000 ms) without any rule firing. When every call returns it, either the config is self-contradictory — maximum_word_length set longer than the analysis window, so the word-count rule can never complete — or clean audio is not reaching Asterisk during the window at all: a codec mismatch mangling the stream, a carrier that bridges audio late, or detection starting before the far end answers.

Fix: first check the arithmetic — maximum_word_length (default 3200 ms) plus the greeting thresholds must fit inside total_analysis_time. If the config is sane, record two or three NOTSURE calls and listen to what Asterisk actually heard during the five seconds. What you hear decides the fix: silence points at dial-plan timing (cause 5), noise points at the carrier path. The NOTSURE deep-dive covers the disposition of those calls specifically.

Causes 4–6: the path around amd.conf

4. Failures clustered on one carrier

Sort your AMD dispositions by carrier and look for skew. When one route drops humans at triple the rate of the others, or passes machines the others catch, the thresholds are not the problem — the route is. Two mechanisms: false-answer supervision, where the carrier returns answer billing on a number that never truly picked up and plays its own announcement (which timing AMD scores as a human greeting), and aggressive voicemail-presentation formats on prepaid ranges that no silence-gap heuristic was built for.

Fix: no amd.conf edit fixes a carrier announcement, because the audio genuinely contains speech — it is just not your prospect. Either move the affected lists off the offending route, or detect acoustically. Across roughly 2.3 billion answered calls a month on the AMDY network, about 14% of what answers is carrier false-answer traffic; a timing heuristic guesses on all of it, an acoustic model classifies it outright.

5. Detection starts too late

Humans decide within the first second of pickup. If your dial plan starts AMD only after a chain of other applications — waits, playback, context hops — the analysis window opens after the greeting is over, and every verdict is a guess made on the wrong audio. Symptom: AMD “works” on manual test calls but misfires at volume, because predictive pacing adds the latency that pushes the answer past the start of analysis.

Fix: start AMD() as early as the dial plan allows — on Vicidial that means confirming the campaign is actually using the AMD dial context and that no custom AGI sits between answer and detection. Watch a live call with asterisk -rx "core show channels" and confirm AMD is running during the first seconds, not after.

6. Verdicts produced but ignored

Asterisk says MACHINE on every voicemail and agents still get connected. That is layer two: Vicidial campaign settings. amd_send_message left empty or set to CONTINUE means the dialer acknowledges the verdict and dials on regardless. drop_call_seconds set high means the system waits out the machine before acting. And sample-campaign copies routinely carry AMD settings that were never enabled for the campaign in question.

Fix: in the campaign’s “Answering Machine Detection” section, set amd_send_message=HANGUP (or route machines to a message drop), and set drop_call_seconds between 6 and 8. Then place one test call to your own voicemail and one from a real cell phone, and watch both dispositions land. This is a two-minute test that validates the whole chain end to end. The Vicidial AMD variables deep-dive maps every layer-two setting.

Causes 7–9: the ones nobody checks

7. Your stats say AMD works — the recordings disagree

The most expensive failure is the invisible one. AMD-dropped calls are not counted as abandons, so a config that hangs up on 6% of real humans shows a clean compliance dashboard forever. The only honest instrument is your own recordings: pull 50 random calls dispositioned as AMD, listen to the first 8–10 seconds of each, count the live humans. More than 3 of 50 is a broken config no matter what the reports say. Run it quarterly — or after every threshold change — because your dialer hanging up on real people never announces itself.

8. Accurate at 10am, broken by 7pm

If accuracy tracks the clock, the config is fine and the list is not. Fresh leads answer fast and clean; aged leads answer slower, route to voicemail more, and transit different carriers. A static threshold set during onboarding is tuned for whichever context you tested in and wrong for most of the rest. Fix: split tuning by list age and dial window if you must stay on timing detection — or accept that the treadmill is the product and step off it. The narrow-middle tuning piece quantifies how fast the correct setting drifts.

9. AMD stopped doing anything after a rebuild

After an Asterisk upgrade or server migration, sometimes detection simply stops: every call HUMAN, zero MACHINE dispositions, no errors anywhere. The usual culprit is app_amd not loaded in the new build, or amd.conf replaced by a package default that nothing reads. Fix: run asterisk -rx "module show like amd" and confirm the module is loaded, then module reload app_amd after every config change. Thirty seconds, and it rules out the entire class of “it broke when we rebuilt” mysteries.

When tuning stops being the answer

Work through the nine causes and you will fix most servers. But notice what the exercise proves: three of the causes are inside amd.conf, three are in the carrier path and dial plan, and three are in the reporting and the list itself. Timing-based detection fails at the boundaries of its inputs, and its inputs — silence gaps and word counts — drift with every list, hour, and route. Tuning is how you chase that drift. It is not how you end it.

Acoustic AI AMD ends it. AMDY classifies the acoustic signature of the answer audio — the sound of the pickup, not the timing of its gaps — and returns a decision starting detection in 1/8 of a second at 99% accuracy. There are no thresholds to re-balance per list or hour, and carrier false-answers, the one failure class no amd.conf value can touch, are classified outright. It installs alongside Vicidial in minutes; the install guide walks it step by step, and the Vicidial AMD hub covers the rest.

One note: better AMD supports your TCPA and abandon-rate posture, but it is not legal advice. Pair accurate detection with the dialing policy your operation already follows. External reference for the detection engine itself: the Asterisk AMD application documentation.

FAQ

Why does Vicidial AMD mark every call as NOTSURE?

NOTSURE means Asterisk ran out of total_analysis_time before any rule fired. The two usual causes: maximum_word_length is set longer than the greeting you are analyzing, or the audio reaching Asterisk is degraded (low-volume carrier audio, a codec mismatch, or detection starting before the carrier actually bridges the answer). Raise total_analysis_time as a stopgap, then check a recording to see whether clean human speech is actually reaching the server during the analysis window.

Why is Vicidial AMD hanging up on real people?

That is the too-aggressive configuration: drop_call_seconds around 4-5 combined with amd_send_message=HANGUP drops anyone whose greeting carries a natural pause. The dropped humans never appear in your abandon rate because AMD drops are not counted as abandons. Pull 50 random AMD-dispositioned recordings, listen to the first 10 seconds of each, and count the live humans. More than 3 of 50 means the config is eating valid contacts.

Why does AMD pass voicemails to my agents?

Detection is deciding HUMAN on machine audio. The most common causes are maximum_number_of_words set too high (a long voicemail greeting scores as several words), after_greeting_silence set long enough that the voicemail message starts before the verdict, and carrier false-answer supervision, where the carrier plays its own announcement that sounds like a human pickup. If the same percentage of failures clusters on one carrier, check FAS before touching amd.conf.

Does changing amd.conf require restarting Asterisk?

app_amd reads amd.conf when the channel loads the application. A soft reload (asterisk -rx "module reload app_amd") applies changes to new calls without dropping live ones. Changes to Vicidial campaign settings like drop_call_seconds take effect for new calls once the campaign reloads, which happens automatically from the GUI.

Can acoustic AI AMD replace amd.conf tuning entirely?

Yes. AMDY classifies the acoustic signature of the answer audio instead of measuring silence gaps, so there are no timing thresholds to tune per list, hour, or carrier. It installs alongside Vicidial, returns a decision in about 125 milliseconds, and catches carrier false-answers that timing-based detection structurally cannot. Timing AMD will always be a re-tuning treadmill because its inputs drift; acoustic detection removes the drift.