Best AMD Solutions for ViciDial and Asterisk Dialers (2026)

Why Predictive Dialers Need AMD

A predictive dialer only works because it over-dials. It places calls ahead of agent availability so that when a prospect answers, an agent is free. The math requires more answered calls than free agents, which means some answered calls have nobody to take them, and every answered call needs an instant verdict: human or machine. Humans get routed to agents before the prospect hangs up. Machines get hung up on or handed a voicemail drop while the agent moves to the next dial.

The verdict matters because of what actually answers. Across roughly 2.3 billion answered outbound calls on the AMDY network in a 30-day window, only 12.5% were a live human. About 73% were machines, and about 14% were carrier false answers where the network signaled a connect and nobody picked up. Without a fast, accurate gate, agents spend most of their connected time talking to recordings and dead air.

Compliance pressure tightens the window further. FCC rules for predictive dialers cap abandoned calls at 3% of calls answered by a person over 30 days, and a live agent must reach the person within 2 seconds of the greeting ending or the call counts as abandoned. A wrong verdict on a human becomes dead air or a dropped call, which is exactly what the cap measures. A slow verdict blows the 2-second window even when the classification is eventually right. So the dialer needs a detector that is both accurate and fast, and the options for getting one on ViciDial or Asterisk fall into three families: the stock heuristic, CPaaS API add-ons, and acoustic AI classifiers.

Stock ViciDial AMD: How app_amd and amd.conf Actually Work

ViciDial runs on Asterisk, and Asterisk ships with app_amd, a dialplan application configured through amd.conf. ViciDial exposes it per campaign through the Detect Answering Machine setting. When a call is answered, app_amd listens to the first seconds of audio and applies timing rules: a long uninterrupted burst of audio looks like a voicemail greeting, a short utterance followed by silence looks like a person. It then sets the channel variable AMDSTATUS to HUMAN, MACHINE, or NOTSURE, and your dialplan routes on that flag. How default AMD works, in plain English →

The stock amd.conf defaults on a standard ViciDial install:

• initial_silence: 2500 ms. How long to wait for audio after answer before deciding.
• greeting: 1500 ms. Bursts longer than this score as a machine greeting.
• after_greeting_silence: 800 ms. How much silence after a greeting before the verdict closes.
• total_analysis_time: 5000 ms. The hard cap on the whole analysis window.
• min_word_length: 100 ms. Shorter sounds are ignored as noise.
• between_words_silence: 50 ms. Gaps shorter than this merge words together.
• maximum_number_of_words: 3. More than three words in the window pushes the verdict toward MACHINE.
• silence_threshold: 256. The loudness floor for audio to count as speech.

It costs nothing extra, it is already on the box, and for clean lists with slow, predictable greetings it does the job. The problems start where the timing model meets real 2026 audio.

The Tuning Levers: amd.conf Variables and ViciDial Campaign Settings

Every shop that runs stock AMD long enough ends up tuning it. The Asterisk-level thresholds above are edited in /etc/asterisk/amd.conf, and ViciDial adds a second layer of campaign settings on top: every ViciDial AMD variable, explained →

• drop_call_seconds. How long the dialer waits for AMD to finish before dropping the call. A practical starting point is 4 to 5 seconds, slightly above total_analysis_time.
• amd_send_message. What happens on a MACHINE verdict: HANGUP ends the call, CONTINUE hands it to a voicemail-drop flow.
• AMD_wait_extra_sec. Extra wait time appended to the analysis window.

The workflow on a live server: edit the thresholds in amd.conf, pick up the changes with asterisk -rx "module reload res_agi.so", and adjust the campaign-level settings in the ViciDial admin under Campaigns. Then watch what moves.

The trap is that the levers pull against each other. Loosen the greeting thresholds so more fast human greetings pass as HUMAN, and more voicemail greetings leak through to agents. Tighten them, and more live people get dropped. Lengthen the analysis window to cut NOTSURE results, and agents sit idle longer on every machine. There is a narrow middle where the tradeoff is least bad, and finding it takes measurement, not guesswork: the narrow middle almost everyone misses →

The Honest Limits of Stock AMD

Tuning buys a few points. It does not change the ceiling. Stock timing-based AMD lands around 70% to 85% accuracy in production, and that ceiling is structural, not a configuration problem. The detector infers what answered from a stopwatch. It cannot hear the difference between a person who says “Hello? Who’s this?” with no pause and the front of a voicemail greeting, because on a timing chart they look the same. Why a simple “hello” breaks default AMD →

The cost of the ceiling lands on your fastest answerers. Stock AMD misclassifies roughly 5% to 15% of live humans as machines, and those are the prospects who picked up quickly, the ones you most wanted on the line. The five drawbacks nobody warns you about →

Then there is the bucket nobody measures. NOTSURE is declared when the analysis window (total_analysis_time, 5000 ms by default) closes without a decisive match. Your dialplan decides what happens to those calls, and many dialplans drop them. If you have never measured your NOTSURE rate, you may be abandoning live people with no log to prove it. AMDSTATUS NOTSURE, the gray zone that drops your best leads →

And there is a whole category stock AMD cannot name at all: carrier false answers, where the network fakes the connect signal. A false answer does not fit HUMAN, MACHINE, or NOTSURE cleanly, so it usually reaches an agent as a “connect” that turns out to be dead air. About 14% of answered calls on the AMDY network fall in this bucket. What carrier false answers cost you, twice →

Stock Asterisk AMD Outside ViciDial

If you run plain Asterisk or a FreePBX-style PBX without ViciDial, the story is the same engine. app_amd and amd.conf are Asterisk components, not ViciDial ones, so a vanilla Asterisk shop gets the identical timing heuristic, the identical defaults, and the identical tuning treadmill. You configure the application directly in the dialplan (the AMD() application call) rather than through a campaign screen, and you own the NOTSURE routing decision yourself, which makes the gray zone more visible but no smaller. FreeSWITCH shops face the equivalent problem with mod_avmd, their own timing-based detector. The deeper technical comparison across all three engines: FreeSWITCH AMD vs Asterisk AMD vs AI AMD →

CPaaS AMD APIs for Asterisk Shops: Twilio, Telnyx, and Plivo

The second family is machine detection sold as an add-on to voice API platforms. All three of the big ones are real, engineered products. They differ in method, speed, and what they will admit about accuracy.

Twilio Enhanced Answering Machine Detection

Twilio’s machine_detection add-on runs about $0.0075 per answered call (its published Enhanced AMD rate as of 2026). It returns a single AnsweredBy flag with outcomes including machine_start, fax, and unknown. The constraint is the network: it only runs on calls placed through Twilio Voice, configured through the Calls/Participants API or the Dial verb.

Telnyx Premium AMD

Telnyx Premium AMD bills about $0.0065 per invocation, per Telnyx’s December 2022 release notes and pricing pages. It uses speech recognition plus machine learning, and it only fires when calls run on the Telnyx network. Silent pickups can time out to a not_sure outcome, and Telnyx does not document false-answer or honeypot detection.

Plivo Machine Detection

Plivo bills machine detection around $0.004 per request as of 2026, the cheapest of the three. Per Plivo’s own docs it is a heuristic on speech (tone, speaking speed), it takes 3 to 5 seconds with a default 5,000 ms detection window, and it is published at 60% to 75% accuracy. It only runs on calls placed through Plivo, enabled by adding parameters to the Plivo Call API.

The honest pros: if your traffic already rides one of these networks, the add-on is the path of least resistance, and you pay per use with no infrastructure to run. The honest cons are accuracy and latency in Plivo’s case, per-call fees that scale linearly forever in all three, and one catch that matters most for a ViciDial shop.

The Integration Catch: CPaaS AMD Means Re-Platforming Your Calls

None of these detectors can be hooked into an existing Asterisk dialplan. Twilio machine detection only runs on Twilio Voice. Telnyx Premium AMD only fires on the Telnyx network. Plivo machine detection only works on calls placed through Plivo. For a ViciDial or Asterisk operation, using them means re-platforming your trunks or routing calls through their APIs. That is a telephony migration project, not a dialplan change, and it swaps your carrier relationships for theirs.

The per-call billing compounds once volume arrives. At one million answered calls a month, detection fees alone run about $4,000 on Plivo, $6,500 on Telnyx, and $7,500 on Twilio, on top of per-minute voice charges, and the line doubles every time your volume doubles. If you were already planning to move your dialing onto a voice API, the add-ons are worth a look. If you want better detection on the stack you have, they are the wrong tool.

AMDY.IO: Native AMD for ViciDial, Asterisk, FreeSWITCH, and Issabel

The third family is acoustic AI classifiers that attach to your existing stack, and this is the category AMDY belongs to. The facts as AMDY publishes them, to be verified on your own traffic like any vendor claim:

• One-line install, about five minutes. One bash command on your dialer server provisions the API key, drops in the dialplan hook, and starts classifying immediately. A full production rollout typically takes 1 to 2 hours.
• Native platform support. ViciDial, Asterisk, FreeSWITCH, and Issabel are supported natively. Other platforms connect through the API and WebSocket gateway.
• Telco-agnostic. You keep your existing carrier, SIP trunks, and dialer. No number porting, no SIP reconfiguration, no media-server changes.
• Acoustic classification. AMDY classifies the sound of the answer audio rather than timing events inside it. Detection starts in 1/8 of a second, classification completes in under 200 ms, and production accuracy is 99%.
• Six output buckets. Human, voicemail, carrier false-answer (FAS), honeypot and spam-trap, fax, and silence, versus the single AMDSTATUS flag from stock AMD.
• Real analytics. 23 reports plus a queryable per-detection log, so the human-versus-machine numbers are something you can audit instead of assume.

Two of those buckets deserve emphasis because stock AMD cannot see them at all. Carrier false-answer gets its own classification instead of arriving as dead air on an agent’s line, and honeypot detection flags the planted numbers that burn caller-ID reputation. Where honest cons live: AMDY is not a dialer and not a carrier, it adds a monthly line item where stock AMD has none, and you are trusting a third-party verdict on every call. The way to resolve that last one is to measure it, which the free tier exists for.

You also do not have to remove stock AMD to run AMDY. You disable app_amd for the campaign so it stops making the call, and AMDY classifies instead. Nothing is uninstalled, and you can run AMDY on one campaign and stock AMD on another to compare them on your own traffic. The line-by-line comparison: default AMD vs AMDY, head to head →

What 2.3 Billion Answered Calls a Month Shows

The accuracy and speed numbers above were measured across roughly 2.3 billion answered outbound calls in 30 days on the AMDY network. The composition of that traffic is the argument for more than two buckets:

• 12.5% were a live human.
• About 73% were machines: voicemail, IVRs, carrier recordings.
• About 14% were carrier false-answers, connections that never connected.
• 0.09% were honeypot and spam-trap numbers, roughly 2 million dials into traps in a single month.

A detector with three timing buckets can label the first two groups, sort of, and is blind to the last two. The full dataset, including when humans actually answer: The State of AMD 2026 →

Side-by-Side: Stock app_amd vs Twilio vs Telnyx vs Plivo vs AMDY

Accuracy figures for Twilio and Telnyx are not published, so the table says so rather than repeat vendor claims. Plivo publishes its own 60 to 75% range in its docs. AMDY’s 99% is measured on the network traffic described above. Judge every number, AMDY’s included, against your own labeled calls.

Cost Comparison at Real Volumes

Stock AMD has no line item, and that is precisely what makes it expensive in ways you never see. Every dropped live human is a lead you paid to generate and then hung up on. Every false-answer connect is paid agent time spent listening to silence. Every re-tune is engineering hours plus a window where the numbers are wrong. The real cost of free AMD, totaled up →

CPaaS pricing is visible and linear. At one million answered calls a month, detection fees alone are about $4,000 with Plivo, $6,500 with Telnyx, and $7,500 with Twilio, on top of voice minutes, and the bill doubles with the volume.

AMDY sells a monthly base with included detections and a flat overage rate:

• Sandbox: $0. 50,000 detections a month, hard cap, no card. Built for pilots and A/B tests.
• Starter: $79/month. 500,000 detections included, then $0.00025 per detection.
• Growth: $299/month. 5,000,000 included, then $0.00015 per detection.
• Scale: $999/month. 25,000,000 included, then $0.00010 per detection.
• Partner: from $2,000/month. Custom volume tiers for co-managed and white-label programs.

The same million answered calls that costs $4,000 to $7,500 on CPaaS add-ons fits inside the $299 Growth plan with room to spare. Put another way, carrier and CPaaS AMD add-ons run roughly $0.004 to $0.0075 per call, 16 to 75 times more than AMDY’s $0.00010 to $0.00025 per-detection pricing. The honest comparison is not free versus paid. It is hidden cost versus a known fraction of a cent.

Which Option Fits Which Shop

• Low volume, low stakes: keep stock app_amd. If you run a few campaigns where a missed connect costs little and abandon-rate math is not squeezing you, the free heuristic is a reasonable choice. It is free and already installed. Upgrade when dropped live prospects, carrier false-answers, or caller-ID reputation start costing real money.
• All-in on a CPaaS already: use its add-on. If your calls already run on Twilio, Telnyx, or Plivo, their detection is the path of least resistance. Accept the per-call fee and the single-network lock-in as the price of staying put.
• ViciDial or Asterisk with real volume: attach a classifier. If dropped humans cost revenue, FAS eats agent time, or your CIDs are getting flagged, the gap between 70 to 85% and 99% is not a rounding error. Attach an acoustic classifier to the stack you have instead of migrating your trunks.

Whatever you pick, verify it the same way: capture your baseline, manually label a sample of answered calls, split live traffic between the candidate and your current setup, and compare human-connect rate, dropped-call rate, and machines leaking to agents. A step-by-step version: how to test AMD accuracy before going live →

That test costs nothing to start. Put AMDY on one campaign, leave stock AMD on another with comparable lists and dial settings, and let the 50,000 free Sandbox detections a month carry the experiment on live traffic. Then read the numbers yourself.

Frequently Asked Questions

Does ViciDial have built-in AMD?

Yes. ViciDial runs on Asterisk, and Asterisk ships with app_amd, a dialplan application configured through amd.conf. You enable it per campaign with the Detect Answering Machine setting. It costs nothing extra and is already on every standard ViciDial box, but it is a timing heuristic, so accuracy tops out around 70% to 85%.

What does AMDSTATUS NOTSURE mean, and why does it matter?

AMDSTATUS is the channel variable app_amd sets after analysis: HUMAN, MACHINE, or NOTSURE. NOTSURE means the audio matched neither pattern within the total_analysis_time window (5000 ms by default). Your dialplan decides what to do with it, and many dialplans drop those calls. If you never measure your NOTSURE rate, you may be abandoning live people with no log to prove it.

Can I use Twilio, Telnyx, or Plivo AMD with my existing Asterisk dialplan?

Not without moving your calls onto their networks. Twilio machine_detection only runs on calls placed through Twilio Voice, Telnyx Premium AMD only fires on the Telnyx network, and Plivo machine detection only works on calls placed through Plivo. For a ViciDial or Asterisk shop, that means re-platforming your trunks or routing calls through their APIs, not a simple dialplan hook.

How much does CPaaS AMD cost per call?

Per the comparison pages on this site: Twilio Enhanced Answering Machine Detection runs about $0.0075 per answered call, Telnyx Premium AMD about $0.0065 per invocation, and Plivo machine detection about $0.004 per request. All three bill per call or invocation on top of your telephony spend.

How does AMDY.IO install on ViciDial or Asterisk?

One bash command on your dialer server, about five minutes. The install provisions your API key, drops in the dialplan hook, and starts classifying immediately. It runs natively on ViciDial, Asterisk, FreeSWITCH, and Issabel over a WebSocket gateway, keeps your existing carrier and SIP trunks, and requires no number porting or media-server changes.

Do I have to remove stock AMD to run AMDY?

No. You disable app_amd for the campaign so it stops making the call, and AMDY classifies instead. Nothing is uninstalled. You can run AMDY on one campaign and stock AMD on another to compare them on your own traffic, and the free Sandbox tier of 50,000 detections a month is enough to run that test.

Which AMD option fits a low-volume operation?

If you run a few low-stakes campaigns where a missed connect costs little and abandon-rate math is not squeezing you, stock app_amd is a reasonable choice. It is free and already installed. Upgrade when dropped live prospects (stock AMD misclassifies roughly 5% to 15% of live humans), carrier false-answers, or caller-ID reputation start costing real money.

What can AMDY detect that stock Asterisk AMD cannot?

Stock AMD has three buckets: HUMAN, MACHINE, and NOTSURE. AMDY classifies the acoustic signature of the answer audio and separates human, voicemail, carrier false-answer (FAS), honeypot and spam-trap, fax, and silence. Across roughly 2.3 billion answered calls a month on the AMDY network, about 14% are carrier false-answers, a category timing-based AMD cannot label at all.