AMD Dialer Not Working? 7 Common Problems and How to Fix Them

AMD is one of those systems that seems to work until it suddenly seems broken. The signs are usually one of two things: agents complaining they keep getting voicemails instead of live people, or your connect rate mysteriously drops while your AMD is classifying the same call volumes.

Before you spend hours debugging, know that most AMD problems fall into seven categories. This guide walks through each one — what causes it, how to diagnose it, and exactly how to fix it.

Problem 1: AMD Is Dropping Too Many Live Calls

Symptom: Agents have light workloads despite normal dial volumes. Call recordings show human voices in MACHINE-classified calls. Connect rate is lower than expected.

What is happening: Your AMD false positive rate is too high — live humans are being classified as machines and dropped before reaching an agent.

This is the most common AMD problem and the most expensive. See VICIdial false positive rate guide for the full measurement and fix process.

Diagnosis: Pull 200 random recordings of MACHINE-classified calls. Listen for human voices. If more than 10% have audible human responses, your false positive rate is too high.

Fixes:

  1. Increase initial_silence — more tolerance for hesitant human answers
initial_silence=3000
  1. Lower min_word_length — catch shorter "Hello?" responses
min_word_length=80
  1. Increase maximum_number_of_words — allow more verbose human greetings
maximum_number_of_words=4
  1. Switch to AI-powered AMD — if tuning cannot get your false positive rate below 8–10%, parameter adjustment alone will not solve it

Problem 2: Agents Keep Getting Connected to Voicemails

Symptom: Agents frequently answer calls that turn out to be voicemail greetings. Average handle time is artificially inflated. Agents are frustrated.

What is happening: Your AMD false negative rate is too high — voicemails are being classified as HUMAN and routed to agents.

Diagnosis: Review 50 calls that agents manually dropped within the first 5 seconds. What percentage were voicemail greetings?

Fixes:

  1. Lower greeting to catch shorter machine greetings
greeting=1200
  1. Lower maximum_number_of_words — stricter word-count threshold
maximum_number_of_words=3

  1. Check iOS 26 voicemail compatibility — iOS 26 voicemail greetings are shorter than previous versions. If your greeting parameter is set high, newer iOS voicemails look like short human responses.

  2. Enable beep detection — ensure your Asterisk AMD configuration is actively using beep detection as a MACHINE indicator

Problem 3: AMD Is Returning NOTSURE on Too Many Calls

Symptom: Your AMD logs show a high percentage of NOTSURE outcomes. Depending on how NOTSURE is handled, this means either calls are defaulting incorrectly or agents are getting an unpredictable mix.

What is happening: AMD is timing out before it can make a classification. The audio analysis window is expiring before a clear HUMAN or MACHINE signal is detected.

Diagnosis: Check your AMD logs for NOTSURE frequency. More than 5% NOTSURE is worth investigating.

Fixes:

  1. Increase total_analysis_time
total_analysis_time=5500

  1. Check how NOTSURE is handled in your VICIdial campaign settings — it should default to HUMAN, not MACHINE, to avoid dropping live calls

  2. Check call audio quality — NOTSURE often indicates low-quality audio where the analysis cannot detect clear speech patterns. Check for carrier issues causing low volume or distortion.

Problem 4: AMD Works Fine in Testing But Fails in Production

Symptom: AMD performed well during your test campaign but accuracy dropped significantly when you went live at full volume.

What is happening: Your test conditions did not represent production conditions. Common causes:

  • Different carrier routing — your test calls routed through one carrier; production calls use another with different audio processing
  • Different time of day — early morning test calls may have different characteristics than peak-hour production traffic
  • Different list demographics — test list was clean and recent; production list has more mobile numbers, aged leads, or international contacts
  • Volume effects — at high call rates, SIP trunks may experience congestion that degrades audio quality

Fixes:

  1. Audit carrier-by-carrier accuracy — segment your AMD results by which SIP carrier handled the call. Different carriers may need different tuning.

  2. Test at production volume and time — run a small production batch during peak hours before full rollout

  3. Check trunk quality under load — use a SIP monitoring tool to verify packet loss and jitter are within acceptable ranges at peak call rates

Problem 5: AMD Accuracy Suddenly Got Worse

Symptom: AMD accuracy was acceptable for months, then dropped noticeably. Nothing obvious changed in your configuration.

What is happening: The call environment changed, not your configuration. Common triggers:

  • Carrier routing change — your SIP provider silently changed their routing, affecting audio quality
  • iOS / Android update — a major mobile OS update changed voicemail greeting characteristics (iOS 26 is the most impactful recent example)
  • List composition change — new list source with different demographic or geographic mix
  • Seasonal traffic patterns — calling patterns change seasonally; parameters tuned for summer traffic may not hold in Q4

Diagnosis:

  1. Check the date when accuracy dropped against any carrier maintenance windows or iOS release dates
  2. Compare current list demographics to the period when accuracy was good
  3. Run a fresh manual audit of 200 MACHINE-classified recordings

Fix: Re-run the tuning process from baseline. If iOS voicemail characteristics changed (iOS 26), you specifically need to adjust greeting parameter to match the new greeting length profile.

Problem 6: AMD Is Working But Slowing Down Agent Connect Time

Symptom: Agents notice a delay between answering and hearing the customer. Abandonment rate is higher than expected. Call quality feels sluggish.

What is happening: AMD analysis latency is adding delay to HUMAN-classified calls. Every millisecond AMD spends analyzing is a millisecond before the agent is connected.

With default Asterisk AMD, analysis can take 3–5 seconds. On a predictive dialer, this latency directly affects abandonment rate — the customer may hang up while AMD is still analyzing.

Diagnosis: Check your AMD processing time in logs. Compare abandonment rate to regulatory threshold (3%). Time from call connect to agent delivery.

Fixes:

  1. Lower total_analysis_time — AMD will make a faster (if sometimes less confident) decision
total_analysis_time=4000

  1. Reduce initial_silence — AMD stops waiting for silence sooner

  2. Switch to AI-powered AMD with low latency — amdify.io returns classifications in 200–400ms, compared to 3–5 seconds for Asterisk AMD, directly reducing agent connect delay and abandonment rate

Problem 7: AMD Is Disabled or Not Running

Symptom: All calls are going directly to agents, including obvious voicemails. Agent talk time per call is low. Agents report constant voicemail greetings.

What is happening: AMD is not active on your campaign. This can happen because:

  • AMD was disabled in VICIdial campaign settings and never re-enabled
  • A VICIdial update reset AMD settings to defaults
  • The app_amd.so Asterisk module failed to load
  • A dialplan change bypassed the AMD application call

Diagnosis:

  1. In VICIdial admin, check Campaign settings → AMD configuration. Confirm AMD is enabled.

  2. On your Asterisk server, verify the AMD module is loaded:

asterisk -rx "module show like amd"

You should see app_amd.so in the output. If not:

asterisk -rx "module load app_amd.so"
  1. Check your dialplan to confirm the AMD() application is being called before agent delivery.

Fix: Re-enable AMD in VICIdial campaign settings or reload the Asterisk module. If the module repeatedly fails to load, check for Asterisk version compatibility issues.

Diagnostic Checklist

If your AMD is not behaving as expected, work through this checklist:

  • Check VICIdial campaign settings — is AMD enabled?
  • Verify app_amd.so is loaded in Asterisk
  • Pull 200 MACHINE-classified recordings and listen for human voices
  • Check AMD logs for NOTSURE frequency
  • Segment accuracy by carrier — is one carrier performing worse?
  • Compare current list demographics to baseline period
  • Check carrier audio quality metrics (packet loss, jitter)
  • Confirm amd.conf parameters match your intended configuration
  • Verify how NOTSURE is handled (should default to HUMAN)

When Fixing AMD Settings Is Not Enough

If you have worked through the above and your false positive rate is still above 8–10%, you have hit the ceiling of what rules-based AMD can achieve. The problems are structural — the same acoustic signals overlap between humans and machines in ways that parameter tuning cannot fully resolve.

At that point, the fix is not more tuning — it is replacing the detection engine. amdify.io is an AI-powered AMD solution built specifically for VICIdial and Asterisk. It integrates as a drop-in replacement for the AMD decision, reduces false positives to 1–3%, and requires no ongoing parameter maintenance.

See the VICIdial integration guide for step-by-step setup instructions, and the best AMD dialer settings guide for the full parameter tuning reference before you decide which approach fits your operation.