Detect and block spam phone calls
support.apple.com
support.apple.com
I don't silence unknown callers on my home land line - I put up a very simple IVR.
Interactive Voice Response, an IVR is a set of prerecorded voice prompts linked to a set of key presses which might perform actions, you'll know what I mean by the following:
"Please press 1 if you think we would like to talk with you; 2 to leave a voicemail; If you are making an unsolicited sales call then please hang up."
I chose the words quite carefully to be quick and get the message across. The initial please is to give you an extra tiny amount of time to understand what is going on as well as being polite.
We don't get much voice spam on our landline. To be honest - none that I can remember. Landlines are less of a target these days I think. Ours basically screws with auto diallers which seem to be the bulk of spam callers, that try to detect a person answering and hand off to an agent.
If I can manage that on my own landline surely a trillion dollar company can manage something far fancier for their customers.
"Turn on Silence Unknown Callers" is a bit rubbish - it's only an allow list. I do that too and deny lists but the IVR is the real filter.
An allow list (which would have been called a whitelist) is soooooo 1990s!
For everything else, the call-screening apps do work. Most of them have e.g. a "no neighbour prefix" filter, to block all calls that (are faked to) come from your own phone number's same area code + first 5 digits.
An IVR isn't something Apple (or any cellular equipment manufacturer) can really offer. For it to work right with sending-to-voicemail etc, it'd need to be something that happens before the call reaches the handset, rather than something the handset itself does. In other words, it'd need to be a feature of a cellular phone plan. But cellular providers have absolutely no incentive to innovate in this space. (I'm still surprised they ever bothered to support visual voicemail — and even now, many of them still charge extra for that!)
I also run SMTP for several sites, despite the HN concorde against self hosting email.
Silly me!
Apple can do pre call selection, just as a competent SMTP filter does the same - ask for DATA, scan it and then either accept or drop. Naiive filters accept DATA unconditionally and then scan it. As far as the sender is concerned - you have accepted it and that scores the ad. spend.
VoIP works just like say SMTP - allow/deny lists first and then do some analysis up the stack and then allow or deny data.
Anyway, compared to a Siri session, SMTP filtering is trivial from a cpu perspective. A simple IVR is trivial compared to a full on inbound telephony session analysis.
Certainly, you can simulate a call-screening IVR on-device; but an on-handset voicemail mailbox isn't your cell provider's voicemail (and so you can't e.g. dial into it off-handset with your voicemail PIN); any https://en.wikipedia.org/wiki/Special_information_tone s your handset generates are going to be recognizable [by being preceding by ringer wait tone] as post-off-hook user-equipment-generated signals (thus modern, smart live-number-scanner robodialers marking your number as "does exist, just pretends not to") rather than infrastructure-level error tones (where indexers would accept that the number really isn't registered), etc.
Compare/contrast to having a business-line PBX IVR that forwards to your cellphone. Since the PBX has a low-latency connection to its carrier and picks up instantaneously, and then analyzes the call before doing any routing/"dialing", it can choose to drop a call before the caller ever receives any ring-wait tone, such that it look to the caller like the call was unroutable at the carrier level. (Google Voice is essentially this kind of thing.)
Analogy to web tech stuff: your handset is like a machine running an HTTP server. The HTTP server can send an error code, or at most hang up the TCP connection without a response, but then Shodan et al will still find out that your IP has an open HTTP port. Your handset also can't enforce anything like a layer-3 firewall, because the PSTN in front of it is acting like a layer-7 load balancer, and has already accepted the request packet on your handset's behalf. To get the effect of "closing the HTTP port", you have to get the carrier call-routing infrastructure ('L7 load-balancer') to refuse the call itself.
Apple can only be in the right place in the PSTN call chain to do this, if Apple MITMs your calls as a virtual cellular carrier, like Google Voice does — giving you a different number than the one your actual cellular carrier gave you. And the actual cellular carriers would never allow Apple to do this, as having fully half their devices using something like Google Voice would heavily commoditize their services (and potentially allow Apple an 'in' to building an actual competing cellular network with millions of pre-signed customers.)