AMD isn't working: the checklist to run through

When AMD (answering machine detection) (answering machine detection) stops behaving, the symptom is usually one of two things: every call sails straight through to your agents as if no detection is happening, or live people get hung up on while real answering machines slip past. Both come down to a handful of settings that have to line up. Here is the checklist I run through, top to bottom, before I touch anything clever.

Start with the campaign, not the dialplan

The single most common reason AMD does nothing is that the calls are not being routed through the AMD-enabled processor at all. Open the Campaign Detail page and check the Campaign VDAD exten field. To activate AMD it has to be set to 8369 so calls go through the AMD call processor. If it is still on the standard exten, detection never runs and every call looks like a live answer.

While you are on that page, confirm the dial method. AMD will not run under a MANUAL or INBOUND_MAN dial method, so if your Campaign is set to either of those, detection is silently skipped no matter what else you configure.

The decision path when AMD misbehaves

flowchart TD
  A[AMD not working] --> B{Campaign VDAD exten is 8369}
  B -->|No| C[Set exten to 8369]
  B -->|Yes| D{Dial method is not MANUAL}
  D -->|No| E[Switch to a predictive method]
  D -->|Yes| F{AMD app loaded on Asterisk}
  F -->|No| G[Load app and reload dialplan]
  F -->|Yes| H{8369 block in extensions.conf}
  H -->|No| I[Add block and reload]
  H -->|Yes| J[Tune AMD parameters]

Confirm the Asterisk app is actually there

AMD relies on an optional Asterisk application being loaded on your server. If it was never installed, the feature simply will not function, and you will see no detection happening at all. On a VICIBox Server ISO install it is loaded standard, but on a hand-built box it may be missing. This case is common enough that it has its own writeup in the AMD application not loaded guide.

Check the dialplan and reload it

Two sections need to be present in your extensions.conf: the 8369 transfer block that runs the AMD application and hands the call to VD_amd.agi, and the 8320 block that plays a message to a detected machine. On a default or VICIBox install these are already in place. If you added them by hand, the change is not live until you reload. Run one of these:

1. Restart Asterisk, or
2. Type dialplan reload on the Asterisk CLI, or
3. Go to Admin then Servers and click submit to trigger a fresh dialplan reload.

Skipping the reload is the quiet killer here. The lines look right in the file, but the running Asterisk has no idea they exist, so the 8369 extension behaves like it is empty. For the full extensions.conf detail, see the AMD campaign setup walkthrough.

If it runs but the accuracy is off

Once detection is genuinely running, a wrong-feeling result is a tuning problem rather than a wiring one. AMD is not perfect and has to be adjusted to the kind of leads and telecom lines you dial. If it is hanging up on real customers, that is an AMD false positive and the parameters on the AMD line are too aggressive. If you also lean on Beep detection for leaving messages, or expect Fax detection to peel off fax lines, those depend on the same processor running first.

One honest caveat: AMD adds processing time to every call, not just the ones that reach a machine, which is why many shops set a 22 to 26 second dial timeout instead. If you want the full picture on how detection fits alongside CPD (call progress detection) and ViciAMD, the complete AMD and CPD guide covers the trade-offs in order.

If you would rather not babysit dialplans and reloads at all, our managed VICIdial comes with AMD wired and tuned out of the box. See our pricing to compare plans.