Turns out Spectrum now blocks TCP/UDP port 5060. My workaround is to use a VPN. After that, everything is fine.
This reddit thread https://www.reddit.com/r/networking/comments/t8nulq/spectrum_is_rate_limiting_voipsip_traffic_port/ suggests Spectrum was rate limiting 5060 on 300mbps plans, but not on the 100mbps plans.
I have the 100mbps plan, and it is definitely affected now.
So if you are in SoCal, using Spectrum, and your VOIP phones suddenly stopped working in the last week or so, maybe this will help you.
Port 5060 is used for call control and is very low traffic. At most you may have timed OPTIONS messages but a “standard” SIP deployment is at most a handful of (small) packets per second per call setup and tear down with occasional REGISTER messages on an interval measured in seconds. Very low traffic and very low bandwidth. Obviously with more devices you get multiples of these numbers but still very low. 15 kbps is a pretty significant amount of SIP traffic.
This is most likely targeting VoIP abuse from tools like sipvicious. In a nutshell they scan the internet looking for open SIP ports. They then try to brute force credentials to place calls.
Why? Toll fraud. The scam works like this:
1) Setup an international toll charge number in some country. Let’s say it charges $5/min. For those that don’t know calls to these numbers get charged to the person placing the call from their phone company and end up on their phone bill with the amount getting paid out (less a cut) to the operator of the number.
2) Compromise a bunch of random exposed SIP implementations on the internet.
3) Place calls to your (or a partners) toll number.
4) Get paid from the toll charges.
5) Some time later the owner of the compromised system gets a huge bill depending on fraud detection systems at the carrier, how fast you could pump calls, etc.
It’s gotten so bad many VoIP providers block international calls by default and now (apparently) might be blocking 5060 traffic in some way.
This isn’t that different to what’s happened with SMTP over the years. To combat spam many last mile ISPs started blocking outbound TCP port 25 so compromised machines couldn’t directly send spam. This is where port 465/587 for SMTP “submission” came from.
Don't get me started on the bajillion 3G+ modems here with default passwords.
Where I am, we used to have a different, "nerdy" ISP [0], where customer was allowed to bring their own modem; they also provided real IPv4/v6 dual-stack since forever, easy to request a /29, tech-support that's realistic to reach, and staffed with people who know what they are talking about, no bulk-firewalling port-25, etc... All for a modest 2x price increase over market average. Alas, they're out of business now.
My guess is that the 2x price increase Xs4all was charging for their plan was a bridge too far for most customers. It's important to keep in mind that the vast majority of people rent their modem, don't know or care what a /29 is, and is calling tech support because the plug is loose or the modem needs a power cycle. Bulk-blocking SMTP happened because open ports are botnet ports, and the average customer does not know how to identify and shut down zombies on their network.
[0] Assuming your provider isn't stupidly committed to "you can't have business class because you're in a residential area, WFH doesn't exist, and the zoning code is gospel, all hail Robert Moses"
I remember Xs4all, sorry to hear they went under.
I also miss the brief moment when we had line sharing on copper telco networks in the United States. Most people were perfectly happy with the standard offerings from their local telco, but those of us who wanted more could connect with an ISP who offered service via a dry pair DSL connection. I loved my time on Speakeasy, for example.
I remember all of the flaws with the line sharing system, too, but it actually worked for the short time we had it, in spite of the problems. Asking a niche ISP to build its own facilities-based network is an exercise in futility for many deployments. Of course, cities or counties or public utility districts could do it but the incumbent providers don't like that.
I tried running a PBX on UDP 5060 and got >4GiB of logged register attempts in a few hours after opening the port, while asterisk was running at 100% CPU just rejecting the registration attempts the whole time.
It's insane compared to any other public service I run.
Every few months iptel.org goes down for a few hours and I get 408 request timeouts. When Spectrum blocked 5060 UDP, I got 408 request timeouts for a week. It finally dawned on me to try my iptel account on my VPS and my SIP register succeeded. That's when I knew Spectrum had shut 5060 UDP. I tried 5060 TCP and that didn't work either.
So hopefully you have some other options soon. :)
With that new info, I decided to stick to my 1k plan until more hardware catches up.
Full technical story at https://blog.habets.se/2022/05/Another-way-MPLS-breaks-trace...
Hops marked with "* * *" do not count as "missing" here.
I hope they'll fix it soon, but not if it delays IPv6.
If I had a choice of FTTP providers then IPv6 support would weigh really high on my choice, but only one has dug up the street.
I think you are right. But I am waaaay to cheap for that. I'm using Twilio on some Raspberry Pi's with some software I wrote myself. For 3 phone numbers, I'm spending like $10 a month total.
Nice.
Rate limiting 5060 wouldn’t have any impact on call quality.
https://blog.prolixium.com/2021/01/23/does-centurylink-dsl-b...
It worked just fine through Comcast's Xfinity service (although at the time, that service had other critical issues for me..) and I have no problem now with Verizon Fios.
https://trends.shodan.io/search?query=port%3A5060+org%3Achar...
A critical service is nonfunctional. You should not have to VPN for your internet service to work. I can’t believe I even have to say that.