4 ms·

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 inte

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.
    - viraptor 13y ago
      This is confusing... Iax doesn't work over TCP and doesn't look like https. It does use a single UDP stream for both control and data, but that makes it really difficult to scale on server side and makes attended transfers tricky.
      - waps 13y ago
        You got me on the TCP/UDP part. Obviously you don't want to run voice over a (real) TCP stream, so I got that wrong. I would argue however, that the "feature" of SIP to send the audio over an out-of-band channel has caused me so much misery over time that I wish it didn't exist. I have managed a VOIP provider and at the edge we terminated SIP, terminated the audio on the incoming system, where it was sent to a central "cluster" for routing, and then terminated again on the outbound. Yes this "wastes" bandwidth, both on the (internal) network and memory/cpu bandwidth too. How much ? Well, about 3*48 kbit per call, on a 10Gbe network. And the machines were needed anyway : inbound customer lines termination needed 2 machines for redundancy. The routing "cluster" needed to be 2 machines so as to be separate from the inbounds (due to much more complicated configs), and again 2 for redundancy in different datacenters (and then 4, and 8 when customer base grew). And the upstream (towards providers) machines weren't even machines, but routers. Again doubled for redundancy. We didn't actually run IAX (mostly because the routers didn't support it), so I do not know much about it. We explicitly avoided using the out-of-band audio feature, and we knew why. It's savings are negligeable, and there's no end to the trouble it causes in operations.
MichaelGG 13y ago
Exactly. SIP ALGs get turned on often (who knows why). There was one cloud computing vendor using NAT that had a SIP ALG "accidentally" statically compiled into the kernels on their routers. They weren't sure why, but thought "it might help", but of course, it ended up just breaking things. This could totally have been a move by Verizon to help enable SIP that just backfired.

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.
  - viraptor 13y ago
    This is confusing... Iax doesn't work over TCP and doesn't look like https. It does use a single UDP stream for both control and data, but that makes it really difficult to scale on server side and makes attended transfers tricky.
    - waps 13y ago
      You got me on the TCP/UDP part. Obviously you don't want to run voice over a (real) TCP stream, so I got that wrong. I would argue however, that the "feature" of SIP to send the audio over an out-of-band channel has caused me so much misery over time that I wish it didn't exist. I have managed a VOIP provider and at the edge we terminated SIP, terminated the audio on the incoming system, where it was sent to a central "cluster" for routing, and then terminated again on the outbound. Yes this "wastes" bandwidth, both on the (internal) network and memory/cpu bandwidth too. How much ? Well, about 3*48 kbit per call, on a 10Gbe network. And the machines were needed anyway : inbound customer lines termination needed 2 machines for redundancy. The routing "cluster" needed to be 2 machines so as to be separate from the inbounds (due to much more complicated configs), and again 2 for redundancy in different datacenters (and then 4, and 8 when customer base grew). And the upstream (towards providers) machines weren't even machines, but routers. Again doubled for redundancy. We didn't actually run IAX (mostly because the routers didn't support it), so I do not know much about it. We explicitly avoided using the out-of-band audio feature, and we knew why. It's savings are negligeable, and there's no end to the trouble it causes in operations.

MichaelGG 13y ago

Exactly. SIP ALGs get turned on often (who knows why). There was one cloud computing vendor using NAT that had a SIP ALG "accidentally" statically compiled into the kernels on their routers. They weren't sure why, but thought "it might help", but of course, it ended up just breaking things. This could totally have been a move by Verizon to help enable SIP that just backfired.