Is a link to a web based manual page really useful and noteworthy?
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!
Allow lists are still great for "secure lines" where the number isn't given out, where only "paired" devices should be able to reach the line. (Coincidentally, phones given to children also fit this description.)
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!)
Apple and co offer Siri which is way more complicated than an IVR which is just recordings. The whole point of what I suggest with an IVR is so simple and so easy to understand and I know it works because I have deployed this across many, many customers and my own gear for roughly 15 odd years. I run quite a few Freepbx setups.
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.
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 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.)
This is great and all but it's been my experience lately that spammers have moved on to text messaging. Does anyone have a reliable method to blocking unwanted texts?
6 comments
[ 3.7 ms ] story [ 28.0 ms ] threadI 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.)