Answered Calls With No Audio: False Answer Supervision and One-Way Audio Explained

Your dialer says the call was answered. The recording is empty. The agent, if the call got that far, hears nothing and hangs up after a few seconds of "Hello? Hello?".

On outbound campaigns this is one of the most common faults and one of the least understood, because it does not look like a fault. The call has an answer time, a duration and a disposition. It is counted as a connect. It is billed. Only the audio is missing.

This guide explains the two main causes, false answer supervision and one-way audio, shows how to tell them apart, how to measure how much of your traffic is affected, and how different answering machine detection products report these calls. On trunks we have examined, between 5% and 15% of answered calls had no audio at all.

What "answered with no audio" means

A phone call has two separate parts. Signalling (SIP) sets the call up and says what state it is in: ringing, answered, ended. Media (RTP) carries the sound. They travel separately, often through different equipment.

A normal call goes like this:

1. Your dialer sends an INVITE.
2. The far end replies 180 Ringing, or 183 Session Progress with early media (ringback, or a network announcement).
3. The callee picks up. The far end sends 200 OK. Billing starts.
4. Audio flows in both directions.

A silent answered call is one where step 3 happens and step 4 does not, at least not in the direction you can hear. There are two very different reasons.

Cause 1: false answer supervision

False answer supervision, usually shortened to FAS, is when a carrier in the route signals "answered" although the called party has not picked up. Your dialer receives 200 OK while the phone is still ringing, or while the network is playing "the number you have dialled is not in service".

It happens for three reasons:

• Fraud. A carrier in the chain answers early to bill for time that should have been free. Ringing is not billable; an answered call is. On low-cost routes this is a known practice.
• Misconfigured gateways. Some gateways convert early media or a network announcement into an answer, with no bad intent.
• Voicemail and announcement platforms that answer the call in order to play a message, which is technically a real answer but not a person.

What you see on a FAS call:

• The call is "answered" very quickly, sometimes in under a second, faster than a person could pick up.
• The recording holds ringback tone, a carrier announcement, or silence.
• The call is short. Nobody is there, so the dialer or the agent ends it within seconds.
• You are billed for it.

Cause 2: one-way audio

One-way audio is a real answer by a real person, but the sound from their side never reaches you. They hear your agent. Your agent hears nothing.

The cause is almost always in how RTP is routed:

• NAT. Your Asterisk server is behind NAT and advertises a private address in SDP, or the far end sends media to an address your firewall does not forward.
• Firewall rules that allow SIP (port 5060) but not the RTP port range (10000 to 20000 by default in Asterisk).
• Direct media. Asterisk tries to hand the media path to the two endpoints directly and one of them cannot reach the other.
• A carrier media gateway fault, which you cannot fix but can prove.

What you see on a one-way audio call:

• Answer timing looks normal, several seconds after dialling.
• The recording has your side only, or pure digital silence on the callee leg.
• It often affects one carrier, one server, or one direction, and it comes and goes.

How to tell them apart

How to measure it on your own traffic

You do not need special tools to get a first number.

1. Count very short answered calls. In VICIdial, calls that were answered and lasted under six seconds are a rough proxy:

SELECT DATE(call_date) AS day,
       COUNT(*) AS answered,
       SUM(length_in_sec <= 6) AS very_short,
       ROUND(100 * SUM(length_in_sec <= 6) / COUNT(*), 1) AS pct
FROM vicidial_log
WHERE call_date >= NOW() - INTERVAL 7 DAY
  AND status NOT IN ('NA','B','AB','ADC','DC','NEW')
GROUP BY day;

A high share does not prove FAS on its own, since people do hang up quickly, but a route where the share is two or three times the others deserves a closer look.

2. Look at RTP on one bad call. On the Asterisk console, while a test call is up:

rtp set debug on

Packets marked "Sent" with none marked "Got" is one-way audio. On chan_sip, sip show channelstats shows received packet counts per call; on PJSIP, pjsip show channelstats does the same.

3. Listen to twenty recordings. Pull twenty calls your detector labelled as silence. If the callee leg is digital silence, that is no media. If you hear ringback or a network message after "answer", that is FAS.

4. Split the numbers by carrier and by destination prefix. FAS clusters on routes. One-way audio clusters on servers and network paths.

How to fix each one

One-way audio (your side):

• In sip.conf or the PJSIP transport, set the external address and local network correctly (externip / external_media_address and localnet / local_net).
• For chan_sip trunks: nat=force_rport,comedia and directmedia=no.
• For PJSIP endpoints: rtp_symmetric=yes, force_rport=yes, rewrite_contact=yes, direct_media=no.
• Open the RTP port range in the firewall and forward it if you are behind NAT. The range is in rtp.conf.
• Make sure no SIP ALG is active on the router. It rewrites SDP and causes exactly this.

False answer supervision (carrier side):

• Send the carrier evidence: call IDs, timestamps, dial-to-answer times, and the recordings. A carrier can trace a route when it has examples.
• Ask for a different route to the affected prefixes, or move that traffic to another carrier.
• Check whether your dialer treats 183 with early media as answer. It should not.
• Do not pay for it quietly. FAS calls are billed minutes, and most carriers credit them when shown the data.

Why this matters more than the minutes

The billed seconds are the small cost. The larger ones:

• Agent time. If your detector passes a silent call as human, an agent spends ten seconds on nothing, hundreds of times a day.
• Wrong tuning. If your detector labels silent calls as "machine", they hide inside your voicemail count. Managers see a high machine rate, tighten the AMD settings, and start dropping real people. The problem was the trunk.
• Wasted leads. A lead whose call had no audio was never actually reached. Marked as "answering machine", it may wait days for a retry or be retired.
• Caller ID reputation. Calls answered and dropped within seconds look like robocalls to carrier analytics.

The first step is therefore not a fix. It is a separate count: how many answered calls had no audio at all?

How AMD products report a silent call

No detector can classify audio that does not exist. What differs is whether the product tells you that is what happened. This table is drawn from each vendor's public documentation as of October 2026; check their sites for current details.

Two notes on that table. A gateway product such as Khomp is in a good position for FAS, because it sees both the signalling and the audio before the call reaches your dialer. And a detector that classifies by sound, such as AMDY, can label ringback after answer as a tone; so can VM Hunter's tone detector. Whichever you use, ask the same question: can I get a count of answered calls with no media, by carrier, without listening to recordings?

How VM Hunter handles it

VM Hunter measures the audio on every call before anything else. If the stream opens and no audio arrives, or what arrives is digital silence, the call is decided from the audio alone and logged with the reason NO_AUDIO. If there is line noise but nothing at speech level, the reason is NO_SPEECH. Both return MACHINE / INITIALSILENCE to the dialer, so your dialplan does not change.

In the portal, the call-health figure shows the share of calls with no audio, and you can filter the call logs by it and export the list for your carrier. An optional email alert tells you when a dialer starts sending no audio, which is usually a trunk or NAT change.

On one customer's traffic, 15% of calls arrived with no audio. Nothing in their dialer reports showed it; the calls were counted as answering machines.

A checklist

1. Count answered calls under six seconds, by carrier and prefix.
2. Listen to twenty "silence" recordings.
3. Run an RTP debug on one bad call.
4. If no packets arrive from the far end: check NAT, firewall, direct media and SIP ALG.
5. If you hear ringback or an announcement after answer: collect examples and open a ticket with the carrier.
6. Make sure your AMD reports no-audio calls separately, so the number stays visible.
7. Recycle those leads as "not reached", not as "answering machine".

If you want the no-audio share for your own traffic without listening to recordings, VM Hunter's free plan covers 5,000 calls a month, which is enough for a day on one campaign. Setup for VICIdial is in the VICIdial guide, and the other AMD options are compared on the comparison page.