Best AMD Dialer Settings for Maximum Accuracy in 2026
Every outbound dialer ships with AMD settings. Very few contact centers have ever changed them.
That is a problem — because the default AMD dialer settings were calibrated years ago for a telephony environment that looks nothing like today's VoIP-dominated, mobile-first, iOS-updated landscape.
This guide covers the specific AMD settings that matter, how to tune them for modern traffic, what benchmarks to aim for, and where the hard ceiling on rules-based tuning is.
Why Default AMD Settings Underperform in 2026
Asterisk's default AMD configuration was designed for landline-era telephony where:
- Voicemail greetings had consistent audio profiles
- Human responses were longer and more uniform
- Carrier audio processing was minimal
- Call traffic was predominantly domestic US
In 2026, your call traffic looks completely different:
- The majority of calls connect to mobile devices
- iOS 26 changed voicemail greeting acoustics significantly
- VoIP carriers apply noise reduction and echo cancellation that alters audio properties
- Short mobile responses ("Hello?" under 300ms) are now common
- International calling is growing across most verticals
Running default settings against modern traffic is like using a weather forecast from 2015 to plan today's outdoor event.
The Core AMD Parameters You Need to Know
For VICIdial and Asterisk-based dialers, AMD is configured in /etc/asterisk/amd.conf. These are the parameters that matter:
`initial_silence` (default: 2500ms)
The maximum silence duration at the start of a call before AMD decides MACHINE.
Voicemail systems often have a brief processing pause before the greeting plays. Humans typically say something immediately.
The problem: If a human hesitates slightly before saying hello — common on mobile, common with elderly callers, common with noisy environments — they get classified as MACHINE.
Direction to tune: Increase if you are dropping fast-hesitating humans. Decrease if you are letting long-silence voicemails through as HUMAN.
`greeting` (default: 1500ms)
The maximum length of a greeting before AMD decides MACHINE.
This is one of the most impactful settings. If the greeting exceeds this threshold without a pause, the call is classified as MACHINE.
The problem: iOS 26 default voicemail greetings are shorter than older iOS versions. If greeting is set too high relative to the new greeting length, iOS 26 voicemails slip through as HUMAN.
Direction to tune: Lower this carefully to catch shorter machine greetings. But lowering too far clips legitimate human responses.
`after_greeting_silence` (default: 800ms)
The silence after a greeting before AMD decides HUMAN.
After a human says "Hello?", they wait for a response. After a voicemail greeting, there is typically a beep. This parameter catches the wait-for-response silence pattern.
Direction to tune: Increase to give more time for slower-responding humans. Decrease if voicemails with short post-greeting silence are slipping through.
`total_analysis_time` (default: 5000ms)
The total time AMD will spend analyzing before giving up and classifying as NOTSURE.
If AMD cannot classify within this window, it returns NOTSURE. Your dialer configuration determines how NOTSURE is handled — most operations default it to HUMAN.
Direction to tune: Increasing this gives AMD more audio to analyze but adds latency. On a predictive dialer, every extra millisecond of AMD analysis time affects pacing and abandonment rates.
`min_word_length` (default: 100ms)
The minimum length for audio to be classified as a "word" rather than noise.
Audio shorter than this threshold is treated as silence or background noise rather than speech.
The problem: Short human responses — "Yep?", "Hi", a quick "Hello?" — can fall below the minimum word length and get treated as silence, leading to MACHINE classification.
Direction to tune: Lower this to catch short human responses. But setting it too low causes background noise to register as words, confusing the word-count analysis.
`between_words_silence` (default: 50ms)
The silence gap between words. Two audio bursts separated by less than this are treated as one continuous word.
Direction to tune: Lower this to split words more finely. Higher to merge closely spaced audio into single words. Affects how "word count" is calculated.
`maximum_number_of_words` (default: 3)
If more than this many words are detected in the greeting, AMD classifies as MACHINE.
This catches the typical voicemail greeting structure: a multi-word recorded message.
The problem: A human who says "Hi there, who is this?" before pausing will hit the word-count threshold and get classified as MACHINE.
Direction to tune: Increase to allow more verbose human greetings through. But increasing too far allows longer voicemail greetings to slip through as HUMAN.
`silence_threshold` (default: 256)
The audio level below which the signal is treated as silence.
Direction to tune: Lower this for quieter calls (common on mobile). Higher for noisier environments where background noise would otherwise register as speech.
Recommended Settings for 2026 US Domestic Traffic
Based on testing across modern VoIP carriers and iOS 26 voicemail behavior, these settings improve accuracy over defaults:
[general]
initial_silence=3000
greeting=1200
after_greeting_silence=900
total_analysis_time=5000
min_word_length=80
between_words_silence=50
maximum_number_of_words=4
silence_threshold=200
Key changes from defaults:
initial_silenceincreased to 3000 — more tolerance for hesitant human responsesgreetinglowered to 1200 — catches shorter iOS 26 voicemail greetings as MACHINEafter_greeting_silenceincreased to 900 — more time for humans to wait before respondingmin_word_lengthlowered to 80 — catches shorter mobile responsesmaximum_number_of_wordsincreased to 4 — allows slightly more verbose human greetingssilence_thresholdlowered to 200 — more sensitive on quieter mobile connections
After applying: asterisk -rx "module reload app_amd.so"
How to Validate AMD Setting Changes
Never change settings without measuring the impact. The process:
Establish a baseline: Before changing anything, manually review 200 MACHINE-classified call recordings. Count false positives (recordings where you hear a human voice). This is your baseline false positive rate.
Change one setting at a time: Adjust a single parameter and run for 24 hours.
Sample and measure: Pull another 200 MACHINE-classified recordings. Compare to baseline.
Track both error types: Measure false positives (live humans dropped) AND false negatives (voicemails reaching agents). Tuning for one often worsens the other.
Repeat: Continue adjusting and measuring until you reach your accuracy ceiling.
AMD Settings by Campaign Type
Different campaigns benefit from different tuning emphasis:
| Campaign Type | Priority | Key Settings to Adjust |
|---|---|---|
| B2C High Volume | Minimize false positives | Lower min_word_length, raise initial_silence |
| B2B Decision Makers | Balance both errors | Default-leaning, raise maximum_number_of_words |
| International | Minimize false positives | Raise initial_silence, lower silence_threshold |
| Aged Leads | Minimize agent wasted time | Lower greeting, lower maximum_number_of_words |
| Mobile-Heavy Lists | Minimize false positives | Lower min_word_length significantly |
The Ceiling on AMD Parameter Tuning
Here is the hard truth about rules-based AMD tuning: there is a performance ceiling you cannot get past.
The problem is fundamental. AMD parameters use the same acoustic properties to detect both machines and humans — silence, word length, greeting duration. A short voicemail greeting looks like a human response. A verbose human greeting looks like a machine. Rules cannot fully separate them because the underlying signals overlap.
In practice, most operations can get from 20% false positive rate down to 8–12% through careful tuning. Below that, the error rate is structural.
| Approach | Achievable False Positive Rate | Tuning Effort |
|---|---|---|
| Default Asterisk settings | 18–25% | None |
| Manually optimized settings | 8–15% | High, ongoing |
| AI-powered AMD (amdify.io) | 1–3% | None |
For operations running more than 500 dials per hour, the difference between 10% and 2% false positive rates represents a significant number of live conversations per day. At that scale, AI-powered AMD pays for itself quickly.
See the full comparison in Asterisk AMD vs AI-Powered AMD: Accuracy Comparison for 2026.
When You Should Stop Tuning and Switch to AI
Stop tuning AMD parameters and switch to AI-powered detection when:
- You have already tuned and your false positive rate is still above 8%
- Your call list has significant mobile or international traffic
- You are running predictive dialer campaigns where AMD latency affects abandonment rate
- You are using multiple SIP carriers and cannot tune for all of them simultaneously
- You need consistent accuracy without ongoing maintenance overhead
amdify.io integrates directly with VICIdial and Asterisk — you disable the built-in AMD, install a small AGI script, and the AI classification API handles detection from there. Integration takes under an hour. See the VICIdial integration guide for step-by-step instructions.
Quick-Reference Tuning Summary
| Symptom | Likely Cause | Fix |
|---|---|---|
| Too many live humans dropped | initial_silence too low or min_word_length too high |
Raise initial_silence, lower min_word_length |
| Too many voicemails reaching agents | greeting too high or maximum_number_of_words too high |
Lower greeting, lower maximum_number_of_words |
| Short responses misclassified | min_word_length too high |
Lower to 70–80ms |
| Noisy calls misclassified | silence_threshold too high |
Lower to 180–220 range |
| AMD taking too long | total_analysis_time too high |
Lower to 4000ms |
| NOTSURE classifications too high | total_analysis_time too low |
Raise to 5500ms |
Final Thoughts
AMD dialer settings have a measurable impact on revenue. Default configurations left unchanged since installation are almost certainly costing you live conversations every day.
Tune the parameters in order of impact — start with initial_silence and min_word_length because they have the largest effect on false positive rate. Measure before and after every change. Know your ceiling.
And when you hit that ceiling — typically 8–12% false positive rate with manual tuning — the next step is AI-powered detection, not more parameter adjustments.