VICIdial and AMD in 2026 — What They Are, How They Work, What Changed

Back in 2021, someone posted here asking “What is VICIdial? What is AMD?” and got told to just Google it. Fair enough at the time. But it’s 2026 now, VICIdial is on SVN 3939, Asterisk 18 is the standard, iOS changed how voicemail works, and half the AMD advice floating around is outdated. So here’s the actual answer.

What is VICIdial

VICIdial is an open-source predictive dialer and contact center platform built on Asterisk. Matt Florell started it in 2003 because he needed a predictive dialer for a 200-seat call center and couldn’t justify spending millions on commercial software. Twenty years later, it’s running on 14,000+ installations across 100+ countries.

It’s not a PBX. FreePBX handles business phones. VICIdial handles outbound campaigns, inbound ACD queues, lead management, call recording, real-time agent monitoring, and predictive dialing. Different tools for different jobs.

The stack in 2026:

  • ViciBox 12.0.2 (OpenSuSE Leap 15.6)
  • Asterisk 18 (not current — Asterisk 22 is the community standard in 2026, but VICIdial is stuck on 18 because it still relies on chan_sip and app_meetme, both removed in Asterisk 21+. This is one of VICIdial’s biggest technical debts)
  • MariaDB 10.11 (MyISAM only — not InnoDB)
  • PHP 8.2, Apache
  • ViciPhone 3.0 (WebRTC softphone via SIP.js)

What it costs: $0 licensing. Infrastructure runs $25-150/agent/month depending on scale. Compare that to Five9 at $175-325/agent/month or Genesys at $75-155/agent/month. At 200 agents, the annual savings vs Five9 is $260K-$380K. That’s not a typo.

What it does well:

  • Predictive dialing — the adaptive algorithm has been refined across 14,000 deployments. Properly tuned, it consistently outperforms commercial dialers by 10-30% in agent talk time
  • You own everything — database, recordings, configs, lead data. Single mysqldump exports it all
  • Scales horizontally — cluster architecture handles 500+ agents across multiple Asterisk servers with shared MySQL backend
  • Full API — Non-Agent API with 50+ functions, Agent API, custom AGI scripts, direct database access with no rate limits

What it doesn’t do well:

  • The admin interface looks like it was built in 2004. Because it was
  • Learning curve is brutal — you need Linux, Asterisk, MySQL, AND contact center operations knowledge
  • Omnichannel is weak. Voice-first. Email and chat exist but aren’t competitive with purpose-built platforms
  • Zero native AI. No sentiment analysis, speech analytics, or AI-assisted QA out of box
  • Documentation is scattered across forums, wiki pages, and tribal knowledge

Who should use it:
If you’re running 25+ agents, doing primarily outbound, have technical capacity (or use managed hosting), and care about cost at scale — VICIdial is hard to beat. If you’re a 10-seat startup that needs omnichannel and polished UI, use Five9 or Convoso.

What is AMD

AMD (Answering Machine Detection) is Asterisk’s built-in system for figuring out whether a human or voicemail answered the phone. It runs inside app_amd.c as a two-state finite state machine processing 20-millisecond audio frames at 8kHz.

The algorithm is simple. It listens for silence vs. voice, counts word transitions, measures greeting length, and makes a binary decision:

INITIALSILENCE — No speech within 2000ms → MACHINE
MAXWORDS — 4+ word segments detected → MACHINE  
LONGGREETING — Cumulative voice > 2000ms → MACHINE
HUMAN — Short utterance + after-greeting silence → HUMAN
NOTSURE (TOOLONG) — Nothing triggered in 5000ms → ???

The parameters that matter:

Parameter Default What it does
initialSilence 2000ms Max wait for any speech
greeting 2000ms Max cumulative voice = machine
afterGreetingSilence 1000ms Silence after voice = human
totalAnalysisTime 5000ms Hard timeout
maximumNumberOfWords 4 Word count threshold
betweenWordsSilence 50ms Gap between words (most important tuning knob)
silenceThreshold 256 Energy level for silence detection

These defaults were calibrated in the Asterisk 1.4/1.8 era (2008-2010) when voicemail greetings were longer, carriers used simpler audio paths, and most calls went to landlines. In 2026, they’re wrong for probably 70% of your traffic.

The dialplan:

exten => 8369,1,AGI(agi://127.0.0.1:4577/call_log)
exten => 8369,n,Playback(sip-silence)
exten => 8369,n,AMD(2000,2000,1000,5000,120,50,4,256)
exten => 8369,n,AGI(VD_amd.agi,${EXTEN})
exten => 8369,n,AGI(agi-VDAD_ALL_outbound.agi,NORMAL)

That Playback(sip-silence) is critical — it primes the audio channel with 250ms of GSM silence. Without it, ~40% of calls return NOAUDIODATA because the codec hasn’t negotiated yet when AMD starts listening.

Why stock AMD breaks in 2026

Three things happened since those defaults were set:

1. Voicemail greetings got shorter. Cell carriers shortened defaults. Apple’s iOS voicemail prompt is now 8-15 words in a conversational tone. A greeting like “Hey it’s Sarah, leave a message” is 6 words — well under the maximumNumberOfWords=4 threshold, but with the kind of casual pacing that triggers HUMAN classification.

2. Carriers added aggressive jitter buffers and silence suppression. Modern VoIP carriers strip silence from the audio stream (VAD/CNG), which destroys the word boundary detection that betweenWordsSilence depends on. A 50ms gap that existed in the original audio gets compressed to nothing. Two words become one. Word count drops. Machine gets classified as human.

3. iOS call screening. This is the big one. When an iPhone user has call screening enabled, iOS answers with “Please state your name and reason for calling” — a full sentence from a synthetic voice. To AMD’s finite state machine, this looks exactly like a voicemail greeting. The call gets classified as MACHINE and dropped. The iPhone owner never knows you called.

Default accuracy in 2026: 75-82% overall, with 15-25% false positives (live humans classified as machines and hung up on).

After per-carrier tuning: 85-92% accuracy, 4-8% false positives. The single most impactful parameter is betweenWordsSilence — it varies 30-120ms per carrier due to their jitter buffer implementation.

AMD Agent Route Options — the feature nobody configures

Since SVN 3200, VICIdial has amd_agent_route_options as a Settings Container. By default, both HUMAN and NOTSURE calls route to agents. NOTSURE means AMD couldn’t decide within 5 seconds — and your agent gets 5+ seconds of dead air.

Minimum recommended config:

HUMAN,HUMAN
NOTSURE,TOOLONG
NOTSURE,INITIALSILENCE  
NOTSURE,MAXWORDS

This blocks dead channels from reaching agents. Also block NOAUDIODATA — that’s carriers sending empty audio streams, and there’s no human on the other end.

AMDMINLEN — DID protection

When AMD classifies a call as MACHINE, VICIdial hangs up after 2-4 seconds. Carriers see this as a Short Duration call. Too many short calls from one DID = spam flagging = your number gets labeled “Scam Likely.”

Fix (SVN 3873+): add this before the Dial line in your carrier entry:

exten => _8567.,n,Set(__AMDMINLEN=7)

Keeps the call alive 7 seconds minimum even after AMD decides it’s a machine. No agent involvement, no wasted time. Just enough call duration to protect your DID reputation.

AI-based AMD — where things are going

Traditional AMD counts words. AI-based AMD understands audio. The difference:

  • Prosody detection — humans answering have rising intonation (“Hello?”), voicemail has flat inflection
  • Background analysis — voicemail recorded in quiet studio, live answers have ambient noise
  • Beep prediction — ML models learn carrier-specific voicemail patterns before the beep even plays
  • Speaker characteristics — recorded greeting on internal mic vs live speech through earpiece at variable distance

AI AMD gets 92-96% accuracy with 2-4% false positives. But it adds 500-1000ms latency and costs $0.005-0.03/call ($1,500-$9,000/month at 10K calls/day).

Best practice for large centers (100+ agents): Run traditional AMD as primary, AI AMD for borderline/NOTSURE cases. 70-80% of calls get decided in 600-800ms, borderline cases get the AI accuracy boost. Cost: ~$1,000-3,000/month for the AI layer.

Integration with VICIdial works via media forking (Asterisk sends audio copy to external service) or SIP REFER (service analyzes then transfers back).

The compliance layer nobody can ignore

None of this matters if your calls get blocked before they ring. In 2026:

  • STIR/SHAKEN is mandatory. A-level attestation requires buying DIDs directly from your SIP trunk provider
  • 48% of consumers don’t answer unknown numbers (that number was 28% in 2020)
  • The 3% abandoned call rule hasn’t changed, but FCC enforcement has teeth now
  • One-to-one consent (effective Jan 2025) means consent must be from consumer to YOUR company by name

VICIdial handles the dialing rules. But STIR/SHAKEN attestation, DID reputation, and consent management require your carrier, your compliance stack, and your operational discipline.


I’ve been deep in VICIdial deployments for years — AMD tuning, cluster architecture, the whole stack. If you want the full technical breakdown on any of this, I wrote detailed guides on VICIdial AMD configuration, open source call center software comparison, and STIR/SHAKEN implementation for VICIdial.

The original 2021 thread got “just Google it” as an answer. Hopefully this is more useful.

Not only is it written in PHP, it seems to have been written by typical PHP programmers. Things like copying/pasting the same code a dozen times, instead of putting it in a function which can be called in a dozen places as necessary with one line of code each time.

It’s no wonder getting rid of some of that technical debt is in the “too-hard” basket. Would you want to entrust mission-critical business operations to obsolete, unsupported software?

Banks do, they are full of COBOL stuff that’s far worse.

I would say considering most “predictive dialer” operations are the same boilerrooms who are interrupting my dinner with phone calls for a new roof or spamming by cell phone, that they pretty much are getting exactly what they deserve, from a code point of view.

So you think the PHP users will self-select out of the software gene pool, so to speak?

There’s a whole lot less COBOL code around than people think. (I guess that process has gone a little further down the track here.)

Here’s what banks are using instead: An oral history of Bank Python

Well actually PHP coding is a LOT like actual Natural Selection in the real world. People think Nature plans and designs with evolution and natural selection but the reality is that evolution and natural selection is a tremendously haphazard slapdash process that produces completely useless organs like the appendix and tonsils - much like PHP coding! LOL

Actually the funniest is if you ask any AI which is better PHP vs Python, at the end of a long winded example cribbed from who knows where, you will get a blurb along the lines of “Python offers broader career opportunities”

I guess the AI’s are not ignorant that it takes money to keep their servers running and the first thing they learned is where the money is. Nature’s self preservation in action! LOL

WebSockets are becoming more important. But PHP is still locked into the mod_php module executing within the event loop of a web server. That works fine for the basic request/response paradigm, but it isn’t so good for continuous full duplex communication, which is what you get with WebSockets.

Python has ASGI, which fully supports async connections and background tasks. And WebSockets.