[TriLUG] Some basic * questions

[William Sutton]

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)
>