AMD Glossary: Answering Machine Detection Terms, Defined
This glossary defines 25 terms used in outbound answering machine detection, covering the Asterisk app_amd application, every amd.conf timing parameter and its documented default, the three AMDSTATUS values including NOTSURE, the ViciDial campaign settings layered on top, and the detection concepts a timing heuristic cannot express.
Answering machine detection (AMD)
Answering machine detection is the process a dialer uses to decide, in the first seconds after a call is answered, whether the audio on the line came from a live person or from a recorded system such as a voicemail greeting.
The decision matters because a predictive dialer has to route the call somewhere immediately: to a waiting agent, to a recorded message, or to a hangup. Everything else in this glossary is either a mechanism for making that decision or a consequence of getting it wrong. What is AI answering machine detection?.
app_amd
app_amd is the Asterisk dialplan application that performs the built-in answering machine detection shipped with Asterisk, and therefore with ViciDial, GoAutoDial and Issabel.
It is invoked from the dialplan as AMD(), reads its thresholds from amd.conf, listens to the answered audio for up to total_analysis_time, and writes its verdict into the AMDSTATUS channel variable. It is a timing heuristic: it measures silence and speech durations, not the character of the sound. What is default AMD in ViciDial.
amd.conf
amd.conf is the Asterisk configuration file that holds the default timing thresholds app_amd uses to classify an answered call.
Every parameter in it can also be passed inline as an argument to AMD() in the dialplan, in which case the inline value wins for that call. Tuning it moves calls between the HUMAN, MACHINE and NOTSURE buckets; it does not add information the heuristic did not already have. The amd.conf cheat sheet.
AMDSTATUS
AMDSTATUS is the Asterisk channel variable that app_amd sets after analysis, and it takes exactly one of three values: HUMAN, MACHINE or NOTSURE.
Your dialplan reads AMDSTATUS and branches on it. Because the variable has three values and most dialplans are written around two, the handling of the third is where most detection loss occurs. ViciDial AMD variables: every setting explained.
AMDCAUSE
AMDCAUSE is the companion Asterisk channel variable that records which threshold produced the AMDSTATUS verdict, using values such as INITIALSILENCE, LONGGREETING, MAXWORDLENGTH and TOOLONG.
It is the only diagnostic app_amd gives you. If your MACHINE verdicts are overwhelmingly INITIALSILENCE, the initial_silence threshold is doing the deciding; if they are LONGGREETING, the greeting threshold is. Log it before you tune anything.
HUMAN (AMDSTATUS value)
HUMAN is the AMDSTATUS value app_amd sets when the answered audio cleared its thresholds in the pattern the heuristic associates with a live person: a short greeting followed by silence, within the analysis window.
It is a statement about timing shape, not about who is on the line. A voicemail greeting that happens to be short and followed by a pause can produce HUMAN.
MACHINE (AMDSTATUS value)
MACHINE is the AMDSTATUS value app_amd sets when the answered audio matched a recorded-system timing pattern, typically a greeting longer than the greeting threshold or an initial silence longer than initial_silence.
Most dialplans hang up or play a message on MACHINE. A live person who answers slowly, or who answers with a long sentence instead of a clipped hello, can produce MACHINE.
NOTSURE (AMDSTATUS value)
NOTSURE is the AMDSTATUS value app_amd sets when it completed its full analysis window but no threshold in amd.conf was crossed decisively enough to justify either HUMAN or MACHINE.
NOTSURE is not an error and not a fourth kind of call. It is app_amd declining to decide and handing the decision back to your dialplan. Whatever happens to a NOTSURE call next is a routing choice you made, not a detection the engine made. AMDSTATUS NOTSURE: the gray zone.
initial_silence
initial_silence is the amd.conf parameter setting how many milliseconds of silence may pass after the call is answered before app_amd leans toward MACHINE, with a documented default of about 2500 ms.
It is the single most consequential parameter for false MACHINE verdicts on real people, because a person who picks up and waits for the dialer to speak first produces exactly the silence this threshold punishes. amd.conf parameter reference.
greeting
greeting is the amd.conf parameter setting the maximum length in milliseconds that a single unbroken greeting can run and still be counted as a human hello, with a documented default of about 1500 ms.
Raise it to tolerate longer human greetings and you start missing short voicemail prompts. Lower it to catch terse voicemails and long-winded humans get tagged MACHINE. There is no value that avoids both.
after_greeting_silence
after_greeting_silence is the amd.conf parameter setting how many milliseconds of quiet must follow a greeting before app_amd treats the greeting as finished and concludes a person is waiting, with a documented default of about 800 ms.
It is what makes app_amd wait after a short hello instead of deciding immediately, and it is part of why a heuristic verdict costs the caller most of a second even in the fast case.
total_analysis_time
total_analysis_time is the amd.conf parameter setting the hard ceiling in milliseconds on how long app_amd will listen before giving up and returning NOTSURE, with a documented default of about 5000 ms.
Every call that hits this ceiling becomes NOTSURE by definition. Lowering it to protect agent time mechanically increases your NOTSURE share.
min_word_length
min_word_length is the amd.conf parameter setting the shortest burst of audio, in milliseconds, that app_amd will count as a word rather than as noise, with a documented default of about 100 ms.
Set it too low and line noise or a carrier click gets counted as speech; set it too high and a clipped one-syllable hello is not counted at all.
between_words_silence
between_words_silence is the amd.conf parameter setting how many milliseconds of quiet separate one counted word from the next, with a documented default of about 50 ms.
It controls how app_amd segments a stream of speech into countable words, which in turn feeds maximum_number_of_words.
maximum_number_of_words
maximum_number_of_words is the amd.conf parameter setting how many words app_amd may count in the greeting before it concludes the audio is a recorded message rather than a person, with a documented default of 3.
Three words is a low bar for a human. "Hello, this is Dave" clears it. This parameter is a common source of MACHINE verdicts on people who answer politely.
maximum_word_length
maximum_word_length is the amd.conf parameter setting the longest single unbroken stream of speech, in milliseconds, that app_amd will accept before treating the audio as a recorded message.
It catches the voicemail prompt that runs on without pausing. Tune it alongside greeting and between_words_silence, since all three describe the same underlying audio in different units.
silence_threshold
silence_threshold is the amd.conf parameter setting the audio energy level below which app_amd counts a sample as silence rather than as sound, with a documented default of about 256.
It is the only parameter that is about the signal rather than about timing, and it is the one that misbehaves on noisy or low-bitrate carrier audio, where background hiss never drops below the threshold and the call therefore never registers a silence.
drop_call_seconds (ViciDial)
drop_call_seconds is a ViciDial campaign setting defining how many seconds a connected call may wait for an available agent before ViciDial drops it, which is the event counted against your abandonment rate.
It sits above AMD rather than inside it, but the two interact directly: detection that is too permissive sends more calls to the agent queue, and a full queue turns those into drops.
amd_send_message (ViciDial)
amd_send_message is a ViciDial campaign setting controlling what happens to a call that AMD classified as a machine — typically playing a recorded message into the voicemail or hanging up immediately.
Combined with your dialplan branch on AMDSTATUS, it determines the real-world consequence of a MACHINE or NOTSURE verdict on the floor.
False answer supervision (FAS)
False answer supervision is when a carrier signals that a call was answered when no person or device on the far end actually picked up, which starts billing and hands your dialer audio that nobody produced.
From the dialer’s point of view a FAS call looks like a connect, so it consumes an agent or a detection and it appears on your invoice. Timing-based AMD generally cannot separate FAS from an ordinary silent pickup, because both present as silence. Carrier false answers (FAS).
Abandonment rate
Abandonment rate is the share of answered calls that a predictive dialer connects and then drops without delivering a live agent, and it is the metric the FTC Telemarketing Sales Rule caps at 3% of answered calls.
The measurement trap is that a live person misclassified as a machine and hung up on never enters the answered-call denominator as an abandoned call, so aggressive AMD improves the reported number while making the underlying behaviour worse. Predictive dialer abandonment rate.
Acoustic classification
Acoustic classification is answering machine detection that decides from the sound of the answer audio itself — its spectral and temporal signature — rather than from measured silence and speech durations or from a transcript of the words.
It is the approach AMDY uses. Because it does not need to wait for a greeting to end and a silence to elapse, it can also separate classes a timing heuristic cannot express at all, such as carrier false answers and specific carrier voicemail systems. Sound, not words.
Transcription-based detection
Transcription-based detection is answering machine detection that runs speech-to-text on the answer audio and decides from the recognised words, for example by matching phrases typical of a voicemail greeting.
It is language-bound, it needs words to exist before it can decide, and it returns nothing useful on a silent pickup or on a bare beep — which together make up a large share of what an outbound dialer actually hits. Why transcription is the wrong tool here.
Honeypot number
A honeypot number is a phone number operated to record and report unsolicited calls rather than to receive them, used by litigators and enforcement bodies to build evidence against outbound callers.
A honeypot answers like a person, so a timing heuristic classifies it as HUMAN and connects an agent. Identifying it requires recognising the specific audio, which is a classification problem rather than a timing one. AMDY emits a distinct HONEYPOTAMD class for it.
Predictive dialer
A predictive dialer is an outbound system that places more calls than it has free agents, using forecast answer and handle rates to have a connected live person arrive roughly when an agent becomes available.
AMD exists because of this overdial. If every call were dialed by an agent who could hear it, no automated human-or-machine decision would be needed.
A note on the defaults quoted here
The millisecond values above are the defaults documented in the sample amd.conf shipped with Asterisk. Distributions repackage Asterisk and ViciDial installers sometimes ship their own values, so read the file on your own box before assuming. The parameter-by-parameter walkthrough of what happens when you move each one lives in the amd.conf cheat sheet, and the ViciDial-specific settings are covered in ViciDial AMD variables.
If you want the measured outcome distribution behind these classes rather than the definitions, see how often answering machine detection is wrong, and for the operational decision NOTSURE forces on you, see what the dialplan should do with NOTSURE.
See your real human-vs-machine numbers — free
50,000 detections a month on the Sandbox plan, no card, 5-minute ViciDial install.