What is default AMD in Vicidial — and how it actually works

If you run a Vicidial dialer, you have used default AMD whether you realized it or not. It is the quiet piece of logic that decides, in the first few seconds of every answered call, whether a person or a machine picked up. Get that decision right and your agents talk to humans. Get it wrong and you either dump live prospects into voicemail or burn agent time on answering machines. This is a from-scratch walkthrough of what default AMD is, why predictive dialers need it, and exactly how the built-in version makes its call.

What default AMD actually is

“Default AMD” — also called stock or built-in AMD — is not a Vicidial feature in the strict sense. It is a feature of Asterisk, the open-source telephony engine Vicidial is built on top of. Asterisk ships with a dialplan application called app_amd, configured by a file named amd.conf. Vicidial simply invokes that application on each answered call when you have asked it to.

Because it comes bundled with the platform, it costs nothing extra and is already installed on every standard Vicidial box. That is its biggest selling point and, as we will see, the root of its limitations. It is a piece of free, general-purpose plumbing that every operator inherits by default.

Why predictive dialers need AMD at all

To understand AMD you have to understand why a dialer over-dials in the first place. A predictive dialer’s entire job is to keep agents busy. Most calls a dialer places never reach a live person — they hit voicemail, ring out, get a busy signal, or land on a disconnected number. If the dialer placed exactly one call per free agent, agents would spend most of the shift waiting. So the dialer deliberately places more calls than it has agents, betting that only a fraction will connect to a human.

That bet creates a problem: when a call is answered, something has to decide instantly whether it reached a human worth handing to an agent, or a machine that should be dropped or sent a message. AMD is that gate. It sits between “the call was answered” and “route this somewhere,” and its verdict drives everything downstream. Without it, the over-dialing strategy collapses — you would have no way to separate the humans from the voicemails fast enough to act.

This is also where compliance pressure enters. Over-dialing produces abandoned and dropped calls, and regulators care about how many. AMD’s accuracy directly affects those numbers, which is why operators obsess over it. (More on the compliance angle in our piece on the TCPA 3% rule.)

How default AMD works, step by step

When a call connects, app_amd does not transcribe what is said and it does not understand any words. It listens to the raw audio of the first few seconds and measures the timing of sound and silence. Specifically, it tracks:

• Initial silence — how long the line stays quiet after the call is answered before any speech begins.
• Greeting length — how long the first continuous burst of speech lasts.
• Silence after the greeting — the pause once that first burst stops.
• Word count and word/silence timing — how many distinct words it hears and how long each word and each gap between words runs.

As these measurements come in, app_amd compares them against the threshold values defined in amd.conf. Those thresholds include things like initial_silence (around 2500ms), greeting (around 1500ms), after_greeting_silence (around 800ms), total_analysis_time (around 5000ms), min_word_length, between_words_silence, maximum_number_of_words, and a silence_threshold that defines how loud audio must be to count as “sound” rather than line noise.

Once the analysis window closes — or once one of the thresholds is decisively crossed — the application reaches a verdict and writes it to a channel variable called AMDSTATUS. That value is one of three things:

• HUMAN — the timing looked like a live person.
• MACHINE — the timing looked like a recorded greeting.
• NOTSURE — the audio did not match either pattern cleanly within the analysis time.

From there the dialplan takes over. It reads AMDSTATUS and routes accordingly: a HUMAN goes to a waiting agent, a MACHINE gets dropped or has a message played, and a NOTSURE is handled by whatever fallback you have configured. The classifier itself makes no routing decision — it only labels the call. What you do with the NOTSURE bucket in particular is its own small art; we cover it in handling AMDSTATUS NOTSURE.

The core assumption: humans and machines on a stopwatch

Everything above rests on a single assumption: that humans and machines sound different on a stopwatch. The reasoning is intuitive. A live person answers with a short “hello,” then pauses and waits for you to speak. A voicemail plays a longer, continuous greeting — “Hi, you’ve reached the Smith residence, we can’t come to the phone right now…” — and ends with a beep. Measured purely as durations of speech and silence, those two patterns really do look different.

That is why the heuristic is reasonable. It captures a genuine, real-world difference in how people and machines behave when they answer. For a large share of calls, it works.

It is also why the heuristic is fragile. The moment a human breaks the expected rhythm, the stopwatch lies. A person who answers with a long “Helloooo… hello? who is this?” can read as a MACHINE. Someone in a noisy room, on a bad cell connection, or who simply pauses before speaking can trip the thresholds the wrong way. And machines have drifted too — some voicemail greetings are now short and clipped, which looks human. The timing model has no way to tell the difference because it never hears what was said, only how long it took. We unpack this failure mode in detail in why “hello” breaks AMD.

Where the settings live

Default AMD is configured in two places, and it helps to know which lever lives where.

On the server: amd.conf

The timing thresholds — initial silence, greeting length, analysis time, word counts, the silence threshold — all live in amd.conf on the Asterisk server. This is where the actual detection behavior is tuned, and it is edited at the file level, not through the Vicidial web admin. If you want a quick reference for every parameter, see our amd.conf cheat sheet.

In Vicidial: the campaign toggle

Whether AMD runs at all is controlled per campaign by the Detect Answering Machine setting. Alongside it sit the Vicidial-layer fields that decide what happens after a machine is detected — notably drop_call_seconds, which governs drop timing, and amd_send_message, which controls whether the dialer hangs up or continues into a message (HANGUP vs CONTINUE). So Asterisk decides what kind of call it is; Vicidial decides what to do about it.

The honest assessment

Default AMD is free, built in, and works often enough that millions of calls a day run through it without anyone thinking twice. For a lot of operators, that is a perfectly fine starting point. There is no shame in running stock.

But it is, fundamentally, a heuristic — a set of stopwatch thresholds applied to audio it does not understand. That is why tuning amd.conf is a perennial chore and why “our AMD accuracy is off” is one of the most common complaints in the Vicidial world. In practice stock AMD lands somewhere around 70–85% accuracy, and it tends to misclassify roughly 5–15% of live humans as machines — every one of which is a connect your agents never get. You can chase those numbers with tuning, but you are tuning a model that listens to timing instead of sound, and there is a ceiling to how far that goes.

If you want to go deeper, the next steps from here are the drawbacks of stock AMD, the AI approach that classifies the acoustic signature of the audio itself, and the full Vicidial AMD guide that ties it all together.

FAQ