7 ms·

Verizon network ALG blocks SIP

63 points by gz5 13y ago

cosarara97 13y ago
Is that legal?
- jrockway 13y ago
  Unless I missed something, there is no such thing as "net neutrality" for cell phone networks. And anyway, this is probably a misconfigured NAT device somewhere, not an intentional plan to block third-party SIP services.
mattvv 13y ago
A lot of networks do this, it's not just Verizon. We've seen invites disappear at many different networks like hotels and different mifis. As well as registrations never go through on some. That said, this and poor implementations of sipinspect on routers appear to be the Achilles heal of SIP.
- deleted 13y ago
  [deleted]
ejdyksen 13y ago
With my iPhone 5 on VZW, I can SIP REGISTER just fine with Bria (a SIP client) running on the phone itself. I can make a call, too (using FreeSwitch). I cannot, however, do any SIP REGISTERs with my MBP tethered to my phone. So the headline would more accurately be: "Verizon blocks SIP on tethered devices"
- gz5 13y ago
  very interesting. and Bria is not using TLS or encapsulating SIP in https? would also be interesting to see how selective VZW is being, e.g. letting some SIP through (even tethered), depending on the app.
droopybuns 13y ago
This is super interesting. In full blown 4g networks, voice is going to be handled via sip traffic via an IMS core. Some things to investigate: Is Verizon using separate APNs for their voice and data. Based on what is presented, I am guessing no... And that they jhave routing/QoS rules that are rather ungranular. They assume all sip traffic must be their own IMS traffic and then route it to their ims core, where a proxy is damaging the flow. Anyone who thinks that an operator will allow you to use SIP traffic over their LTE network forever is incomprehensibly naive. Paying customer voice traffic should not have to compete for resources with your data traffic. Net neutrality is not a suicide pact.
- mdasen 13y ago
  With Verizon, there's an issue of open access. Verizon bid on 700MHz spectrum with special "open access" rules that require them to allow any application. In the 2008 700MHz auction, there were five blocks up for auction and Verizon went for the one band that had these restrictions: that customers be allowed to use any compatible device they like and use any software, content, or services they like. Paying customer voice traffic is today, and can be in the future, carried on other spectrum.
  - droopybuns 13y ago
    Spectrum is only part of the equation... And if they didn't design things right, they won't be able to take advantage of spectrum differently like you propose.
    - mdasen 13y ago
      Yeah. . .but to be a bit crass, that's totally Verizon's problem. I mean, at some point they have to have had meetings, "so, how will these open access rules affect our future?" And yea, I'm being a bit silly when I say "they have to have" (this is going to be a bit of a silly comment). Companies do dumb things all the time. But if the response was, "eh, who cares. I'm sure people will forget about it," then it's kinda their own fault. Without these restrictions, that spectrum may have raised more money. It was auctioned with these restrictions with the idea that the restrictions are in the public interest and that it might cause the winner to undergo additional costs or lose certain pricing options. If the result is, "c'mon dude, you can't really expect us to do that," I don't have a lot of pity for it. Net neutrality isn't meant to be a suicide pact, but to be frank, almost all of the wireless spectrum that the FCC has made available for mobile doesn't carry this restriction. Verizon knew this restriction going in and could have chosen not to bid on that spectrum. I think with Verizon having gone in with full knowledge of the restrictions involved, it's reasonable to hold them accountable.
kkielhofner 13y ago
Verizon appears to be using CGN (Carrier Grade NAT) for IPv4 on their LTE network. Having seen many, many SIP ALGs in the field before this looks less like intentional blocking and more like typical broken (but somewhat well intentioned) SIP ALG behavior. Unfortunately SIP ALGs only work (well) when combined with properly configured far-end equipment that doesn't perform the various SIP checks to detect endpoints behind NAT devices. My suggestion for any provider in these situations is to use SIP over TLS. SIP ALGs can't modify packets they can't inspect. Often times SIP ALGs can be defeated simply by changing SIP port numbers. I'd expect onsip to know better and not write a sensationalist article implying that there is some anti-competitive behavior from Verizon at play here. Hanlon's razor at it again (Verizon).
- viraptor 13y ago
  I agree that this may not be intentional. ALG is the cancer of SIP. I never saw one that actually works. Petty much every documentation that describes home network configuration for VoIP will start with "if your router advertises SIP ALG capabilities, turn it off". They're at best behaving in silly ways with simple traffic and mess up pretty much everything in more interesting scenarios (hold+transfer can be broken in so many ways...)
  - snuxoll 13y ago
    God, I've lost count of the times where the SIP ALG on my WNR3500L's stock firmware just caused my softphone for work to behave in the strangest ways, normally causing one-way audio. The worst part is we have well defined ways for handling NAT traversal for SIP without need for an ALG, but router manufacturers still include them?
    - waps 13y ago
      Switch to a combined channel. If everything's in one TCP connection, it doesn't matter as much what the NAT does. Better yet, make it work over "HTTPS" (ie. what looks like HTTPS). Easiest possible way to do this : switch to IAX.
popee 13y ago
Whenever this is real problem or not, one thought came to mind. SIP and HTTP are pretty similar. It would be nice to have kind of (REST?) translation SIP -> HTTP/1.1. No need for complications (like webRTC, websockets, etc), just simple and clean proxy somewhere on the internet. Example: SIP invite: INVITE sip:bob@biloxi.example.com SIP/2.0 translated to: HTTP /path/to/invite/bob@biloxi.example.com HTTP/1.1 Client sends that HTTP request to HTTP->SIP proxy so that it is translated into specific SIP request method (INVITE). When proxy gets response from SIP it converts it back to HTTP in similar fashion and deliver to client. That way they couldn't forbid SIP signalization on client because on client side it's plain old HTTP/HTTPS :-) This should not be problem to implement as library or something like that. In short, simple SIP over HTTP tunnel. P.S. Unlike HTTP, SIP is federated protocol and because of that it is, in a sense, little bit more decentralized. HTTP is designed as man in the middle attack protocol. One step at a time :-)
eli 13y ago
It's possible it's changed, but at one point VoIP was specifically against the terms of service for Verizon wireless data plans (playing games too).
zw123456 13y ago
I cannot say how I know this, but I can assure you that this is a perfect example of Hanlon's razor at work. I am 100% sure that it is not intentional.
mp3jeep01 13y ago
I remember seeing similar behavior trying to do testing in a cafe using a Verizon MiFi over LTE. I called up their support staff and they tried to blame the problem on me saying they don't block anything, it must be on my end...typical.
shmerl 13y ago
Are they blocking Jingle as well? I hope T-Mobile won't do any such lunacy when they'll roll out their LTE.
traderd65 13y ago
Using standard Internet protocols (HTTP/HTTPS) isn't subject to carrier shenanigans (whether deliberate or not): http://finance.yahoo.com/news/rebtel-chooses-pubnub-pulse-speed-130000674.html http://finance.yahoo.com/news/rebtel-chooses-pubnub-pulse-sp...

63 points by gz5 13y ago

cosarara97 13y ago

Is that legal?

jrockway 13y ago
Unless I missed something, there is no such thing as "net neutrality" for cell phone networks. And anyway, this is probably a misconfigured NAT device somewhere, not an intentional plan to block third-party SIP services.

mattvv 13y ago

A lot of networks do this, it's not just Verizon. We've seen invites disappear at many different networks like hotels and different mifis. As well as registrations never go through on some. That said, this and poor implementations of sipinspect on routers appear to be the Achilles heal of SIP.

deleted 13y ago
[deleted]

ejdyksen 13y ago

With my iPhone 5 on VZW, I can SIP REGISTER just fine with Bria (a SIP client) running on the phone itself. I can make a call, too (using FreeSwitch). I cannot, however, do any SIP REGISTERs with my MBP tethered to my phone. So the headline would more accurately be: "Verizon blocks SIP on tethered devices"

gz5 13y ago
very interesting. and Bria is not using TLS or encapsulating SIP in https? would also be interesting to see how selective VZW is being, e.g. letting some SIP through (even tethered), depending on the app.

droopybuns 13y ago

This is super interesting. In full blown 4g networks, voice is going to be handled via sip traffic via an IMS core. Some things to investigate: Is Verizon using separate APNs for their voice and data. Based on what is presented, I am guessing no... And that they jhave routing/QoS rules that are rather ungranular. They assume all sip traffic must be their own IMS traffic and then route it to their ims core, where a proxy is damaging the flow. Anyone who thinks that an operator will allow you to use SIP traffic over their LTE network forever is incomprehensibly naive. Paying customer voice traffic should not have to compete for resources with your data traffic. Net neutrality is not a suicide pact.

mdasen 13y ago
With Verizon, there's an issue of open access. Verizon bid on 700MHz spectrum with special "open access" rules that require them to allow any application. In the 2008 700MHz auction, there were five blocks up for auction and Verizon went for the one band that had these restrictions: that customers be allowed to use any compatible device they like and use any software, content, or services they like. Paying customer voice traffic is today, and can be in the future, carried on other spectrum.
- droopybuns 13y ago
  Spectrum is only part of the equation... And if they didn't design things right, they won't be able to take advantage of spectrum differently like you propose.
  - mdasen 13y ago
    Yeah. . .but to be a bit crass, that's totally Verizon's problem. I mean, at some point they have to have had meetings, "so, how will these open access rules affect our future?" And yea, I'm being a bit silly when I say "they have to have" (this is going to be a bit of a silly comment). Companies do dumb things all the time. But if the response was, "eh, who cares. I'm sure people will forget about it," then it's kinda their own fault. Without these restrictions, that spectrum may have raised more money. It was auctioned with these restrictions with the idea that the restrictions are in the public interest and that it might cause the winner to undergo additional costs or lose certain pricing options. If the result is, "c'mon dude, you can't really expect us to do that," I don't have a lot of pity for it. Net neutrality isn't meant to be a suicide pact, but to be frank, almost all of the wireless spectrum that the FCC has made available for mobile doesn't carry this restriction. Verizon knew this restriction going in and could have chosen not to bid on that spectrum. I think with Verizon having gone in with full knowledge of the restrictions involved, it's reasonable to hold them accountable.

kkielhofner 13y ago

Verizon appears to be using CGN (Carrier Grade NAT) for IPv4 on their LTE network. Having seen many, many SIP ALGs in the field before this looks less like intentional blocking and more like typical broken (but somewhat well intentioned) SIP ALG behavior. Unfortunately SIP ALGs only work (well) when combined with properly configured far-end equipment that doesn't perform the various SIP checks to detect endpoints behind NAT devices. My suggestion for any provider in these situations is to use SIP over TLS. SIP ALGs can't modify packets they can't inspect. Often times SIP ALGs can be defeated simply by changing SIP port numbers. I'd expect onsip to know better and not write a sensationalist article implying that there is some anti-competitive behavior from Verizon at play here. Hanlon's razor at it again (Verizon).

viraptor 13y ago
I agree that this may not be intentional. ALG is the cancer of SIP. I never saw one that actually works. Petty much every documentation that describes home network configuration for VoIP will start with "if your router advertises SIP ALG capabilities, turn it off". They're at best behaving in silly ways with simple traffic and mess up pretty much everything in more interesting scenarios (hold+transfer can be broken in so many ways...)
- snuxoll 13y ago
  God, I've lost count of the times where the SIP ALG on my WNR3500L's stock firmware just caused my softphone for work to behave in the strangest ways, normally causing one-way audio. The worst part is we have well defined ways for handling NAT traversal for SIP without need for an ALG, but router manufacturers still include them?
  - waps 13y ago
    Switch to a combined channel. If everything's in one TCP connection, it doesn't matter as much what the NAT does. Better yet, make it work over "HTTPS" (ie. what looks like HTTPS). Easiest possible way to do this : switch to IAX.

popee 13y ago

Whenever this is real problem or not, one thought came to mind. SIP and HTTP are pretty similar. It would be nice to have kind of (REST?) translation SIP -> HTTP/1.1. No need for complications (like webRTC, websockets, etc), just simple and clean proxy somewhere on the internet. Example: SIP invite: INVITE sip:bob@biloxi.example.com SIP/2.0 translated to: HTTP /path/to/invite/bob@biloxi.example.com HTTP/1.1 Client sends that HTTP request to HTTP->SIP proxy so that it is translated into specific SIP request method (INVITE). When proxy gets response from SIP it converts it back to HTTP in similar fashion and deliver to client. That way they couldn't forbid SIP signalization on client because on client side it's plain old HTTP/HTTPS :-) This should not be problem to implement as library or something like that. In short, simple SIP over HTTP tunnel. P.S. Unlike HTTP, SIP is federated protocol and because of that it is, in a sense, little bit more decentralized. HTTP is designed as man in the middle attack protocol. One step at a time :-)

eli 13y ago

It's possible it's changed, but at one point VoIP was specifically against the terms of service for Verizon wireless data plans (playing games too).

zw123456 13y ago

I cannot say how I know this, but I can assure you that this is a perfect example of Hanlon's razor at work. I am 100% sure that it is not intentional.

mp3jeep01 13y ago

I remember seeing similar behavior trying to do testing in a cafe using a Verizon MiFi over LTE. I called up their support staff and they tried to blame the problem on me saying they don't block anything, it must be on my end...typical.

shmerl 13y ago

Are they blocking Jingle as well? I hope T-Mobile won't do any such lunacy when they'll roll out their LTE.

traderd65 13y ago

Using standard Internet protocols (HTTP/HTTPS) isn't subject to carrier shenanigans (whether deliberate or not): http://finance.yahoo.com/news/rebtel-chooses-pubnub-pulse-speed-130000674.html http://finance.yahoo.com/news/rebtel-chooses-pubnub-pulse-sp...