Asterisk AMD Configuration: amd.conf Settings, AMDSTATUS, and False Positives

A caller says, “Hello, this is Jordan speaking,” but your dialer sends the call down the machine route before an agent hears it. Another call reaches voicemail, yet Asterisk returns NOTSURE and ties up an agent for several seconds.

These failures usually start with an amd.conf profile that does not match the greetings, carriers, and call-screening systems present in the campaign. Amdy provides another detection path for Vicidial and Asterisk environments, but first it helps to understand exactly what native Asterisk AMD is deciding.

Quick answer: how to set up Asterisk AMD configuration

Use this workflow to configure and validate native Asterisk answering machine detection:

1. Edit /etc/asterisk/amd.conf and set the nine timing and audio-analysis parameters under [general].
2. Reload the AMD module or restart Asterisk so the revised configuration is active.
3. Run AMD() on the answered channel before connecting it to an agent or machine destination.
4. Read AMDSTATUS and route HUMAN, MACHINE, and NOTSURE separately.
5. Log AMDCAUSE so you know which threshold produced each decision.
6. Test the configuration against labeled human and voicemail recordings from the actual campaign.
7. Change one setting at a time, then compare false-human, false-machine, and NOTSURE results.
8. Stop tuning when human and machine greeting patterns overlap or call screening defeats timing rules.

A usable starting configuration looks like this:

``ini [general] initial_silence = 2500 greeting = 1500 after_greeting_silence = 800 total_analysis_time = 5000 min_word_length = 100 between_words_silence = 50 maximum_number_of_words = 3 silence_threshold = 256 maximum_word_length = 5000 ``

Treat these as starting values, not universal answers. Carrier audio, language, microphone noise, voicemail prompts, and the way people answer your calls all affect the result.

How Asterisk AMD configuration works

The Asterisk AMD() application listens to the beginning of an answered call and divides the audio into silence and words. It then applies fixed thresholds from amd.conf or from arguments passed directly to the application.

Asterisk does not understand what the greeting means. It does not know that “Please state your name and the reason for your call” is a call-screening prompt. It measures durations, pauses, word-like audio segments, and the total number of segments.

The official Asterisk AMD application documentation lists the available arguments and channel variables. The configuration file uses the same controls in a reusable global profile.

When analysis ends, Asterisk sets two important variables:

• AMDSTATUS contains HUMAN, MACHINE, or NOTSURE.
• AMDCAUSE records why the application reached that result, often with a measured value.

The application blocks the current dialplan path while it analyzes the audio. A five-second analysis window can therefore add close to five seconds of dead air when the detector cannot decide earlier. That delay matters in predictive dialing because the person may hang up before the agent receives the call.

Our worked example will use an outbound appointment-reminder campaign running through the [amd-route] dialplan context. Human recipients often answer with short greetings, but some say, “Hello, this is Jordan speaking.” Voicemail greetings generally continue for several seconds. Call screening introduces a third pattern: a synthetic voice asks the caller to identify themselves, then waits.

Asterisk amd.conf settings explained

Each setting affects a specific part of the opening greeting. The values are milliseconds except for the word count and silence amplitude threshold.

amd.conf setting	Common starting value	What triggers a decision	Main tuning risk
initial_silence	2500	Too much silence before speech can produce MACHINE	Quiet humans become false machines
greeting	1500	A long opening greeting can produce MACHINE	Talkative humans are rejected
after_greeting_silence	800	Enough silence after a short greeting can produce HUMAN	Brief pauses in voicemail greetings look human
total_analysis_time	5000	Reaching the limit produces NOTSURE	Longer values increase dead air
min_word_length	100	Controls whether a sound counts as a word	Short words or clipped audio are ignored
between_words_silence	50	Controls when separate words are recognized	Noise can fragment one phrase into many words
maximum_number_of_words	3	Too many words can produce MACHINE	Natural human introductions become machines
silence_threshold	256	Separates silence from audio energy	Trunk gain and background noise distort every timing rule
maximum_word_length	5000	Excessive continuous speech can produce MACHINE	Music or noise may look like one long word

The sample amd.conf file maintained with Asterisk is useful for confirming parameter names and baseline values for your installed branch. Check the documentation matching your Asterisk version before copying a configuration from another server.

initial_silence

initial_silence is the maximum silence allowed before the detector hears the first qualifying word. If that period expires, Asterisk normally returns MACHINE with an AMDCAUSE beginning with INITIALSILENCE.

Reducing the value can catch voicemail systems that answer before their prompt begins. It can also reject real people who take a moment to respond, answer in a noisy room, or receive the call through a carrier with delayed media.

For the appointment-reminder example, setting this to 1200 milliseconds looked attractive because it shortened machine handling. It also created a predictable failure: recipients who answered and waited for the caller to speak were classified as machines. The setting was returned to 2500 milliseconds while the other causes were examined.

greeting

greeting limits the length of the greeting phase before a long greeting is considered machine-like. A result caused by this limit normally reports LONGGREETING.

Lower values identify traditional voicemail greetings quickly. Higher values accommodate people who answer with their name, company, or department. Increasing the value also means some machines remain connected longer.

Do not change greeting merely because total classification feels slow. Inspect AMDCAUSE first. If the problematic calls end with TOOLONG, the total analysis limit may be involved instead.

after_greeting_silence

after_greeting_silence defines how much silence must follow a short greeting before Asterisk accepts the answer as human. This is the pause in the familiar human pattern: “Hello?” followed by silence.

A shorter value returns human calls faster. It also creates false-human results when a voicemail speaker pauses between sentences. A longer value is more conservative but leaves genuine callers waiting.

This setting should be tested with complete audio, including carrier delay. Measuring only the greeting from an edited recording removes the silence behavior you are trying to evaluate.

total_analysis_time

total_analysis_time caps the entire decision period. If no other rule settles the call before that limit, AMDSTATUS becomes NOTSURE and AMDCAUSE commonly reports TOOLONG.

Raising the value gives borderline greetings more time to reveal themselves. The cost is caller experience. An extra two seconds may improve machine recognition while causing more humans to abandon during silence.

Keep NOTSURE as a real operational outcome. Converting every timeout into MACHINE hides uncertainty and can discard live contacts.

min_word_length and between_words_silence

min_word_length controls the minimum duration required for audio to count as a word. Very short bursts are ignored. Increase it and Asterisk may ignore clipped syllables. Reduce it and clicks, line noise, or breathing may be counted.

between_words_silence determines how much quiet separates two words. If it is too short for the audio conditions, one phrase may become several detected words. That can trigger MAXWORDS even when the speaker said very little.

These values interact. Change them cautiously and retain the original configuration in version control.

maximum_number_of_words

maximum_number_of_words is a common source of false-machine classifications. Once Asterisk detects more than the permitted number of words, it can return MACHINE with MAXWORDS as the cause.

In our example, the default limit of three mishandled “Hello, this is Jordan speaking.” Depending on how pauses and syllables were segmented, Asterisk counted enough words to cross the limit before the recipient stopped talking.

Raising the limit to five protected that greeting. It also let some short voicemail greetings continue further into analysis. That trade-off was accepted only after the team checked how many real calls and machines carried the MAXWORDS cause.

silence_threshold

silence_threshold defines the audio energy below which Asterisk treats the signal as silence. This is not a timing value, even though it changes every timing measurement that depends on silence.

A threshold that works on one SIP trunk may perform poorly on another. Background office noise, comfort noise, aggressive gain, music, and poor mobile connections can keep the signal above the threshold. Asterisk then sees continuous speech where a listener hears a pause.

Check raw channel recordings before altering word timings. If silence segmentation is wrong, tuning greeting or maximum_number_of_words treats the symptom.

maximum_word_length

maximum_word_length limits continuous audio that Asterisk considers one word. A machine decision caused by this setting normally includes MAXWORDLENGTH in AMDCAUSE.

It protects against uninterrupted voicemail audio, music, and signals that never fall below the silence threshold. Frequent triggers can also indicate bad silence detection. Listen to those calls rather than assuming the speakers truly produced one continuous word.

How to apply Asterisk AMD configuration in the dialplan

Call AMD() after the outbound channel has answered and media is available. The application can read the defaults from amd.conf:

```asterisk [amd-route] exten => s,1,NoOp(Run AMD on answered outbound call) same => n,AMD() same => n,NoOp(AMD status: ${AMDSTATUS}; cause: ${AMDCAUSE}) same => n,GotoIf($["${AMDSTATUS}" = "HUMAN"]?human) same => n,GotoIf($["${AMDSTATUS}" = "MACHINE"]?machine:notsure)

same => n(human),Goto(agent-connect,s,1) same => n(machine),Goto(machine-treatment,s,1) same => n(notsure),Goto(manual-review,s,1) ```

The labels are intentionally explicit. They prevent an unrecognized value from falling through to the machine route.

You can override the global settings inside AMD() by supplying positional arguments. That is useful when campaigns have materially different greeting patterns, but long argument strings are easy to misread. Keep comments beside each campaign override and preserve the order shown in the official application documentation.

Reload the module after changing amd.conf:

``bash asterisk -rx "module reload app_amd.so" ``

Confirm the module accepted the file and watch the Asterisk console during test calls. A successful reload does not prove that the audio reaches AMD() at the expected moment.

How to route HUMAN, MACHINE, and NOTSURE correctly

HUMAN should normally continue to an available agent or the next live-contact step. Minimize additional prompts between classification and connection. A correct classification still produces a poor result if the recipient hears silence afterward.

MACHINE can proceed to a permitted voicemail treatment, campaign-specific message, disposition, or hangup. Follow the legal and carrier requirements that apply to prerecorded messages. Detection does not grant permission to leave one.

NOTSURE deserves its own route. For a high-value campaign, connecting uncertain calls to an agent may be preferable to losing a person. For a campaign where agent capacity is constrained, you may send them to a separate queue or end the attempt according to policy. The choice should be visible in reporting.

The Asterisk GotoIf() documentation explains the conditional branching used above. Avoid testing only for MACHINE and treating everything else as human. Missing variables, application errors, and future routing changes can then reach agents unnoticed.

Vicidial operators should also confirm where its campaign logic invokes AMD and how each result maps to a lead status. The detailed Vicidial AMD configuration guide covers that layer, while the article on what to do with NOTSURE calls examines routing choices in more depth.

How to tune Asterisk AMD without hiding false positives

Export the last 90 days first. Select recordings from the same campaign, trunk mix, destination region, and calling hours that the revised configuration will handle.

Label each recording according to what a reviewer hears, not according to the existing dialer disposition. Existing dispositions already contain AMD errors. Use at least these categories:

• Human greeting
• Traditional voicemail greeting
• Call-screening or virtual-assistant prompt
• Silence or failed media
• Ambiguous audio requiring review

Replay the audio through the same Asterisk processing path where possible. Record AMDSTATUS, AMDCAUSE, decision time, and the final reviewed label. The process in How to Measure Answering Machine Detection Accuracy explains why a labeled test set is more useful than a single overall accuracy figure.

Change one parameter per run. In the worked example, the first useful finding was not that AMD needed to be “more accurate.” It was that false machines clustered under MAXWORDS. That evidence supported testing a word limit of five. Changing greeting, after_greeting_silence, and maximum_number_of_words together would have made the improvement impossible to attribute.

Measure the errors separately. A false machine loses a live contact, while a false human consumes agent time and may create dead air. NOTSURE affects whichever route you assign to it. The business cost is different for each outcome.

Use the AMD ROI calculator if you need to translate machine traffic and agent handling into an operational estimate. Do not reduce the evaluation to cost alone. Caller abandonment and compliance constraints can set stricter limits than agent minutes.

When Asterisk AMD configuration tuning is no longer enough

Timing adjustments work when humans and machines produce meaningfully different pause and greeting patterns. They stop working when those patterns overlap.

Call screening is the clearest example. A synthetic assistant may say a short sentence and pause, which resembles a human greeting under timing rules. Some services ask for the caller’s name, play a hold prompt, or transfer only after interaction. The call-screening detection guide describes why these flows break assumptions built around classic voicemail greetings.

Tuning has probably reached its limit when:

• Reducing false machines consistently increases false humans by an unacceptable amount.
• The same AMDCAUSE appears across correctly and incorrectly classified calls.
• Different trunks require conflicting silence thresholds.
• Call-screening prompts dominate the remaining errors.
• Longer analysis improves classification but causes caller abandonment.
• Campaign-specific overrides have become difficult to operate safely.

At that point, another threshold often moves errors between categories rather than removing them. Review how often AMD is wrong and compare results by call type, not just as one combined rate.

How Amdy replaces repeated Asterisk AMD tuning

Amdy is intended for Vicidial and predictive-dialer teams that need an AI-based classification path instead of relying only on fixed Asterisk timings. The implementation still requires disciplined routing, but the user workflow changes.

First, connect the answered-call media according to the documented Amdy WebSocket API. The client guide defines the protocol and classification codes, so dialplan or dialer logic can work from a documented result rather than parsing an informal message.

Next, receive the classification while the call is active. Map the returned result to the same operational destinations used in the native example: agent connection, machine treatment, or an uncertainty policy. Keep a safe fallback for unavailable or malformed responses.

Then retain the detection outcome alongside the campaign disposition. Amdy’s detection features show the data available for evaluating how calls were classified. Compare those results with reviewed recordings before moving all traffic.

Finally, roll out by campaign or traffic segment. Do not replace the native path on every call after a small test. Run a controlled evaluation, inspect disagreements between Asterisk and the AI detector, and pay particular attention to live people sent toward machine treatment.

For Vicidial deployments, the main Amdy integration page explains the intended environment. Current plan limits and costs are listed on the pricing page, so they can be compared with agent time, lost contacts, and the maintenance burden of campaign-specific timing profiles.

This approach removes repeated adjustment of silence and word-count thresholds from normal campaign operation. It does not remove the need to define HUMAN, MACHINE, and uncertain-result routing or to monitor outcomes after carriers and call patterns change.

Common Asterisk AMD configuration mistakes

One frequent mistake is copying amd.conf from another dialer without replaying local calls. Two campaigns on the same server may need different handling because one reaches consumers on mobile phones while another reaches staffed business lines.

Another is treating NOTSURE as a technical error. It often means the total analysis window ended before the rules found a decisive pattern. Route and report it deliberately.

Teams also tune from aggregate dispositions. If agents mark every silent call as voicemail, false humans, delayed audio, and actual machines become one category. Listen to the recordings.

Do not overlook answer supervision. A SIP provider can signal an answered call before usable media arrives, consuming the initial_silence window. The guide to false answer supervision on SIP trunks explains that upstream failure mode.

Finally, avoid using a single “accuracy” percentage to approve changes. Report human recall, machine recall, false-machine rate, false-human rate, NOTSURE rate, and decision time. The practical testing procedure is available in How to test AMD accuracy.

Asterisk AMD configuration FAQ

Where is amd.conf located in Asterisk?

The usual path is /etc/asterisk/amd.conf. Package layouts and custom source installations can use a different configuration directory. Check asterisk.conf if the file is not there.

Do I need to restart Asterisk after changing amd.conf?

A full restart is usually unnecessary. Reload app_amd.so, verify the console output, and place controlled test calls. Schedule changes carefully on active dialers because new calls may use the revised thresholds immediately.

Can I use different AMD settings for each campaign?

Yes. Pass overrides as arguments to AMD() or route campaigns through separate dialplan logic. Document every positional value. A shared global profile is easier to maintain, while campaign overrides offer better control when greeting behavior genuinely differs.

Why does Asterisk classify real people as MACHINE?

Start with AMDCAUSE. MAXWORDS points toward word segmentation or a low word limit. LONGGREETING indicates that the greeting duration was exceeded. INITIALSILENCE can result from quiet recipients, delayed media, or a short initial-silence limit. Listen to examples from each cause before changing the configuration.

What should I do with AMDSTATUS NOTSURE?

Keep it separate in the dialplan and reporting. High-value calls may go to an agent, while lower-value traffic may use another policy. Never silently merge NOTSURE into MACHINE, because that conceals potentially live contacts.

Is native Asterisk AMD enough for call screening?

Not reliably. Native AMD measures timing and audio segmentation, while screening assistants can imitate the short-prompt-and-pause pattern associated with humans. If screening prompts form a material share of errors, test an AI detector against a labeled recording set.

Does Vicidial use the same Asterisk AMD settings?

Vicidial can invoke Asterisk AMD, but campaign settings, dialplan generation, statuses, and routing add another layer. Confirm both the underlying amd.conf behavior and the Vicidial campaign configuration. The guide to Asterisk and AI AMD options helps frame that choice.

Choose the next change from the cause data

If errors cluster under one clear AMDCAUSE, adjust that setting, replay the labeled calls, and verify the result on live traffic. Keep the previous profile ready for rollback.

If the errors span human greetings, voicemail, call screening, and inconsistent trunk audio with no useful separation, stop adding timing exceptions. Preserve explicit routing for all outcomes and test an AI-based detector against the same recordings. That gives you a comparison grounded in calls your operation actually receives.