How voicemail and answering machine detection works

Voicemail and answering machine detection works by analyzing the audio after a call is answered: speech duration, pauses, greeting cadence, background characteristics, recognized words, and the presence of a recording tone all contribute evidence. The detector classifies the answer as human, machine, or uncertain, then a separate policy decides whether to continue, hang up, wait for a beep, leave a message, or retry later. It is an inference problem, not a reliable flag delivered by the phone network.

An answered call does not identify who answered

In normal call signaling, answer supervision means that the far end accepted the call. On a SIP call, that is commonly represented by a successful final response such as 200 OK, followed by an ACK. On a traditional telephone path, the carrier provides an equivalent answer indication. Neither signal says whether the accepting endpoint was a person, a carrier voicemail platform, an office answering machine, an interactive menu, or a fax device.

Once media begins, the calling application receives the same kind of audio stream in every case. It must listen and infer what is on the other end. That is why answering machine detection, usually abbreviated AMD, starts after answer rather than during ringing.

Early media makes the boundary less tidy. A network can send announcements or ringback audio before final answer. A detector that starts on the first audio packet may analyze a carrier message as if it were the called party's greeting. The call controller therefore needs to distinguish signaling state from media state and define whether pre-answer audio is ignored, classified separately, or treated as a terminal network outcome. The full signaling sequence is explained in how a phone call works.

The classic clue is greeting cadence

People and voicemail systems tend to answer differently, though none of the differences is absolute. A person often gives a short greeting and then waits: "Hello?" A voicemail greeting often contains a longer uninterrupted phrase, perhaps a name, an availability statement, and instructions, followed by a pause and a tone.

Traditional AMD turns those tendencies into a timing state machine. It tracks:

• How long the initial silence lasts after answer.
• The duration of each speech segment.
• The silence between speech segments.
• Total speaking time before a decision.
• The number of apparent words or speech bursts.
• Whether a candidate beep or other special tone appears.
• Whether the analysis window expires without enough evidence.

For example, one short speech segment followed by sustained silence can support a human classification. A long greeting or several speech segments separated by short pauses can support a machine classification. The actual thresholds are deployment choices, not protocol constants.

This approach is fast and explainable, but its assumptions are fragile. A person may answer with a formal business greeting. A voicemail greeting may be only a recorded "Hi." A noisy line can divide one phrase into several segments, while aggressive silence suppression can merge or hide boundaries. Language and speaking style also change word and pause patterns.

Modern detectors combine independent signals

A stronger detector treats each observation as evidence rather than a decisive rule. Its input may include energy and spectral features from decoded audio, VAD speech boundaries, a streaming transcript, a tone detector, and call-signaling context. A statistical classifier or a hand-built scoring policy combines those inputs over time.

Transcript content can be useful when phrases such as "leave a message," "after the tone," or "is not available" appear. It cannot be the only signal. Transcription may lag behind the audio, a custom greeting may avoid familiar phrases, and the same words can occur in a human conversation. The system must also support languages and accents for which its phrase rules are incomplete.

Audio characteristics offer different evidence. A recorded greeting may have stable background noise or compression, but modern voicemail recordings can sound indistinguishable from live speech. Far-end noise, speakerphone acoustics, and network transcoding can make a human sound recorded. A classifier trained on one traffic source may therefore perform differently after a carrier, codec, or destination mix changes.

Good designs expose an unknown result. Forcing every ambiguous call into human or machine hides uncertainty and makes the downstream policy dangerous. An application can handle unknowns conservatively, collect examples, and improve the detector without pretending that every call is knowable.

Human detection and beep detection are different decisions

Voicemail detection is sometimes described as if the system merely listens for a beep. In practice, classification and message timing are separate problems.

The first decision asks, "Is this likely a machine greeting?" The second asks, "If it is a machine, when is it safe to play the recorded message?" A system can classify a long greeting as voicemail before the greeting ends, but playing immediately would talk over the instructions. Conversely, some systems do not use a conventional beep at all, or the tone can be distorted by the media path.

A beep detector looks for concentrated energy near one or more tone frequencies with sufficient duration and a plausible position in the greeting. It must reject DTMF digits, call-progress tones, notification sounds, and speech harmonics. There is no single universal voicemail tone profile, so a detector that recognizes only one frequency and duration will miss valid systems and trigger on unrelated sounds.

Silence after the greeting is another possible start signal. The controller may wait for a tone, a sufficiently long post-greeting pause, or whichever arrives first. It also needs a maximum wait so a missing beep does not hold the call indefinitely.

Only then can a voicemail drop begin. The outbound message should be ready to play without an avoidable generation delay. The media sender must start on the correct call leg, maintain packet timing, and confirm that the call is still connected. If playback begins late, the recording may start with dead air; if it begins early, the first words can be covered by the greeting or tone.

Synchronous and asynchronous detection trade speed for confidence

In synchronous AMD, the application waits for a classification before allowing its normal conversation flow to proceed. This protects a human from hearing an automated opening intended for voicemail, but the analysis delay can create an awkward pause after a real person says hello.

In asynchronous AMD, the application begins interacting while detection continues. A human gets a faster response, but the system may start its live-call greeting over a voicemail recording before reversing course. The response pipeline must be cancelable if the classification changes.

A hybrid can make an early human decision when evidence is strong, continue monitoring uncertain calls, and reserve slow machine confirmation for cases that need a message drop. This improves average responsiveness without pretending early decisions are risk-free. The exact balance depends on whether the application values immediate human engagement, accurate voicemail messages, or consistent campaign dispositions most.

The state machine after classification

Detection is useful only when the call controller has explicit transitions for its outcomes. A practical result set includes human, machine_start, machine_end_or_beep, fax_or_special_tone, silence, and unknown. The names are not standardized; what matters is keeping observations separate from actions.

For a likely human, the controller opens the live dialogue path. For a likely machine, it can hang up, continue monitoring for a recording point, or play a configured message. If the destination is an IVR, the correct action may be phone-menu navigation rather than voicemail handling. If it is a fax tone or network announcement, the call should end with a distinct disposition instead of being counted as voicemail.

The final call disposition should retain confidence and reason codes where possible. "Machine because long greeting plus beep" is more useful for debugging than a bare boolean. Store the event timeline and the relevant audio subject to the workflow's recording, notice, and retention requirements.

Why false classifications happen

AMD errors cluster around a few boundary cases:

• Long human greetings: receptionists and business users may state a company and department before pausing.
• Short custom voicemail greetings: a recording may contain one word and silence.
• Humans who keep talking: someone who answers and immediately speaks to another person can resemble a recorded greeting.
• Noise and echo: television audio, hold music, or a speakerphone can keep VAD active.
• Carrier announcements and IVRs: both can contain recorded speech and tones but require different handling.
• Clipped audio: if analysis starts late, the detector misses the greeting's first segment and measures the wrong cadence.
• Silence: a muted person and a silent machine provide nearly identical evidence until something else happens.

Threshold changes move errors rather than eliminating them. Making machine detection more aggressive catches more voicemail but risks sending a live person a recording. Making human detection more aggressive improves pickup responsiveness but can talk into greetings and leave truncated messages.

Testing and operating AMD

Test with actual destination types and the codecs, carriers, and languages the application will encounter. Include default and custom voicemail greetings, short and long human greetings, business switchboards, IVRs, fax tones, silence, background media, and calls that disconnect mid-greeting. Replayable audio fixtures help with deterministic regression tests, while live calls reveal signaling and media-start behavior fixtures cannot reproduce.

Measure more than classification accuracy. Track time to human decision, time to machine decision, message start relative to the beep or greeting end, truncated-message rate, false-human and false-machine outcomes, unknown rate, and calls that never reached a terminal state. Review errors by destination and call path before changing global thresholds.

Retry logic belongs outside the detector. A retry policy can decide whether a voicemail outcome should be attempted again, after what delay, and under which campaign limits. Keeping that policy separate prevents a low-level audio classifier from silently making business or compliance decisions.

On ThunderPhone, voicemail detection can let the agent prompt decide what to do, hang up, or leave a configured message. Campaigns can retry voicemail outcomes according to their retry policy. Those are workflow choices around the detector; they do not remove the need to handle uncertain classifications.

FAQ

Can SIP tell an application that voicemail answered?

Normally, no. A successful answer response indicates that the call was accepted, not whether a human or machine accepted it. The application generally has to infer the answer type from post-answer media.

Is a beep required for voicemail detection?

No. Greeting cadence and speech content can support a machine classification before any tone. A beep or a post-greeting pause is especially useful for deciding when to start leaving a message.

Why not wait longer for a perfect decision?

More audio can improve confidence, but a human experiences that wait as dead air. Calls can also disconnect before a late detector acts. AMD policies trade decision speed against classification and message-timing errors.

Should an uncertain answer be treated as a person or a machine?

That is a workflow decision. A safety-sensitive or high-value inbound flow may favor a human path; an outbound campaign may choose to end, retry, or use a neutral opening. Preserve unknown so the policy can decide explicitly.