Detecting answering machines with VD_amd.agi

Answering machine detection (AMD (answering machine detection)) is the process of deciding, within the first few seconds of a picked-up call, whether a human or a recording device answered. Connecting a live agent to a voicemail greeting wastes the agent's time and counts as an abandoned call. VD_amd.agi is the AGI (Asterisk Gateway Interface) script VICIdial uses to act on that detection result. It does not run AMD itself — Asterisk's built-in AMD() application runs first and sets a channel variable, then VD_amd.agi reads that result and routes the call to its proper destination.

How VD_amd.agi fits into the dialplan

flowchart TD
  A[Outbound call answered] --> B[call_log.agi logs attempt]
  B --> C[AMD Asterisk application runs]
  C --> D{AMD result}
  D -->|HUMAN| E[VD_amd.agi called with NO flag]
  D -->|MACHINE| F[VD_amd.agi called with YES flag]
  E --> G[agi-VDAD_LB_transfer.agi routes to agent]
  F --> H[Hangup or voicemail drop]
  G --> I[Agent receives call]
  H --> J[Call ends]

The script takes two arguments separated by five dashes. The first is the dialed extension. The second is a flag: NO means a human answered (proceed to agent), and YES means a machine was detected (hang up or play a voicemail drop message). The standard load-balanced setup looks like this:

exten => 8369,1,AGI(call_log.agi,${EXTEN})
exten => 8369,2,(AMD),AMD
exten => 8369,3,AGI(VD_amd.agi,${EXTEN}-----NO)
exten => 8369,4,AGI(agi-VDAD_LB_transfer.agi,${EXTEN})
exten => 8369,5,AGI(agi-VDAD_LB_transfer.agi,${EXTEN})
exten => 8369,6,AGI(agi-VDAD_LB_transfer.agi,${EXTEN})
exten => 8369,7,Hangup

exten => 8320,1,AGI(VD_amd.agi,${EXTEN}-----YES)
exten => 8320,2,Hangup

Extension 8369 handles the full path: log the call, run AMD, then invoke VD_amd.agi with the NO flag (human path), then attempt agent transfer up to three times before hanging up. Extension 8320 is the machine path — the AMD (answering machine detection) result routes there and the call ends after VD_amd.agi does its cleanup.

The AMDMINLEN setting

One useful feature is AMDMINLEN. Setting this variable immediately before your Dial() line forces the AMD process to run for at least the specified number of seconds before concluding. A value of 7 means the script runs for a minimum of 7 seconds before making its decision and potentially hanging up. This helps on calls where a machine plays a long preamble before the greeting, which would otherwise be cut off before AMD could reliably classify it.

exten => _91NXXNXXXXXX,n,Set(__AMDMINLEN=7)

False positives and when to avoid AMD

An AMD false positive happens when AMD classifies a human answer as a machine and hangs up on a live person. This is the most damaging failure mode because the lead hears a click and you miss a contact. False positives are more common with elderly callers who answer slowly, callers in noisy environments, and calls where the carrier inserts audio before the remote party speaks. Tuning Asterisk's AMD parameters — particularly silence and speech thresholds — reduces false positives but never eliminates them entirely. For campaigns where miss rate is critical, some operators disable AMD and accept the cost of agents occasionally connecting to voicemail instead.

VICIdial also integrates with ViciAMD, a dedicated commercial AMD service, as an alternative to Asterisk's built-in detection. The VICIdial admin settings for a Campaign let you choose between the two approaches per campaign.

For a broader look at how AGI scripts work alongside the VICIdial API, see the VICIdial API and AGI overview. For the HTTP-based API perspective on how calls are tracked and leads updated, the guide on reading VICIdial API responses is a good companion.

Every VICIfast plan ships with the standard AMD dialplan already in place so you can configure AMD thresholds without manually editing extensions.conf.