Answering Machine Detection (AMD)

Answering Machine Detection (AMD) is a Wavix intelligence feature that analyzes the initial audio of an outbound call to determine if it was answered by a human or a machine. When an answering machine or voicemail greeting is detected, the Wavix platform automatically disconnects the call, saving your agents time and improving scale and efficiency.

How AMD works

Wavix AMD analyzes the initial audio of a call to distinguish between a human response and a pre-recorded voicemail message. By identifying frequency patterns and audio characteristics, the platform can detect a machine even during Early Media playback (before the final answer signal). Wavix AMD also screens for automated network announcements played during Early Media—the period before a call is technically answered. By identifying these pre-answer signals and terminating the call immediately, the Wavix platform ensures that your resources are only dedicated to successful human connections.

Detection window and call signalling

Analysis starts as soon as Wavix has audio to evaluate — either from Early Media played by the called party’s carrier before the call is formally answered, or from the live audio right after the called party picks up. A verdict is normally reached within about four seconds of whichever starting point applies. Until the verdict is in, the call is not yet bridged:

Your application or PBX keeps receiving the ringing indication, with no media.
If the called party has already answered, they may say “Hello” and wait for a reply during this window.
If a machine is detected during Early Media, before the call is answered, Wavix disconnects it and the SIP caller receives a busy indication — the call is reported as Busy in both your logs and Wavix logs, and is not billed as answered.
If a machine is detected after the call is answered, Wavix still disconnects it, but the call has already been answered by definition: it appears as Answered in Wavix call logs, with a talk time of roughly the detection window (three to four seconds), and is billed as an answered call plus the AMD fee (see Billing). Your dialer or PBX may show a busy/failed disposition of its own if it interprets the disconnect that way, so reconcile against the Answered by field rather than your dialer’s disposition alone.
If a human is detected, the call is bridged immediately.

Because the called party may already be waiting when the verdict lands, connect calls that pass AMD straight through to an agent or application that is ready to talk. Any extra queueing, ringing, or second detection stage after AMD adds to that silence and increases the chance the called party hangs up.

Detection outcomes

Verdict	What happens to the call	How it is reported
Human	Bridged immediately.	`machine_detected: false`; Answered by shows `human`.
Machine	Disconnected by Wavix. A SIP caller receives a busy indication. Reported and billed as `Busy` if detected during Early Media (before answer), or as `Answered` (call + AMD fee) if detected after answer — see Detection window and call signalling.	`machine_detected: true`; Answered by shows `machine`.
Undetermined	Bridged, exactly as if a human had answered.	Not flagged as a machine; Answered by shows neither `human` nor `machine`.

Wavix does not return an AMDSTATUS parameter or a NOTSURE signalling result. If your dialer logs values such as HUMAN, MACHINE, or NOTSURE per call, they come from a detection layer inside the dialer, not from Wavix. Running two detection layers on the same call lengthens the silence after answer and can drop calls that Wavix already classified as human. See Using AMD with an outbound dialer.

When AMD cannot reach a verdict

Some calls cannot be classified confidently — heavy background noise, a very delayed or silent answer, or a network announcement in an unexpected format. In those cases Wavix connects the call rather than dropping it, so a real person is never cut off because of an inconclusive verdict, and no AMD fee is applied to that call.

Activation levels

You can enable AMD at two different levels depending on your integration needs:

1. Trunk level (Wavix portal & Wavix Embeddable)

Recommended for calls manually placed from your PBX or third-party systems connected via SIP, as well as features built using Wavix Embeddable. For these methods, AMD is controlled globally for the specific SIP trunk:

Sign in to your Wavix account.
In the top menu, click on Numbers & Trunks → Trunks.
Select an existing SIP trunk to edit (or create a new one).
Wavix Embeddable uses the SIP trunk configured during your application setup.
Scroll down to the Trunk features section.
Toggle Voicemail detection to ON.
Click Save and close.

Once enabled, any outbound call made through this trunk—whether via a hardware phone or a Wavix Embeddable instance—that is answered by a machine will be automatically dropped.

2. Call level (API only)

Recommended for programmable voice applications where you want granular control over which specific calls use AMD. This is currently supported exclusively by the Calls API.

Via Calls API

To enable AMD for a specific call, set the voicemail_detection property to true in your POST /v1/calls request.

curl -X POST "https://api.wavix.com/v1/calls" \
  -H "Authorization: Bearer <your_api_key_here>" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "13614157006",
    "to": "1234567890",
    "voicemail_detection": true
  }'

const axios = require('axios');

axios.post('https://api.wavix.com/v1/calls', {
  from: '13614157006',
  to: '1234567890',
  voicemail_detection: true
}, {
  headers: {
    'Authorization': 'Bearer <your_api_key_here>',
    'Content-Type': 'application/json'
  }
})
.then(response => console.log(response.data))
.catch(error => console.error(error));

package main

import (
	"bytes"
	"encoding/json"
	"fmt"
	"net/http"
)

func main() {
	url := "https://api.wavix.com/v1/calls"
	payload := map[string]interface{}{
		"from":                "13614157006",
		"to":                  "1234567890",
		"voicemail_detection": true,
	}
	jsonPayload, _ := json.Marshal(payload)

	req, _ := http.NewRequest("POST", url, bytes.NewBuffer(jsonPayload))
	req.Header.Set("Authorization", "Bearer <your_api_key_here>")
	req.Header.Set("Content-Type", "application/json")

	client := &http.Client{}
	resp, err := client.Do(req)
	if err != nil {
		fmt.Printf("Error: %v\n", err)
		return
	}
	defer resp.Body.Close()

	fmt.Printf("Status: %s\n", resp.Status)
}

require 'net/http'
require 'uri'
require 'json'

uri = URI.parse("https://api.wavix.com/v1/calls")
header = {
  'Content-Type' => 'application/json',
  'Authorization' => 'Bearer <your_api_key_here>'
}
body = {
  from: '13614157006',
  to: '1234567890',
  voicemail_detection: true
}

http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
request = Net::HTTP::Post.new(uri.request_uri, header)
request.body = body.to_json

response = http.request(request)
puts response.body

AMD events and webhooks

To receive real-time notifications about AMD results, you can configure an on-call webhook. Wavix sends a POST callback to your designated URL whenever a call event occurs, such as when a call is answered and the AMD analysis is complete. You can create a webhook using the Create a webhook endpoint:

curl -X POST "https://api.wavix.com/v1/calls/webhooks" \
  -H "Authorization: Bearer <your_api_key_here>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-app.com/webhooks/calls",
    "event_type": "on-call"
  }'

The machine_detected event

When a call is answered and subsequently ends, Wavix triggers a completed event callback. The JSON payload includes a machine_detected boolean field that indicates whether the call was screened by the AMD system. Sample completed event payload:

{
  "uuid": "5dccb6b0-f35c-488c-867b-86fb012c4415",
  "direction" : "outbound",
  "event_type": "completed",
  "event_time": "2025-09-22T12:56:45.000Z",
  "event_payload": null,
  "call_started": "2025-09-22T12:56:38.000Z",
  "call_answered": "2025-09-22T12:56:40.000Z",
  "call_completed": "2025-09-22T12:56:45.000Z",
  "from": "+18045961058",
  "to": "17653889567",
  "machine_detected": true,
  "tag": "marketing-campaign"
}

machine_detected: true: An answering machine or voicemail was detected.
machine_detected: false: A human was detected.

By listening for the completed event, your application can accurately log the outcome of the call, including whether it was dismissed by AMD or successfully answered by a human.

Auditing AMD results on your own traffic

Detection accuracy depends on the destination, on local answering habits, and on how voicemail systems in that market present their greeting. Rather than relying on a single global figure, measure AMD on your own traffic. The per-call verdict is available in three places:

Webhooks — the machine_detected field on the completed event described above. Persist it against your own campaign records to build a view of false machine and false human detections over time.
CDR API — List CDRs returns the verdict for historical calls, so you can audit retrospectively even if you did not store the webhook payload.
Portal export — in app.wavix.com, export your call history as CSV and read the Answered by column. Filtering on human and machine isolates classified calls; excluding both leaves the undetermined ones.

To review suspected misclassifications, filter for answered calls with a very short duration and cross-reference the AMD verdict. If call recording is enabled on the same trunk, the recording makes the review conclusive.

Billing

The AMD fee is charged per screened call, in addition to the call charge itself. Calls where the verdict was undetermined do not carry the AMD fee, but the call is still billed normally. A call ending in a machine verdict after answer is billed as any other answered call (for its few seconds of talk time) plus the AMD fee; if the machine is detected during Early Media, before answer, the call is not billed as answered at all. Check your rate sheet or contact your account manager for the rate that applies to your account. To reconcile a period, export call history as CSV, select Answered in the Disposition column, and exclude human and machine in Answered by. The remaining calls are the undetermined ones, which are billed for the call itself but not for AMD.

Limitations

Wavix AMD is a single centrally tuned model rather than a configurable engine. In practice this means:

No tuning parameters. Total analysis time, initial-silence and greeting thresholds, and word-count limits are not exposed. The model is tuned on live traffic, including noisy lines and delayed answers.
No beep detection. Wavix does not detect or wait for the end-of-greeting beep. Detected machines are disconnected rather than held open, so AMD is not suitable for flows that leave a message in a voicemail box.
No self-service asynchronous mode. By default, the call is not bridged until the verdict is in, so the detection window is always visible to the called party. Wavix can run detection in parallel after the call connects instead — useful for automated flows (for example, an AI agent or a prerecorded message) that would rather start talking immediately and accept that a small fraction of calls disconnect a few seconds in. This mode is not exposed in the Wavix portal; contact your account manager to enable it on a trunk.
Outbound only. AMD applies to outbound calls.

Using AMD with an outbound dialer

Predictive and queue-mode dialers are the most common AMD integration, and also the easiest to misconfigure. A few rules keep live customers from being dropped:

Run detection in one place only. If Wavix AMD is enabled on the trunk, disable voicemail detection in your dialer. Two layers on the same call stack their analysis windows and the second layer will discard calls Wavix already passed as human.
Do not treat the busy indication as a busy line. On an AMD-enabled trunk, a busy response to an outbound attempt usually means AMD detected a machine and dropped the call. Classify it as screened in your retry logic rather than requeuing it as an unreachable number.
Bridge passing calls straight to a waiting agent. Any queueing or ringing stage after AMD is added to the silence the called party already experienced.
Persist the verdict per call. Without it you cannot distinguish an AMD drop from a network failure when auditing a campaign.

Real customers are being dropped before the agent connects

Check whether a second detection layer is active in your dialer, since its own machine or inconclusive verdict will end the call after Wavix has already passed it as human. Then export the affected calls and compare your dialer’s verdict against the Answered by column to establish which layer made the decision.

The called party hears several seconds of silence after answering

This is the detection window and is expected. Reduce total silence by removing any queueing, ringing, or second detection stage between the AMD verdict and the agent.

My dialer reports NOTSURE or MACHINE but the call was connected

Wavix does not emit those statuses. A connected call means Wavix classified it as human or could not reach a verdict; the status your dialer logged came from its own detection layer.

I need to confirm which trunks have AMD enabled

In your Wavix account, go to Numbers & Trunks → Trunks, open each trunk you created, and check Voicemail detection under Trunk features.

Messaging

Two-factor authentication

Voice

Numbers

MCP server

Answering Machine Detection (AMD)

How AMD works

Detection window and call signalling

Detection outcomes

When AMD cannot reach a verdict

Activation levels

1. Trunk level (Wavix portal & Wavix Embeddable)

2. Call level (API only)

Via Calls API

AMD events and webhooks

The machine_detected event

Auditing AMD results on your own traffic

Billing

Limitations

Using AMD with an outbound dialer

​How AMD works

​Detection window and call signalling

​Detection outcomes

​When AMD cannot reach a verdict

​Activation levels

​1. Trunk level (Wavix portal & Wavix Embeddable)

​2. Call level (API only)

​Via Calls API

​AMD events and webhooks

​Subscribe to call events

​The machine_detected event

​Auditing AMD results on your own traffic

​Billing

​Limitations

​Using AMD with an outbound dialer

How AMD works

Detection window and call signalling

Detection outcomes

When AMD cannot reach a verdict

Activation levels

1. Trunk level (Wavix portal & Wavix Embeddable)

2. Call level (API only)

Via Calls API

AMD events and webhooks

Subscribe to call events

The machine_detected event

Auditing AMD results on your own traffic

Billing

Limitations

Using AMD with an outbound dialer