ViciDial AMD variables: every setting explained

Why these variables matter

Every ViciDial install ships with Asterisk’s built-in answering machine detection turned on. It works by timing the answer audio — measuring initial silence, greeting length, and pauses between words — and comparing those numbers against thresholds you control in amd.conf and through ViciDial’s own campaign settings. Get the thresholds wrong and you either idle your agents on voicemails or drop real humans before an agent connects.

The catch: even a perfectly tuned set of thresholds tops out at around 70–85% accuracy. Timing rules cannot distinguish a human who answers quickly from a machine that opens with a short greeting — the audio looks the same to Asterisk. That ceiling is structural, not a configuration problem. See the full amd.conf cheat sheet →

That said, the settings below are the levers you have today. Understanding each one prevents the most common misconfigurations and gives you a baseline before you evaluate whether AI AMD removes the tuning problem entirely.

Core amd.conf variables

initial_silence (default: 2500 ms)

Maximum silence allowed at the very start of the answer, before Asterisk hears any audio at all. If the call is silent for longer than this value, Asterisk calls it a machine. The logic is that a live human will say something within 2.5 seconds; a dead-air machine recording or carrier false-answer might not.

Raise it: fewer machines misclassified as “human” on slow-opening voicemails, but you wait longer on every call. Lower it: faster decisions, but you drop humans who hesitate or pick up from a noisy environment. Common mistake: setting this under 1000 ms on a cell-heavy list — handset latency alone can push the first audio past a short threshold.

greeting (default: 1500 ms)

Maximum duration of the initial audio burst before Asterisk decides whether it’s a greeting or a machine message. A short burst (under 1500 ms) is scored as a human greeting; a long uninterrupted burst is scored as a machine playback.

Raise it: more tolerance for long human greetings (“Thank you for calling Smith Consulting, this is David”). Lower it: you classify more long greetings as machines — which is exactly what causes the “Hello?” false positive on fast answerers. What AI AMD does differently →

after_greeting_silence (default: 800 ms)

After the initial audio burst ends, Asterisk waits up to this many milliseconds for a pause. A pause here on a human call means they’ve finished saying “Hello” and are waiting for you. A pause here on a machine means the outgoing message is about to start playing.

Raise it: more patience for humans who pause after answering. Lower it: faster detection but you clip the pause humans naturally make. This is the variable most operators forget exists, and misconfiguring it produces a subtle pattern: calls that score HUMAN immediately after the greeting but then sit in silence long enough to time out.

total_analysis_time (default: 5000 ms)

Hard ceiling on how long Asterisk will spend analyzing a single call. If no other rule has fired, AMD declares NOTSURE at this limit. NOTSURE is where your best leads die →

Raise it: more time to analyze ambiguous calls, fewer NOTSURE outcomes. Lower it: faster overall cadence but more undecided calls. For predictive dialing, a 5-second analysis window is already long enough to lose a live human who hangs up waiting. Many operators set this to 3000–4000 ms in practice.

min_word_length (default: 100 ms)

Minimum audio duration for Asterisk to count a chunk of sound as a “word.” Anything shorter is treated as noise and ignored.

Raise it: fewer noise spikes counted as words (useful on very noisy lines). Lower it: more sensitive to short phonemes, which can miscount syllables on compressed VoIP. Leave this at 100 ms unless you have a specific noise problem confirmed by call recordings.

between_words_silence (default: 50 ms)

How long a silence gap between audio chunks must be before Asterisk treats them as separate words. A 50 ms gap is a natural inter-phoneme pause; a longer gap separates distinct words.

Raise it: you merge more audio into single “words,” reducing the effective word count. Lower it: you split more words, which can push a short human greeting past the maximum_number_of_words limit and misclassify it as a machine. This is a common tuning trap: lowering between_words_silence in an attempt to be more sensitive while also keeping maximum_number_of_words low.

maximum_number_of_words (default: 3)

If the greeting contains more than this many “words” (as counted by the silence-gap logic above), Asterisk classifies the answer as a machine. The intuition is that a machine plays a full scripted message while a human just says “Hello.”

Raise it: you tolerate longer human greetings, reducing the false-positive rate on “Thank you for calling…” style answers. Lower it: you catch more voicemails but you will drop humans who give a full greeting. In practice, any call list that includes business numbers needs this above 3. Most production configs sit at 5–6.

silence_threshold (default: 256)

The amplitude level (in raw PCM units) below which audio is considered silence. On standard telephony (8-bit μ-law, 8 kHz), 256 represents a low but nonzero signal.

Raise it: Asterisk needs louder audio to count as “talking” — useful if background noise is triggering false detections. Lower it: you pick up softer greetings but you also pick up line hiss and codec artifacts as speech. This is the right lever when AMD is classifying clearly-silent calls as HUMAN. Leave it alone otherwise.

ViciDial-layer settings

These live in the ViciDial campaign configuration, not in amd.conf. They control what happens after Asterisk returns its AMD decision.

drop_call_seconds

How many seconds after the call is answered (and before an agent connects) ViciDial will abandon the call if AMD hasn’t returned a decision yet. This is your safety valve against AMD hanging on ambiguous calls.

Set it too low and ViciDial drops calls before AMD finishes analyzing them — you end up abandoning live humans because the analysis took 3 seconds. Set it too high and your abandon rate climbs on every call AMD stalls on. A practical starting point is 4–5 seconds, slightly above your total_analysis_time.

amd_send_message

When set to Y, ViciDial plays a pre-recorded message to calls Asterisk classified as MACHINE, rather than simply dropping them. This turns machine-detected calls into a passive voicemail drop.

Useful for campaigns that want voicemail drops on answering machines. Not relevant if you want machines hung up on immediately. Make sure your message complies with local regulations — leaving a recorded message on a cell phone has its own TCPA implications. AMD and the TCPA 3% rule →

AMD_wait_extra_sec

An additional wait period (in seconds) that ViciDial adds after the call connects before it starts the AMD analysis. This compensates for carriers or endpoints that take a moment to settle before audio begins.

On clean VoIP trunks with fast audio start, set this to 0. On older carrier routes with delayed audio onset, 1–2 seconds can reduce the number of calls where Asterisk’s initial silence timer fires immediately because it never heard any audio. Common misconfiguration: leaving this at a non-zero default on a low-latency trunk, which adds unnecessary delay to every single call.

Quick-reference table

Common mistakes

• Lowering greeting to speed things up. Every millisecond you shave off the greeting window is a human who answered normally getting classified as a machine.
• Setting maximum_number_of_words to 2 or 3 on a business list. Business receptionists routinely answer with 6–10 words. You will drop them.
• Ignoring the interaction between between_words_silence and maximum_number_of_words. They compound. Tune one without adjusting the other and you shift the effective word-count in ways that aren’t obvious from reading the config.
• Setting drop_call_seconds below total_analysis_time. ViciDial will abandon calls before AMD finishes — you lose both the AMD result and the live human.
• Leaving AMD_wait_extra_sec at a non-zero value on a fast trunk. You add dead time to every call for a problem you no longer have.
• Never measuring your NOTSURE rate. If AMD returns NOTSURE on 10% of calls and your dialplan drops them, you are dropping real people and you have no log to prove it. NOTSURE explained →

The ceiling you cannot tune past

After working through all of the above, the honest conclusion is that heuristic AMD has a structural accuracy ceiling of roughly 70–85%. The reason is not a missing variable — it’s that timing rules cannot distinguish audio that’s ambiguous by nature. A human who answers “Hello?” quickly and a machine that opens with a short scripted greeting can produce nearly identical timing profiles in Asterisk’s analysis window.

AI AMD classifies the acoustic signature of the audio rather than timing events within it. That approach reaches 99% accuracy in production, catches carrier false-answers and honeypots that timing rules cannot see, and eliminates the tuning treadmill entirely. What AI AMD is and how it works →

FAQ

Where do I edit these settings on a running ViciDial server?

Edit /etc/asterisk/amd.conf for the Asterisk-level variables, then run asterisk -rx "module reload res_agi.so" to pick up the changes without restarting Asterisk. ViciDial campaign-level settings (drop_call_seconds, amd_send_message, AMD_wait_extra_sec) are in the Admin → Campaigns panel.

What should I set first when tuning?

Start with maximum_number_of_words and greeting. Those two variables have the largest effect on whether live humans pass as HUMAN. Then check your NOTSURE rate before touching anything else.

Can tuning get me above 90% accuracy?

Not reliably on a mixed residential/mobile list. 70–85% is the practical ceiling for timing-based heuristics on 2026 call lists. The gains above that require a model that understands the audio signal itself, not just its timing.