VICIdial AMD Type: Built-in AMD vs Third-Party Engines

The AMD Type field on a campaign decides which detection engine inspects an answered outbound call and decides whether a human or a machine is on the line. It sits near the other answering machine detection (AMD (answering machine detection)) controls on the campaign screen, and for almost every system the right value is the one already there. This post explains what each choice means and when, if ever, you should change it.

What AMD Type controls

AMD Type names the detection technology used when routing answered outbound calls. The default is AMD, which means the built-in Asterisk AMD application that ships with a standard install. That engine runs inside the 8369 call processor, listens to the start of the call, and labels it before handing the call to the routing script. Most operators never touch this field because the built-in engine is free, already wired into the Dialplan, and good enough once tuned.

You should only change AMD Type if you have a supported third-party detection engine installed AND you have confirmed the correct Routing Extension with your system administrator. Picking an engine that is not present, or pointing it at the wrong extension, breaks routing for every answered call on the campaign. This is not a setting to experiment with on a live list.

The third-party options

Two alternative paths come up most often. The first is ViciAMD (ViciAMD), which can show the detection status, the cause, and a transcript of the customer's opening words to the agent the moment the call lands. The second is a KHOMP call progress detection gateway, a separate hardware/software path that performs broader call progress detection (CPD (call progress detection)) than the Asterisk engine, including signals the built-in tool cannot catch. KHOMP brings its own settings container so a single campaign can use a dedicated configuration.

The historical paid option was Sangoma's per-channel licensed CPD engine, which reached roughly 95 to 97 percent accuracy and could lower your drop rate (Drop rate) by spotting disconnect tones. It reached end of life years ago, so it is not a path for new builds.

How the choice flows

flowchart TD
  A[Outbound call answered] --> B{AMD Type}
  B -->|AMD default| C[Asterisk AMD in 8369]
  B -->|ViciAMD| D[ViciAMD engine plus agent display]
  B -->|KHOMP| E[KHOMP CPD gateway]
  C --> F[Routing script labels call]
  D --> F
  E --> F
  F --> G[Send to agent or machine path]

Before you change it

Check three things first. Make sure your campaign uses an auto-dial method such as ratio dialing (Ratio dialing) or adaptive dialing (Adaptive dialing), because detection does not run in manual modes. Confirm the engine is actually installed and licensed. Then verify the Routing Extension with your administrator so the labeled call reaches the right place.

• Keep AMD for built-in detection on a standard system.
• Choose ViciAMD when you want detection results shown to agents.
• Choose KHOMP when a dedicated gateway already handles your detection.

For the full background on how detection fits into outbound dialing, read our AMD and CPD complete guide, and for a primer on the feature itself see what VICIdial AMD is.

Running a managed VICIdial cluster means the built-in AMD engine and the dialplan around it are already in place and tuned, so changing AMD Type stays a deliberate choice rather than a setup chore. See VICIfast pricing to get a cluster where detection works out of the box.