What Campaign VDAD Exten Does and Why AMD Needs 8369

When people try to turn on answering machine detection (AMD (answering machine detection)) and nothing happens, the usual reason is one field on the campaign (Campaign) that was never changed. That field is Campaign VDAD exten, and it quietly decides which call processor every dialed call runs through. This post explains what it does and why 8369 is the magic value.

What the VDAD exten field controls

VDAD is the outbound auto-dial process. When the dialer places a call and it connects, the call is handed to an extension (Extension) in your dialplan (Dialplan) that processes it: it logs the call, decides whether a live person is on the line, and routes it to an agent (Agent) or to another action. The Campaign VDAD exten field is simply which extension in the dialplan that handoff goes to.

A standard campaign points at a processor that does the routing but does not analyze the audio. The call connects, gets logged, and goes to whoever is next in line. That is fast and fine when you do not care whether a human or a machine answered. To get AMD, you have to send the call through a different processor, one that pauses to run the detection step before it decides where the call should go. That processor lives at extension 8369, and pointing the field at it is the whole switch.

Why 8369 specifically

Extension 8369 is the AMD-enabled call processor in the dialplan. It runs a specific sequence of steps in order, and the AMD analysis is baked right into the middle of it:

1. Play a brief silence so the line is clean before analysis.
2. Log the call through the call_log AGI.
3. Run the Asterisk AMD application, which listens to the early audio and guesses human versus machine.
4. Run VD_amd.agi to read that result and act on it.
5. Hand off to the outbound VDAD routing AGI, which sends the call where it should go.

flowchart TD
  A[Call connects] --> B[Campaign VDAD exten]
  B -->|Standard processor| C[Route only no analysis]
  B -->|8369 AMD processor| D[Play silence]
  D --> E[Log call]
  E --> F[Asterisk AMD analysis]
  F --> G[VD_amd.agi acts on result]
  G --> H[VDAD routing AGI sends call]

Compare that with the standard processor, which skips straight to routing. Without 8369 in the field, the Asterisk AMD step never runs, so there is no human-versus-machine result to act on. That is why changing this one value is what actually enables detection, not just having the AMD application installed.

Common gotchas

• The 8369 block must exist in your extensions.conf. On a default or VICIBox install it is already there; if you added it, reload the dialplan before testing.
• 8369 only matters on auto-dial methods. The dial method (Dial method) MANUAL and INBOUND_MAN bypass this processor entirely, so AMD will not run.
• Setting 8369 turns AMD on, but it does not tune it. The detection accuracy still depends on the AMD parameters in that dialplan line and on your leads.
• A typo here fails quietly. If the field points at a number with no matching dialplan entry, calls will not process correctly, so copy the value exactly and test a few calls before trusting it.

It is worth saying that 8369 is the standard AMD-enabled processor on a typical install, but the real point is the behavior, not the digits. The field is your switch between a plain routing processor and one that analyzes the call first. If a custom build uses a different extension for its AMD path, the rule is the same: point Campaign VDAD exten at whichever extension runs the AMD step. On stock and VICIBox systems, that is 8369.

Once 8369 is in place, the next question is what AMD is doing with the audio. Read how VICIdial AMD detects machines for the detection logic, and the AMD and CPD complete guide for the whole subject end to end.

Skip the dialplan archaeology

Hunting through extensions.conf to confirm the 8369 block exists is exactly the chore a managed VICIdial host handles for you. On VICIfast the AMD processor is in place and verified. To get a server where this just works, see VICIfast pricing.