Call screening is answering your outbound calls before the person does

This is a newer failure mode than false answer supervision or the NOTSURE gray zone, and it behaves differently from both. A screening prompt is not a machine that owns the line and it is not a person who has joined the call. It is a third thing, and the two-bucket model that most dialplans still run has no place to put it.

What call screening is, and how it differs from spam blocking

Spam blocking decides whether your call reaches the handset. Call screening decides who answers it when it does. That distinction is the whole article, because only one of the two produces audio on your leg of the call.

A blocking product sits in the network or in the dialer app. It looks at the calling number, checks it against reputation data, and either drops the call, sends it to voicemail, or lets it through with a “Scam Likely” label attached. Your dialer never hears a prompt, because there is nothing to hear: you get a voicemail greeting, an unanswered call, or a fake answer. Those failure modes are covered in carrier false answers and Spam Likely caller ID reputation.

A screening assistant runs on the handset. It picks up the call for real, plays a synthesised prompt, listens for a reply and transcribes it for the owner in real time. From the network’s point of view the call is answered and audio is flowing. From your dialer’s point of view somebody is talking. From the owner’s point of view, nothing has happened yet.

Google Call Screen

Google’s Call Screen, in the Phone by Google app on Pixel devices, has the phone answer a call the owner did not pick up. Google’s documentation calls the answering component Call Assist; it asks who is calling and why, and the caller’s reply is transcribed on screen while it happens. Google documents the feature as running on-device, and the owner can then answer, ask a follow-up, or hang up. Depending on device and settings it can be invoked manually or run automatically on calls from unknown numbers. (Source: support.google.com/phoneapp/answer/9118387.)

For an outbound dialer, the important properties are that the call is genuinely answered, that the first audio is a machine, and that the machine expects a spoken answer. A predictive dialer that bridges an agent on answer puts that agent in front of an assistant. A dialer that runs timing-based AMD hangs up.

Apple iOS 26 Call Screening

Apple shipped Call Screening in iOS 26. It lives in the Phone settings under Screen Unknown Callers, with the options Never, Ask Reason for Calling and Silence. On Ask Reason for Calling, iOS answers calls from numbers not known to the user and asks for the caller’s name and reason; once the caller has given them, the iPhone rings and shows the owner that response so they can decide whether to pick up. (Source: Apple Support, “Screen and filter calls”.) Unlike Google’s, it does not hold a back-and-forth conversation with the caller — it collects the identifying information and hands the decision to the owner.

The practical consequence is the same as Google’s: your outbound call is answered by software that speaks first. The audio differs in wording and length, but the timing signature — silence, then a fluent scripted sentence, then a wait — is close enough that a threshold-based classifier treats both the same way.

What the carriers actually do (mostly, they do not speak)

Carrier products are routinely lumped in with handset screening and they should not be. The three large US carrier offerings label, block or reroute. None of them answers your call and speaks a prompt to you.

Only the first two rows create the problem this article is about. The bottom three cost you contacts, but they cost them in ways your existing reporting already sees as failed calls rather than as misclassified answers.

Why silence-based AMD calls a screening prompt a machine

Asterisk’s app_amd never hears words. It measures durations: how long the line stays silent after answer, how long the first continuous utterance lasts, how many separate utterances arrive, and how long it is willing to wait before giving up. Those thresholds are the whole classifier, and they are enumerated in the amd.conf cheat sheet.

Now consider what a screening assistant produces. Brief silence while the software answers. Then one continuous, fluent, several-second sentence with no hesitation and no pause for breath. Then silence, because it is waiting for the caller. Written as timings, that is indistinguishable from “Hi, you’ve reached Dave, leave a message after the tone.” A long single utterance following answer is the canonical machine signature. The classifier is not making a mistake by its own rules — the information needed to tell the two apart was never in the timings.

This is the same structural failure that a long “hellooo?” causes in reverse, and it is why we argue detection has to work from the character of the sound rather than from the shape of the silence around it, which is the subject of sound, not words. It also means the fix is not a threshold change. Loosening greeting to let screening prompts through reclassifies genuine voicemail greetings as human at the same time, a trade described in the narrow middle.

How much of your traffic is being screened right now

Over a trailing 30-day window of hourly greeting aggregates on the AMDY platform, out of 2,871,066,285 classified greetings:

Roughly one answered greeting in fifteen is a screening assistant. On a two-bucket dialplan every one of those is a MACHINE verdict and a hang-up, on a handset whose owner is sitting there reading a transcript of your call. That is a materially different loss from hanging up on a voicemail box: the person is present, attentive, and has just been given a reason to distrust the number. The wider measured distribution — human rate, machine rate, carrier false answers — is on the features page and in how often AMD is wrong.

SCREENINGAMD, and what a dialplan should do with it

AMDY returns SCREENINGAMD as its own classification, alongside RINGINGAMD, NUMBERSAMD, VMNOTSETUPAMD, SUBNOTAVAILAMD, TELAMD and THANKYOUAMD. The full classification list is in the API documentation.

Having the class is only half the work. The branch you attach to it is the other half, and there is no default that is right for everyone:

• Do not route it to MACHINE. The line is owned by a live person who is watching. Hanging up throws away the most reachable contact in the answered set.
• Do not bridge an agent immediately either. No person is on the line yet. The agent spends the prompt duration listening to software, and if enough of your traffic is screened, that is measurable occupancy loss.
• Play a short identifying message. The prompt is asking who is calling and why. Answering it truthfully is the behaviour the feature is designed for, and it puts your name and reason in front of the owner as text.
• Or hang up and schedule a callback, flagged as a screened number. You now know the record is a live, attentive owner on a modern handset, which is better information than most of your list carries.

Whichever branch you pick, the ViciDial campaign settings sitting on top of the AMD verdict still apply — amd_send_message decides what actually executes on the machine path, and drop_call_seconds caps how long a bridged call waits. Both are covered in the ViciDial AMD guide and in ViciDial AMD variables. The branch-choosing method is the same one used for the undecided bucket in what to do with NOTSURE.

How to measure screening on your own traffic

Platform-wide shares do not transfer. Screening exposure tracks handset mix, and handset mix tracks the demographics and geography of your list. A consumer list skewing toward newer iPhones and Pixels will see more of it than a B2B list dialling desk phones. Measure it before you act on it.

Write the returned classification into a CDR field, let it run for a full month, then count:

-- Run against your own dialer database, not ours.
-- Assumes the AMDY classification is written into CDR(userfield).
SELECT userfield                                       AS classification,
       COUNT(*)                                        AS calls,
       ROUND(100 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS pct
  FROM cdr
 WHERE calldate >= CURDATE() - INTERVAL 30 DAY
   AND userfield <> ''
 GROUP BY 1
 ORDER BY calls DESC;

If you are on stock app_amd, there is no screening class to count, so the measurement has to be manual: pull fifty recordings that came back MACHINE with a short greeting duration and listen to them. If a meaningful fraction are assistants asking who is calling, you have quantified the loss. The sampling procedure is written out in how to test your AMD accuracy.

What we could not verify

Several things people will reasonably ask about are not established well enough for us to assert, so we are naming them instead of guessing:

• Adoption rates and default settings. We have no reliable figure for what share of Pixel or iPhone owners have screening active, and we could not confirm from vendor documentation which setting either platform ships as the default. Neither vendor publishes enablement numbers.
• Which vendor produced which detection. Our greeting classes describe what the audio sounds like, not which product generated it. We cannot attribute the 170.3 million voice-screening greetings to Google specifically, and we do not.
• Whether answering the prompt improves connect rates. It is the behaviour the feature expects, and it is plausible. We have not run a controlled test, so treat the recommendation as reasoning rather than as a measured result.
• Carrier-side screening beyond the three products above. Regional carriers, MVNOs and third-party apps behave in ways we have not surveyed. The speak-versus-block split in the table covers the three large US carriers only.
• Trend direction. One 30-day window is a level, not a slope. We are not claiming screening is rising or falling until we have comparable windows to put beside it.

FAQ

What is call screening on a mobile phone?

Call screening is a feature where the handset itself answers an incoming call from an unknown number, plays a prompt asking who is calling and why, and shows the reply to the owner before the owner decides whether to pick up. Google Call Screen on Pixel and Apple Call Screening in iOS 26 both work this way. The person is present but has not joined the call, so the audio your dialer hears is a machine speaking on their behalf.

How much outbound traffic hits a screening assistant?

On the AMDY platform, screening-class greetings accounted for 194,230,690 of 2,871,066,285 classified greetings over a trailing 30-day window, or 6.77%. Google-style voice screening alone was 170,317,698 detections, 5.93% of classified greetings. These are platform-wide anonymised aggregates and your own share will differ with handset mix and list quality.

Why does legacy AMD label a screening prompt as a machine?

Asterisk app_amd decides from timing alone: how long the initial silence runs, how long the first continuous utterance runs, and how many words it contains. A screening assistant produces a fluent multi-second scripted sentence with no pause for a reply, which is exactly the timing signature of a voicemail greeting. Nothing in the timing distinguishes it from a machine, so the verdict comes back MACHINE and the call is hung up on someone who is standing there watching the transcript.

Do T-Mobile, Verizon and AT&T screen calls the same way?

No, and the difference matters. T-Mobile Scam Shield, Verizon Call Filter and AT&T ActiveArmor label, block or route calls without speaking a prompt to the caller. A blocked or voicemail-routed call produces no screening audio at all, so it shows up as a false answer, a voicemail greeting or an unanswered call rather than as screening. Only handset-side assistants that answer and speak create the audio that confuses AMD.

What should the dialplan do with SCREENINGAMD?

Treat it as its own branch, not as MACHINE and not as HUMAN. The owner is present, so hanging up wastes a reachable contact, but no person is on the line yet, so bridging an agent immediately burns agent seconds on a prompt. The workable options are a short identifying message that satisfies the screening prompt, or a scheduled callback on a record now known to belong to a live, attentive owner.

Detection figures are anonymized, aggregated platform-wide counts from hourly greeting aggregates over a trailing 30-day window (hourly buckets from 2026-07-26 21:00 to 2026-08-25 18:00 US Eastern Time); no individual account or phone number is identified. The denominator is every greeting detection recorded in that aggregate, catch-all classes included. Your own mix will vary by list, handset mix, carrier and campaign.