The Two Dialplan Entries VICIdial AMD Needs

Answering machine detection in VICIdial leans on two blocks in your dialplan. If they are missing, turning AMD on in the campaign screen does nothing useful. On a default or VICIBox build these are already in place, but if you built your own server or you are debugging why AMD will not fire, this is the first thing to check in extensions.conf.

Entry one: extension 8369

Extension 8369 is the AMD-enabled call processor. It is what you point a campaign at when you set the Campaign VDAD exten to 8369. The block runs a short sequence in order. First it plays a brief silence so the line settles. Then it logs the call. Then it runs the Asterisk AMD application with its tuning parameters. Then it calls VD_amd.agi to route based on the result. Finally it hands the call to the outbound VDAD AGI that connects an agent (Agent).

• exten => 8369,1,Playback(sip-silence)
• exten => 8369,2,AGI(agi://127.0.0.1:4577/call_log)
• exten => 8369,3,AMD(2000|2000|1000|5000|120|50|4|256)
• exten => 8369,4,AGI(VD_amd.agi,${EXTEN})
• exten => 8369,5,AGI(agi-VDAD_ALL_outbound.agi,NORMAL-----LB)

The numbers inside AMD() are the tuning parameters, in order: initial silence, greeting length, after-greeting silence, total analysis time, minimum word length, between-words silence, max words, and silence threshold. Tightening or loosening these is how you trade false positives against false negatives. The block ends with a Hangup so a finished call does not linger. There are two more outbound routing lines after the VD_amd.agi step that act as load-balanced fallbacks, so a call that cannot route on the first attempt still has a path.

Notice the order. Detection happens at priority 3, routing at priority 4, and only then does the outbound AGI try to connect a person. That sequence is the whole reason AMD costs a little time on every call: each one walks through silence, logging, analysis, and routing before anyone picks up. It is also why a missing or out-of-order line here breaks AMD in confusing ways rather than failing outright.

Entry two: extension 8320

The second block handles playing a recorded message to a detected machine. When a call is forwarded as a machine, or when an agent marks a live call as one, it lands on 8320, which calls VD_amd.agi with a YES flag so the script plays your prompt instead of re-analyzing the call. This is the path that drops a voicemail (Voicemail drop) for you.

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

flowchart TD
  A[Campaign VDAD exten 8369] --> B[Play silence]
  B --> C[Log call]
  C --> D[Run AMD]
  D --> E[VD_amd.agi routes]
  E -->|Human| F[VDAD outbound to agent]
  E -->|Machine| G[Extension 8320]
  G --> H[Play recorded message]
  H --> I[Hangup]

After you edit the file

Changes to the dialplan (Dialplan) do not apply until Asterisk reloads. You can restart Asterisk, type dialplan reload at the Asterisk CLI, or open Admin then Servers and click submit to trigger a reload. Until you do, the new lines sit dormant and the campaign behaves as if AMD were off. This catches a lot of people: they edit the file, set the campaign, and wonder why nothing changed.

One more requirement sits outside these two blocks. The optional AMD application has to be loaded on your Asterisk server, or extension 8369 cannot run its detection step at all. On a VICIBox build it is installed as standard, but on a hand-built server it is worth confirming before you blame the dialplan. Also remember AMD only works on auto-dial methods, so do not expect these entries to do anything in manual dialing (Manual dialing (click to dial)).

For the surrounding setup, read our AMD and CPD guide, and to understand the script these lines call, see what VD_amd.agi does.

We set these dialplan entries up correctly on every managed server so you never edit extensions.conf yourself. See VICIfast pricing to skip the manual steps.