FreeSWITCH Answering Machine Detection: Setup and Testing Guide

An outbound call is answered, FreeSWITCH marks the channel as connected, and your dialer has only a few seconds to decide what answered. Send voicemail to an agent and you waste agent capacity. Classify a person as a machine and you discard a live contact.

FreeSWITCH answering machine detection solves this by analyzing post-answer audio before the call reaches its final route. Amdy can provide that classification through its FreeSWITCH integration, while FreeSWITCH remains responsible for call control.

Quick answer: how to set up FreeSWITCH answering machine detection

Use this workflow:

1. Capture audio from the outbound leg immediately after confirmed answer.
2. Choose between local heuristic detection and an external AI detector.
3. Install and authenticate the detector without changing your existing carrier path.
4. Start detection at the correct point in the FreeSWITCH dialplan.
5. Stream enough post-answer audio to reach a decision within a fixed time budget.
6. Route human, machine, and unknown results separately.
7. Log the classification, reason, timing, UUID, and final call outcome.
8. Test against labeled campaign recordings before changing production traffic.

The worked example throughout this guide uses an outbound renewal campaign. Calls enter FreeSWITCH through extension 7001. Humans transfer to agent queue 6100, machines transfer to voicemail workflow 6200, and uncertain calls go to 6100 rather than being discarded.

Capture the right audio for FreeSWITCH answering machine detection

An AMD system needs the audio from the called party, not the agent leg, a mixed conference, or a recording that starts several seconds after answer. This sounds obvious, but incorrect media placement causes many production failures.

FreeSWITCH creates and controls separate channel legs. In a typical outbound call, the A-leg belongs to the dialer or agent side and the B-leg is the customer-facing carrier leg. Detection normally belongs on the B-leg because that is where the greeting arrives.

Start collecting audio when the B-leg is genuinely answered and media is available. A SIP 200 OK establishes the answered dialog, but carrier behavior can complicate the practical timing. Some carriers supply announcements or ringback as early media before final answer. The rules for provisional and final SIP responses are defined in RFC 3261, but a compliant signaling sequence does not guarantee that the audio represents a person or voicemail greeting.

Inspect both signaling and RTP when validating placement. If the detector hears ringback, a carrier announcement, or silence inserted by the upstream network, threshold tuning will not fix the underlying problem.

For extension 7001, the media source should be the called party channel created by the outbound originate operation. The detector begins when that channel answers. It should not wait until after transfer to queue 6100, because the opening greeting may already be over by then.

Preserve the first audio frames. Greetings often begin immediately, and losing the opening syllable can turn a short human response such as “Hello?” into silence followed by background noise.

Choose a FreeSWITCH answering machine detection method

There are two broad ways to classify calls from FreeSWITCH. A local heuristic detector measures timing patterns such as initial silence, speech duration, word-like segments, and pauses. An external AI detector receives live audio and returns a classification based on a broader audio model.

Neither option removes the need for routing logic or testing. They differ in operational burden and how well they handle varied greetings.

Beep detection and answering machine detection are related, but they are not interchangeable. A beep detector may tell you when to play a prerecorded message. It usually cannot protect a live person from being treated as voicemail during the first seconds of a call. The distinction is covered further in this guide to voicemail detection versus AMD.

For the renewal campaign, use AI classification for the initial human, machine, or unknown decision. If a machine is detected and the campaign permits a voicemail drop, use separate beep or end-of-greeting logic before playing the message.

Install the detector for FreeSWITCH without rebuilding the dialer

Keep the integration boundary narrow. FreeSWITCH should continue originating calls, managing channels, transferring calls, and reporting hangups. The detector should receive the audio and return a decision that FreeSWITCH can use.

For Amdy, begin with the current FreeSWITCH installation instructions. Use the documented package, connection, and authentication procedure rather than copying old commands from a forum post. Deployment details can change while the call-flow principles remain the same.

Before enabling campaign traffic, verify four conditions in a controlled environment:

• FreeSWITCH can reach the detection service over the required network path.
• Credentials are stored outside public dialplan files and log output.
• The called-party audio format is accepted by the detector.
• A timeout produces a defined route instead of leaving the channel waiting.
• Reconnects do not start duplicate detection sessions for the same UUID.
• Detection stops when the call transfers or hangs up.

If the deployment uses a custom media application, follow the streaming API documentation. WebSocket behavior, including opening handshakes and connection closure, is standardized in RFC 6455. Your implementation still needs application-level rules for call identity, audio ordering, timeout handling, and duplicate responses.

Do not place API secrets directly in XML committed to a repository. Load them from an appropriate protected configuration source and restrict access to the FreeSWITCH service account.

Put FreeSWITCH answering machine detection at the correct dialplan point

Detection belongs after confirmed answer but before the irreversible routing decision. Starting earlier can classify carrier audio. Starting later creates dead air and may miss the greeting.

The logical dialplan for the worked example looks like this:

``text outbound call answers -> attach call UUID and campaign ID -> start called-party audio detection -> wait within the configured decision budget -> HUMAN: transfer to queue 6100 -> MACHINE: transfer to voicemail workflow 6200 -> UNKNOWN or ERROR: transfer to queue 6100 ``

Treat this as a call-state design, not XML to paste into production. The exact FreeSWITCH applications and variables depend on whether you use the packaged integration or build against the API. The FreeSWITCH integration reference should be the source for supported commands and current configuration.

Attach the FreeSWITCH UUID to the detection request and retain it in every log entry. Also include a campaign identifier. Two campaigns can use the same dialplan while needing different reporting, fallback rules, and acceptable decision times.

Avoid running two AMD processes on the same audio unless you are conducting a controlled comparison. Competing processes can extend the delay, produce conflicting channel variables, or trigger two transfers. If you compare detectors, fork the audio deliberately and nominate one result as authoritative.

In extension 7001, the authoritative result controls the transfer. The comparison result, if present during a test, is written to logs only.

Set an AMD decision budget without clipping live answers

Every detector balances decision speed against available evidence. A longer observation window may capture enough greeting structure to separate a person from voicemail, but it also makes a human wait longer. A very short window reduces delay while increasing ambiguous decisions.

Use a maximum decision budget rather than an open-ended wait. It needs to cover processing and network time, not just audio duration. When the budget expires, FreeSWITCH must move to a known fallback route.

For the renewal campaign, uncertain calls go to queue 6100. That choice protects live contacts. Another operation may choose a separate verification route, but hanging up on unknown results is usually the riskiest default because the lost people are difficult to see in top-line dialer reports.

Do not hide detection time with fake ringback after the called party has answered. The person may be saying hello while hearing nothing in return, which creates dead air and repeat greetings. That experience contributes to hangups even when the final classification is technically correct. The practical symptoms and fixes are explained in the guide to reducing dead air in outbound call centers.

Track decision latency from the moment usable called-party audio reaches the detector. SIP answer time alone is not precise enough when RTP arrives late or the carrier changes its media source.

Route human, machine, and unknown results separately

A binary result looks simpler, but it conceals uncertainty. Production routing should support at least human, machine, unknown, timeout, and technical error states, even if several states share the same fallback destination.

For the example campaign, HUMAN transfers to queue 6100. MACHINE enters workflow 6200, where the system may wait for a recording tone and perform an approved voicemail action. UNKNOWN, timeout, and detector error also transfer to 6100 while creating distinct log events.

Keep classification separate from the business action. “Machine” describes the audio decision. It does not automatically authorize playing a message, leaving prerecorded content, or calling again. Campaign consent, calling hours, internal policy, and applicable law still govern the action.

Predictive dialer operators should also consider abandonment obligations. The US rule includes requirements related to abandoned outbound telemarketing calls and recorded messages in 47 CFR § 64.1200. Have qualified counsel determine how the rule applies to your campaign and system behavior.

Map machine subtypes only when they change routing. Creating many labels that all reach 6200 adds reporting complexity without operational value. By contrast, keeping timeout separate from a confident machine result is useful because a rise in timeouts can reveal connectivity or capacity trouble.

Log and test FreeSWITCH answering machine detection

AMD accuracy cannot be established from provider labels alone. Compare the automated decision with a reviewed ground truth for audio captured under your own carriers, destinations, campaigns, and calling periods.

Log the FreeSWITCH UUID, campaign, carrier or trunk, answer timestamp, detection start timestamp, response timestamp, raw detector result, normalized route, final disposition, and failure reason. If policy permits recording for quality review, store a controlled reference to the reviewed audio rather than placing sensitive recording locations in broad-access logs.

Build a labeled validation set before directing all traffic through the new route. Include short hellos, long business greetings, bilingual greetings, background television, interactive voice response systems, voicemail greetings with immediate speech, silence after answer, and carrier announcements. Do not fill the set only with easy examples.

For extension 7001, export a review batch from the same renewal campaign. Have reviewers label what actually answered without seeing the detector result first. Blind review reduces the tendency to agree with the machine-generated label.

Measure errors by direction:

• A false machine is a live person routed away from an agent.
• A false human is voicemail or an automated system sent to an agent.
• An unknown is a call where the detector withheld a confident decision.
• A timeout is a call where the result arrived outside the routing budget.
• A routing mismatch is a correct classification followed by the wrong FreeSWITCH action.

These categories have different operational costs. A single “accuracy” percentage can hide a serious false-machine problem behind a large number of correctly identified voicemail calls. Use the process in How to Measure Answering Machine Detection Accuracy to construct the review and confusion matrix.

Run the integration in shadow mode first if your call flow allows it. Record the result while the existing route remains authoritative. Once labels and timestamps are reliable, move a controlled portion of traffic to active routing and compare dispositions by campaign and trunk.

Tune FreeSWITCH AMD using campaign evidence

Threshold tuning should answer a specific observed error. Do not change several timing values because the overall contact rate moved on one shift.

Suppose the renewal campaign review finds that people saying “Hello, this is Maria” are routed as machines. Listen to those calls alongside correctly identified voicemail greetings. Determine whether the current detector treats uninterrupted speech duration as excessive, whether the beginning of speech was clipped, or whether an upstream announcement contaminated the audio.

Only the first issue points directly to a speech-duration threshold. Clipped audio requires media-path correction. Carrier announcements require trunk investigation or routing changes. Threshold changes applied to the wrong cause usually trade one error type for another.

If you use timing-based AMD derived from Asterisk-style parameters, document every value and its intended effect. The detailed Asterisk AMD configuration guide explains how initial silence, greeting length, after-greeting silence, word length, and total analysis time interact. FreeSWITCH implementations may expose different controls, so do not assume parameter names or defaults transfer directly.

Change one decision rule at a time. Re-run the same labeled set, then test a fresh batch to check whether the apparent improvement survives new audio. Preserve the previous configuration so rollback takes minutes rather than a maintenance window.

Campaign-specific tuning can improve a narrow workload, but it increases maintenance. A setting that works for residential renewals may perform poorly against business switchboards. Separate profiles only when the routing system can reliably select the right profile and your team can keep each one tested.

How Amdy handles FreeSWITCH answering machine detection

A manual build requires you to maintain the audio connection, decision service, result normalization, error handling, and testing process. Amdy removes the detector-building portion while leaving FreeSWITCH in control of the call.

The sequence begins with the Amdy FreeSWITCH install guide. Configure the supported connection and credentials, then associate the detector with the outbound path where called-party audio becomes available.

When extension 7001 produces an answered outbound leg, FreeSWITCH sends the relevant live audio through the configured integration. Amdy analyzes the audio and returns the detection result. Your FreeSWITCH routing maps that result to queue 6100, voicemail workflow 6200, or the unknown fallback.

For a custom application, use the API quickstart and the published API reference rather than creating an undocumented message format. The dialer should retain its own call UUID, enforce its timeout, and reject a late response after the call has moved to another state.

Amdy does not remove the need to label calls. It changes what your team maintains. Instead of tuning a growing collection of silence and speech thresholds, the team focuses on correct audio placement, result routing, latency, and campaign-level validation.

Keep the fallback under your control. If the connection fails during the worked example, FreeSWITCH should send the call to 6100 and log a detector error. It should not wait indefinitely, assume voicemail, or terminate a potentially live call.

Review current capabilities in Amdy features and check the pricing page when estimating production usage. Include engineering time, review labor, lost live contacts, agent voicemail exposure, and operational support in the comparison. A detector with no software fee can still be expensive when staff repeatedly tune it or cannot identify false-machine calls.

Common FreeSWITCH answering machine detection mistakes

The first common mistake is analyzing the wrong leg. The detector receives the dialer, agent, or mixed audio and appears inconsistent because it is not hearing the called party cleanly.

The second is treating every answer event as usable media. Verify when RTP begins and what it contains. False answer supervision, early media, and carrier announcements can all create misleading input. This guide to SIP trunk false answer supervision shows why signaling and audio must be examined together.

The third is routing unknown as machine. That makes uncertain live answers disappear from agent reports. Preserve unknown as a first-class result, even if it currently shares the human route.

The fourth is using beep detection as the initial classifier. Waiting for a beep can hold a live call too long, while acting before the beep can start a voicemail message over the greeting.

The fifth is evaluating only agent dispositions. Agents can identify voicemail sent to them, but they cannot label people incorrectly removed before connection. Sample audio from all routes, especially confident machine results.

The sixth is retrying a failed streaming session without checking call state. A reconnect after transfer can attach detection to the wrong media or return a stale result. Bind each session to the UUID and close it when the authoritative route changes.

The final mistake is optimizing for the smallest latency number. A fast wrong classification is not an operational improvement. Set a usable budget, then measure both delay and error direction.

How to decide between local FreeSWITCH AMD and an AI service

Use local heuristic detection when the call population is narrow, the greeting patterns are stable, and someone owns ongoing tuning. It can also suit environments where audio must remain within a controlled network and external processing is not approved.

Use an AI service when campaigns vary substantially or manual threshold maintenance is already consuming engineering time. It is also a practical choice when false-machine errors are difficult to diagnose with timing values alone.

Run both in shadow mode if the choice is unclear. Send them the same called-party audio, preserve their independent timing, and compare each result with blinded human labels. Do not compare vendors using different days, trunks, or campaign mixes.

Review the broader comparison of FreeSWITCH, Asterisk, and AI AMD when the decision includes platform architecture as well as detection quality.

FreeSWITCH answering machine detection FAQ

Does FreeSWITCH have built-in answering machine detection?

FreeSWITCH can support AMD workflows through modules, dialplan logic, media applications, and external services. The exact local capability depends on the build and modules installed. Confirm what your distribution actually contains instead of assuming an online example matches your server.

Beep detection alone should not be described as complete human-versus-machine classification. It serves a narrower purpose.

Where should AMD run in a FreeSWITCH dialplan?

Run it on the called-party leg after confirmed answer and as soon as usable post-answer audio is available. Complete the classification before bridging or transferring to the final agent route, then stop detection once the route changes.

What should happen when FreeSWITCH AMD returns unknown?

Route unknown calls according to the business cost of each error. For most agent-assisted outbound campaigns, sending unknown calls to an agent or a separate verification path is safer than treating them as voicemail. Log unknown separately so it can be reviewed.

Can I use the same AMD settings for every campaign?

You can start with one profile, but do not assume it will perform equally across residential calls, business numbers, languages, carriers, and regions. Validate each material campaign mix. Create separate profiles only when the evidence supports them and operations can maintain them.

How do I reduce false machine detections in FreeSWITCH?

Check media placement and clipping first. Then review false-machine recordings for shared patterns such as long introductions, background speech, or pauses. Adjust only the rule connected to the observed failure and retest against both old and new labeled calls.

How many calls should I test before production?

There is no universal number that makes a test representative. Include enough reviewed calls to cover the greetings, trunks, regions, time periods, and edge cases your campaign actually produces. Continue sampling after launch because carrier behavior and campaign mix change.

Can FreeSWITCH AMD work with VICIdial?

Yes, when FreeSWITCH or another SIP component is part of the call path and the dialer can consume or act on the classification. If the deployment is centered on VICIdial and Asterisk, use the dedicated VICIdial AMD guide and VICIdial integration documentation instead of forcing a FreeSWITCH-specific design onto it.

Is an external AMD API too slow for predictive dialing?

It can be if the media path, network connection, or timeout handling is poorly designed. Measure from first usable audio to accepted decision. Keep connections efficient, place infrastructure appropriately, and define a fallback that FreeSWITCH executes when the response exceeds the budget.

Put the FreeSWITCH AMD workflow into production safely

Begin with one campaign and one clearly identified outbound path. Confirm the detector receives the B-leg audio, preserve the UUID across every event, and route unknown or failed detections safely.

Export and label real calls before changing production routing. Then activate AMD for a controlled traffic segment, watch false-machine cases and decision latency, and retain an immediate rollback path.

If local thresholds are stable and the maintenance burden is acceptable, keep the design simple. If greetings vary, false positives persist, or tuning has become a recurring engineering task, connect FreeSWITCH to Amdy and keep the routing policy in your dialplan.