Answering Machine Detection in VICIdial: the complete guide

Answering Machine Detection (AMD) listens to the first few seconds of an answered outbound call and decides whether a live person or a machine picked up. The goal is simple: send your agents more conversations and divert the voicemails — either hang up on them or play a recorded message. This guide is the hub for everything AMD in VICIdial: how it works, how it's wired, the honest tradeoffs, how to read the results, and when you're better off skipping it entirely.

What AMD actually does

When an outbound call connects, the line gives you no clean signal about who answered. A human saying "hello" and a voicemail greeting saying "hi, you've reached…" both look like an answered call to the dialer. AMD (answering machine detection) is the software that tries to tell them apart. It samples the audio, measures the pattern of speech and silence in the opening seconds, and rules "human" or "machine."

The thing AMD is chasing is a clean Live answer — a real person on the line, ready to talk. Machines never become sales. So if AMD works, your agents spend their time on people instead of listening to "please leave a message after the tone." For a deeper plain-English explanation of the concept, start with what VICIdial AMD is.

Under the hood, VICIdial's AMD is the Asterisk AMD() application driven through a dedicated dial extension and an AGI script. The exact mechanics of how the audio analysis reaches a verdict are covered in how VICIdial AMD detects machines.

The honest tradeoff

AMD is not free, and the cost is the part most operators underestimate. It analyzes the opening of every call before connecting an agent — not just the machine ones. That means a couple of seconds of processing on every single answered call, including the live people you most want to reach quickly. On a busy Campaign, that delay adds up.

It's also imperfect. AMD makes two kinds of mistakes. A false positive hangs up on a real human because the opening sounded machine-like. A false negative passes a machine through to an agent because the greeting fooled it. The first one is worse — it quietly burns leads and frustrates the people you called. We have a whole post on fixing AMD false positives because it's the single biggest reason AMD gets a bad reputation.

There's a quieter alternative that avoids AMD entirely: set your Dial timeout to roughly 22–26 seconds. Most voicemail systems pick up only after several rings, so a timeout in that window lets the call expire before the machine ever answers. The live people — who answer within a few rings — still come through, and the machines mostly time out on their own. It's not as surgical as AMD, but it costs nothing in processing time and produces zero false positives. We compare the two head to head in AMD vs dial timeout.

A bit of history puts the current state of things in perspective. Years ago there was a paid, hardware-assisted option that did call progress detection with roughly 97% accuracy — far better than software guessing. It was discontinued. What remains for nearly everyone today is software AMD, which is good but never that precise. That gap is why tuning matters so much, and why "should I even turn this on" is a real question rather than a default yes.

How AMD is wired in VICIdial

AMD isn't a checkbox you flip on a single screen — it's a path the call takes through the dialplan. Here's the chain, from the bottom up.

The AMD processor at extension 8369

The Asterisk box needs the optional AMD application loaded, which is standard on a managed VICIdial install. The dialplan then has an AMD-enabled processor sitting at extension 8369. That extension runs the AMD() application with a string of tuning numbers, then hands off to VD_amd.agi — the AGI script that records AMD's verdict back into VICIdial so the dialer knows what to do with the call.

Those numbers in the AMD() call are the knobs: initial silence allowed, greeting length, silence after the greeting, total analysis time, minimum and maximum word length, and the silence threshold. They're what you adjust when AMD is guessing wrong. We break each parameter down in the AMD Asterisk parameters, and walk through a tuning pass in tuning AMD accuracy.

Turning it on: Campaign VDAD exten

To route a campaign's calls through that AMD processor, you set the campaign's "Campaign VDAD exten" to 8369. The VDAD extension is where answered calls land before an agent is connected. Point it at 8369 and every answered call flows through AMD instead of the normal processor. Leave it at the default and AMD never runs, no matter what else you configure. The full step-by-step lives in setting up an AMD campaign, and the exten field itself is covered in the Campaign VDAD exten 8369 setting.

The dial-method restriction (this one bites people)

AMD only works on auto-dialed calls. Your Dial method must be RATIO, one of the ADAPT_ methods, or another automatic mode. It does NOT work with MANUAL or INBOUND_MAN. That makes sense once you think about it — AMD needs to control the call before an agent is on it, and manual dialing puts the agent on the call from the start. But it catches plenty of operators who set everything else up perfectly and then wonder why nothing is being detected.

Because of this, AMD lives in the world of Predictive dialing and Ratio dialing — campaigns where the dialer places calls ahead of the agents and needs to know which ones are worth connecting. The restriction is spelled out in the AMD manual-mode warning.

The AMD decision, end to end

Here's the whole flow once it's wired up — from the moment the far end answers to where the call ends up:

flowchart TD
  A[Outbound call answered] --> B[Routed to exten 8369]
  B --> C[AMD analyzes opening seconds]
  C --> D{Human or machine}
  D -->|Human| E[Connect to agent]
  D -->|Machine, no message| F[Hang up]
  D -->|Machine, leave message| G[Play voicemail prompt]
  E --> H[Live conversation]
  F --> I[Logged as machine status]
  G --> I

Two branches matter. On a human verdict, the call goes to an available Agent just like a normal connect. On a machine verdict, you've got a choice: hang up immediately, or play a recorded message and then hang up. Both outcomes get logged so you can measure how often AMD fired.

Leaving a message on the machines

Hanging up on every voicemail is fine for some campaigns, but for others a dropped message is a soft touch that earns callbacks. To leave one, set the campaign's "AMD send to vm exten" to Y, then put a pre-recorded prompt filename in the "Answering Machine Message" field. That can be a built-in prompt name or an audio-store ID. This is effectively a Voicemail drop — a canned message left on detected machines without tying up an agent. The full setup is in the AMD send-to action.

The prompt audio has to be in the right format: GSM 8k/8bit mono, or WAV PCM 8k/16bit mono. The easiest way to record one is to dial 8168 from a phone attached to the system, enter the PIN, and read your message; it plays back a prompt ID you then paste into the campaign. The recording workflow and the format gotchas are covered in recording the answering machine message.

Reading the results

AMD isn't a fire-and-forget setting. You need to watch what it's doing, and VICIdial gives you the data. Every machine-detected call gets a machine Disposition and Called status, so you can pull a report and see exactly how many calls AMD diverted and how many it passed through. Those status codes are the audit trail for the whole thing — what they mean and how to read them is in AMD statuses explained.

The two numbers you care about most are AMD's hit rate against your overall Contact rate. If your contact rate drops after turning AMD on, or agents start complaining about dead air the moment a call connects, that's the tell — AMD is hanging up on live people. Loosen the settings, or turn AMD off in favor of a longer dial timeout. The relationship between AMD and Drop rate is worth understanding too, since over-aggressive detection can show up in both metrics. See how CPD lowers your drop rate, and the broader guide to lowering your VICIdial drop rate.

If you're running a serious campaign on managed infrastructure, you want headroom to test these settings on real traffic without fighting the box. That's the whole idea behind a dedicated single-tenant server. See VICIfast pricing — provisioned in under 40 seconds, your own dialer, your own carrier.

Tuning and false positives

AMD is sensitive to your lead quality and your telecom lines, so the defaults rarely fit perfectly. Tuning is a loop: run a batch, pull the machine statuses, listen to a sample of recordings, and adjust. The trade is always the same.

• Tighter settings catch more machines — but raise the false-positive rate, hanging up on real people.
• Looser settings protect live answers — but let more machines slip through to agents.
• There is no universally correct setting. It depends on your lists, your dial method, and the lines your carrier hands you.

When AMD goes wrong, an AMD false positive is the failure mode that costs you money, because it throws away a live answer you paid to reach. Always tune toward protecting humans first, then tighten only as far as your data lets you. The accuracy-vs-aggression balance is the subject of the AMD log report.

AMD can also pick up on related signals on the line. A Beep detection step helps time a dropped message so it lands after the machine's tone rather than over the greeting, and Fax detection keeps fax lines from being treated as either humans or normal machines. These edge cases get their own posts in what call progress detection is and VICIdial fax detection.

CPD vs AMD

You'll hear both terms, and they're related but not identical. CPD (call progress detection) — Call Progress Detection — is the broader idea: analyzing call progress tones like ringing, busy, intercept (SIT) tones, the answer event, and answering-machine beeps. AMD is the narrower, practical slice of CPD that nearly everyone runs today, focused specifically on the human-versus-machine question after answer.

In VICIdial, the implementation you'll actually configure is ViciAMD — the software AMD path through extension 8369. The dedicated hardware CPD that once hit ~97% accuracy is gone, so software AMD is the tool in your hands. We lay out the distinction in plain terms in viciAMD vs standard AMD.

When to use AMD — and when to skip it

AMD earns its keep on campaigns where the machine rate is high enough that the processing-time cost pays for itself. Cold consumer lists, time-of-day windows when most people aren't home, and large lead pools where agent time is the scarce resource — those are the cases where diverting machines materially improves agent productivity.

Skip it when your machine rate is low, when you're running manual or preview dialing (where it won't work anyway), or when a 22–26 second dial timeout already filters most voicemails for free. The decision tree — machine rate, dial method, tolerance for false positives — is laid out in when to use VICIdial AMD.

The summary version: AMD is a real tool with a real cost. Turn it on when the numbers justify it, tune it toward protecting live answers, watch your dispositions and contact rate, and don't be afraid to fall back to a longer dial timeout if it's hanging up on your people. Treat it as one lever among many in your Dialer pacing setup, not a magic switch.

Want a clean, dedicated VICIdial box to dial in your AMD settings on real traffic — your own carrier, your own dialer, nothing shared? Check VICIfast pricing and spin one up in under 40 seconds.