Two iPhone features now decide, on the recipient's device, whether your outbound call ever reaches a person: Apple's call screening answers unknown callers with an on-device screening agent, and Live Voicemail plays the voicemail greeting and transcribes the message on the lock screen while the phone never rings. Both answer the call — and both are machine-side outcomes for an outbound campaign. This post explains what the features do at the behavior layer, what they do to your answer-rate and human-contact metrics, and how Devotel Orbit's answering machine detection (AMD) verdicts let you branch on each of them instead of dropping to a binary answered-or-not reading.
What iOS 26 screening and Live Voicemail actually do
Both features intercept the call on the recipient's device, before a person chooses to talk. The carrier leg completes either way, so from the network's vantage the call is answered; the difference is who answered it.
Call screening routes a call from a number not in the recipient's contacts to an on-device screening agent. The agent answers immediately, asks the caller for a name and a reason for the call, and presents the live transcript to the recipient, who can then pick up. For an outbound dialer or an AI voice agent, the far end that answered is Apple's agent — a polite automated gatekeeper, not a person.
Live Voicemail handles the call that screening declines or never intercepts. When the call reaches the recipient's voicemail, the greeting plays and the message transcribes live on the lock screen, and the recipient can choose to intercept mid-message. The calling side hears a greeting and a prompt to speak; no human ever heard the phone ring.
The two features compose into a default-off funnel for unknown numbers: screening first, Live Voicemail as the fallback, and neither one delivers a ring to a person unless the recipient explicitly accepts.
What changes in your answer metrics
If your reporting counts "answered" as a human contact, screening and Live Voicemail inflate it. The network reports the call as answered, a classical listen-and-guess classifier may even read the screening agent's prompt as a live voice, and your dashboards register a contact that never had a person on it. As the feature rollout grows across iPhone users, that inflation grows with it.
The correction is definitional, not directional: treat a human contact as a call whose AMD verdict came back human, and treat screened and voicemail-intercepted answers as their own outcomes. Segment your answer-rate reporting by verdict and re-baseline it by carrier and region, because feature adoption varies by both. Teams that keep a binary answered/not-answered reading will watch their screen climb while their conversations fall, and will misread every downstream metric — cost per contact, agent occupancy, conversion per dial — on the same broken definition.
Branch on the AMD verdicts, not binary answered-or-not
Devotel Orbit's AMD layer classifies the first seconds of an answered outbound call and returns one of eight verdicts. Two of them exist precisely for these Apple behaviors: ios_call_screening, which fires when Apple's screening agent answered, and ios_live_voicemail, which fires when the call landed in a Live Voicemail box. The full taxonomy, and why no_answer and silence deliberately sit on the continue side, is covered in the answering-machine-detection explainer.
You opt in per call with amd: true on POST /api/v1/voice/calls. A machine-side verdict — including the two Apple ones — fires the `call.hit_voicemail` webhook event with the specific amd_type before the hangup events, so your campaign learns the exact outcome instead of inferring it. Branch on that field:
if (event.type === "call.hit_voicemail") {
const kind = event.amd_type;
if (kind === "ios_call_screening") {
// your policy: drop, retry later, or leave a message
}
if (kind === "ios_live_voicemail") {
// your policy — not necessarily the same one
}
}The point of the two distinct verdicts is that screening and voicemail are different situations: a screened call reached an active gatekeeper who may still pick up, while a Live Voicemail call sits in a box. A retry window, a message-leaving policy, or a no-recontact rule can differ between them — but only if your pipeline carries the distinction instead of collapsing it into "machine."
Tenant-owned posture: drop, leave a message, or retry
Neither this post nor the platform decides what you do with a screened or voicemail-intercepted call. Devotel Orbit gives you the classification (amd: true per call, an eight-verdict taxonomy, a verdict-specific webhook event) and the branch point; the policy — drop the call, leave a message, or schedule a retry — is your tenant's configuration decision under your own legal guidance, the same posture split the AMD explainer states for machine verdicts generally. Record that decision in your dialing policy and your dispositions, so an auditor can read why a given number was handled a given way.
One rule that does not vary by policy: never re-engage a screened or voicemail-intercepted number in the same dialing pass. Whatever posture you pick, apply it through your retry scheduling and your suppression lists, not through an immediate redial.
Buyer checklist
When you evaluate a platform for outbound voice against these Apple behaviors, ask for five things:
- Screening and Live Voicemail named as distinct verdicts — a generic "machine" verdict cannot drive different policies for the two cases.
- The verdict delivered in a webhook event before the hangup — so the branch happens in your handler, not after the fact.
- Per-verdict disposition recording — dialer dispositions that tag screening and voicemail separately keep your retry and reporting honest.
- Answer-rate reporting segmented by verdict — human contacts measured against
human, not against network answer. - A retry and suppression surface you control — AI-agent outbound flows branch on the same event; whatever your counsel approves, the control must be tenant-set, not platform-mandated.
Frequently asked questions
Does AMD work on SIP trunks? AMD runs on the outbound leg of calls placed through the voice API, over the Devotel softswitch, the same path the AMD explainer documents. A trunked call carrying the detection marker classifies the same way.
What exactly does the webhook carry? call.hit_voicemail fires before the hangup events with the specific amd_type verdict and a detection timestamp, so the branch happens in your handler instead of at call end.