Carrier false answers (FAS): paying for connections that never happened

Look at your dialer’s answer rate and it probably feels healthy. Calls connect, the counter climbs, agents stay busy. But a large slice of those connections are a lie told by the network. The call shows as answered. Nobody answered it. This is the most under-measured leak in outbound dialing, and on the AMDY network it is bigger than the share of calls that reach an actual human.

What a carrier false answer actually is

A carrier false answer — the mechanism is called false answer supervision, or FAS — is when the network signals a call as answered or connected before, or instead of, a real party picking up. Your switch receives the equivalent of a “200 OK”: as far as your dialer knows, you are on a live call. In reality there is no human and no answering machine on the line. Just dead air, a tone, or a recorded network message.

FAS comes from a few distinct sources:

• SIT tones and intercept recordings. The Special Information Tone triple-beep followed by “the number you have dialed is not in service” is a connection that the carrier marks as answered, even though it’s a recording telling you the call failed.
• Fake answer supervision on VoIP / least-cost routes. Some intermediate carriers inject an early answer signal to start the billing clock sooner than a real answer would. The audio that follows is silence or filler; the supervision is fake on purpose.
• Certain carrier behaviors. Network congestion handling, gateway timeouts, and route hand-offs can all surface as “answered” with nothing on the far end.

The common thread: the connect signal and the actual call state disagree. Across the AMDY network — about 2.3 billion answered outbound calls a month — roughly 14% of answered calls are carrier false-answers. To put that next to everything else on the wire: about 12.5% are live humans and about 73% are answering machines. FAS is a larger share of your traffic than the humans you are actually trying to reach. We broke the full distribution down in the State of AMD 2026 report.

Why FAS costs you twice

A false answer is not a harmless no-op. It bills you on two separate axes.

1. The carrier may bill you for the connect

Once a call is marked answered, the meter starts. Depending on your route and contract, you can be charged per-minute or per-connect for a call that never reached a person. With fake answer supervision specifically, the early answer signal exists precisely to start that meter sooner. Multiply a per-connect charge by 14% of your dial volume and the line item is real money — money spent on connections that, by definition, never happened.

2. It poisons your floor and your stats

The second cost is operational, and it’s sneakier. A false answer that isn’t caught does one of two things:

• It lands on an agent as dead air. The dialer thinks it has a live connect, so it bridges the call. The agent says “hello,” hears nothing, waits, says it again, disposes the call, and moves on. Seconds of paid agent time, gone, repeated thousands of times a day.
• It inflates your answer rate. Every uncaught FAS counts as “answered,” so your connect rate reads higher than your real human-contact rate. Your numbers look better than reality — which is the worst possible failure mode, because it hides the problem instead of flagging it. You can’t fix a leak you’re measuring as a win.

That hidden-cost-of-a-good-looking-stat pattern is the same theme we cover in the real cost of “free” AMD: the most expensive problems are the ones your dashboard reports as fine.

Why stock Asterisk AMD can’t catch it

This is not a tuning problem. Stock Asterisk AMD — app_amd, configured in amd.conf — was designed to answer exactly one question: is the greeting on this call a human or a machine? It listens for a greeting, times the speech and silence, and sets AMDSTATUS to HUMAN, MACHINE, or NOTSURE.

A false answer breaks that model at the root, because there is no greeting to classify. There’s no human voice and no voicemail prompt — just silence, an intercept tone, or a recorded carrier message that doesn’t match either bucket. So FAS falls through into NOTSURE, or worse, gets mishandled as one of the two real categories. The engine was never given a third bucket for “connected, but nobody is there,” so it cannot put a call in one. No amd.conf setting fixes a category that doesn’t exist. We dig into the limits of that two-bucket design in the drawbacks of stock AMD.

How acoustic detection handles a false answer

AMDY doesn’t try to force a false answer into a human-or-machine choice. It listens to the acoustic signature of the answer audio — the actual sound on the line, not a transcript of words — and gives FAS its own bucket, right alongside human, voicemail, honeypot/spam-trap, fax, and silence. The decision lands in 1/8 of a second, before the call ever needs to bridge to an agent.

Once FAS is a first-class classification, three things become possible that stock AMD can’t do:

• Auto-disposition it. A FAS result is a clean signal your dialer can act on — hang up and recycle the lead instead of burning an agent on dead air.
• Stop routing dead air to the floor. Agents only get bridged on real connects, so paid talk time goes to actual conversations.
• Pull the evidence. Every FAS detection is timestamped and written to the per-detection log, so you have a record of exactly which billed-as-answered calls had nobody on them.

Because AMDY is a WebSocket gateway that’s telco-agnostic, none of this requires switching carriers — you keep your existing routes and add a classifier in front of them. The point isn’t to read the words on the call; it’s to recognize the sound of a connection with no one behind it. That sound-not-words approach is what makes the FAS bucket possible at all (more on that in sound, not words).

How to spot FAS in your own data

You don’t need to take the 14% figure on faith — the pattern shows up in your own CDRs once you know what to look for:

• Answered calls with near-zero talk time. A cluster of “answered” records that disposed in 1–3 seconds with no agent talk time is a classic FAS fingerprint.
• A gap between connect rate and human-contact rate. If your dialer reports a high answer rate but agents report a lot of dead-air “hellos,” the difference is where the false answers are hiding.
• Route- or carrier-specific spikes. Break the dead-air connects down by trunk or route. If one least-cost route is responsible for an outsized share, that’s your fake-answer-supervision source.

Detecting FAS cleans up both sides of the ledger at once. On the operations side, your reported connect rate finally matches reality, agents stop eating dead air, and you can compare routes honestly. On the cost side, you get a defensible list of calls your carrier billed as answered that no one answered — the raw material for a billing dispute or a route change. AMDY surfaces both views across its 23 analytics reports and the queryable per-detection log. For the full picture of where AMD fits in a Vicidial stack, start with the Vicidial AMD guide.

FAS rate by carrier (July 2026)

The 14% figure above is a network-wide headline number without a disclosed window. Here is a separate, dated snapshot: FAS rates broken out per carrier, measured against the amd_carrier_daily table on the AMDY analytics TimescaleDB for 1 July 2026 through 31 July 2026. Across that window the network saw 3,163,497,966 total detections, of which 398,886,342 were classified FAS, for a network-wide FAS rate of 12.61%. That is lower than the 14% figure elsewhere on this page, and the two aren’t really comparable: the 14% figure was published in June 2026, before this page adopted the dated, disclosed-window convention used below, so its exact measurement window isn’t recorded. A roughly one-point drop over the following month or so is consistent with a real, gradual decline in network-wide FAS rather than a methodology error, since this pull uses the same source table and aggregation as every other sourced figure on this page. We are showing both numbers rather than quietly overwriting the older one, and will keep dating each new snapshot going forward so the trend can be tracked honestly instead of asserted from two points.

The per-carrier breakdown below is data nobody outside AMDY can publish, because it requires a live detection pipeline with carrier attribution on every call. Rows are LERG operating-company-name (OCN) records, not consumer brand names, and every row here has more than 500,000 detections in the window. A few carriers appear more than once under different regional OCN registrations — “NEW CINGULAR WIRELESS PCS, LLC” (with state suffixes), “SOUTHWESTERN BELL,” and “BELLSOUTH TELECOMM INC DBA SOUTHERN BELL TEL & TEL” are all AT&T-family OCNs, and “CELLCO PARTNERSHIP DBA VERIZON WIRELESS” (with state suffixes) is Verizon. These are separate LERG registrations for the same carrier group in different regions, not different companies. Summed together, AT&T’s OCN registrations are the single largest carrier by volume in this table.

Spread is wide: SOUTHWESTERN BELL sits at 8.59% FAS while AERIAL COMMUNICATIONS, INC. sits at 16.63%, nearly double, on comparable volume. If your dial plan can route around the highest-FAS carriers on your traffic, that spread is the first place to look for a route-level fix rather than a classifier-level one.

Method and query

Network-wide total, unmodified query:

SELECT sum(count) total, sum(fas_count) fas,
       round(100.0*sum(fas_count)/nullif(sum(count),0),2) as fas_pct
  FROM amd_carrier_daily
 WHERE day >= '2026-07-01' AND day < '2026-08-01';

Per-carrier breakdown, unmodified query:

SELECT coalesce(company, ocn) as carrier, sum(count) total,
       sum(fas_count) fas,
       round(100.0*sum(fas_count)/nullif(sum(count),0),2) as fas_pct
  FROM amd_carrier_daily
 WHERE day >= '2026-07-01' AND day < '2026-08-01'
 GROUP BY coalesce(company, ocn)
HAVING sum(count) > 500000
 ORDER BY total DESC
 LIMIT 15;

FAQ

What is a carrier false answer (FAS)?

A carrier false answer is a call the network signals as answered or connected when no human and no machine actually picked up. The supervision signal lies: your dialer thinks it has a live connection, but on the other end there is dead air, an intercept tone, or a recorded network message. Across the AMDY network, about 14% of answered calls are carrier false-answers.

What is false answer supervision?

False answer supervision (FAS) is when a carrier or intermediate route sends the "answered" (connect / 200 OK) signal before — or instead of — a real party answering. It can come from SIT tones and intercept recordings, fake answer supervision injected on some VoIP and least-cost routes to start billing early, and certain carrier behaviors. The result is a connected call with nobody on it.

How common are false answers?

On the AMDY network, across roughly 2.3 billion answered outbound calls a month, about 14% are carrier false-answers — meaning roughly 1 in 7 of your "answered" calls were never answered by anyone. For comparison, only about 12.5% are live humans and about 73% are answering machines. FAS is a bigger slice of your traffic than live humans.

Why can't Vicidial's AMD detect FAS?

Stock Asterisk AMD (app_amd) was built to answer one question: is this greeting a human or a machine? It waits for audio it can score as HUMAN or MACHINE. A false answer has no greeting at all — just silence, a tone, or an intercept — so it has nothing to classify against. It collapses into NOTSURE or gets mishandled. There was never a third category for "connected but nobody is there."

Can I dispute carrier charges for false answers?

Often, yes — if you have the evidence. When AMDY classifies a call as FAS it timestamps it and logs the per-detection record, so you can pull every call your carrier billed as answered that had no real party on it and take that to your carrier or route provider. Whether a credit is owed depends on your contract and route, so pair the data with your own carrier agreement; this is operational guidance, not legal or billing advice.

False answer supervision and the other terms on this page are defined individually in the AMD glossary.