Voicemail Detection Latency: The Millisecond Budget

Written by: Matt Beucler, CEO, Plura AI

Key Takeaways

• Voicemail detection latency works as a controllable budget with five distinct stages, each with its own settings.
• The audio analysis window and silence thresholds drive most AMD latency, while classification compute contributes only about 46 ms.
• Each stage connects to specific, tunable parameters that trade speed against accuracy and FCC compliance risk.
• Platform defaults vary widely, so teams need per-campaign tuning and carrier-level audio control to hit target operating points.
• Plura AI gives operators carrier-grade control over voicemail detection latency; see how your own call volume performs in a live walkthrough.

The Problem: Voicemail Detection Latency As a Millisecond Budget

Engineers staring at a call log showing 2.8 seconds of dead air face a diagnostic problem before they face a tuning problem. Without a stage-by-stage decomposition, the only available move is to tighten the overall detection timeout and watch what breaks. That approach produces two failure modes at once: accuracy degrades because the classifier loses audio evidence, and agent idle time compounds across thousands of calls because the wrong stage was shortened.

The compliance dimension raises the stakes. Under 47 C.F.R. § 64.1200(a)(7), a call is abandoned if no agent connects within two seconds of the called party’s completed greeting, and the FCC caps abandoned calls at 3% of live-answered calls per campaign over a rolling 30-day period.² AMD false positives count as abandoned calls under FCC rules: when AMD misclassifies a live human as a machine and the dialer disconnects, a live person answered and no agent connected. Every millisecond of unnecessary detection delay narrows the window between the end of the greeting and the two-second compliance clock.

The budget framing resolves the diagnostic problem. When every millisecond maps to a named parameter, latency becomes a controllable engineering variable. The focus shifts from “why is AMD slow?” to “which stage is over-budget, and what does shortening it cost in accuracy?”

The Voicemail Detection Latency Budget: Five Stages You Can Tune

The table below decomposes total voicemail detection latency into its constituent stages. Each row represents a separate engineering decision with its own accuracy tradeoff.

Voicemail detection latency budget: stage-by-stage decomposition with controlling parameters.

Stage	Typical Duration	Controlling Parameter
Answer-to-audio-start (SIP answer supervision, post-dial delay)	Varies by carrier and codec negotiation	Carrier PDD, SIP 200 OK timing, codec negotiation
Audio analysis window (classifier observation period)	About 800 ms for ML-based classifiers to 5,000 ms for legacy rule-based systems	total_analysis_time (Asterisk), MachineDetectionTimeout (Twilio), machine_detection_time (Vobiz)
Silence and speech-end threshold (pause required before verdict)	About 800 ms (Asterisk after_greeting_silence) to 2,500 ms (Asterisk initial_silence)	after_greeting_silence (Asterisk), MachineDetectionSpeechEndThreshold (Twilio), VAD_EOS_DELAY (LumenVox)
Classification decision (model inference)	About 46 ms (Kumar Saurav’s 2026 classifier) to roughly 200 ms (first AI classification attempt)	Classifier architecture; 46 ms on a commodity dual-core CPU with a temporal-feature ensemble
Agent or handoff connection (webhook round-trip, queue routing)	Varies by webhook response time and agent availability	Webhook response time, async vs. sync AMD, agent availability, contact flow execution

The classification decision stage contributes the smallest share of latency. Kumar Saurav’s 2026 arXiv preprint (arXiv:2604.09675) reports end-to-end inference in 46 ms on a commodity dual-core CPU with no GPU, supporting 380+ concurrent WebSocket calls. The dominant latency contributors are the audio analysis window and the silence threshold, and both are fully configurable.

Answer-To-Audio-Start: Carrier And Codec Effects

The answer-to-audio-start stage covers everything between SIP 200 OK and the first voiced frame. Carriers, routes, and codec negotiation all influence this gap. High post-dial delay or slow answer supervision can consume a meaningful share of the two-second abandonment window before AMD even begins listening.

Operators usually cannot tune this stage directly inside AMD. They manage it by selecting carrier partners, routing profiles, and codec settings that minimize post-dial delay and reduce jitter buffer variance.

The Audio Analysis Window: Why Systems Need 2–3 Seconds

The audio analysis window sets the maximum time the classifier can observe audio before it must decide. Voicemail detection analyzes telephony audio in the first 2 to 5 seconds after a call is answered to determine whether a live person or a voicemail system picked up. Shortening this window reduces the evidence available to the classifier before it commits to a verdict.

Making a classification decision within about 1.5 seconds means the system has seen very little audio and accuracy is lower, while waiting 3 to 5 seconds provides substantially more signal and significantly improves accuracy. Voicemail greetings and live human answers can sound nearly identical in the first 200–400 milliseconds of a call, so early classification without extended context is unreliable.

Kumar Saurav’s 2026 study achieved 96.1% combined accuracy across 764 telephony recordings using 15 temporal features extracted from a pre-trained voice activity detector, with a 0.3% false positive rate and a 1.3% false negative rate across 77,000 production calls³. Adding transcription keywords or beep-based features did not improve the best real-time configuration and increased latency substantially. The audio observation window, not compute, sets the practical floor for decision time.

LumenVox’s Call Progress Analysis documentation confirms that legacy telephony AMD systems require multi-second audio windows of roughly 5 seconds to reach a stable human-versus-machine decision, and that with less than 1,800 ms of audio available, the classifier cannot distinguish between human residence and human business categories. LumenVox enforces a minimum value of 1,000 ms, below which the algorithm cannot reliably make any determination, so sub-second windows are not viable for rule-based AMD.

Silence And Speech-End Thresholds: The 1,200–2,500 ms Pause Requirement

The silence threshold defines how long the system must observe silence after speech ends before it commits to a verdict. This stage sits directly on the human detection path and often becomes the largest single contributor to perceived dead air on live calls.

Twilio’s Voice limitations documentation states that raising MachineDetectionSpeechEndThreshold delays human detection and can cause human silences to be misinterpreted as machine behavior. Twilio’s documented default for this parameter is 1,200 ms, so the system waits 1,200 ms of silence after speech ends before routing to an agent. That 1,200 ms sits inside the FCC’s two-second abandonment window.

Asterisk’s after_greeting_silence defaults to 800 ms: if silence after a greeting exceeds this value, the result is a HUMAN classification. VICIdial’s stock AMD configuration ships with between_words_silence defaulting to 50 ms, which determines how long a gap between words triggers a machine classification and acts as the most sensitive AMD tuning knob for carrier-specific behavior.

LumenVox’s VAD_EOS_DELAY defaults to 1,200 ms and governs how much silence after speech triggers an end-of-speech event; raising it to 1,500 ms can yield significantly better accuracy for machine-to-human misclassification-sensitive applications at the cost of 300 ms of additional delay. Each of these thresholds maps directly to the silence-and-speech-end-threshold row in the latency budget table. Shortening any of them reduces latency and increases the risk of misclassifying a slow-speaking human as a machine.

Classification Decision And Handoff: Small Compute, Big Variability

The classification decision stage covers model inference. Modern ML-based AMD completes this work in tens of milliseconds on commodity hardware, so compute rarely dominates the budget. The real variability appears in the handoff stage, where webhook round-trips, contact flows, and agent availability determine how quickly a live person hears a human voice.

Async AMD, efficient routing logic, and fast webhook responses keep this stage tight. Slow webhooks or deep queues can add seconds of delay even when AMD itself is fast.

Platform-Specific Latency Profiles Across Common Stacks

Those thresholds and windows look different on every platform. Twilio’s AMD exposes tunable thresholds with documented defaults of 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 configurable between 3 and 59 seconds.⁴ Twilio’s documentation acknowledges that AMD will not always return the correct answer, and that tuning its parameters involves explicit tradeoffs between accuracy and latency. Lowering MachineDetectionTimeout increases unknown results, lowering MachineDetectionSpeechThreshold increases false machine detections on short human responses, and raising MachineDetectionSpeechEndThreshold delays human detection.

Asterisk’s total_analysis_time defaults to 5,000 ms, which caps the entire decision. VICIdial’s stock AMD configuration ships with total_analysis_time at 5,000 ms, initial_silence at 2,000 ms, greeting at 2,000 ms, and after_greeting_silence at 1,000 ms. These defaults were calibrated in the Asterisk 1.4/1.8 era (2008-2010) and now yield a 15-25% false positive rate. After per-carrier tuning, VICIdial’s stock AMD accuracy improves to 85-92% with 4-8% false positives.

AWS’s official guidance for Amazon Connect Outbound Campaigns states that AMD analysis plus contact flow execution together should total 2 seconds or less after the greetingEndTimestamp. AWS defines AMD Detection Time as Contact Flow Started minus greetingEndTimestamp, and Flow Execution Time as connectedToAgentTimestamp minus Contact Flow Started, both retrievable from Contact Flow Logs in Amazon CloudWatch filtered by Contact ID.

LiveKit’s official blog reports a median (P50) time to detection of 840 milliseconds for its Agents AMD feature⁴. LiveKit’s AMD architecture runs detection outside the agent’s main loop using a short-circuiting rule in front of an LLM classification step, so easy cases stay fast and only ambiguous cases incur the cost of a model call. Pipecat’s voicemail detection documentation follows a similar pattern, gating the agent’s first reply on the AMD verdict while keeping the media path live during detection.

See how high-volume operators instrument voicemail detection latency at the carrier level and compare these profiles to your own traffic.

The Speed/Accuracy Tradeoff By Campaign Type

The right operating point depends on which failure mode costs more for a given campaign. Three common scenarios illustrate the tradeoff.

Outbound sales dialer. The priority is human detection speed. AMD analysis windows are typically 1.5 to 3 seconds, which is long enough for many live callers to notice the delay, and this silent gap is one of the most commonly reported negative experiences associated with predictive dialer calls. A target of 1 to 1.5 seconds for human detection requires shortening the analysis window and accepting a higher false-negative rate on machines when voicemail drops are not part of the campaign.

Voicemail drop campaign. The priority is full-greeting analysis. Beep detection is one of the most definitive AMD signals, but relying on it means waiting for the entire greeting to finish, 5 to 10 seconds into the call. Operators running voicemail drops widen the analysis window and accept the latency cost in exchange for near-zero false positives on machine classification.

Inbound AI voice agent with voicemail fallback. The priority is fast human detection with a graceful fallback path. LiveKit’s AMD routes any STT transcript through an LLM because the transcript is the strongest available signal, and for short utterances with no transcript it errs toward treating the call as human and hands control back to the agent immediately. This bias toward human classification is a sensible default when misclassifying a live person is the worst-case failure mode.

How To Measure Voicemail Detection Latency In Your Stack

Instrumentation is the prerequisite for tuning. Without per-stage timestamps, there is no way to attribute latency to the correct parameter. The measurement approach stays consistent across stacks: timestamp at answer, at first audio, at classification decision, and at agent handoff.

AWS documents the AMD Detection Time formula for Amazon Connect as Contact Flow Started minus greetingEndTimestamp, and Flow Execution Time as connectedToAgentTimestamp minus Contact Flow Started, both retrievable from Contact Flow Logs in Amazon CloudWatch filtered by Contact ID. Measuring from connectedToSystemTimestamp instead inflates the figure by including customer answer time, greeting duration, and PSTN carrier latency, which obscures the AMD-specific contribution.

For Asterisk and VICIdial stacks, log the SIP 200 OK timestamp, the first voiced frame timestamp, the AMDSTATUS set timestamp, and the agent bridge timestamp. The delta between the first voiced frame and AMDSTATUS is the audio analysis window plus silence threshold combined. The delta between AMDSTATUS and the agent bridge is the handoff stage.

Twilio’s documentation notes that AMD performance depends on webhook response time, making webhook round-trip latency part of the effective AMD decision budget. Logging webhook receipt and response timestamps separately isolates this contribution from the classifier’s own decision time.

Reducing Voicemail Detection Latency While Protecting Accuracy

The following levers are ordered by impact. Apply them sequentially and measure after each change before moving on.

• Shorten the analysis window before sharpening thresholds. Long windows cause human hang-ups even when classification is correct. Reduce total_analysis_time or MachineDetectionTimeout first, then observe the NOTSURE or unknown rate before touching silence thresholds.
• Tune thresholds per campaign rather than globally. Carrier audio processing degrades gap-based AMD because aggressive jitter buffers and silence suppression compress word boundaries, with jitter buffer variation ranging from 30–120 ms across carriers. A threshold calibrated for AT&T traffic often misfires on T-Mobile traffic.
• Bias “not sure” results toward routing to an agent. Practical AMD tuning guidance from operators recommends biasing “not sure” results toward routing to an agent. A live person left on hold usually represents the more expensive mistake.
• Use asynchronous AMD so the media path stays live. Vobiz recommends asynchronous machine detection via machine_detection_url so the media path stays live while detection runs in the background, with the agent’s greeting gated on the callback result rather than on call answer.
• Co-locate media and webhook endpoints with your telephony region. Twilio recommends hosting AMD-related media in the region closest to the Twilio region handling the call, naming us-east-1, eu-west-1, and ap-southeast-2 as the regions to co-locate against.
• Audit machine-dispositioned recordings weekly. A practical AMD audit method is to pull MACHINE-classified calls with duration greater than 8 seconds, since voicemail greetings typically conclude in 4–7 seconds and longer calls before the beep are often live humans.

Where Plura AI Fits In Your Voicemail Detection Stack

High-volume operators running outbound campaigns at scale face a structural problem that parameter tuning alone cannot solve. The carrier layer underneath the AMD stack sits outside their control. Audio quality, post-dial delay variance, and SIP answer supervision timing all affect what the classifier hears before it decides. When the carrier introduces 120 ms of jitter buffer variation, a threshold calibrated for 50 ms between-words silence will misfire on a predictable percentage of calls regardless of how carefully the AMD parameters are set.

Plura AI is its own FCC-licensed audio bridging carrier. Voice originates on Plura’s domestic infrastructure, not a third-party CPaaS. That means the audio the voicemail detection classifier receives is controlled at the source, rather than inherited from a reseller’s network with its own jitter characteristics. Plura issues branded caller ID at the carrier level and runs STIR/SHAKEN authentication on every outbound call¹, which affects pickup rates and therefore the distribution of call types the AMD classifier sees. Real-time DNC scrubbing runs before dial inside the platform, so the AMD system is not processing calls that should never have been placed.

For operators evaluating plans and rates, the relevant question is which platform provides the parameter control, carrier-level audio quality, and instrumentation to hit a chosen operating point reliably at volume. Plura’s AI Predictive Dialer is built for operators who need that level of control, and Plura’s platform infrastructure includes TCPA compliance support, DNC compliance support, and SOC 2 certification, which apply across its features including the AI Predictive Dialer.¹

Put the voicemail detection latency budget to work on your own call volume in a live session with the Plura team.

Conclusion: Using The Latency Budget To Evaluate Platforms

Voicemail detection latency breaks down into five line items, each controlled by a named parameter. The audio analysis window and silence threshold dominate the total. As noted earlier, classification compute is not the bottleneck. The handoff stage, driven by webhook response time and agent availability, often becomes the largest source of variability in production deployments.

When evaluating AMD platforms and configurations, the practical criteria are clear. Teams need to know which stages are instrumented and measurable, which parameters are exposed for per-campaign tuning, what the P95 latency looks like under production load, and whether the carrier layer underneath the classifier introduces audio quality variance that undermines threshold calibration. A platform that publishes a median detection time without disclosing the measurement methodology, the percentile, and the carrier mix is publishing a marketing number rather than an infrastructure metric.

Operators who need voicemail detection latency they can actually control benefit from a carrier-grade foundation under the classifier. Plura’s AI Predictive Dialer runs on Plura’s own FCC-licensed audio bridging carrier, with branded caller ID issued at the carrier level, STIR/SHAKEN authentication on every outbound call, and real-time DNC scrubbing before dial. The audio the classifier hears is controlled at the source.

Walk through the voicemail detection latency budget using your own call data with Plura and decide where to set your operating point.

---

Read Next

• Voicemail Detection Accuracy: 2026 Benchmarks and Tuning
• Voicemail Detection Parameters: Cross-Platform Guide
• Voicemail Detection Accuracy Benchmarks for Outbound Teams
• Voicemail Detection Providers Compared: Accuracy & AI (2026)
• How to Improve Voicemail Detection Accuracy: 2026 Guide