GuideJun 23, 2026 8 min read

The amd.conf cheat sheet: every Vicidial AMD setting explained

Every parameter in Asterisk’s amd.conf, what it does, its default, and what happens when you raise or lower it — plus the Vicidial-layer settings that sit on top.

Stock AMD on Vicidial is Asterisk’s app_amd module, and every knob it has lives in one file: amd.conf. The module listens to the first few seconds of an answered call, measures silence and speech, and from those measurements decides whether it is talking to a person or a machine. The thresholds in amd.conf are what draw the line between HUMAN, MACHINE, and NOTSURE.

This is a working reference. Below is every parameter, its rough default, and the practical trade-off when you turn it up or down. None of these values are sacred — they ship as compromises for an “average” list that does not exist on your dialer. Treat the table as a map, then read the honest caveat at the end before you spend an afternoon on it.

The amd.conf parameters

All timings are milliseconds. Defaults vary slightly by Asterisk build, so confirm against the comments in your own /etc/asterisk/amd.conf before you trust a number.

Parameter

What it does · default · raise/lower

initial_silence (~2500 ms)

Maximum silence allowed before the first sound. If the line stays quiet past this, AMD leans MACHINE. Raise it to tolerate slow answers and noisy carriers; lower it to decide faster, at the cost of flagging hesitant humans as machines.

greeting (~1500 ms)

Maximum length of a single greeting still counted as a human "hello". Raise it to tolerate longer human hellos, but you will start missing short voicemail prompts; lower it to catch terse voicemails, but long-winded humans get tagged MACHINE.

after_greeting_silence (~800 ms)

Silence expected after a human says hello and waits for a reply. A real person pauses here; a machine keeps talking. Raise it to be more forgiving of quiet humans; lower it and you risk calling a still-talking machine a human.

total_analysis_time (~5000 ms)

Hard cap on the whole decision. When this expires AMD must answer with whatever it has — often NOTSURE. Lower it for a faster connect (fewer seconds of dead air for agents) but more NOTSURE and weaker accuracy; raise it for confidence at the cost of latency.

min_word_length (~100 ms)

Shortest burst of sound counted as a "word". Raise it to ignore clicks, breaths, and line noise; lower it and short syllables or static get counted as speech, skewing the word count.

between_words_silence (~50 ms)

Gap of silence that separates one word from the next. Raise it and run-together speech is read as one long word; lower it and a single word can be split into several, inflating the word count toward MACHINE.

maximum_number_of_words

Word count above which the answer is judged a machine greeting (a voicemail prompt is wordy). Raise it to let chatty humans through; lower it and brief humans who say more than a flat "hello" tip into MACHINE.

silence_threshold (~256)

Audio level at or below which a sample is treated as silence. Raise it on noisy lines so background hum is not counted as speech; set it too high and real quiet speech gets swallowed as silence.

maximum_word_length

Longest single continuous sound before AMD assumes it is a machine greeting (one unbroken stream of speech, like a voicemail message). Tune it alongside greeting and between_words_silence.

The two that move the needle most are initial_silence and greeting. Together they decide what a “human hello” is allowed to look like, and they are the usual culprits when a campaign starts hanging up on live leads. The fast, no-pause “Hello? Who’s this?” that real people actually use is exactly the shape that breaks timing-based AMD.

The AMDSTATUS outcomes

When app_amd finishes, it sets one channel variable, AMDSTATUS, to one of three values, and your dialplan routes on it:

HUMAN — the analysis saw a short greeting followed by a pause. The call is passed to an agent or your campaign’s human path.
MACHINE — long greeting, too many words, or silence past initial_silence. The call is dropped or routed to a voicemail action.
NOTSURE — total_analysis_time ran out before a confident call. You decide how to treat it; many operators route NOTSURE to a human to avoid dropping a real lead.

That third bucket is where a lot of money quietly goes. Routing every NOTSURE to an agent protects leads but wastes agent time on machines; dropping them all does the opposite. There is no good default — see what NOTSURE really means for the trade-off in full.

The Vicidial-layer settings on top

Vicidial does not stop at AMDSTATUS. Two campaign-level settings sit on top of amd.conf and change what actually happens once AMD has decided.

drop_call_seconds

This controls how long a call flagged as a machine is held before Vicidial drops it. It is not in amd.conf — amd.conf only makes the human-vs-machine call; drop_call_seconds decides what to do with the seconds afterward. If you leave messages, you set it long enough to wait for the answering-machine beep. If you do not, you keep it short so machines are released quickly and your hopper keeps moving.

amd_send_message (HANGUP vs CONTINUE)

This is the action taken when AMD returns MACHINE. HANGUP drops the call (immediately, or after drop_call_seconds) and is what most predictive campaigns want — it protects agent time. CONTINUE keeps the call up and plays a pre-recorded message into the voicemail before hanging up, which is how voicemail-drop campaigns work.

The interaction matters: amd.conf decides if it is a machine, amd_send_message decides what to do about it, and drop_call_seconds decides when. Every false positive from a too-tight greeting threshold flows straight into whichever action you picked — so a live human gets a voicemail drop or a hang-up they never deserved. The accuracy of the whole pipeline is capped by the weakest link, and that link is almost always the timing heuristic in amd.conf.

The honest caveat

You can tune these nine parameters for hours and get a real improvement — for one list, on one day, on one carrier. The problem is that none of those stay still. The right initial_silence for a fresh list is wrong for an aged one; the right greeting at 9 a.m. drifts by the evening; a carrier change shifts the whole answer-audio profile underneath you. The thresholds that win this week quietly lose next week.

If you do want to push stock AMD as far as it goes, the place to start is narrowing the uncertain middle — tightening the band where AMD flips between humans and machines. But understand the ceiling: even perfectly tuned, timing-based AMD is a heuristic, and a heuristic on noisy answer audio tops out around 70–85% accuracy while dropping 5–15% of your live humans. That is the structural limit of guessing identity from how long someone paused. For the full picture of what stock AMD can and cannot do, see what default AMD actually is.

The alternative is to stop measuring timing altogether. AMDY is an AI model that classifies the acoustic signature of the answer audio — the sound of the answer, not how long the pause was — and returns a decision in under 200 ms at 99% accuracy. There is no initial_silence to set, no greeting window to guess at, and nothing that drifts with list age or time of day. It installs on Vicidial with one bash command in about five minutes, keeps your existing carrier, and classifies more than two buckets — human, voicemail, carrier false-answer, honeypot, fax, and silence. The full setup is in the Vicidial AMD guide.

FAQ

Where is amd.conf located?

On a standard Asterisk or Vicidial install it lives at /etc/asterisk/amd.conf. After editing it you reload the module with "module reload app_amd.so" (or a full "core reload") from the Asterisk CLI — there is no need to restart the whole dialer.

What's the most important amd.conf setting?

initial_silence and greeting do the most work. initial_silence decides how long the caller can stay quiet before AMD leans toward MACHINE, and greeting caps how long a "human hello" can run before it looks like a voicemail message. Most false positives on live humans trace back to one of those two being too tight for your lists.

What is drop_call_seconds?

It is a Vicidial-layer setting (not part of amd.conf) that controls how long a call flagged as a machine is held before Vicidial drops it. It exists so the system can wait for the answering-machine beep — useful if you leave messages — rather than hanging up the instant AMD returns MACHINE.

What's the difference between amd_send_message HANGUP and CONTINUE?

amd_send_message is the Vicidial campaign action taken when AMD returns MACHINE. HANGUP drops the call immediately (or after drop_call_seconds). CONTINUE keeps the call up and plays a pre-recorded message into the voicemail before hanging up. HANGUP protects agent time; CONTINUE is for ringless-style voicemail drops.

Do I still tune amd.conf with AMDY?

No. AMDY replaces the timing heuristic entirely with an acoustic AI classifier, so there are no thresholds to tune. You can leave amd.conf at its defaults or stop calling app_amd at all — AMDY returns the human-vs-machine decision over its WebSocket gateway in under 200 ms at 99% accuracy.

See your real human-vs-machine numbers — free

50,000 detections a month on the Sandbox plan, no card, 5-minute Vicidial install.

Start free Sandbox Vicidial AMD guide