Beyond the Beep: How Premium ML Answering Machine Detection Outperforms Traditional AMD

An outbound call connects. For roughly the next two and a half seconds, a piece of software most teams have never audited decides what happens to that call: bridge a live agent, wait for a beep and drop a message, or hang up. Get it right and your agents spend their day talking to people. Get it wrong in one direction and an agent sits through fifteen seconds of somebody's voicemail greeting. Get it wrong in the other direction and a real human says "Hello? … Hello?" into dead air, hangs up annoyed, and files the number away as spam.

That software is answering machine detection — AMD — and most of what runs in production today is built on techniques from the era when an "answering machine" was a physical box with a cassette tape in it.

This article is about the difference between that traditional approach and the premium, ML-based detection engine we build at IQAAI: what each one actually measures, where the old heuristics genuinely still work, where they quietly fail, and why the arrival of on-device call screening — an iPhone politely answering on its owner's behalf — has turned a manageable accuracy problem into a category problem that timer-based AMD cannot see at all.

How Traditional AMD Actually Works

Strip away the vendor marketing and nearly every classical AMD implementation — Asterisk's app_amd, FreeSWITCH's mod_amd, and the detection layers inside most dialers — measures the same handful of things: when there is sound, and for how long.

The logic runs on energy, not meaning. A typical configuration reads like this:

; classic timer-based AMD — every value is a guess about human behavior
initial_silence      = 2500   ; humans answer and speak quickly
greeting             = 1500   ; humans say "hello?" briefly, machines monologue
after_greeting_silence = 800  ; humans pause and wait for you
between_words_silence  = 50
maximum_number_of_words = 3   ; more than 3 "words" of energy = machine
min_word_length      = 100
total_analysis_time  = 5000   ; give up and guess after 5 seconds

The model behind those numbers is a caricature, but a serviceable one: a human answers, says something short — "Hello?" — and stops, waiting for the caller to identify themselves. A machine answers and delivers an uninterrupted monologue: "Hi, you've reached… please leave a message after the tone." So the detector counts bursts of audio energy as "words," times the silences between them, and calls anything long and continuous a machine. Beep detection, where it exists, is a frequency detector listening for a sustained single tone.

To be fair to the approach: it is computationally free, it needs no models, and on clean calls against classic voicemail patterns it is respectable. That is why it survived for twenty years.

The Failure Modes Everyone Learned to Accept

The trouble is that every one of those timers encodes an assumption about how people answer phones, and people are not uniform.

• The slow "hello." Someone answers while driving, pauses, then speaks. initial_silence expires first. A live prospect is classified as a machine and hung up on — the most expensive mistake in outbound, and it is invisible because nobody reviews calls that were never bridged.
• The long human greeting. A receptionist answers: "Good afternoon, thank you for calling Meridian Dental, this is Amber, how can I help you?" That is far more than three "words" of continuous energy. Human classified as machine.
• The human-voiced voicemail greeting. Personal voicemail greetings are recorded by the very human whose cadence the heuristics model. A short, casual "Hey, it's Sam — leave a message" fits the "human" template almost perfectly. Machine classified as human; agent connected to a recording.
• IVRs, hold music, and early media. Carrier ringback, IVR menus, and queue music are neither greeting patterns. Timer AMD has no category for them, so it forces them into one of two wrong answers.
• Geography and carrier variance. Silence padding, compression, and early-media behavior differ by carrier and country. Teams end up maintaining per-route timer profiles by trial and error — tuning a caricature, one campaign at a time.

Accuracy claims for this class of detection tend to be measured on clean, cooperative test sets. Run it against real traffic — mobile networks, speakerphones, businesses, international routes — and the error rate is a tax you pay on every campaign, split between wasted agent minutes and silently discarded live prospects.

For years that tax was tolerated because the alternatives were expensive. Then the problem changed shape entirely.

Then Phones Started Answering Themselves

With iOS 26, Apple shipped Call Screening: for calls from unknown numbers, the phone itself can answer, and a synthetic voice asks the caller to state their name and the reason for the call before the owner ever hears a ring. Google's Pixel phones have offered Call Screen since 2018. Between them, a growing share of outbound calls to mobile numbers are now answered by something that is neither a human nor a voicemail machine.

Listen to what traditional AMD hears in that moment: prompt speech onset, natural cadence, a sentence-length utterance, then polite silence. Every timer votes human. The dialer bridges an agent — who is now negotiating with an operating system:

"If you record the name and reason for calling, I'll see if this person is available."

An agent who fumbles this gets screened out. A voice agent that doesn't recognize it burns its opening script on a machine that is transcribing it for a skeptical human. And whatever happens next — the real person picking up, or the call sliding into voicemail — traditional AMD has already committed to its answer. It fired once, guessed "human," and left.

This is not a tuning problem. Screening is a third class of call answer with its own grammar and its own outcomes, and detecting it requires understanding the words being said. That is exactly what a timer cannot do — and exactly where an ML pipeline starts.

What a Premium AMD Pipeline Actually Does

Our engine replaces the timer caricature with a streaming perception pipeline. Several detectors run concurrently on the live media, and a fusion layer maintains a probability for every class — human, machine, IVR, screening — updated frame by frame. The console screenshots in this article are the engine's own replay of real decisions; nothing is mocked up.

The stages, in the order the audio meets them:

1. Neural voice activity detection. A neural VAD (we use Silero) produces a per-frame speech probability alongside raw energy, with separate open/close thresholds so the engine knows precisely when speech starts, stops, and hesitates — not merely that energy crossed a line. The greeting's fine-grained rhythm is itself a feature: the timing information traditional AMD uses survives in the ML pipeline as one input among many, rather than the entire verdict.

2. Streaming ASR with early peeks. The engine does not wait for the greeting to finish. As soon as enough audio accumulates it issues short peek decodes — partial transcriptions that come back in 150–350 ms — and full segment decodes when the speaker pauses. A peek containing "you've reached the voicemail of" settles the question long before any silence timer would expire.

3. Class posteriors with guardrails. Every piece of evidence — VAD rhythm, transcript content, cue events — moves the posteriors. The guardrails matter: a lone "Hi." looks human, but the engine's lone_human guard refuses to finalize on one ambiguous word and waits ~300 ms for the next peek. On screened calls, that next peek reads "Hi, if you record the name…" — and what looked human resolves to screening. Low-confidence decodes are held rather than trusted.

4. Cue detectors. Voicemail beeps, screening-silence windows, and speaker changes are detected as discrete events and fused with the transcript context — so a beep confirms an already-suspected machine and precisely times the message drop, rather than being a lone frequency detector that hold music can spoof.

5. Interim → final → revised decisions. This is the structural difference that makes screening detectable at all. Traditional AMD fires once and disconnects its brain. Our engine emits an interim label early, commits a final when confidence and deadlines require one — the dialer needs an answer it can act on — and keeps listening. If the world changes, the decision is revised and re-emitted. A screened call finalizes as screening in under three seconds, and eight seconds or twenty seconds later becomes takeover or voicemail_fallthrough the moment the evidence arrives.

Screening Is a State Machine, Not a Label

Once screening is detected, the engine enters a monitoring loop that timer AMD has no equivalent for. The screener speaks, then leaves deliberate silence for the caller's response; the engine tracks these screening_silence windows and watches for speaker changes. Two outcomes matter, and they demand opposite actions from your dialer:

Human takeover. The owner heard the transcribed reason and picked up — "Thanks John, please stay on the line." The engine detects the speaker change, revises to takeover, and your platform bridges an agent immediately, ideally armed with the context that this prospect just actively chose to take the call. These are, by definition, the highest-intent connects in the campaign.

Voicemail fallthrough. The owner declined or didn't respond, and the screener hands off: "This person is not available, if you would like to leave an additional message, please reply after the tone." The engine revises to voicemail_fallthrough, and the call is handled like a machine — drop a message after the beep, or release the line and save the minutes.

A dialer that treats screened calls as "human" burns agent time at exactly the moment a machine is transcribing the agent's confusion for the prospect to read. A dialer that treats them as "machine" hangs up on the highest-intent people in the list. Only a detector that models screening as a state — with takeover and fallthrough as tracked outcomes — gets both cases right on the same call.

Latency Is a Compliance Feature

Speed is not a vanity metric in AMD; it is load-bearing. In the US, the FTC's Telemarketing Sales Rule effectively requires connecting an answered call to a live agent within two seconds of the person's completed greeting, and caps abandoned calls at 3% of answered calls per campaign; Ofcom's persistent-misuse regime in the UK pushes in the same direction. Every millisecond your AMD spends deliberating comes out of that budget — which is precisely why traditional AMD's five-second total_analysis_time ceiling gets tuned down until its accuracy collapses.

The streaming architecture resolves the trade-off instead of shifting it. Because peeks arrive continuously, the engine finalizes as soon as the evidence is sufficient, not when a timer expires: unmistakable machine greetings have finalized in as little as ~200 ms, and across the sessions shown here the final decision lands at a median of roughly 2.7 seconds — inside the compliance window, with the screening cases correctly parked in a state that has no agent waiting on it at all.

If You Can't Replay It, You Can't Fix It

The quietest failure of traditional AMD is that it is unauditable. It emits HUMAN or MACHINE and discards everything it knew. When a campaign's connect rate drops, or a carrier changes its early-media behavior, or a client disputes an abandoned-call figure, there is nothing to inspect — just a verdict with no working shown.

We consider observability part of the detector, not a bolt-on. Every call produces a structured event stream — VAD frames, segment opens and closes, each ASR decode with its individual latency, posterior contributions, cue firings, grace windows, revisions — and the console renders any historical call as the full timeline you see in these screenshots. A single 32-second screened call generates roughly a thousand events and eight ASR decodes; when a decision is wrong, the reason is visible in one replay, and the fix becomes a model or threshold change validated against the recorded corpus rather than a timer nudged by folklore.

The Honest Comparison

When Traditional AMD Is Enough

In the spirit of honesty: if you dial low volumes into a single geography, your traffic is mostly landlines and classic voicemail, your greetings-to-agents economics are forgiving, and screening-capable smartphones are rare in your contact lists, timer-based AMD plus a beep detector will serve you adequately — and it costs nothing. Replacing it would be buying accuracy you cannot yet monetize.

The calculus flips when any of these are true: agents are your dominant cost and their talk-time utilization is a KPI; your abandonment rate lives near a regulatory ceiling; you leave voicemail messages at scale and mis-timed drops are silently discarded; you run voice AI agents that must respond to a screening prompt coherently; or your connect rates to mobile numbers have been sliding since 2025 for reasons your current AMD reports as "human, short call." That last one is call screening, and no timer configuration will ever surface it.

Where This Fits

We offer this detection engine as part of our AI answering machine detection and call screening detection solutions — as a service integrated into your dialer or voice AI stack, or deployed into your own infrastructure alongside the FreeSWITCH and Voice AI platforms we build and operate. The same engine that produced the screenshots above runs against live SIP/RTP media and emits its interim, final, and revised decisions over a socket your platform consumes in real time.

If your outbound stack is still guessing from silence timers — or your team has started asking why so many "humans" hang up after four seconds — bring us a sample of your call recordings. We will run them through the engine and show you, decision by decision, what your current AMD has been missing.