What VD_amd.agi Does After a Call Clears AMD in VICIdial

AMD listens to a call, but it does not move the call anywhere. That job belongs to a small script called VD_amd.agi. It runs right after the analysis finishes and is the piece that turns an AMD result into an actual route. If you have ever wondered what happens in the half second between a call being answered and an agent picking up, this is most of it.

Where the script runs

On an AMD-enabled campaign, calls pass through the 8369 extension in your dialplan (Dialplan). That extension plays a moment of silence, logs the call, runs the Asterisk AMD application, and then calls VD_amd.agi. Only after VD_amd.agi has done its work does the call get handed to the outbound VDAD AGI that actually connects an agent. So the script sits between detection and routing.

It is invoked with the extension as an argument, plus a flag. A flag of NO means a normal AMD pass, where the script reads the detection result and sends the call onward. A flag of YES, used on extension 8320, means the call has already been judged a machine and the script should play the recorded message to it rather than re-analyze anything.

sequenceDiagram
  participant C as Carrier
  participant D as Dialer 8369
  participant S as VD_amd.agi
  participant A as Agent
  C->>D: Call answered
  D->>D: Run AMD analysis
  D->>S: Pass result with NO flag
  S->>S: Read AMD status
  alt Human result
    S->>A: Hand to VDAD route
  else Machine result
    S->>C: Play message or hang up
  end

What it decides

VD_amd.agi reads the status that AMD set, then applies your campaign settings to it. If the result is a human, it sends the call on to the outbound routing AGI so an agent (Agent) gets it. If the result is a machine and you have AMD send to Action pointed at a message, it routes the call so the recorded prompt plays. If your action is set to hang up, it ends the call there.

When an agent manually marks a live call as an answering machine, the same script handles leaving a voicemail drop (Voicemail drop) through the 8320 path. That is why the script appears twice in the dialplan: once for automatic AMD routing, and once for the agent-triggered message. The two share the same code but get opposite flags, which keeps the logic in one place.

It is worth being clear about what the script does not do. It does not perform the audio analysis itself. The Asterisk AMD application does that on the line just before, and it is the one that sets the status the script later reads. So if your detection accuracy is off, you tune the AMD parameters, not VD_amd.agi. The script only acts on the verdict it is handed.

Why you should care

Most operators never touch VD_amd.agi directly, and that is fine. It is wired up automatically on a default or VICIBox build. But knowing it exists explains a lot of behavior you would otherwise chase in the wrong place. If machine calls are not getting your message, the problem is usually the action setting the script reads, not the detection itself. If calls hang too long before an agent answers, the analysis time feeding the script is the place to look, and the AMDMINLEN minimum-run setting can affect that too.

Reading the AMD Log Report alongside this helps. The report shows the status each call got, and since the script acts purely on that status, the report tells you exactly what decision VD_amd.agi made and why. When a campaign (Campaign) behaves unexpectedly, lining up the logged status against your action settings usually points straight at the fix.

The script only matters on auto-dial methods, since AMD does not run in manual or inbound-manual modes. For the full mechanism around it, see our complete AMD and CPD guide, and for the dialplan side read the AMD entries in extensions.conf.

If editing AGI scripts and dialplans is not how you want to spend your week, we manage all of it for you. See VICIfast pricing and let us handle the plumbing.