3 ms·

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 e

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.

derefr 4y ago
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.)

derefr 4y ago

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.)