Hacker News Reader

Comment by majos | Hacker News Reader

What's keeping major carriers from getting serious about these steps already?

My experience was that the major carriers had little economic incentive to invest in improving telephone service, which they viewed as a legacy line of business. They were focused on selling data plans, building their networks, and entering new markets (especially online services and advertising).

If they truly aren't interested in it, that'd be great, they could just stop, open up to become dumb data pipes and create a market of competitive third-party service for the telephony part.

Spam calls are actually a cash cow. Uses your minutes and Verizon also makes money selling a subscription spam blocking service that would be worthless without the annoying calls:

https://www.theverge.com/2017/6/30/15906800/verizon-anti-spa...

What percentage of US cell plans aren't unlimited minutes these days? I'm thinking it has to be a tiny amount.

Seems like they would like to unclog their Network not to mention their servers have to handle and store all the voicemails.

The receiving provider usually gets paid to terminate the call.

It may only be a fraction of a cent per minute, but these are the same telecoms that will gladly send you a bill every month because you owe them 1 cent.

In the past, cellular network operators earned revenue based off minutes sold. That's why voicemail has very verbose instructions that are read to you every single time. It's a way of inflating average call duration and thus revenue.

These days with unmetered calling, the receiving telco still makes some money off incoming calls through termination charges.

Are the telcos trying to kill the system outright then?

They indirectly make money from the fraud, so incentives are not aligned for them to stop it.

And there are insufficient dis-incentives. There are no competitors who offer a superior spam filtering solution and market it.

If carriers became financially liable for robocalls by a government mandated date, e.g. 2020, they would find a solution. Even if was as simple as not getting paid to carry spam traffic (as opposed to an EU level % of global revenue fine).

Another trivial solution would be to offer some sort of voice CAPTCHA for phones - get asked question and provide answer in order to connect. Someone on here posted awhile back that they implemented their own and said it completely eliminated robocalls.

I have done this. I have my own VoIP system. One of my DIDs picks up and is a recording of me saying "I'm screening my calls for telemarketers and scams. enter code 5300 any time to be connected to $myname". If 5300 is entered, it dials out to the DID for my cellphone and transfers the call. No code, or no action, call goes nowhere.

You can fairly easily make the code whatever you want or make it a multi step process.

If I remember correctly from the conversation I mentioned above: this is only implementable yourself with a VOIP solution and not an actual phone line?

As long as you have a programmable PBX with POTS support (e.g. Asterisk with a telephony expansion card [1]), you can do this with landlines too.

[1] https://www.asterisk.org/products/telephony-interface-cards

I really recommend against introducing analog anything into a modern VoIP system in 2018. Better to port your landline's DID to a VoIP service and route it from there. If you need a physical landline looking phone, good quality sip desk phones are $50 (assuming you don't care about huge color screens).

Definitely. End-to-end digital is best for fidelity and reliability. Running your own PBX is another point of failure for a service most people expect very high uptime out of, and opens you up to toll fraud. It's only worth it if you have a lot of phone or want call recording or transferring.

Did you find a way to do this that didn't require paying per-minute to (e.g.) Twilio for the call forwarding back to your cell phone?

I do pay per minute in 6 second increments but the price is so small to be barely noticeable.

Really? You end up having to pay per minute for the entire duration of every forwarded (non-spam) inbound phone call...

Yes, costs average less than $6 a month. Wholesale SIP termination and origination is remarkably cheap if you are dealing with the US48 states and Canada.

I believe I'm at something like 6/10ths of 1 cent per minute.

Yes, that's about right. It's just a matter of whether you're willing to pay $6/month for this. :)

$6 a month is more than a fair price for me to eliminate robocalls; I receive about 5-10 on average in any given day.

The collateral damage are systems that have you mark your place in line and call you back. It seems like these could be manually whitelisted though with some ingenuity.

DTMF based challenge is probably easier. Even requiring callers to dial 1 to ring through is enough to keep robocall campaigns from ringing your physical phone.

I've been thinking about issuing my friends and family priority access PINs. If they save it to their contact entry for me after the number, I can entirely gate access. e.g. "5558675309,9876" Especially if combined with a time condition e.g. 11 p.m. to 6 a.m.

SS7 is so broken that there's little telco could do even if they put effort into it.

Fixing ss7 at this point would be like polishing the brass doorknobs on the Titanic.

This is a good analogy unfortunately. SMS is the worst culprit there from my standpoint, given companies use it to send short term credentials (yes they do...) or for 2fa.

I either disagree or am ignorant about SS7. See my other post on this page. Interested to read others thoughts about implementing a "opt-in, call back only or GTFO system".

If I have full control of a DID, implementing callback isn't hard. That would be a bandaid type solution built on top of the existing phone network, however. Fixing ss7 at a systemic level so that all call routing in and outbound is verifiable, CID spoofing is impossible, is what is nigh impossible.

Are there any proposed replacements? Even SIP has vulnerabilities, foot gun features, and fundamental design problems like use of MD5 digest, NAT intolerance, and vendor and device specific bugs.

Reply on news.ycombinator.com