VICIdial AMD Settings Explained: What Each Value Does and How to Tune It

VICIdial's answering machine detection has a reputation for being either fine or useless, depending on who you ask. Both camps are describing the same eight numbers. Set well for your list, the built-in detector is a reasonable filter. Left at defaults on the wrong list, it hangs up on a fifth of the people who answer.

This guide explains what each VICIdial AMD setting actually does, how the detector reaches a verdict, how to tune it one value at a time, and where tuning stops helping. At the end is a comparison of what you can and cannot adjust in the other AMD options for VICIdial: Khomp, AMDY and VM Hunter.

Menu names and defaults vary between VICIdial and ViciBox versions. Check each value on your own server before changing it.

Where AMD lives in VICIdial

There are three layers, and it helps to know which one you are changing.

1. The campaign. In the campaign's detail view, the Routing Extension decides whether detection runs at all. On a stock install, 8368 sends answered calls straight to agents and 8369 sends them through AMD first. Related campaign fields control what happens to a machine: AMD Send to VM exten, the answering machine message extension, CPD AMD Action, and on recent versions AMD Type.

2. The dialplan. Extension 8369 in extensions.conf on each dialer server is where Asterisk's AMD() application is called. You can see yours with:

asterisk -rx "dialplan show 8369@default"

On many installs the line looks like this, with the eight parameters passed directly:

exten => 8369,1,AMD(2000,2000,1000,5000,120,50,4,256)

3. amd.conf. If AMD() is called with no arguments, Asterisk reads the values from /etc/asterisk/amd.conf. If arguments are passed in the dialplan, they win. This is the most common reason a change "does nothing": the file was edited but the dialplan passes its own numbers.

After a dialplan change, run dialplan reload. After an amd.conf change, run module reload app_amd.so.

How the detector decides

Asterisk's AMD() does not listen to words. It measures when there is sound and when there is silence, and applies rules:

• A long silence at the start: nobody is speaking. Machine.
• A short burst of sound followed by silence: someone said "Hello?" and is waiting. Human.
• A long unbroken run of sound: a greeting is playing. Machine.
• Many separate bursts of sound: a sentence. Machine.

It then sets two channel variables. AMDSTATUS is HUMAN, MACHINE, NOTSURE or HANGUP. AMDCAUSE says which rule fired: INITIALSILENCE, HUMAN, LONGGREETING, MAXWORDS, MAXWORDLENGTH or TOOLONG, each followed by the measured values.

Every setting below is a threshold in one of those rules.

The eight settings

The parameters are positional, in this order. Times are in milliseconds.

1. Initial silence

How long the line can stay quiet after answer before the call is declared a machine (INITIALSILENCE). Asterisk's default is 2,500.

• Too low: people who take a breath, or bring the phone to their ear slowly, are dropped.
• Too high: dead-air calls wait longer before being cleared.

If your "machine" recordings include many quiet pickups followed by a late "Hello?", raise it.

2. Greeting

The longest run of speech that still counts as a person. Longer than this and the cause is LONGGREETING. Default 1,500.

• Too low: "Hello, this is David speaking" is called a machine.
• Too high: short voicemail greetings pass as human.

This is the setting with the hardest trade. Business lists, where people answer with a company name, need it higher than consumer lists.

3. After-greeting silence

How much silence after the first speech confirms a person has stopped and is waiting. Default 800. Reaching it gives HUMAN.

• Too low: the natural gap between "Hi," and "you've reached..." is taken as a person.
• Too high: every human verdict is delayed by the same amount, and the callee hears more dead air.

4. Total analysis time

The ceiling on the whole analysis. If no rule has fired by then, the result is NOTSURE with cause TOOLONG. Default 5,000.

Check what your dialplan does with NOTSURE. Some treat it as machine, some as human. That one choice can move your numbers more than any threshold.

5. Minimum word length

A sound must last at least this long to count as a word. Default 100.

• Too low: clicks, breaths and line noise are counted as words, pushing calls towards MAXWORDS.
• Too high: a clipped "Yes?" is ignored and the call drifts to INITIALSILENCE.

6. Between-words silence

The gap that separates one word from the next. Default 50. Lower values split speech into more words; higher values merge them. It interacts with the next setting, so change them together or not at all.

7. Maximum number of words

How many words are allowed before the call is declared a machine (MAXWORDS). Sample configurations use 3; the VICIdial dialplan line above uses 4.

• Too low: "Hello? Who is this?" is a machine.
• Too high: a short greeting such as "Leave a message after the tone" gets through.

Note that Asterisk versions differ on whether the limit must be reached or exceeded. Test rather than assume.

8. Silence threshold

The audio level below which a frame counts as silence, on a scale of 0 to 32,767. Default 256.

• Too low: line hiss counts as sound. Nothing is ever silent, and calls end as TOOLONG or LONGGREETING.
• Too high: quiet speakers are treated as silence.

Noisy trunks and transcoded routes need a higher value. This is the first thing to check if results change after a carrier change.

There is a ninth value, maximum word length (default 5,000), which declares a machine when a single unbroken sound runs that long. It rarely needs changing.

The campaign fields

• Routing Extension. 8368 for no AMD, 8369 for AMD. A third-party detector uses its own extension here.
• AMD Send to VM exten. Whether machine calls are sent to the answering machine message extension to leave a recording.
• Answering Machine Message. The extension or recording played to machines when the above is on.
• WaitForSilence Options. Used with voicemail drop, to wait for the greeting to end before the message plays.
• CPD AMD Action and AMD Type. For external call progress detection hardware and gateways, such as the Khomp integration.

How to tune without guessing

1. Get a baseline. For one campaign and one day, count the dispositions, then listen to twenty recordings the detector called machine and twenty it called human.
2. Log the cause. Add a NoOp(${AMDSTATUS} ${AMDCAUSE}) after AMD() so the Asterisk log shows which rule fired on each call.
3. Find the dominant wrong cause. If the dropped people are mostly INITIALSILENCE, raise initial silence. If they are MAXWORDS, raise the word limit or the minimum word length. If voicemails reaching agents are mostly HUMAN with a short greeting, lower the greeting value.
4. Change one value, run one day, listen again.
5. Tune per list type. Mobile-heavy consumer lists and business lists want different values. Use separate campaigns and separate extensions.

Count the two errors separately. A person called a machine is a lost lead. A machine called a person costs an agent fifteen seconds. Most centres tune only against the second, because it is the one agents complain about, and make the first worse.

Where tuning stops

Tuning moves the line between two errors. It does not remove the overlap, because some people and some machines produce the same timing:

• "Hello?" then a pause is a person. So is "Hi, this is Mike." then a pause, except when it is the start of Mike's voicemail greeting. The timing is identical for the first two seconds.
• iOS call screening ("Hi, if you record your name and reason for calling...") is a sentence of continuous speech. It will always be LONGGREETING or MAXWORDS. There is a person behind it, and no threshold can tell you.
• Carrier announcements ("The number you have dialled...") are machines, correctly, but are not distinguished from voicemail, so disconnected numbers are recycled like voicemail.
• Calls with no audio end as INITIALSILENCE, the same as a quiet person.

Operators who measure the built-in detector carefully typically find 15 to 20% of live answers classified as machines on consumer lists. When you have tuned and are still above 10%, you are at the limit of the method.

The other AMD options for VICIdial, and what you can tune in each

This comparison uses each vendor's public documentation as of October 2026. Check their sites for current details.

A fair summary: the built-in detector is free and tunable but blind to content. Khomp moves the decision into a gateway before the call reaches VICIdial. AMDY and VM Hunter are both hosted AI services with a free tier; they differ in method, sound versus words. We tested that difference with an acoustic model of our own on 4,000 agent-labelled calls, and published the results and their limits. That model is ours, not AMDY's, so run your own comparison before deciding.

How to compare any of them with your current settings

Whatever you are considering, the test is the same and takes a day:

1. Split one list at random into two campaigns. Leave one on extension 8369 with your tuned settings. Point the other at the alternative's routing extension.
2. Same agents, same hours, recordings on.
3. Next morning, listen to the first three seconds of 200 calls from each and mark what was really there: person, voicemail, carrier message, call screening, silence.
4. Count people dropped and machines passed, separately, for each side.

For the VM Hunter side, setup is one script and one dialplan extension (8370 in our guide), about 30 minutes, and the free plan covers the test. The steps are in the VICIdial integration guide. If the built-in detector is not behaving at all, start with VICIdial AMD not working instead.