{"id":3814,"date":"2026-09-12T05:08:22","date_gmt":"2026-09-12T05:08:22","guid":{"rendered":"https:\/\/www.plura.ai\/articles\/voicemail-detection-outbound-calls"},"modified":"2026-09-12T05:08:22","modified_gmt":"2026-09-12T05:08:22","slug":"voicemail-detection-outbound-calls","status":"publish","type":"post","link":"https:\/\/www.plura.ai\/articles\/voicemail-detection-outbound-calls","title":{"rendered":"Voicemail Detection: AMD Accuracy and Carrier Layer"},"content":{"rendered":"<p><em>Written by: Matt Beucler, CEO, Plura AI<\/em><\/p>\n<h2 id=\"key-takeaways\">Key Takeaways<\/h2>\n<ul>\n<li>Voicemail detection (AMD) analyzes the first few seconds of call audio to classify human versus machine answers. The core design choice is synchronous detection, which adds latency, versus asynchronous detection, which bridges immediately.<\/li>\n<li>AMD performance depends on codec, jitter buffer, and audio-path processing at the carrier layer. The carrier path shapes detection quality more than the model alone.<\/li>\n<li>False positives, where humans are classified as voicemail, cost more than false negatives. Modern AMD achieves 90-95% accuracy, while durational approaches plateau at 80-85% because of information ceilings.<sup data-disclaimer-id=\"24\" data-disclaimer-index=\"3\">3<\/sup><\/li>\n<li>Platform behavior varies significantly. Twilio, Retell, LiveKit, and Pipecat expose different AMD result vocabularies and timing parameters, which directly shape call-flow design.<sup data-disclaimer-id=\"25\" data-disclaimer-index=\"4\">4<\/sup><\/li>\n<li>Plura AI solves AMD at the carrier layer as an FCC-licensed audio-bridging carrier. <a href=\"https:\/\/www.plura.ai\/plura-webchat\" target=\"_blank\"><strong>See carrier-layer detection in production<\/strong><\/a> with a live Plura demo.<\/li>\n<\/ul>\n<h2>How Voicemail Detection Handles The First Few Seconds<\/h2>\n<p>When an outbound call connects, AMD begins analyzing audio immediately. The classification must resolve before the agent\u2019s audio contaminates the channel. Vendors commonly describe a three-to-five-second decision window from connection, though documented windows range from about one to two seconds up to a 30-second default timeout.<\/p>\n<p>The detection process follows this sequence:<\/p>\n<ol>\n<li>The call connects and audio begins streaming into the detection engine.<\/li>\n<li>The engine analyzes pitch, tone, speech duration, silence patterns, and energy envelope characteristics to distinguish a live greeting from a recorded one.<\/li>\n<li>The engine classifies the answer as human, machine, fax, or unknown, with additional sub-classifications depending on the platform.<\/li>\n<li>Routing logic fires based on the classification. The system connects to a live agent or <a href=\"https:\/\/plura.ai\/ai-voice-demo\" target=\"_blank\" rel=\"noindex nofollow\">AI voice agent<\/a>, leaves a voicemail drop, or hangs up.<\/li>\n<\/ol>\n<p>Timing and behavior provide the most reliable AMD signals, not the sound of the voice itself. A recorded greeting and a live \u201cHello?\u201d from the same person look similar spectrally. The difference appears in what follows. A live person pauses and waits. A voicemail greeting runs as a continuous monologue and ends with a beep.<\/p>\n<p>Voice activity detection (VAD) only flags whether an audio frame is speech or non-speech. AMD combines VAD output with greeting phrases, timing, and call state to classify the answer as live person, greeting, beep, carrier intercept, or silence. Modern AI-based AMD systems also transcribe the first few seconds of audio and classify the text, since voicemail greetings often self-identify with phrases like \u201cleave a message after the tone.\u201d<\/p>\n<p>Operationally, AMD behaves as a carrier-layer problem. Detection quality depends on where the call originates, which codec the carrier uses, how the audio is processed before it reaches the detection engine, and whether the carrier strips SIP headers that could disambiguate a redirected call. Carrier voicemail systems return the same SIP response sequence as a human answer, and trunking providers often strip headers that could reveal a redirect, so AMD must operate in the media path rather than the signaling layer.<\/p>\n<p><a href=\"https:\/\/www.plura.ai\/plura-webchat\" target=\"_blank\"><strong>See carrier-layer detection in production<\/strong><\/a> with a live Plura demo.<\/p>\n<h2>Synchronous Vs. Asynchronous AMD: The Architectural Tradeoff<\/h2>\n<p>The synchronous versus asynchronous AMD decision is the highest-impact architectural choice in outbound call design. Most vendor configuration guides treat it as a parameter, not a primary design framework.<\/p>\n<p><strong>Synchronous AMD<\/strong> holds the call flow until detection completes before fetching routing instructions. <a href=\"https:\/\/apivoice.co\/blog\/answering-machine-detection-amd\" target=\"_blank\" rel=\"noindex nofollow\">This adds roughly two to five seconds of silence at the start of the call.<\/a> The person who answered hears dead air while the engine decides. If the verdict is \u201chuman,\u201d the agent connects into a call where the prospect has already been waiting in silence and may have hung up.<\/p>\n<p><strong>Asynchronous AMD<\/strong> connects the call immediately and runs detection in parallel. <a href=\"https:\/\/apivoice.co\/blog\/answering-machine-detection-amd\" target=\"_blank\" rel=\"noindex nofollow\">The detection result is posted to a dedicated callback endpoint a few seconds after connection, which lets the application branch its logic after the initial answer.<\/a> The tradeoff is timing risk. If the verdict arrives late, a human may already have heard the agent begin speaking to what the system assumed was a voicemail. A voicemail may also record the first half of a live-agent pitch.<\/p>\n<p>The table below summarizes how the two approaches differ across bridging behavior, latency, accuracy, and best-fit use case.<\/p>\n<table>\n<thead>\n<tr>\n<th>Attribute<\/th>\n<th>Synchronous AMD<\/th>\n<th>Asynchronous AMD<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Call bridging<\/td>\n<td>Held until verdict<\/td>\n<td>Immediate<\/td>\n<\/tr>\n<tr>\n<td>Added latency<\/td>\n<td><a href=\"https:\/\/apivoice.co\/blog\/answering-machine-detection-amd\" target=\"_blank\" rel=\"noindex nofollow\">2-5 seconds of dead air<\/a><\/td>\n<td>Near zero at connection<\/td>\n<\/tr>\n<tr>\n<td>Accuracy tradeoff<\/td>\n<td>Higher, more audio context available<\/td>\n<td>Lower on ambiguous greetings, late verdicts cause misroutes<\/td>\n<\/tr>\n<tr>\n<td>Best-fit use case<\/td>\n<td>Voicemail drop campaigns where dead air is acceptable<\/td>\n<td>AI outbound agents where live-caller experience matters<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>For AI outbound agents, asynchronous AMD works best in most cases. The agent can begin with a short hold phrase while detection runs, which reduces perceived dead air. <a href=\"https:\/\/apivoice.co\/blog\/answering-machine-detection-amd\" target=\"_blank\" rel=\"noindex nofollow\">A documented best practice is to use a brief initial greeting such as \u201cPlease hold&#8230;\u201d while async AMD runs.<\/a> If the verdict arrives as \u201cmachine\u201d after the agent has already begun speaking, the session must tear down the agent connection mid-call and switch to voicemail message delivery. The call flow needs explicit handling for that branch.<\/p>\n<p>Under 47 CFR 64.1200(a)(7), a telemarketing call is treated as abandoned if it is not connected to a live sales representative within two seconds of the called person\u2019s completed greeting.<sup data-disclaimer-id=\"23\" data-disclaimer-index=\"2\">2<\/sup><\/p>\n<h2>Why AMD Produces False Positives And False Negatives<\/h2>\n<p>A false positive in AMD is a live human classified as voicemail. A false negative is a voicemail classified as human. <a href=\"https:\/\/dialerseat.com\/faq\/how-does-amd-work\" target=\"_blank\" rel=\"noindex nofollow\">Modern AMD on a clean carrier path is approximately 90-95% accurate, with the remaining 5-10% of errors split between false positives and false negatives.<\/a><\/p>\n<p>False positives create the larger business impact. A live prospect is dropped, hears silence or a voicemail message, and the contact opportunity disappears. <a href=\"https:\/\/vmhunter.com\/blog\/vicidial-vs-five9-amd-false-positives\" target=\"_blank\" rel=\"noindex nofollow\">A false positive burns a contact, harms brand perception, and can contribute to regulatory findings in collections, healthcare, or financial services.<\/a> False negatives waste agent time but remain recoverable. The agent hears a voicemail greeting and dispositions the call.<\/p>\n<p>The documented failure modes cluster into three categories.<\/p>\n<p><strong>Short human greetings.<\/strong> A quick \u201cHello?\u201d under 1.5 seconds followed by a clear pause looks, durationally, like the front of a voicemail greeting on a stopwatch. <a href=\"https:\/\/vmhunter.com\/blog\/vicidial-vs-five9-amd-false-positives\" target=\"_blank\" rel=\"noindex nofollow\">Two audio clips of 1.8 seconds of speech followed by 700 ms of silence are near-identical durationally: \u201cGood morning, Dana speaking\u201d versus \u201cYou\u2019ve reached Dana Whitfield.\u201d Any detector measuring only speech and silence intervals must classify them the same way, and one classification will be wrong.<\/a><\/p>\n<p><strong>Long or unusual voicemail greetings.<\/strong> Short custom voicemail greetings under three seconds often score as a person, which causes false negatives where the agent waits for a reply and delivers half its script after the beep. Long business greetings and slow or non-native speakers cross silence-pattern speech thresholds and read as machines.<\/p>\n<p><strong>Carrier and device variance.<\/strong> <a href=\"https:\/\/vmhunter.com\/blog\/vicidial-vs-five9-amd-false-positives\" target=\"_blank\" rel=\"noindex nofollow\">Roughly 70% of outbound contact volume now terminates on mobile networks, where variable jitter, codec transitions, and comfort-noise generation systematically corrupt the silence measurements that durational AMD models use.<\/a> Carrier screening products and automated screening announcements match neither human nor voicemail templates, so threshold-based detectors produce unstable output.<\/p>\n<p>Apple\u2019s iOS 26 Call Screening adds a new failure mode. Apple\u2019s iOS 26 call screening intercepts unfamiliar numbers before they ring through, and Plura\u2019s AI agent communicates with that layer so calls present with the company\u2019s name and the reason for the call. Detection reads it as human because it behaves like one acoustically and lexically, which inflates answer rate while connect rate stays flat.<\/p>\n<p>As noted earlier, modern AMD reaches 90-95% accuracy on a clean carrier path, but durational approaches hit an information ceiling at <a href=\"https:\/\/vmhunter.com\/blog\/vicidial-vs-five9-amd-false-positives\" target=\"_blank\" rel=\"noindex nofollow\">80-85% accuracy.<\/a> No adjustment to configuration thresholds can fix this ceiling because the distinguishing evidence is not present in the measurements. Detection quality depends on the carrier path, since the audio reaching the engine has already passed through codec, jitter buffer, and silence suppression before the model sees a single frame.<\/p>\n<h2>Twilio, Retell, LiveKit, And Pipecat: AMD Implementation Differences<\/h2>\n<p>Each major voice platform exposes AMD results differently, which directly affects call-flow design. The descriptions below summarize each platform\u2019s documented behavior.<\/p>\n<p><strong>Twilio.<\/strong> Twilio\u2019s AMD exposes an <code>answeredBy<\/code> parameter whose possible values include <code>human<\/code>, <code>machine_start<\/code>, <code>fax<\/code>, and <code>unknown<\/code> in its faster detection mode, and additionally returns <code>machine_end_beep<\/code>, <code>machine_end_silence<\/code>, and <code>machine_end_other<\/code> when configured to wait for the voicemail greeting to finish. The <code>unknown<\/code> result represents a detection timeout rather than a third semantic category. Twilio\u2019s default AMD thresholds are 2,400 ms of speech before a machine verdict, a 1,200 ms speech-end threshold, a 5,000 ms silence timeout, and a 30-second overall detection timeout configurable between 3 and 59 seconds. Twilio\u2019s documentation notes that AMD will not always return the right answer because humans and voicemail greetings do not follow uniform patterns.<\/p>\n<p><strong>Retell.<\/strong> Retell is a developer-facing voice AI platform that exposes voicemail detection as part of its outbound call configuration. Retell\u2019s detection integrates with its agent loop, so the agent can handle voicemail routing without a separate webhook architecture. Teams using Retell should consult Retell\u2019s current API documentation for the specific result vocabulary and timing parameters, since these can change.<\/p>\n<p><strong>LiveKit.<\/strong> LiveKit\u2019s AMD implementation returns <code>human<\/code>, <code>machine-ivr<\/code>, <code>machine-vm<\/code>, <code>machine-unavailable<\/code>, or <code>uncertain<\/code>, which differs from Twilio\u2019s vocabulary. LiveKit reported 95.7% F1 on human detection, 98.2% on IVR, and 97.3% on voicemail using transcript-plus-LLM judgment, with a median time to decision of 840 milliseconds.<sup data-disclaimer-id=\"24\" data-disclaimer-index=\"3\">3<\/sup> LiveKit\u2019s documentation states that behavior on models it has not evaluated is not guaranteed, which creates a dependency that threshold-based detectors do not carry.<\/p>\n<p><strong>Pipecat.<\/strong> Pipecat, an open-source implementation, gates TTS output until an LLM labels the transcript CONVERSATION or VOICEMAIL, with a default voicemail response delay of 2.0 seconds. This transcript-first approach means Pipecat\u2019s detection latency depends on the time required to generate and classify a transcript, not on a fixed timing threshold. Teams building on Pipecat control the detection logic directly and can tune the LLM prompt and delay parameters for their specific traffic mix.<\/p>\n<h2>How To Test Voicemail Detection Across Carriers And Greeting Lengths<\/h2>\n<p>Most AMD testing uses production dashboards and agent dispositions as the benchmark. Those sources contain predictions without independent truth, so they do not provide a valid accuracy measure. A human classified as machine never reaches an agent and often has no corrective label, which makes the data selectively observed.<\/p>\n<p>A defensible AMD test harness includes several connected components that work together.<\/p>\n<ol>\n<li><strong>Stratified sampling.<\/strong> <a href=\"https:\/\/amdy.io\/blog\/answering-machine-detection-accuracy-testing\" target=\"_blank\" rel=\"noindex nofollow\">A simple random sample becomes weak when important conditions such as weekend traffic, Spanish-language greetings, business numbers, or a newly added SIP trunk are rare and disappear inside the average.<\/a> Sample across campaigns, carriers, hours, regions, languages, and call outcomes so each segment appears in the test set.<\/li>\n<li><strong>Blinded human labeling.<\/strong> Trained reviewers label calls without seeing the detector\u2019s classification, confidence, or reason code. Disagreements go to a senior reviewer using a written adjudication policy. Ground-truth labels should include at minimum human, machine, ambiguous, and invalid.<\/li>\n<li><strong>Varied greeting lengths.<\/strong> Cekura recommends varying greeting length deliberately at three seconds, ten seconds, and twenty-five seconds because they behave like three different problems. Each length stresses the detector in a different way.<\/li>\n<li><strong>Per-carrier segmentation.<\/strong> AMD testing should be done per carrier because carrier-specific routing and audio characteristics affect AMD outcomes. Tag calls by carrier and join against call records to correlate AMD outcomes with specific trunks.<\/li>\n<li><strong>Pass\/fail criteria.<\/strong> Define acceptable false positive and false negative rates before testing. At 50,000 dials a month, even a top published accuracy of 98.5% means at least 750 calls land in the wrong branch regardless of provider. Design the uncertain path deliberately. A common default is to treat uncertain as human, since disconnecting on a customer usually costs more than a wasted minute.<\/li>\n<li><strong>Latency measurement.<\/strong> Report median, 90th percentile, and 95th percentile decision time for each ground-truth class. A detector that waits six seconds may classify a long voicemail greeting correctly but still leave a live person hearing dead air.<\/li>\n<li><strong>Live shadow testing.<\/strong> <a href=\"https:\/\/amdy.io\/blog\/answering-machine-detection-accuracy-testing\" target=\"_blank\" rel=\"noindex nofollow\">Offline replay of fixed recordings is not a complete AMD production test because real-time detectors make decisions while audio is arriving, and packet timing, early media, clipping, codec changes, jitter, silence suppression, and answer supervision can alter the input.<\/a> A shadow or controlled live test through the production media path should complement fixed-recording tests.<\/li>\n<\/ol>\n<p>Retest after any carrier change, codec change, new SIP trunk, dialer upgrade, or major geographic shift. Detection accuracy drifts with carrier routing and greeting styles.<\/p>\n<h3>Open-Source AMD: Capabilities And Limitations<\/h3>\n<p>Asterisk\u2019s <code>res_amd<\/code> module ships free with every VICIdial and Asterisk install.<sup data-disclaimer-id=\"25\" data-disclaimer-index=\"4\">4<\/sup> <a href=\"https:\/\/asterisk-doxygen.osso.pub\/master\/api\/d1\/de4\/amd_8conf.html\" target=\"_blank\" rel=\"noindex nofollow\">It exposes configurable thresholds including <code>initial_silence<\/code> at a 2,500 ms default, <code>greeting<\/code> at 1,500 ms, <code>after_greeting_silence<\/code> at 800 ms, <code>total_analysis_time<\/code> at 5,000 ms, and <code>silence_threshold<\/code> at 256, and it makes its classification decision entirely from these timing cutoffs.<\/a><\/p>\n<p><a href=\"https:\/\/vmhunter.com\/blog\/vicidial-vs-five9-amd-false-positives\" target=\"_blank\" rel=\"noindex nofollow\">VICIdial\u2019s AMD has no access to what was said on the call, so it cannot distinguish \u201cHello?\u201d from \u201cYou\u2019ve reached Dana.\u201d The lexical evidence that separates human from voicemail is absent from its measurements.<\/a> Documented false positive rates for open-source AMD on modern campaigns traversing VoIP networks and cell phones commonly fall in the 15-25% range, with 15-20% frequently cited.<\/p>\n<p>This ceiling reflects missing information rather than poor tuning. No adjustment to <code>amd.conf<\/code> can fix it because the distinguishing evidence is not present in the timing data. Open-source AMD can work for low-volume operations with homogeneous traffic. High-volume outbound at carrier scale typically requires a different approach.<\/p>\n<h2>Voicemail Drop Vs. Live-Agent Routing<\/h2>\n<p>AMD supports two distinct downstream use cases, and each one carries different accuracy requirements.<\/p>\n<p><strong>Voicemail drop campaigns<\/strong> depend on accurate machine detection but can tolerate some false negatives. If the agent occasionally hears a voicemail greeting and dispositions the call manually, the operational cost stays low. The critical failure mode is false positives. A live prospect receives a pre-recorded voicemail message, which wastes a contact opportunity and, depending on call type and consent status, can raise regulatory questions. Teams running voicemail drop campaigns should consult qualified counsel on applicable requirements under the TCPA (47 U.S.C. 227) and FCC implementing regulations.<sup data-disclaimer-id=\"23\" data-disclaimer-index=\"2\">2<\/sup><\/p>\n<p><strong>Live-agent and AI voice agent routing<\/strong> depends on accurate human detection with minimal latency. A false positive drops a live prospect. A false negative connects an agent or <a href=\"https:\/\/plura.ai\/ai-voice-demo\" target=\"_blank\" rel=\"noindex nofollow\">AI voice agent<\/a> to a voicemail greeting, which wastes talk time and produces junk transcripts. For <a href=\"https:\/\/plura.ai\/ai-predictive-dialer\" target=\"_blank\" rel=\"noindex nofollow\">AI predictive dialer<\/a> deployments, the detection decision directly determines agent utilization. Every false positive represents a live conversation that never occurred.<\/p>\n<h2>Why Plura AI Operates At The Carrier Layer<\/h2>\n<p>Most AI voice platforms are API resellers built on top of Twilio or another CPaaS. CPaaS stands for Communications Platform as a Service, the API-only telecom layer that providers like Twilio sell to AI vendors that do not own their own carrier. These platforms rent the carrier layer. As a result, they cannot issue branded caller ID under their own identity, cannot enforce compliance before the call leaves the network, and cannot control the audio path that AMD depends on.<\/p>\n<p>Plura AI is its own FCC-licensed audio-bridging carrier. Voice originates on Plura\u2019s domestic infrastructure, not a third-party CPaaS. That distinction matters for AMD in a specific operational way. The audio arriving at the detection engine is shaped by the carrier\u2019s codec, jitter buffer, and silence suppression. When Plura owns the carrier, it controls those variables. When a platform rents from Twilio, it inherits Twilio\u2019s audio path and cannot tune detection at the layer where the problem lives.<\/p>\n<p>Plura\u2019s <a href=\"https:\/\/plura.ai\/ai-predictive-dialer\" target=\"_blank\" rel=\"noindex nofollow\">AI Predictive Dialer<\/a> decides who to call next using stateful conversion signals and runs on that carrier stack. Every outbound call includes STIR\/SHAKEN caller ID authentication, which the destination carrier uses to verify legitimate origination. Plura issues branded caller ID directly through its FCC-licensed carrier, so calls present with the company\u2019s name rather than an unfamiliar number or a \u201cSpam Likely\u201d label.<\/p>\n<p>On the compliance side, Plura supports SOC 2, HIPAA, ISO certification, GDPR, SHAKEN\/STIR caller ID verification, TCPA compliance, and DNC compliance.<sup data-disclaimer-id=\"22\" data-disclaimer-index=\"1\">1<\/sup> These are platform capabilities. Customers remain responsible for their own compliance obligations and regulatory posture.<\/p>\n<p>Plura\u2019s <a href=\"https:\/\/plura.ai\/ai-voice-demo\" target=\"_blank\" rel=\"noindex nofollow\">AI voice agent<\/a> also communicates with Apple\u2019s iOS 26 call-screening layer, so calls that would otherwise be intercepted before they ring through can present a recognizable identity to the recipient. Most platforms cannot do this because they do not own the carrier.<\/p>\n<p><a href=\"https:\/\/www.plura.ai\/plura-webchat\" target=\"_blank\"><strong>Explore Plura\u2019s carrier-layer architecture<\/strong><\/a> in a live demo.<\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>How Do Synchronous And Asynchronous AMD Behave In Production?<\/h3>\n<p>Synchronous AMD holds the call flow until the detection engine returns a verdict before connecting the call or fetching routing instructions. The person who answered hears dead air for the duration of the detection window, typically two to five seconds. The advantage is that the engine has more audio context before making a decision, which can improve accuracy on ambiguous greetings.<\/p>\n<p>Asynchronous AMD connects the call immediately and runs detection in parallel. The verdict is delivered to a callback endpoint a few seconds after connection. The call flow must handle a late verdict. If the engine determines \u201cmachine\u201d after the agent has already begun speaking, the session must interrupt and switch to voicemail delivery. For AI outbound agents where live-caller experience matters, asynchronous AMD is the standard approach because it removes dead air at connection.<\/p>\n<h3>Why Does Voicemail Detection Produce False Positives?<\/h3>\n<p>False positives occur when a live human is classified as a voicemail. Threshold-based detectors measure speech duration, silence intervals, and word count. A short human greeting like \u201cHello? Hello?\u201d produces a timing signature that overlaps with the front of a voicemail greeting. The detector cannot distinguish them because it sees duration and pauses, not the words themselves.<\/p>\n<p>Carrier and device variance amplifies this issue. Mobile networks introduce variable jitter, codec transitions, and comfort-noise generation that distort the silence measurements the detector relies on. A detector tuned on one carrier\u2019s audio path can fail silently on another. AI call screeners add another failure mode. They produce a synthetic prompt that some detectors score as a live human, which inflates apparent answer rates while actual connect rates stay flat.<\/p>\n<p>Durable improvement comes from detection that runs at the carrier layer with access to the full audio path, combined with model-based classification that reads the words as well as the timing.<\/p>\n<h3>How Does Carrier Ownership Affect Voicemail Detection?<\/h3>\n<p>The right outbound calling platform depends on call volume, compliance requirements, and whether the operation needs live-agent routing, AI voice agents, or both. For high-volume outbound, key evaluation criteria include whether the platform owns its carrier stack or rents from a third-party CPaaS, how AMD is implemented and at what layer, whether branded caller ID is issued at the carrier level, and how compliance enforcement is handled before each dial.<\/p>\n<p>Plura AI operates its own FCC-licensed audio-bridging carrier, issues branded caller ID directly, runs STIR\/SHAKEN authentication on every outbound call, and enforces real-time DNC scrubbing and TCPA-litigator screening inside the platform before dial. Its AI Predictive Dialer uses stateful conversion signals to decide who to call next and runs on that carrier stack. Compare <a href=\"https:\/\/plura.ai\/pricing\" target=\"_blank\">Plura\u2019s plans and rates<\/a> side by side.<\/p>\n<h3>What Is A Voicemail Detection API?<\/h3>\n<p>A voicemail detection API is a programmatic interface that accepts call audio and returns a classification of the answered party as human, machine, fax, or unknown. Major CPaaS providers expose AMD as part of their voice API. Twilio returns values including <code>human<\/code>, <code>machine_start<\/code>, <code>machine_end_beep<\/code>, <code>machine_end_silence<\/code>, <code>machine_end_other<\/code>, <code>fax<\/code>, and <code>unknown<\/code>. LiveKit returns <code>human<\/code>, <code>machine-ivr<\/code>, <code>machine-vm<\/code>, <code>machine-unavailable<\/code>, or <code>uncertain<\/code>. Pipecat uses an LLM to classify a transcript as CONVERSATION or VOICEMAIL.<\/p>\n<p>Third-party AMD APIs operate on audio that has already been shaped by the carrier\u2019s codec and audio path. A platform that owns its carrier can influence audio quality before it reaches the detection engine. A platform that rents from a CPaaS cannot.<\/p>\n<h3>Can Open-Source Answering Machine Detection Match Commercial AMD?<\/h3>\n<p>Open-source AMD, primarily Asterisk\u2019s <code>res_amd<\/code> module used in VICIdial deployments, operates on configurable timing thresholds such as initial silence, greeting length, after-greeting silence, word count, and total analysis time. It has no access to the words spoken on the call. As noted in the open-source section, documented false positive rates commonly fall in the 15-25% range.<\/p>\n<p>This ceiling reflects missing information. Threshold tuning cannot bridge the gap because the distinguishing evidence between a short human greeting and the front of a voicemail greeting is not present in the timing measurements. Commercial AMD systems that combine timing signals with transcript-based classification and model-based fusion can reach substantially lower false positive rates. Open-source AMD can work for low-volume, homogeneous traffic where a 15-20% false positive rate is acceptable, but it does not meet most high-volume outbound requirements.<\/p>\n<h2>Conclusion: The Carrier-Layer Argument<\/h2>\n<p>Voicemail detection for outbound calls is a carrier-layer problem, not a model problem. The audio arriving at the detection engine has already passed through codec, jitter buffer, and silence suppression. A platform that rents its carrier from a third-party CPaaS cannot control those variables. A platform that owns its carrier can.<\/p>\n<p>The synchronous versus asynchronous AMD choice remains the highest-impact architectural decision in outbound call design. Synchronous AMD trades dead air for additional context. Asynchronous AMD trades speed for the risk of misroutes on late verdicts. For AI outbound agents, asynchronous usually serves as the default, with explicit handling for late machine verdicts built into the call flow.<\/p>\n<p>Plura AI owns its FCC-licensed carrier stack, issues branded caller ID at the carrier level, runs STIR\/SHAKEN authentication on every outbound call, and enforces real-time DNC scrubbing and compliance controls inside the platform before dial. Its <a href=\"https:\/\/plura.ai\/ai-predictive-dialer\" target=\"_blank\" rel=\"noindex nofollow\">AI Predictive Dialer<\/a> and <a href=\"https:\/\/plura.ai\/ai-voice-demo\" target=\"_blank\" rel=\"noindex nofollow\">AI voice agent<\/a> run on that infrastructure.<\/p>\n<p>Run your numbers through Plura\u2019s <a href=\"https:\/\/plura.ai\/calculator\" target=\"_blank\">ROI calculator<\/a> to check impact in real time. Compare <a href=\"https:\/\/plura.ai\/pricing\" target=\"_blank\">Plura\u2019s plans and rates<\/a> side by side.<\/p>\n<p><a href=\"https:\/\/www.plura.ai\/plura-webchat\" target=\"_blank\"><strong>Test carrier-layer AMD on your traffic<\/strong><\/a> in a live Plura demo.<\/p>\n<hr data-disclaimer-divider=\"true\">\n<div data-disclaimer-footer=\"true\">\n<p data-disclaimer-id=\"22\" data-disclaimer-type=\"content_based\"><sup data-disclaimer-index=\"1\">1<\/sup> Plura AI maintains SOC 2, HIPAA, ISO, and GDPR posture as part of its platform infrastructure. References to compliance frameworks in this article describe Plura\u2019s platform capabilities and do not constitute a guarantee that any customer using Plura will themselves be compliant with applicable laws or standards. Customers remain solely responsible for their own regulatory obligations, certifications, consent management, recordkeeping, and the claims they make to their own end users. Consult qualified legal counsel for guidance specific to your use case.<\/p>\n<p data-disclaimer-id=\"23\" data-disclaimer-type=\"content_based\"><sup data-disclaimer-index=\"2\">2<\/sup> This article describes regulatory frameworks at a general level and does not constitute legal advice. Laws and regulations vary by jurisdiction, change over time, and apply differently depending on facts and circumstances. Readers should consult qualified legal counsel before making compliance decisions.<\/p>\n<p data-disclaimer-id=\"24\" data-disclaimer-type=\"content_based\"><sup data-disclaimer-index=\"3\">3<\/sup> Performance figures, customer outcomes, and industry statistics referenced in this article are drawn from cited third-party sources or Plura customer case studies. Individual results vary based on implementation, use case, industry, audience, and execution. Past or aggregate performance is not a guarantee of future results.<\/p>\n<p data-disclaimer-id=\"25\" data-disclaimer-type=\"content_based\"><sup data-disclaimer-index=\"4\">4<\/sup> References to third-party products, services, companies, or research are made for informational and comparative purposes only. Plura AI is not affiliated with, endorsed by, or sponsored by any third party named in this article unless explicitly stated. Trademarks and product names referenced remain the property of their respective owners.<\/p>\n<p data-disclaimer-id=\"21\" data-disclaimer-type=\"fixed\">This article is provided for informational purposes only and reflects Plura AI\u2019s understanding at the time of publication. Product capabilities, integrations, and specifications are subject to change. For the most current information, visit plura.ai.<\/p>\n<p data-disclaimer-id=\"27\" data-disclaimer-type=\"fixed\">This article was produced with the assistance of AI tools and reviewed by Plura AI prior to publication.<\/p>\n<\/div>\n<section data-read-next=\"true\">\n<h2>Read Next<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/voicemail-detection-voice-ai\" target=\"_blank\">What Is Voicemail Detection in Voice AI?<\/a><\/li>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/predictive-dialer-voicemail-detection\" target=\"_blank\">Predictive Dialer Voicemail Detection: How AMD Works<\/a><\/li>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/voicemail-detection-best-practices\" target=\"_blank\">Voicemail Detection Best Practices for AI Predictive Dialers<\/a><\/li>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/voicemail-beep-detection\" target=\"_blank\">Voicemail Beep Detection: How It Works and Why It Fails<\/a><\/li>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/how-voicemail-detection-works\" target=\"_blank\">How Voicemail Detection Works: Signals, AI, and AMD<\/a><\/li>\n<\/ul>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>See how AMD works, why false positives happen, and how Plura AI&#8217;s carrier-layer approach improves voicemail detection accuracy at scale.<\/p>\n","protected":false},"author":106,"featured_media":3813,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8],"tags":[],"class_list":["post-3814","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-voice-agents"],"_links":{"self":[{"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/posts\/3814","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/comments?post=3814"}],"version-history":[{"count":0,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/posts\/3814\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/media\/3813"}],"wp:attachment":[{"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/media?parent=3814"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/categories?post=3814"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/tags?post=3814"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}