[TriLUG] Some basic * questions

[Aaron S. Joyner]

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)