FreeSWITCH AMD vs Asterisk AMD vs AI AMD: a technical comparison

Asterisk AMD: app_amd and amd.conf

Asterisk’s AMD module, app_amd, was written for a simpler era of telephony. It works by analyzing the first few seconds of audio after a call is answered and applying a set of timing-based heuristics configured in amd.conf.

The core logic runs something like this: measure silence periods, count what it calls “words” (runs of audio above a silence threshold), and compare the timing of those words against configured thresholds. A human typically speaks a short greeting and then waits. A voicemail typically plays a longer uninterrupted greeting. The algorithm tries to separate the two using InitialSilence, MaximumWordLength, SilenceBetweenWords, and MinimumWordCount.

On clean landline audio with a quiet background and a cooperative voicemail, this works reasonably well. On modern mobile traffic — compressed codecs, variable-length greetings, humans who say “Hello?” fast and then wait — it degrades badly. The practical accuracy ceiling for tuned app_amd on real-world outbound lists is 70–85%. You can tune it higher on one narrow campaign and watch it fall apart on the next. Full amd.conf parameter reference →

The other structural weaknesses: app_amd has no concept of carrier false-answers (a network that signals “connected” without anyone picking up). It doesn’t detect honeypots or spam traps. And because it waits to count words, it introduces latency — the classification doesn’t arrive until the engine has heard enough audio, which can mean waiting 1.5–3 seconds while a human wonders why no one is responding.

FreeSWITCH AMD: mod_vmd and mod_avmd

FreeSWITCH takes a fundamentally different approach. Its two AMD modules — mod_vmd (Voicemail Detection) and mod_avmd (Adaptive VMD) — are not trying to classify the greeting itself. They are listening for the beep that follows a voicemail greeting. The distinction matters.

mod_vmd uses energy-based detection: it watches for a sustained single-frequency tone in the audio stream that matches the pattern of a voicemail beep. When it finds one, it fires an event that your dialplan can act on — typically to start recording a message or to flag the call as machine.

mod_avmd uses an adaptive version of the same idea. Rather than hard-coding the beep frequency, it adapts to the tone it finds, which makes it marginally more robust against beeps that drift in pitch (some carrier voicemail systems use tones slightly off the canonical 440 Hz).

The practical consequence of this design: FreeSWITCH AMD is fast and reliable at detecting the beep, but it’s doing so after the voicemail greeting has already played. For outbound dialing, that means the system is waiting through the entire greeting (“You’ve reached John, I’m not available…”) before it can act. Humans who get to voicemail are missed — the module only fires after the beep. FAS calls (no audio at all) are invisible to both mod_vmd and mod_avmd, because there’s no beep to detect.

For FreeSWITCH deployments doing outbound dialing, the usual workaround is to combine mod_avmd with a timeout: if the beep is detected, flag as machine; if the call exceeds N seconds without a beep, assume it’s a human. This introduces latency and a separate accuracy problem (long-greeting humans get dropped at the timeout).

AI AMD: acoustic ML classification

AI AMD — AMDY specifically — solves the problem with a machine-learning model trained on the acoustic signature of what answered the phone, not on the timing of silence or the presence of a beep.

The model was trained on hundreds of millions of real call answers across call types, carriers, codecs, and geographic regions. It classifies based on what the audio sounds like, not on thresholds you’ve tuned against a specific campaign. That difference is why it works without configuration: the pattern of a voicemail greeting sounds different from a human saying hello sounds different from a carrier intercept, and the model has seen enough of each to separate them with high confidence.

The classification returns in under 200 milliseconds — before an agent is connected, before a second of audio has played. AMDY also classifies categories that neither Asterisk AMD nor FreeSWITCH AMD can see at all: carrier false-answers (five distinct FAS patterns), honeypots and spam traps, disconnected carrier intercepts, fax tones, and dead air.

The integration model is an add-on, not a replacement. AMDY receives the answer audio as a WebSocket stream from your Asterisk or FreeSWITCH server and returns the classification. Your telephony stack stays exactly as it is. ViciDial admins install it with a single script in about five minutes.

Side-by-side comparison

Which one to use — and why the choice isn’t always obvious

If you’re running ViciDial on Asterisk and your call list is clean landline traffic, stock app_amd with careful tuning might sit at 80%+ accuracy. That’s the scenario it was built for, and the 5-minute AI AMD install might not be your first priority. Measure first with the 50-call audit before you optimize anything.

If you’re on FreeSWITCH and doing outbound dialing (not just voicemail drop), mod_avmd is not the right primary AMD. Its beep-detection design is excellent for the narrow use case of voicemail deposit systems where you want to wait through the greeting and record after the beep. For prospecting calls where an agent needs to connect to a human starting detection in 1/8 of a second, it’s the wrong tool — regardless of how well you configure the timeout.

The consistent answer across both telephony stacks is that heuristic and tone-based AMD share the same ceiling: they can’t classify what they weren’t designed to see (FAS, honeypots, carrier intercepts), and they can’t train themselves on new carrier patterns as networks change. An ML model can.

A note on coexistence

AMDY doesn’t require you to remove app_amd or mod_avmd from your stack. The WebSocket add-on model means you can run AMDY as your primary classification engine while keeping the existing modules available as a fallback if the WebSocket connection drops. This is how most production installs are set up: AMDY handles the normal path, stock AMD handles the edge case where the AI endpoint is unreachable.