Voicemail Detection Parameters: Cross-Platform Guide

Written by: Matt Beucler, CEO, Plura AI

Updated 2026-09-09

Key Takeaways

• Voicemail detection parameters (AMD) control how outbound systems separate live humans from answering machines using four thresholds: timeout, speech, silence, and beep detection.
• Misconfigured parameters create wasted calls on voicemail and premature hang-ups on live prospects across every major platform.
• Twilio, Asterisk, Plivo, and Vonage expose different parameter names and defaults, so each platform needs its own tuning strategy.²
• Carrier-grade detection removes manual AMD tuning by analyzing audio patterns automatically instead of exposing raw thresholds.
• Plura AI’s AI Predictive Dialer delivers carrier-grade voicemail detection that removes the tuning burden so teams can focus on live conversations.

The Four Core Voicemail Detection Parameters Used Across Platforms

Every AMD implementation relies on the same four parameters, even though vendors label them differently. These shared concepts make it easier to translate settings from one platform to another.

Voicemail Detection Timeout

The timeout parameter, also called detection timeout or total analysis time, caps how long the system listens before returning a default result. If no decision is reached within this window, the call is classified as “unknown” or “not sure.” On some cloud APIs, voicemail detection timeouts can be configured up to 60 seconds (for example, Twilio caps machineDetectionTimeout at 60 s), while on-premises systems like Asterisk default to 5,000 ms (5 seconds) for total analysis time. A timeout that is too low increases unknown results. One that is too high adds dead air, which can cause live humans to hang up before an agent connects.

Voicemail Detection Speech Threshold Settings

The speech threshold defines the minimum duration of speech activity required to classify audio as a human greeting versus a machine greeting. Cloud platforms like Twilio express this in milliseconds, with machineDetectionSpeechEndThreshold defaulting to 1,200 ms, while Asterisk uses a combination of minimum word length (default 100 ms) and maximum word count (default 3 per the tuning guide, though the official amd.conf reference lists 2). A speech threshold set too low increases false machine detections on short human responses like “Hello?” A threshold set too high can miss brief voicemail greetings entirely.

Voicemail Detection Silence Threshold

The silence threshold governs how much silence triggers a decision. Two distinct silence parameters exist: initial silence (how long the system waits for audio before the greeting begins) and after-greeting silence (how much quiet after speech indicates the greeting has ended). Asterisk defaults to 2,500 ms of initial silence and 800 ms of after-greeting silence. Plivo exposes machine_detection_initial_silence (range 2,000-10,000 ms) and machine_detection_silence (range 500-5,000 ms). Incorrect silence values often drive false “human” detections on short voicemail greetings.

Voicemail Beep Detection

Beep detection determines whether the system listens for the distinct voicemail beep tone that follows a recorded greeting. When enabled, the system waits for the beep before triggering a message-drop action. Some platforms, like Twilio with machineDetection=DetectMessageEnd, listen for the end of the greeting message, while others listen specifically for the beep tone. Beep detection is critical for campaigns that drop pre-recorded messages, but it adds analysis time that can cause live humans to hang up if misconfigured.

See carrier-grade AMD in action on your own outbound campaigns.

Twilio Voicemail Detection Parameters

Twilio’s Voice API exposes AMD through the <Dial> verb’s machine detection attributes. Twilio’s official documentation defines the following key parameters:

Parameter	Default	Description
machineDetection	Not set	Set to Enable for detection only, or DetectMessageEnd to detect the end of the greeting message
machineDetectionTimeout	30 s (range 3–59 s)	Maximum time to wait for a machine detection result; default is 30 seconds with an allowed range of 3 to 59 seconds
machineDetectionSpeechThreshold	2,400 ms	Minimum speech duration to classify audio as a machine greeting
machineDetectionSpeechEndThreshold	1,200 ms	Silence required after speech to determine the greeting has ended
machineDetectionSilenceTimeout	5,000 ms	Initial silence window before declaring no-speech
asyncAmd	false	Enables asynchronous AMD with status callbacks

Twilio’s limitations documentation notes that AMD does not always return the correct answer and that tuning involves tradeoffs. A low machineDetectionTimeout increases unknown results. A low machineDetectionSpeechThreshold increases false machine detections on short human responses. A high machineDetectionSpeechEndThreshold delays human detection and can misinterpret human silences as machines.

Asterisk AMD Parameters

Moving from a cloud API to an on-premises PBX, Asterisk’s AMD module exposes a broader set of controls that require similar attention. Asterisk’s built-in AMD module is configured in amd.conf. The official Asterisk configuration reference documents the following parameters and defaults:

Parameter	Default	Description
initial_silence	2,500 ms	Maximum silence before greeting; if exceeded, call is classified MACHINE
greeting	1,500 ms	Maximum greeting length; if exceeded, call is classified MACHINE
after_greeting_silence	800 ms	Silence after greeting that triggers HUMAN classification
total_analysis_time	5,000 ms	Maximum time for AMD to reach a decision
silence_threshold	256 (scale 0–32767)	Audio energy level below which signal is treated as silence
min_word_length	100 ms	Minimum voice duration to count as a word
maximum_word_length	5,000 ms	Maximum duration of a single utterance
between_words_silence	50 ms	Silence required between detected words
maximum_number_of_words	3 (per tuning guide; official reference lists 2)	Maximum words in greeting before MACHINE classification

Asterisk’s AMD() application sets two variables after analysis: AMDSTATUS (HUMAN, MACHINE, or NOTSURE) and AMDCAUSE, which records the specific threshold that produced the decision, such as INITIALSILENCE, LONGGREETING, MAXWORDS, or TOOLONG.

Plivo Voicemail Detection Settings

Plivo’s Voice API exposes machine detection through the machine_detection parameter, which accepts true (detect and continue) or hangup (detect and disconnect). Plivo’s official API documentation defines the following tuning parameters:

Parameter	Default / Range	Description
machine_detection	true or hangup	Enables AMD or hangs up when a machine is detected
machine_detection_time	5,000 ms (range 2,000–10,000 ms)	Time allotted for machine detection
machine_detection_initial_silence	Range 2,000–10,000 ms	Initial silence before classification
machine_detection_initial_greeting	Range 1,000–5,000 ms	Maximum greeting duration to analyze
machine_detection_maximum_speech_length	Range 1,000–6,000 ms	Maximum speech duration before determination
machine_detection_maximum_words	Range 2–10 words	Maximum words before determination
machine_detection_silence	Range 500–5,000 ms	Silence after speech indicating end of greeting
machine_detection_answer_time	Range 100–45,000 ms	Total time for AMD analysis

Plivo’s US call quality documentation notes that hanging up on every voicemail generates short-duration calls that can trigger carrier spam flags and per-call surcharges. Their guidance states: “Do not hang up on every voicemail. Leave a brief message or schedule a retry instead.”

Vonage AMD Parameters

Vonage’s Voice API does not expose configurable voicemail detection parameters comparable to dedicated AMD products. A review of Vonage’s official developer documentation shows that Vonage’s Voice API focuses on call control and PSTN branded calling rather than machine detection. Teams using Vonage for outbound campaigns typically implement AMD at the orchestration layer or use a third-party detection service. Vonage’s branded calling feature, built with First Orion’s INFORM platform, improves answer rates by attaching verified identity information to outbound calls, which reduces the likelihood of calls being screened to voicemail.²

Plura AI Voicemail Detection

Plura AI’s AI Predictive Dialer handles voicemail detection at the carrier level as part of its FCC-licensed infrastructure.¹ Unlike the platforms above, which require manual AMD parameter tuning, Plura uses carrier-grade analysis to distinguish live humans from voicemail systems automatically. Operations teams skip the tuning cycle entirely: they no longer calibrate speech thresholds, experiment with silence timeouts, or troubleshoot false positives. The AI Predictive Dialer connects agents only to live humans, which reduces wasted calls and dead air from manually configured AMD systems.

Schedule a predictive dialer walkthrough tailored to your outbound use cases.

Cross-Platform Voicemail Detection Parameter Comparison

The table below summarizes default timeout, speech, and silence values for each platform so you can see how much manual tuning each stack expects from your team.

Platform	Default Timeout	Default Speech Threshold	Default Silence Timeout
Twilio	30 s (range 3–59 s)	2,400 ms (machineDetectionSpeechThreshold)	5,000 ms (machineDetectionSilenceTimeout)
Asterisk	5,000 ms (total_analysis_time)	100 ms min word length (min_word_length)	2,500 ms initial / 800 ms after greeting
Plivo	5,000 ms (machine_detection_time)	1,000–6,000 ms configurable (machine_detection_maximum_speech_length)	2,000–10,000 ms configurable (machine_detection_initial_silence)
Vonage	Not exposed	Not exposed	Not exposed
Plura AI	Automatic (carrier-grade)	Automatic (carrier-grade)	Automatic (carrier-grade)

How to Reduce False Positives in Voicemail Detection

False “human” detections, where the system misclassifies a voicemail greeting as a live person, create the most pain in AMD configuration. Short greetings like “Leave a message” are the most common trigger. The playbook below outlines platform-specific adjustments.

Twilio False-Positive Fix

Twilio’s limitations documentation identifies the root cause. A low machineDetectionSpeechThreshold increases false machine detections on short human responses, while a high machineDetectionSpeechEndThreshold delays human detection. For short voicemail greetings, increase machineDetectionSpeechThreshold to 3,000–4,000 ms and reduce machineDetectionSpeechEndThreshold to 1,500–2,000 ms. Also verify webhook response time, and host media in the region closest to your Twilio region.

Asterisk False-Positive Fix

Asterisk’s after_greeting_silence parameter (default 800 ms) often drives misclassification. When a voicemail speaker pauses between sentences, the silence can exceed 800 ms and Asterisk classifies the call as HUMAN. Increase after_greeting_silence to 1,200–1,500 ms to tolerate pauses in recorded greetings. Also consider raising maximum_number_of_words from the default of 3 to 5–6, since short greetings like “Hello, this is Jordan speaking” can exceed the default word count and trigger a false MACHINE classification.

Plivo False-Positive Fix

Plivo’s machine_detection_silence parameter (range 500–5,000 ms) controls the silence after speech that indicates the end of a greeting. For short voicemail greetings, increase this value to 2,000–3,000 ms so that brief pauses within the greeting are not interpreted as the end of the message. Also adjust machine_detection_maximum_speech_length. If this value is set too low, the system may classify a short greeting as a human response before the full message plays.

General Tuning Principles

Change one parameter at a time and validate against labeled recordings from your actual campaign. Background noise, short greetings, and campaign-specific speech patterns vary by environment. Track false-machine and false-human rates separately. A false machine loses a live contact, while a false human consumes agent time and creates dead air.

Best Practices for Testing Voicemail Detection Across Carriers

Carrier behavior varies significantly, and AMD settings that work on one network may fail on another. Use this testing workflow to keep results consistent:

1. Export real recordings from the last 90 days of the same campaign, trunk mix, destination region, and calling hours.
2. Label each recording according to what a reviewer hears, such as human greeting, traditional voicemail greeting, call-screening prompt, silence or failed media, or ambiguous audio, rather than the existing dialer disposition.
3. Test with complete audio including carrier delay. Measuring only the greeting from an edited recording removes the silence behavior being evaluated.
4. Measure false-machine and false-human rates separately, along with NOTSURE rate and decision time.
5. Watch for False Answer Supervision (FAS). When a carrier returns an answer signal before a human picks up, AMD analysis starts on hold music, ringback bleed, or silence, which corrupts the analysis window.

Frequently Asked Questions

What Is the Best Voicemail Detection Timeout?

The optimal timeout depends on your platform and campaign. Twilio caps machineDetectionTimeout at 60 seconds with a default of 30 seconds. Asterisk defaults total_analysis_time to 5,000 ms (5 seconds). Plivo’s machine_detection_time defaults to 5,000 ms with a range of 2,000–10,000 ms. A shorter timeout reduces dead air but increases “unknown” results. A longer timeout catches more voicemail greetings but increases the risk of live humans hanging up during analysis. The right value depends on greeting patterns for your destination numbers and carrier mix. Start at the platform default, measure your NOTSURE rate, and adjust in 500 ms increments while tracking both false-machine and false-human outcomes separately.

How Do I Reduce False Positives in Voicemail Detection?

False positives, or misclassifying voicemail as human, are most often caused by short greetings with internal pauses. The primary fix is to increase the after-greeting silence threshold on your platform: after_greeting_silence on Asterisk, machineDetectionSpeechEndThreshold on Twilio, and machine_detection_silence on Plivo. This change gives the system more time to confirm that the greeting has ended before returning a HUMAN result. Also verify that your speech threshold is not set too low, which can classify brief human responses as machines. Always change one parameter at a time and validate against a labeled recording set from your actual campaign before deploying to production.

How Do Voicemail Detection Systems Tell a Human from a Machine?

AMD systems analyze audio patterns such as speech duration, silence between phrases, number of distinct words, and the presence of a beep tone. A typical voicemail greeting runs about 10–30 seconds, with most professional guidance recommending 15–25 seconds, and it ends with a beep. A live human typically answers with a short “Hello?” followed by silence while waiting for the caller to speak. AMD parameters encode these distinctions as speech thresholds, silence timeouts, and word counts. When a greeting’s duration, word count, or silence pattern exceeds the configured thresholds, the system classifies the call as a machine. When the audio is short and followed by silence, the system classifies it as human. Short voicemail greetings and brief human responses can produce nearly identical audio signatures, so tuning becomes an ongoing process rather than a one-time configuration.

What Does a NOTSURE Result Mean in Asterisk AMD?

A NOTSURE result means Asterisk’s AMD module reached the total_analysis_time limit without enough evidence to classify the call as either HUMAN or MACHINE. The AMDCAUSE variable typically reports TOOLONG in this case. NOTSURE represents a legitimate operational outcome rather than a technical error. Routing every NOTSURE result to MACHINE hides uncertainty and can discard live contacts. Many teams route NOTSURE calls to a dedicated queue, such as a short-duration agent review or a retry with a longer total_analysis_time, and track the NOTSURE rate separately. A rising NOTSURE rate often signals that total_analysis_time is too short for greeting patterns on the current carrier mix.

Does Plura AI Offer Voicemail Detection?

Yes. Plura AI’s AI Predictive Dialer includes carrier-grade voicemail detection as a built-in feature. Because Plura operates its own FCC-licensed carrier infrastructure, voicemail detection runs automatically without manual parameter tuning.¹ The AI Predictive Dialer connects agents only to live humans, which reduces wasted calls on answering machines. Teams that have spent engineering cycles tuning Twilio, Asterisk, or Plivo AMD parameters often shift that effort to higher-value work once Plura handles detection at the carrier level.

Stop Tuning and Focus on Live Conversations

Voicemail detection parameters often determine whether a dialer wastes thousands of calls on answering machines or consistently connects agents to live humans. This guide has outlined the exact parameter names, defaults, and tuning values for Twilio, Asterisk, Plivo, and Vonage, along with a troubleshooting playbook for common failure modes. Manual AMD tuning remains a constant operational burden as carrier behavior changes, greeting patterns shift, and new campaigns introduce fresh edge cases. Plura’s AI Predictive Dialer uses carrier-grade voicemail detection that works out of the box so leaders can focus on staffing, conversion, and revenue. Request a live Plura demo to review your current AMD performance and explore a carrier-level approach.

---

Read Next

• How to Improve Voicemail Detection Accuracy: 2026 Guide
• Voicemail Detection Integration for Contact Centers
• Voicemail Beep Detection: How It Works and Why It Fails
• What Is Voicemail Detection in Voice AI?
• Voicemail Detection Best Practices: 2026 Tuning Guide