Vicidial amd.conf settings: the values that matter in production

Most “best amd.conf settings” posts copy the same block of numbers without explaining what any of them measure or when the number is wrong. This page does the opposite: each variable gets its stock default, the range that holds up on production Vicidial servers, and the specific failure you invite by leaving it at default. The file lives at /etc/asterisk/amd.conf on your Vicidial box, and every change applies to new calls after module reload app_amd — no restart needed.

Context first, because it decides which values are right. Asterisk’s app_amd does not listen for words; it measures timing. Silence at the start of the answer, the length of the first audio burst, gaps between bursts. Against those measurements it fires one of three verdicts into the AMDSTATUS channel variable: HUMAN, MACHINE, or NOTSURE. Vicidial’s campaign layer then acts on the verdict with drop_call_seconds and amd_send_message. The variables below control layer one. For the full reference table, the amd.conf cheat sheet pairs every variable with its neighbors.

The values that matter in production

All durations are milliseconds. Four of these nine do most of the damage on a stock install: maximum_number_of_words, after_greeting_silence, initial_silence, and total_analysis_time. The other five you will set once and never think about again.

The four that cause most problems

maximum_number_of_words: default 3 — the default is wrong

The heuristic says a human greets briefly and a machine monologues, so more than three words means machine. On consumer lists in the 2010s that mostly held. Today the assumption fails twice: business numbers route to receptionists who answer with six to ten words, and mobile users increasingly answer with a full phrase (“hi this is Sam how can I help”) in a single breath. At the default of 3, both classify as machines and your dialer hangs up on paying prospects.

Set it to 5 for consumer lists, 6 with any business presence. Push past 6 and scripted voicemail greetings — which are word-dense but machine-paced — start leaking through to agents. The cost of each step is asymmetric: a value one too low drops revenue, a value one too high wastes a few agent seconds. When in doubt, round up and verify with a recording audit.

after_greeting_silence: default 800 ms — where humans get misfired

After the first audio burst ends, Asterisk waits up to this long for a pause before deciding what it heard. Humans pause inside their greetings — “hello?… yeah?” — and an 800 ms window counts that hesitation as the gap before a machine’s outgoing message. The verdict lands instantly, the call drops, and nothing in your abandon statistics shows it, because AMD drops are not abandons.

Stay at 800 ms for tight consumer lists; move to 1000–1200 ms when your 50-call recording audit finds humans under MACHINE dispositions. Every millisecond you add here also delays machine drops, so this is a see-saw, not a free fix. Check the trade monthly — it drifts with your list composition. The narrow-middle tuning piece shows how fast that drift moves.

initial_silence: default 2500 ms — mostly right, dangerously cut

This is the ceiling on leading silence before Asterisk declares a machine. It interacts with something amd.conf cannot see: handset and carrier latency. A cell answer can sit silent for 800–1200 ms before the human’s “hello” traverses the network. Operators chasing faster drops routinely cut this to 1000 ms or less, and cell-heavy lists quietly lose 2–4% of real contacts to it.

Never below 1500 ms; 2500 remains the right answer for most mixed lists. If leading silence is genuinely a problem on your routes, the cause is usually carrier lateness — answer supervision returned before audio bridges — and that is a routing issue wearing an amd.conf costume. The FAS guide untangles exactly that.

total_analysis_time: default 5000 ms — the NOTSURE ceiling

Five seconds is the hard limit of analysis per call. Anything unresolved by then returns NOTSURE, and on Vicidial a NOTSURE is usually treated as human-or-dropped depending on campaign config. A live human often hangs up on silence before five seconds elapse, so long analysis windows produce a quiet class of calls where the human left before the verdict arrived.

Run 3000–4000 ms in production. Below 3000 you manufacture NOTSUREs on every slow-opening answer; at the 5000 default you pay the timeout in agent dead air. Whatever you choose, decide what happens to the NOTSUREs — the NOTSURE playbook covers disposition strategy, and this variable is where most of them are born.

The five you set once

greeting caps the first audio burst at 1000–1800 ms; below that, human greetings classify as machines, above it, voicemail intros sneak through. maximum_word_length (2200–3200 ms) bounds how long a single “word” can run before the call leans machine — keep it comfortably inside total_analysis_time or the arithmetic can never resolve. min_word_length stays at 100 ms; it exists to ignore line noise. between_words_silence stays near 50 ms — raising it merges adjacent bursts and inflates word counts until machines look human. silence_threshold stays at 256 unless recordings prove your carrier audio is genuinely quiet, in which case it is the correct lever for dead-air misdetections.

A production starting point

For a mixed consumer list dialed through standard carriers, this block is where we see servers land after tuning:

• initial_silence=2500 — untouched default
• greeting=1500 — untouched default
• after_greeting_silence=1000 — +200 over default, protects hesitant humans
• total_analysis_time=4000 — −1000, cuts NOTSURE dead air
• maximum_number_of_words=5 — +2 over default, stops business drops
• maximum_word_length=2800 — inside the analysis window

Pair it with campaign settings drop_call_seconds=7 and amd_send_message=HANGUP. Then earn the right to call it done: pull 50 random MACHINE-dispositioned recordings, listen to the first 10 seconds, and count the humans. More than 3 of 50 means the block above is wrong for your list, whatever any guide says — including this one. The AMD-not-working troubleshooting guide maps every symptom those recordings can show.

The ceiling you cannot tune past

Everything above optimizes one method: guessing from silence gaps and word timing. The method has a hard ceiling because its inputs are proxy signals. Carrier false-answer supervision defeats it completely — the announcement audio really contains speech, and no threshold separates it from a prospect saying hello. List age and hour shift the boundaries faster than quarterly audits catch them. Across roughly 2.3 billion answered calls a month on the AMDY network, about 12.5% of answers are live humans, 73% machines, and 14% carrier false-answers — that 14% is pure guesswork for timing AMD.

Acoustic AI detection changes the input instead of the threshold. AMDY classifies the acoustic signature of the answer audio and returns a decision starting detection in 1/8 of a second at 99% accuracy — no amd.conf, no per-list re-tuning, and FAS classified outright. It installs alongside Vicidial without touching your dial plan; the install walkthrough and the Vicidial AMD hub cover the setup. If you keep timing AMD, the block above is the best version of it. If you are tired of re-verifying it every month, that is the off-ramp.

Compliance note: tuned AMD supports your TCPA and abandon-rate posture; it is not legal advice. For the detection engine’s own documentation, see the Asterisk AMD application reference.

FAQ

What are the default amd.conf values in Asterisk?

The stock file ships initial_silence=2500, greeting=1500, after_greeting_silence=800, total_analysis_time=5000, min_word_length=100, between_words_silence=50, maximum_number_of_words=3, silence_threshold=256, and maximum_word_length=5000 (with maximum_word_length defaulting to 3200 in some builds). Vicidial installs these defaults unchanged, which is why out-of-the-box AMD misclassifies business answers and long greetings.

What is the best maximum_number_of_words setting for Vicidial?

Five for consumer lists, six when your data includes business lines. The default of 3 assumes a human answers with three words or fewer, but receptionists routinely answer with six to ten, so every business number gets classified as a machine. Above 6 the pendulum swings back and scripted voicemail greetings start scoring as human speech.

Do I need to restart Asterisk after editing amd.conf?

No. Run asterisk -rx "module reload app_amd" and new calls pick up the changed file without dropping live channels. Confirm the module is actually loaded first with module show like amd — after server rebuilds it sometimes is not, and every amd.conf edit is silently inert until it is.

What drop_call_seconds should I use with these amd.conf values?

Six to eight covers most production lists. Fresh teleforwarded leads dialed in the morning tolerate 6; aged lists dialed in the evening need 8 to 9 to preserve human connects. drop_call_seconds is the Vicidial campaign layer that acts on the verdict amd.conf produces — the two must be tuned together, because a tight amd.conf with a tight drop window is how real people get dropped.

Is there an amd.conf setting that fixes carrier false-answer supervision?

No. FAS is the carrier returning answer supervision and playing its own announcement — the audio genuinely contains speech, so every timing threshold sees a plausible human. The fix is acoustic detection, which classifies the sound of the announcement, or moving the list to a different route. Threshold tuning only redistributes FAS damage between dropped humans and passed machines.