Can I turn in my geek badge? I thought I knew quite a bit about quite a bit, but once again Aaron shows how truly knowledgable he is!
-- William Sutton On Wed, 31 May 2006, Aaron S. Joyner wrote: > Mark Turner wrote: > > > Comments below. > > > > Brian Henning wrote: > > > >> I figure the easiest way is to set up an Asterisk server here, attach > >> it to our existing PBX to show up as another extension, and push an > >> asterisk session (is that good terminology?) through an SSH tunnel > >> (or is that a bad idea?) to the remote employee's broadband-equipped > >> machine, which will sport a cheap headset/boom mic arrangement. > > > > > > As Ron pointed out, SSH does TCP forwarding. You should check into > > OpenVPN, as it can handle both TCP and UDP. > > Using IAX avoids most of the complexity of this problem, as it doesn't > use RTP media streams to send it's data. This avoids one of the primary > problems with SIP/RTP and NAT - that the ports chosen for the RTP > streams are random, and by default usually from a large range (like > 10,000 ports or so). This is because RTP by design requires that each > direction of each voice channel have it's own unique port, thus you need > two ports for every bi-directional voice channel you carry at a time. > Protocols like RTP make firewall administrators angry. Having said > that, note that SIP/RTP sends unencrypted voice audio over the Internet, > not really a good idea for business communications. You can encrypt the > single UDP port used by Asterisk easy enough, though. OpenVPN isn't a > bad choice, given it's general utility. It's a good package to be > familiar with, so you'd be well advised to start there. :) More on > it's overhead in a moment. > > >> 4 - Bandwidth. The remote employee is on some flavor of cable-based > >> broadband, and we're currently on 1.5m/384k (or thereabouts) ADSL. > >> We don't currently shove a lot of data up that pipe (most of the > >> time), but how much bandwidth does one call require? 8k is nibbling > >> at the back of my mind.. > > > 8k = 8,000 = 8k miscellaneous units of measure! My favorite! :) All > kidding aside, I presume you mean 8k bytes per second (kB/s), which is > 64k bits per second (kb/s). That's the bandwidth required by the G.711 > codec, and is a good starting point for an understanding (more details > to follow). > > > An uncompressed G.711 channel is roughly 80kbps. There are G.729 > > licenses you can buy from Digium which will compress that to around > > 16kps or so (Jon, help me out here). The freeware Linux version of > > X-Lite doesn't support G.729, but if your users are of the Windows > > variety, you can buy the G.729 version of X-Lite inexpensively. > > An uncompressed G.711 voice channel is 64kb/s, but that's just the > protocol, aka the data portion of the packets. And the typical VOIP way > is to send a *lot* of very small packets, as that keeps latency down and > minimizes the impact of any single lost packet. So, with UDP you get a > fairly large overhead because each individual packet doesn't contain > much data, so the packet headers add up. Thus, for a G.711 call, that > 80kb/s number is quite realistic (I actually prefer 72kb/s, for reasons > I'll explain later, but 80kb/s is a safely padded number for sure). I'm > sure Mark is aware of all this, I'm just being thorough so that when you > see the 64kb/s number thrown around, you understand that Mark is not on > crack, and is giving you good real world numbers. :) Moving along, the > same is roughly true for G.729. The actual protocol consumes 1/8th as > much bandwidth and thus theoretically takes 8kb/s. Since all your > compressing is the data portion of the packet, and you're still sending > the same number and frequency of packets, you still have about the same > overhead, measured in kb/s. > > Let's break down the overhead per packet. I'm talking primarily about > RTP media stream packets, for which the data portion is just the codec > data, nothing else. All of the meta data is usually handled via SIP, > which is a TCP protocol capable of dealing with lost packets and latency > accordingly. It's also really low bandwidth and plain-text based, and > the delivery of it's messages aren't critical to the flow of audio. So > on to RTP... The packet header on a UDP packet (only talking layer3/4 > headers, ignoring layer2 headers as the size of those almost certainly > varies across the packet's life) is 160bits per packet*. The usual > practice is to send packets at 20ms intervals. This results in 50 > packets per second (1000/20 = 50). 50 packets per second * 160 bits = > 8000 bits / second. So our overhead should be roughly 8kb/s in packet > headers plus what ever protocol we use. Thus, if we use G.711, the > protocol uses 64kb/s and we add 8kb/s of packet headers by sending one > packet every 20ms, we get an effective consumed bandwidth on the wire of > 72kb/s. G.729 uses 8kb/s for the protocol, plus our 8kb/s of headers > gives us 16kb/s. If we want to know how much actual bandwidth is being > consumed at the Ethernet layer (ie. if you look at bits sent by your > Ethernet card, via ifconfig or iptables) we simply add 144 bits** of > data per packet, which works out to 7.2kb/s of Ethernet overhead > (assuming you're not doing 802.1q tagging, the overhead of that is left > as an exercise to the reader). So on-the-wire usage by G.711 is > 79.2kb/s (9.9kB/s), and G.729 usage is 23.2kb/s (2.9kB/s). > > So how much overhead does OpenVPN add to this scenario? Also, how long > does it take to encrypt each packet, and thus how much latency is > introduced by the VPN? I honestly haven't done VOIP through OpenVPN > (only classic ipsec, which is mostly the same for the encryption > portion, but I digress), so I'll leave it to someone else more familiar > with OpenVPN to do the math and also provide some real world experience > to back it up. Or since it's on my list of things to do to setup > OpenVPN at home (*blush*), perhaps I'll eventually get around to > providing more info on this. > > Aaron S. Joyner > > > * - The break down goes something like this, bits on the left column, > description on the right. Good references for this can probably be > found by googling 'udp packet header'. > 32 bits - source ip (start of ip header) > 32 bits - dest ip > 8 bits - protocol id and length (with 8 bits of leader padding) > 8 bits - source port (start of udp header) > 8 bits - dest port > 8 bits - length > 8 bits - checksum > (start of data) > > ** - Ethernet headers break down as follows: > 48 bits - source mac > 48 bits - dest mac > 16 bits - type field (start data/next header after this) > 32 bits - checksum (at end of packet) > -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
