5 drawbacks of stock Asterisk AMD nobody warns you about

Stock Asterisk AMD — the app_amd application you configure in amd.conf — is the default answer to answering-machine detection on almost every Vicidial cluster. It ships in the box, costs nothing, and sets a single variable, AMDSTATUS, to HUMAN, MACHINE, or NOTSURE. For a lot of operators that is where the conversation ends.

It should not. app_amd is a timing heuristic: it listens to the first few seconds of audio, measures silences and word-like bursts, and guesses. That design tops out around 70–85% accuracy, and the way it fails is expensive in ways your reports never show you. Here are the five drawbacks that matter, ranked by how much money they quietly cost.

1. It drops live humans — 5 to 15% of them

This is the one that hurts most, because the victims are exactly the people you paid to reach. Stock AMD decides “human or machine” by timing the rhythm of the first few seconds: a pause, then a greeting of a certain length, then silence. The trouble is that real people do not answer on a metronome.

The fast greeting is the classic failure. Someone picks up and fires off “Hello? Who’s this?” with no pause — the most natural way to answer a call from a number you don’t recognize. The timing heuristic was waiting for an initial silence and a measured greeting; it got a clipped, overlapping burst instead, so it has nothing clean to measure and falls back to MACHINE. The silent pickup is the other half: a human answers, says nothing, and waits for you to speak. No greeting, no audio to time, same wrong verdict.

On stock AMD this misfires on roughly 5–15% of live humans. Worse, Vicidial then acts on the verdict — drop_call_seconds and amd_send_message set to HANGUP — and the call is gone before an agent ever connects. And here is the trap: it is logged as AMD, not as a dropped human. You never see the cost, so you never chase it. (We pulled this failure apart in your dialer is hanging up on real people.)

2. It’s blind to carrier false-answers (FAS)

A carrier false-answer is when the network reports the call as “connected” even though no human and no machine ever picked up. The SIP signaling says answered; the audio is dead air, a re-order tone, or an intercept message from the carrier — not the actual called party.

This is not a rounding error. Across roughly 2.3 billion answered calls a month, about 14% are FAS — more than one in every eight “answered” calls. Stock AMD has no category for this. It was built to distinguish a person’s greeting from a voicemail’s greeting, and on a FAS there is no greeting at all. So app_amd times the silence and guesses — sometimes MACHINE, sometimes a wrong HUMAN that routes a worthless connection to a paid agent, sometimes NOTSURE that you have to decide what to do with. Every one of those is a metric you can’t trust. We break the mechanics down in carrier false-answers explained.

3. It only knows two buckets — so it keeps you dialing spam traps

Stock AMD’s entire worldview is human vs machine. That binary leaves out a category that is quietly wrecking outbound programs: honeypots and spam-traps — numbers seeded by analytics networks specifically to catch dialers.

app_amd cannot flag a honeypot because it has nowhere to put it — a trap number answers like any other call, and the heuristic just calls it human or machine and moves on. So you keep dialing the exact numbers that are scoring you. Hit enough of them and your caller IDs get flagged “Spam Likely,” your answer rates collapse across your whole number pool, and now you have a caller-ID reputation problem that no amount of amd.conf tuning can fix. The detector that should have warned you was structurally incapable of seeing it. More on the reputation spiral in why your numbers get flagged Spam Likely.

4. It’s a tuning treadmill

There is a widespread belief that stock AMD is “fine, you just have to tune it.” The problem is that the correct tuning is not a fixed target — it moves underneath you.

The settings that work today won’t work next week

app_amd exposes a row of knobs — initial_silence, greeting, after_greeting_silence, total_analysis_time, silence_threshold and friends. The values that minimize errors depend on things you do not control: how old and warm the list is, the time of day, and which carrier happens to route the call. Fresh leads answer differently than a list you’ve been hammering for a month. Morning calls behave differently than evening ones. Each carrier shapes the audio slightly differently.

And every adjustment is a trade, not a fix

So you re-tune, and re-tune again. Worse, the knobs pull against each other: tighten the thresholds to catch more answering machines and you drop more live humans (drawback #1); loosen them to save humans and you let more machines through to agents. You are not climbing toward an optimum, you are trading one error for another along a fixed curve. We mapped that trade-off in the narrow middle of amd.conf tuning.

5. There’s no real analytics — so the problem stays invisible

The final drawback is what ties the other four into a permanent state. Stock AMD gives you a flag, not a record. AMDSTATUS lands on the call as HUMAN, MACHINE, or NOTSURE, Vicidial acts on it, and the call moves on. There is no per-detection log you can query, no breakdown of how often the HUMAN verdict was actually a FAS, no way to see how many dropped “machines” were live people.

That blindness is the reason the first four drawbacks never get fixed. You cannot manage what you cannot measure. The 5–15% of humans you drop are filed under AMD and never surface. The 14% FAS rate is buried inside your “answered” count. The spam-trap dials look identical to good dials. The tuning treadmill keeps spinning because you have no instrument that tells you whether last night’s change helped or hurt. The cost is real and it is large — and it is completely invisible.

These aren’t bugs — they’re the design

Notice that none of these five are a misconfiguration you can patch. They are inherent to what stock AMD is: a timing heuristic with two output buckets. A heuristic that measures silence will always be beaten by humans who don’t pause and by carriers that fake the connection, and two buckets can never represent FAS or a honeypot no matter how you set amd.conf.

The alternative is to stop timing the silence and start classifying the sound. AMDY is an AI model that reads the acoustic signature of the answer audio itself — what the call actually sounds like, not how long the gaps are. That changes every line above: 99% accuracy with a decision in under 200 ms; it hears a FAS for what it is and flags honeypots and spam-traps to protect your caller-ID reputation; and instead of one flag it gives you 23 analytics reports plus a queryable per-detection log, so the dropped-human cost finally becomes something you can see and fix. It is telco-agnostic — keep your carrier — and installs on Vicidial, Asterisk, FreeSWITCH, or Issabel with one bash command in about five minutes.

For the full picture, the Vicidial AMD guide walks through every output category and how the install works.

FAQ