"AMD not working" because the AMD Asterisk application isn't loaded

You set the campaign exten, picked a message, and yet AMD (answering machine detection) (answering machine detection) acts like it is switched off, with every call landing on an agent as a live answer. Before you start tuning parameters, rule out the one cause that no amount of tuning will fix: the AMD Asterisk application is not loaded on the server. AMD depends on an optional Asterisk app, and if that app is not present, the feature will not work at all.

Why this happens

On a VICIBox Server ISO install the AMD application is included standard, so most people never see this. The gap shows up on hand-built boxes, custom Asterisk compiles, or servers where someone trimmed modules to save resources. If you do not have a default VICIdial or VICIBox install, getting this working can take a little systems administration, or a hand from whoever owns your Asterisk box.

How to confirm the app is missing

The 8369 dialplan block calls the AMD application directly, on the line that reads AMD with its parameter string of timing values. When the application is loaded, that call runs and hands the result to the VD_amd.agi script, which routes the call to its proper destination. When the application is not loaded, that AMD step has nothing to execute, so detection never produces a verdict and the call just continues as a normal live answer.

So the tell is consistent: the 8369 lines are present in extensions.conf, the campaign is pointed at exten 8369, the dial method is not MANUAL, and detection still does nothing. That pattern points straight at the missing application rather than a Campaign setting.

Decision flow

flowchart TD
  A[AMD produces no verdict] --> B{8369 block present}
  B -->|No| C[Add the 8369 dialplan block]
  B -->|Yes| D{Campaign exten is 8369}
  D -->|No| E[Point campaign at 8369]
  D -->|Yes| F{AMD app loaded on Asterisk}
  F -->|No| G[Install or load the app]
  G --> H[Reload dialplan]
  F -->|Yes| I[Look at parameter tuning]
  H --> J[Retest a known machine]

Getting the app loaded

Loading the optional AMD application is an Asterisk-side job. Once the module is in place, your existing 8369 block can finally execute the AMD step instead of falling through it. The two dialplan sections still need to be present: the 8369 transfer block that runs AMD and hands off to the VD_amd.agi routing script, and the 8320 block that handles playing a message to a detected machine. If those blocks were never added on a hand-built box, put them back exactly as they appear on a default install, because the AGI script names and the order of steps matter for the routing to work.

Reload, then retest

Any change to extensions.conf only takes effect after a reload. Pick whichever fits your access:

• Restart Asterisk entirely, or
• Run dialplan reload on the Asterisk CLI, or
• Open Admin then Servers and click submit to fire off a dialplan reload.

Then place a test call to a number you know hits an answering machine and watch whether detection now fires. If it does, you are back in business and any remaining oddness is tuning, such as an AMD false positive on a noisy line, rather than a missing module. The same goes for Fax detection and ViciAMD features, which all sit on top of the same detection step running first.

If you want the conceptual background on what detection is actually deciding, read what VICIdial AMD is, and for the whole detection picture including CPD (call progress detection), the complete AMD and CPD guide ties the pieces together.

Tired of chasing missing modules on a self-built stack? Our managed VICIdial ships with the AMD application loaded and ready. Check our pricing to see what is included.