VICIdial AMD Not Working? How to Tell a Settings Problem From a Trunk Problem

"VICIdial AMD not working" covers three different problems that look the same from the agent's seat: the detector is not running at all, it is running but every call comes back the same way, or it is running and simply wrong too often. Each has a different cause and a different fix. This guide takes them in the order you should check them.

It applies to VICIdial's built-in detection (Asterisk app_amd, reached through the AMD routing extension) and, where noted, to third-party AMD such as VM Hunter.

First, find out which problem you have

Pull the dispositions for one campaign over one day and look at the split between the AMD outcomes. Then listen to twenty recordings from each group. Twenty is enough to see a pattern.

1. AMD is not running on the campaign

VICIdial only runs detection if the campaign is set up for it.

• In the campaign's detail screen, check the AMD settings: the campaign must be configured to send calls through the AMD routing extension (the default AMD extension is 8369; the non-AMD extension is 8368). If the routing extension is the non-AMD one, no detection happens.
• Check the campaign's dial method. Manual and some preview methods do not run AMD at all.
• If you have added a third-party detector, confirm the campaign's routing extension points at its extension (for VM Hunter, 8370 in the docs), and that the extension exists in the dialplan on every dialer server (asterisk -rx "dialplan show 8370@default").

If AMD is configured but you still see no detection, check the Asterisk full log for the call: you should see AMD() (or the EAGI line for a third-party client) executing after answer. If it is absent, the call is not reaching that extension.

2. AMD runs but every call is a machine

When the detector hears no audio, every verdict is "initial silence" or "machine". Causes, in order of how often we see them:

• AGI instead of EAGI. A third-party detector that reads audio from the channel needs EAGI(), not AGI(). With AGI() the script runs but gets no audio, so every call is silence. This is the single most common cause with external AMD.
• Audio not flowing yet at answer. Some carriers deliver answer supervision before media is established. The first second of the call is empty, and a detector with a short window decides on nothing. Compare the recording's first second with the AMD timestamps.
• Wrong leg. If the dialplan runs AMD on a leg that carries your own audio (ringback, the agent) rather than the callee's, the detector classifies you. Recordings make this obvious.
• Codec or sample-rate mismatch on external detectors expecting 8 kHz PCM. The log on the VM Hunter side shows audio_bytes = 0 or a wrong sample rate for the call.

The test: pick one call, find its recording, and ask whether a person listening to the first two seconds could have made a verdict. If there is nothing to hear, the detector is not at fault.

3. Verdicts are mostly right but too many people are dropped

This is the normal state of app_amd. It decides from timing, and its thresholds are a guess about how people and machines sound. Operators who measure it find 15 to 20% of live answers classified as machines, and the number swings with the list.

VICIdial exposes the app_amd parameters in its admin settings (the cpd_amd_* values in System Settings on recent versions, or amd.conf on the dialer directly). The ones that matter most:

• Initial silence. How long the callee can stay quiet after answer before the call is called a machine. Too short, and a person who takes a breath before "Hello?" is dropped. Start at 2,500 ms and raise it if you lose quiet answerers.
• Greeting length. How long continuous speech can run before it is a greeting rather than a person. Too long, and voicemail greetings reach agents; too short, and a talkative person is dropped. 1,500 ms is a common starting point.
• After-greeting silence. How much silence after the first speech confirms a person (they stopped and are waiting). Around 800 ms.
• Maximum number of words. More words than this in the window means a machine. Three or four for most lists.
• Minimum word length. Sounds shorter than this are not counted as words. Raise it (around 100 ms) if line clicks and breaths are being counted and pushing calls to "machine".
• Silence threshold. The level below which audio counts as silence. Noisy trunks need a higher value or every hiss is a "word".

Change one value at a time, run a day, and listen to twenty recordings from each disposition again. Tuning helps at the margins; it does not change what the method can do. app_amd cannot tell "Hello?" followed by a pause from "Hi, this is Mike, leave a message" cut at the same point, because both are a short burst of speech followed by silence of about the same length. A detector that uses the words can.

4. A large share of "machine" calls are the same prompt

Listen to your "machine" recordings and you will hear one prompt over and over on consumer lists: "Hi, if you record your name and reason for calling, I'll see if this person is available." That is iOS 26 call screening. A person is on the other end, reading a transcript of what you say, and your dialer is saying nothing.

app_amd hears a sentence of continuous speech and calls it a greeting. There is no setting that fixes this, because the fix is to recognise the words. On one customer's traffic, 15% of answered calls were screening prompts, three times the live answers.

What to do: detect the prompt, play a one-sentence intro saying who is calling and why, then connect an agent. The call screening page covers the routing; VM Hunter labels these calls CALLGUARD_PHRASE on every integration.

5. "Silence" calls that really are silent

If the recordings of your "initial silence" calls contain nothing at all, not even line noise, the dialer is being told the call was answered while no media is arriving. Causes:

• False answer supervision from the carrier: the call is marked answered while it is still ringing or while a network message plays. The audio starts late or never.
• One-way audio on the trunk, usually NAT or RTP configuration: the callee hears you, you hear nothing.
• Early media handling: ignore_early_media and progress settings that start the detector before the call is connected.

On trunks we have examined, this ranges from 5% to 15% of answered calls. No detector can classify audio that does not exist. The fix is on the carrier or trunk side, and the first step is to show the carrier the numbers: call IDs, timestamps, and the zero-byte recordings.

VM Hunter labels these calls separately from quiet-but-present audio (NO_AUDIO vs NO_SPEECH in the reason), so the share shows up in your call logs without listening.

6. Checks for a third-party detector

If you run an external AMD client on VICIdial:

• Verdicts arrive late. Anything played to the callee before the client runs, or audio buffered before streaming, delays the verdict by the same amount. The client should run immediately after answer with silence playing.
• Connection timeouts in the client log mean the dialer cannot reach the service: check outbound TCP to the service's port from each dialer server.
• Authentication failures mean the API key is not set where Asterisk can see it (environment variables are read from Asterisk's process, not your shell).
• The fail-safe. Know what the client does when the service is unreachable. The VM Hunter client treats a failure as MACHINE by default so a call is never left hanging; set it to HUMAN if you would rather connect than drop.

When to stop tuning and change the method

If sections 1, 2 and 5 are clear and you are still dropping 10% or more of live answers after tuning, the detector is doing what timing-based detection does. The way to find out what a speech-based detector would do on your list is a side-by-side: one campaign on the built-in extension, one on the alternative, same list, same day, then twenty recordings from each disposition.

VM Hunter's VICIdial integration is one script and one dialplan extension, and every call it analyses is logged with its transcript, reason and audio, which makes the listening pass quick. The free plan's 5,000 calls cover a day's test on most lists.