GoAutoDial AMD setup: integrating AI answering machine detection

What GoAutoDial is

GoAutoDial is an open-source, web-based call center suite built on top of ViciDial and Asterisk. Versions 4 and 5 run on CentOS or Debian and ship a polished browser UI over the same telephony stack that ViciDial operators know well. The web layer handles campaign configuration, agent management, reporting, and disposition routing — but underneath, calls are still processed by Asterisk, and answering machine detection still runs through Asterisk’s app_amd.

That means everything true about ViciDial’s AMD is equally true about GoAutoDial’s. The same configuration file, the same AMDSTATUS variable, the same structural accuracy ceiling. GoAutoDial’s web UI doesn’t reimplement AMD — it just provides a friendlier surface for the settings that live in amd.conf.

How GoAutoDial AMD works

When a campaign dials a number and the call is answered, Asterisk runs app_amd, which analyzes the answer audio using timing and silence heuristics. The result is stored in the AMDSTATUS dialplan variable: HUMAN, MACHINE, or NOTSURE. GoAutoDial routes those outcomes based on the campaign’s AMD settings.

In the GoAutoDial admin panel, AMD settings are found under Campaign settings › AMD Settings. The key parameters you’ll see there map directly to the underlying amd.conf variables:

• AMD: Enabled / Disabled — toggles app_amd for the campaign.
• Drop Call Seconds — how long to wait before hanging up on a detected machine. Maps to the dialplan timer after AMDSTATUS returns MACHINE.
• Send AMD Message — whether to play a pre-recorded voicemail drop when a machine is detected.
• No Agent No Delay — controls whether human-answered calls are immediately connected or wait for an available agent first.

The amd.conf timing variables (InitialSilence, Greeting, AfterGreetingSilence, etc.) are typically edited directly in the file on the server; they don’t surface in GoAutoDial’s web UI.

The limitations — same as every heuristic AMD

GoAutoDial’s AMD tops out at roughly 70–85% accuracy because it uses the same heuristic approach as stock Asterisk. The algorithm counts syllables and measures silence intervals — logic designed for clean PSTN audio in the early 2000s. On modern VoIP, compressed cell audio, and regional carrier quirks, those heuristics break in predictable ways.

• NOTSURE concentration — uncertain calls cluster your most engaged prospects (fast answerers who don’t pause). Most dialers hang up on NOTSURE by default. See how NOTSURE drops your best leads →
• False answer supervision blindness — carrier FAS looks like an answered call to app_amd. The dialer counts it as a connection, burns agent capacity, and your reports never show it. What FAS costs you →
• Fast greetings misread as machines — a human who answers with “Hello?” and no pause triggers the syllable counter the same way a voicemail intro does. Why “Hello?” breaks default AMD →
• Honeypot blindness — spam traps and number-reputation probes return a valid answer signal that heuristic AMD cannot distinguish from a real pickup.

No amount of tuning in Campaign settings › AMD Settings overcomes these structural limits. The ceiling is set by the heuristic algorithm, not by the configuration values.

How AMDY integrates with GoAutoDial

AMDY works at the Asterisk dialplan level, not the GoAutoDial application level. The installer patches the Asterisk configuration directly on the server — the GoAutoDial web UI doesn’t need changes, and your campaign settings stay as they are.

Because GoAutoDial runs on top of ViciDial’s Asterisk backend, the AMDY install command is identical to a standard ViciDial install:

The installer runs on the GoAutoDial server (CentOS or Debian), detects the Asterisk installation, injects the AMDY dialplan hook, and registers the server with your AMDY account. No telephony migration, no carrier change, no ViciDial configuration changes.

Under the hood, AMDY taps the answer audio stream via a local WebSocket connection. When a call is answered, AMDY’s acoustic model starts classifying it in 1/8 of a second and writes the result back into the Asterisk channel variables that GoAutoDial already reads — so routing behavior continues to work exactly as configured.

What changes in the GoAutoDial UI after AMDY is installed

The AMD settings panel in GoAutoDial looks identical after installation. Nothing changes there by design. What changes is the accuracy of the values flowing through those settings:

• Higher HUMAN rates in campaign reports — calls that heuristic AMD was dropping as MACHINE or NOTSURE are now correctly classified as HUMAN and connected to agents.
• Lower NOTSURE rates — AMDY makes a definitive classification on virtually every call; the gray zone shrinks to near zero.
• FAS calls flagged separately — carrier false-answers that previously appeared as MACHINE dispositions are identified and tracked in the AMDY dashboard.
• Honeypot alerts — spam-trap numbers are flagged before your DIDs are burned on them.

Your agents see the operational change: more live humans connected per hour, fewer dead-air calls that wasted their attention. GoAutoDial’s built-in reporting shows the improvement in connect rate and agent utilization without any report reconfiguration on your part.

Troubleshooting common GoAutoDial AMD issues

Calls never reaching AMD

If AMDSTATUS is never set — or calls are all hitting the same disposition regardless of who answers — the issue is usually dialplan order. Check that the AMDY dialplan hook is being executed before the campaign’s routing logic. Run asterisk -rx "dialplan show" and confirm the AMDY context is included in the right place.

All calls returning NOTSURE

If AMDY is installed but every call comes back NOTSURE, the audio isn’t reaching the classifier. The most common cause is an audio routing issue — the answer audio stream isn’t being mixed into the channel AMDY is listening on. Check that the Asterisk audio snoop is enabled and that no conflicting recording or monitoring application is consuming the stream first.

High drop rate after install

If your abandon rate spikes after enabling AMDY (or any AMD change), check Drop Call Seconds in your campaign’s AMD settings. If this value is set very low (under 2 seconds), a human who takes a breath before speaking can be treated as a machine and dropped before connecting. Start with 3–4 seconds and adjust based on your call data. The AMDY dashboard shows per-call classifications and timing, which makes the right value easy to find.