Answering machine detection decides, in the first few seconds of an outbound call, whether the audio coming back is a live person or a recorded greeting. Get it right and your agent talks to humans. Get it wrong and you either burn a lead or, on a telemarketing campaign, trip a regulator's abandonment limit.
What answering machine detection actually does
The job is a classification problem with a deadline. A call connects, audio starts flowing, and something has to label the far end before the agent commits to a script. The labels that matter in practice are narrower than the name suggests: a live human, a voicemail greeting, an automated menu, a fax tone, or no confident answer at all.
Every platform exposes this as a small vocabulary of verdicts. Twilio's voice API returns human, machine_start, fax, or unknown in its faster mode, and splits the machine case into machine_end_beep, machine_end_silence, and machine_end_other when you ask it to wait for the greeting to finish, per Twilio's answering machine detection reference. LiveKit's implementation returns human, machine-ivr, machine-vm, machine-unavailable, or uncertain.
That unknown bucket is the one to watch. It is not an error state. It is the system telling you it ran out of time.
Why the signaling layer cannot answer this for you
The obvious place to look for the answer is the call setup itself, and it is not there.
When a carrier's voicemail system picks up an outbound SIP call, it returns the same response sequence a person does: a provisional 100, a 183 session progress, then a 200 OK. One documented account of integrating Twilio's Elastic SIP Trunking reports that the only signaling-level difference was time to answer, which is far too noisy to classify on. In that same setup, the headers that could disambiguate a redirected call, Diversion and History-Info, were stripped by the trunking provider before they reached the application.
The practical consequence is that this problem can only be solved in the media path. You have to listen to the audio.
The two ways answering machine detection is built
Two architectures dominate, and they fail differently.
Threshold and cadence heuristics
The older approach measures the shape of the audio rather than its meaning. It watches how long the far end talks without pausing, how long the silences run, and whether a tone appears. A voicemail greeting is a long uninterrupted stretch of speech. A human says two words and stops.
Twilio exposes these thresholds directly, and the defaults tell you how the tradeoff is priced: 2,400 ms of speech before a machine verdict, a 1,200 ms speech-end threshold, a 5,000 ms silence timeout, and a 30-second overall detection timeout that you can tune between 3 and 59 seconds. Raising the speech threshold buys accuracy on chatty humans and costs you time on every single call.
Transcript and model classifiers
The newer approach transcribes the opening audio and classifies the text or the learned audio features. Per LiveKit's telephony documentation, its detector runs a fast heuristic path for short greetings followed by silence and falls back to a language-model classifier when a transcript needs actual reasoning, with a 2.5-second human speech threshold and a 20-second timeout by default. That documentation is candid that behavior on models it has not evaluated is not guaranteed, which is a dependency the older approach does not carry.
Published research has largely moved to the learned end, using transfer learning from pre-trained audio models to train classifiers that run on a live stream, with reported test-set accuracy in the mid-90s. Timing signals have not disappeared from these systems. Coarse silence duration, which is a different signal from the beep tone a mailbox plays once its greeting finishes, still contributed measurable accuracy gains in at least one such classifier. Even in a learned system, plain timing carried information the model had not already extracted.
How the two compare
| Threshold and cadence | Transcript and model classifier | |
|---|---|---|
| Decides on | How long the far end speaks, how long it pauses, whether a tone appears | What the opening audio says, or learned features of how it sounds |
| Typical tunables | Speech threshold, speech-end threshold, silence timeout, overall timeout | Speech and silence thresholds, model choice, overall timeout |
| Published defaults | Twilio: 2,400 ms speech, 1,200 ms speech-end, 5,000 ms silence, 30 s timeout | LiveKit: 2.5 s human speech, 20 s timeout |
| Breaks on | Humans who answer with a full sentence, and unusually short greetings | Transcription errors, and models the vendor has not evaluated |
| Marginal cost per call | None beyond the wait | Inference time plus a dependency on a model provider |
| Recovers from ambiguity by | Timing out into an unknown verdict | Escalating from the fast path to the classifier |
The two are not mutually exclusive, and the better implementations layer them. LiveKit's fast path is a cadence heuristic; the classifier only runs when the cadence signal is not decisive. That ordering matters, because it keeps the cheap path on the common case and pays for inference only on the calls that are genuinely hard.
What accuracy is realistic
Treat any vendor's headline accuracy as a claim about their test set, not about your traffic. The most useful public numbers come with their denominators attached.
A 2026 arXiv paper on real-time voicemail detection using temporal speech activity features reports 96.1% combined accuracy, or 734 correct out of 764 telephony recordings, split into 99.3% on an expert-labeled test set of 140 and 95.4% on a held-out production set of 624. In production validation across 77,000 calls it held a 0.3% false positive rate and a 1.3% false negative rate, with end-to-end inference in 46 ms on a dual-core CPU.
Two things in that paper deserve more attention than the accuracy figure.
The first is that the two error rates are not symmetric, and they should not be. A false positive and a false negative cost different amounts: a false positive on a live human risks a regulatory violation, while a false negative on a machine only wastes a dial.
The second is a negative result. The authors report that adding transcription keywords or beep-based features did not improve their best real-time configuration and increased latency substantially. Beep detection is exactly what a mode like Twilio's DetectMessageEnd is built around, and it is the intuitive thing to reach for. Measured under a real-time budget, it did not pay for itself.
Twilio states the limit plainly in its own documentation: because not all humans and not all voicemail greetings follow similar patterns, detection will not always return the right answer.
The compliance stake, in two numbers
This is where a misclassification stops being a wasted dial and becomes a regulatory event, and it is the part most engineering discussions skip.
Under 47 CFR 64.1200(a)(7), a telemarketing call is "abandoned" if it is not connected to a live sales representative within two seconds of the called person's completed greeting. Abandoning more than three percent of calls answered live by a person, measured over a 30-day period for a single calling campaign, is a violation. Note the scope: this rule governs telemarketing calls, not every outbound call your platform might place.
Now put that against how a human verdict is actually reached. Twilio treats speech as complete only once its speech-end threshold of silence has elapsed, 1,200 ms by default. On someone who answers with a word or two, waiting out that silence is most of the work, and it spends 1,200 of the regulation's 2,000 ms before your agent can begin connecting anyone. The 2,400 ms speech threshold is a different setting, the one that trips a machine verdict on continuous speech, so it never sits on the human path at all.
The two clocks are offset rather than identical, which is what makes this easy to miss. Detection starts when the greeting starts; the abandonment window opens only once the greeting finishes. They still compete, because the verdict and the handoff both have to land inside that window. A false machine verdict on a live human produces exactly the outcome the rule defines as abandonment, and widening the speech-end threshold to stop clipping slow talkers spends whatever margin is left.
A detector tuned to be confident is a detector that is late. That is the actual tradeoff, and it is a policy decision, not a tuning decision.
The latency cost nobody budgets for
Detection is not free even when it is correct.
In the faster mode, a verdict arrives as soon as the party is identified. In beep-waiting mode, the call sits through the entire greeting before your agent hears anything. Twilio bounds that wait with a detection timeout that defaults to 30 seconds and is configurable from 3 to 59, and any human on the other end of it is listening to silence.
The asynchronous variant has an infrastructure cost too: on Twilio it consumes one of a per-call limit of four forked audio streams, which can starve transcription or recording features that need the same resource.
How to test answering machine detection before you dial
None of this is knowable from a dashboard. Detection accuracy is a property of your carrier mix, your target geography, and the greetings your specific contacts have recorded, so it has to be measured on your own traffic.
Cekura treats the answer classification as a testable layer rather than a vendor setting. Cekura places simulated outbound calls into controlled scenarios, including voicemail greetings of varying length, IVR menus, and humans who answer with a long sentence rather than a short one, then scores what the agent did with each verdict. Cekura's public benchmark methodology, 7 configurations across 82 scenarios with 3 retained repeats, is the same frozen matched design: every platform receives an identical system prompt, identical tool definitions, and identical test data, and calls that fail to connect stay in the denominator rather than being quietly dropped.
That last detail is what makes a number comparable. A detection rate calculated only over calls that connected cleanly is not the rate your campaign will experience.
Four things are worth measuring separately, because they move independently:
- False positive rate on humans. Your compliance exposure. Weight this highest.
- False negative rate on machines. Your wasted-spend number, and the cheaper of the two errors.
- Time to verdict, at p90 and p99. Averages hide the calls that time out. The tail is what your callers experience.
- Behavior on an unknown verdict. Decide the fallback deliberately. A system that treats uncertainty as "human" and one that treats it as "machine" have opposite failure signatures.
Cekura pairs that pre-launch suite with production monitoring, because greeting patterns drift as carriers change their default mailbox prompts. A threshold tuned against last quarter's traffic is an assumption, and Cekura re-scores it against live calls rather than leaving it unverified. For the wider call-path checks that sit underneath this, our guide to telephony testing covers connectivity, audio quality, and keypad input, and the outbound voice AI QA guide covers campaign-level testing. If your interest is specifically the mailbox case rather than the general classification problem, our voicemail detection explainer goes deeper on greetings and beeps.
Frequently asked questions
Is answering machine detection the same thing as voicemail detection?
Not quite. Voicemail detection is the narrower job of spotting a mailbox greeting. Answering machine detection is the full classification step, which also has to separate humans from IVR menus, fax tones, and carrier messages such as "the number you have dialed is unavailable". In casual use the terms are swapped freely, and most platforms ship one feature covering both.
How accurate is answering machine detection in practice?
Published research on learned classifiers reports accuracy in the mid-90s, with one 2026 paper measuring 96.1% across 764 recordings and a 0.3% false positive rate over 77,000 production calls. Your own rate will differ, because accuracy depends on your carrier mix and the greetings your contacts have recorded. Measure it on your traffic.
Does answering machine detection add latency to the call?
Yes, always. A verdict needs audio, and audio takes time. In beep-waiting mode the agent stays silent until the greeting ends, a wait Twilio bounds at 30 seconds by default and 59 at most. Even the faster mode has to sit through its speech-end threshold, 1,200 ms by default, before it will call the far end human. Cekura measures time to verdict at p90 and p99 rather than on average, because the tail is what callers actually hear.
Can I detect an answering machine from the SIP signaling instead of the audio?
Generally no. Carrier voicemail returns the same response sequence as a human answer, and the headers that would identify a redirect are often stripped by the trunking provider. The classification has to happen in the media path.
What happens when the detector is not sure?
It returns an explicit uncertainty verdict, such as unknown or uncertain, usually after a timeout. This is a configuration decision rather than a bug: you choose whether an unsure call is treated as a human or as a machine, and the two choices have opposite risks. Cekura tests both fallback paths, since the default is rarely the right answer for a given campaign.
Does answering machine detection create compliance risk?
It can reduce or create it depending on tuning. Federal rules define an abandoned telemarketing call as one not connected to a live representative within two seconds of the called person's completed greeting, capped at three percent of live-answered calls over a 30-day campaign window. A detector that labels a human as a machine produces exactly that outcome, so false positives carry regulatory weight that false negatives do not.
