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/
