3 ms·

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

by 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 waps 13y ago

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.