The AMD() Asterisk Parameters and What Each Number Controls

When you turn on answering machine detection (AMD (answering machine detection)) for a campaign (Campaign), the work happens on one line in your dialplan (Dialplan). That line calls the Asterisk AMD application with a string of numbers, and each number controls one part of how the system decides human versus machine. Get them right and detection matches your traffic. Get them wrong and you flag people as machines or let machines through.

Where the parameters live

AMD runs through the AMD-enabled call processor, which you switch on by setting the Campaign VDAD exten to 8369. That extension plays brief silence, logs the call, runs the AMD application with its parameters, runs the VD_amd script, then hands the call to the outbound routing. The numbers we are talking about sit inside that AMD() call. For how the extension is wired, see our piece on the 8369 call processor.

The eight numbers in order

The parameters appear in this fixed order, measured in milliseconds or counts:

1. Initial silence: how long the system waits for any speech at the start. A machine often opens with silence before the greeting; a longer value tolerates that gap.
2. Greeting length: how long a stretch of speech can run before it is judged a machine greeting rather than a human hello. This is the single biggest lever for false positives.
3. After-greeting silence: how much silence after speech the system needs to confirm a greeting has ended.
4. Total analysis time: the hard cap on how long AMD will listen before it must return a result. Higher means more accuracy but more delay on every call.
5. Minimum word length: the shortest sound counted as a word, which filters out clicks and noise.
6. Between-words silence: the gap between sounds that marks the boundary between separate words.
7. Maximum number of words: how many words before the call is treated as a machine, since people answer with few words and greetings use many.
8. Silence threshold: the audio level below which the line counts as silent, which controls how the system handles noisy lines.

flowchart LR
  A[Call answered] --> B[Initial silence window]
  B --> C[Detect speech]
  C --> D{Greeting length and word count}
  D -->|Short, few words| E[HUMAN]
  D -->|Long, many words| F[MACHINE]
  C --> G[Total analysis time cap]
  G --> H[Return result]

How tuning trades one error for another

Tightening the greeting length and maximum word count makes AMD quicker to call something a machine. That catches more machines but raises the chance of a false positive (AMD false positive) on a person with a chatty greeting. Loosening those same values protects live people but lets more machines reach your agent (Agent). There is no setting that wins both ways. You tune toward whichever error is costing you more.

Change one number, dial a few hundred leads, then check the AMD Log Report to see what the new value actually decided. Repeat. Tuning by feel does not work; tuning against logged results does. Our guides on fixing false positives and the full AMD and CPD guide show the direction to move each number.

A note on cost

The total analysis time matters beyond accuracy. Because AMD runs on every answered call, a longer analysis window adds delay to live answers too, not only machines. Keep it long enough to be accurate and no longer.

Editing dialplan numbers by hand is exactly the kind of work a managed dialer should take off your plate. VICIfast handles the extensions and the AMD application so you can tune the parameters that matter without a dialplan reload going wrong. See VICIfast pricing to get a dialer where AMD is already wired correctly.