I didn't mean that IVR is complicated, I meant that a handset is not in the right place in a PSTN circuit to be able to reject a call, send a call to (cell-prov

I didn't mean that IVR is complicated, I meant that a handset is not in the right place in a PSTN circuit to be able to reject a call, send a call to (cell-provider) voicemail, etc. By the time a handset receives a call, the call is already "routed" as far as the cellular ISP is concerned (like being connected to an extension in a PBX); and there's no in-line or out-of-band control signal that the handset can send to change that routing. 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 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.)