SARK UCS/MVP SAIL Bandwidth Usage

_SARK UCS/MVP _ SAIL was primarily built to utilise low bandwidth Codecs and, in particular, G.729. However, it will run happily with heavy codecs such as ulaw/alaw provided you have sufficient bandwidth.

Bandwidth Considerations.

When estimating your bandwidth requirement you should base your calculations on the slowest component in your network. If you are unfamiliar with ADSL broadband, you may not be aware that the uplift speed is considerably less than download. This is because most users uplift very little to the internet other than e-mail and url addresses. Therefore, it is this uplink speed which will usually limit the overall capability of your VOIP operations. Nowadays, most ADSL systems will download at anything up to 2, 4 or even 8 megabits per second. However,upload speed is usually only 256Kbs, or around one eighth of the download speed. Furthermore, real world sustainable rates are likely to be even less. As a starting point, until you gain more experience with your particular system you should base your initial estimates on half of the rated uplift speed, which means around 128kbps for ADSL and 64kbps for cable (which usually has an uplift speed of only 128kbps).

A VOIP call uses two "channels" simultaneously, carrying speech in each direction. A traditional landline phonecall uses around 64Kbps in either direction which means that we could only handle two simultaneous calls at 128kbps (actually, it's a little less as we'll see in a moment).

CODECs.

On the other hand if we were to use software to compress the soundwave data then we should, in theory, be able to carry more conversations for the same bandwidth. The software which encodes, or digitizes, the sound is called a Codec. And, as we supposed above, some codecs will not only encode the sound they will also compress it. However, there's no such thing as a free lunch and the more the data is compressed the more noticeable it is to the human ear after decompression.

There are several different codecs to choose from and they fall into two categories; so called "lossless" codecs, which don't compress (much) and "lossy" codecs which can and do compress the data to a remarkable degree. As an aside, because lossy codecs, by their very nature, lose data in the compression/decompression process you cannot use them to accurately transmit FAX data over the internet.

So what do the respective CODECs actually use? J.Todd's article (which can be found at http://lists.digium.com/pipermail/asterisk-users/2003-June/014788.html) suggests the following:-

J.Todd's Numbers

Testing Results
CODEC	one call	calls/megabit	calls/128K
G.711 (ulaw)	82.1kbps	15	2
ILBC	28.0kbps	47	6
G.729	30.0kbps	103	12
GSM	35.4kbps	68	8
LPC10	21.9kbps	164	20
SPEEX	37.4kbps	57	7

Translation Impact.

As you can see there is a huge difference in the number of calls which can be handled by the various CODECs. However in general, the more compressive the CODEC, the less natural the resulting sound. Furthermore, the process of compression and decompression itself can impose heavy loads on your CPU leading to problems of their own. You can see what your own CPU will manage in terms of translation by using the SHOW TRANSLATION command at the Asterisk console.

In general, ULAW/ALAW (G711), GSM and G729 are the three with the best price/performance. We have set SAIL up to use ulaw/alaw or GSM/G729 depending upon whether you choose FIDELITY or THRUPUT in Globals. This gives a good trade off between maximum calls through the pipe, reasonable quality and low CPU consumption. However, there is nothing to stop you changing this bias by changing the "allow" statements in the SIP and IAX ".conf" entries in the trunks and extensions panels (or even the carrier and device panels). Should you do this then do try to choose your CODECs such that you minimise the amount of translation that Asterisk is having to do.