3 ms·

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

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

by snuxoll 13y ago

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.