Showing posts with label codecs. Show all posts
Showing posts with label codecs. Show all posts

Saturday, August 9, 2008

Codecs & asterisk

If you have worked with Asterisk/Trixbox for any length of time, you have dealt with codecs. You’ve seen terms thrown around such as ulaw, alaw, G711, G729, and on and on and one. But what are these? And what are the differences between them? When should use use G726 instead of ulaw? What codecs are even possible in Trixbox? I’ll try to clear some of this up.

For VoIP communication, you need to start with a protocol. The three big protocols are SIP, IAX2, and H323. SIP and IAX2 are natively supported in Trixbox’s version of Asterisk (v1.2), so I’m going to assume that you’re using one of these. Once you have your protocol in place, a codec tells the system what format to send the calls across the protocol.

Codecs are used to convert an analog voice signal to digital. They vary in sound quality and bandwidth consumption. Typically, the better the sound quality, the more bandwidth consumed…the less bandwidth consumed, the worse the sound quality. Here are the codecs currently supported in Asterisk v1.2:

ulaw - AKA G.711 - 64Kbps - ulaw is the standard US codec for uncompressed voice. For internal extension to extension calls, this is the preferred codec. Notice the 64Kbps? This is how much bandwidth is consumed by this codec. When thinking about bandwidth consumption, I like to think in terms of phone lines…a typical phone line (or T1 channel) is 56Kbps (remember the days of modems??). ulaw is just a little higher than that. If your Internet connection is a modem, you would want a more compressed codec. If you have 768Kbps up/down DSL, you should be able to run 12 ulaw calls across the connection (768Kbps / 64Kbps = 12). That is typically not recommended however, and with other Internet stuff going on, that number gets reduced significantly. If a client told me they had a 768Kbps connection, I would tell them not to expect good voice quality on more than 3-4 simultaneous calls with ulaw and that connection.

alaw - AKA G.711 - 64Kbps - alaw is the same as ulaw, but it is the European standard codec.

G.723.1 - 6.3Kbps or 5.3Kbps - This is the standard codec used by H323. Since I’m not talking about H323, I’ll skip this one.

G.726 - 32 Kbps - G726 is a good alternative to ulaw when you need to save some bandwidth. It consumes 1/2 the amount of bandwidth of ulaw, and the voice quality isn’t degraded much.

G.729 - 8Kbps - The G729 codec is excellent, but there is a trade-off. It has very low bandwidth consumption and decent voice quality, however it also has a dark side in that it isn’t free. G.729 licenses are available from Digium at the cost of $10.00 per channel. They also take a significant amount of CPU power to process the compression. Installation requires a purchased license from Digium, and you have to download and run their registration program…it is pretty easy to do, but is still an additional step. Plus, it bases the registration on the MAC address of the computer it was installed on, and is only transferrable once (and you have to contact Digium to do it). This is a good codec, but try G.726 or GSM first.

GSM - 13Kbps - GSM is a codec that comes from cell phone technology. It has pretty low bandwidth consumption, but you will notice lower voice quality than a standard PSTN line.

iLBC - 13.33Kbps - iLBC is another low-bandwidth codec. They claim better quality than G729, but I haven’t had much experience with them…I don’t know if that is a true statement or not.

Speex - configurable 4-48Kbps - Speex is another less-known codec. It’s advantage is that it is flexible (4Kbps to 48Kbps) in terms of bandwidth consumption, but it takes up more CPU than even G.729. Again, I have never used this codec, so I don’t know much more about it.

I hope that helps clear codecs up a bit. My general rule of thumb is to use ulaw if there aren’t any bandwidth constraints. If bandwidth is a consideration, I then try G.726 and GSM in that order. If a customer is jazzed about G.729, I have no problem using that as well (although I don’t think it offers enough advantage over G.726 or GSM to be worth $10 bucks).





AddThis Feed Button

Tuesday, August 5, 2008

VoIP Codecs

A codec, which stands for coder-decoder, converts an audio signal into compressed digital form for transmission and then back into an uncompressed audio signal for replay. It's the essence of VoIP.

Codecs accomplish the conversion by sampling the audio signal several thousand times per second. For instance, a G.711 codec samples the audio at 64,000 times a second. It converts each tiny sample into digitized data and compresses it for transmission. When the 64,000 samples are reassembled, the pieces of audio missing between each sample are so small that to the human ear, it sounds like one continuous second of audio signal. There are different sampling rates in VoIP depending on the codec being used:

  • 64,000 times per second
  • 32,000 times per second
  • 8,000 times per second
A G.729A codec has a sampling rate of 8,000 times per second and is the most commonly used codec in VoIP.

Codecs use advanced algorithms to help sample, sort, compress and packetize audio data. The CS-ACELP algorithm (CS-ACELP = conjugate-structure algebraic-code-excited linear prediction) is one of the most prevalent algorithms in VoIP. CS-ACELP organizes and streamlines the available bandwidth. Annex B is an aspect of CS-ACELP that creates the transmission rule, which basically states "if no one is talking, don't send any data." The efficiency created by this rule is one of the greatest ways in which packet switching is superior to circuit switching. It's Annex B in the CS-ACELP algorithm that's responsible for that aspect of the VoIP call.

The codec works with the algorithm to convert and sort everything out, but it's not any good without knowing where to send the data. In VoIP, that task is handled by soft switches.

E.164 is the name given to the standard for the North American Numbering Plan (NANP). This is the numbering system that phone networks use to know where to route a call based on the dialed numbers. A phone number is like an address:

    (313) 555-1212

    313 = State
    555 = City
    1212 = Street address

The switches use "313" to route the phone call to the area code's region. The "555" prefix sends the call to a central office, and the network routes the call using the last four digits, which are associated with a specific location. Based on that system, no matter where you're in the world, the number combination "(313) 555" always puts you in the same central office, which has a switch that knows which phone is associated with "1212."

The challenge with VoIP is that IP-based networks don't read phone numbers based on NANP. They look for IP addresses, which look like this:

    192.158.10.7
IP addresses correspond to a particular device on the network like a computer, a router, a switch, a gateway or a telephone. However, IP addresses are not always static. They're assigned by a DHCP server on the network and change with each new connection. VoIP's challenge is translating NANP phone numbers to IP addresses and then finding out the current IP address of the requested number. This mapping process is handled by a central call processor running a soft switch.

The central call processor is hardware that runs a specialized database/mapping program called a soft switch. Think of the user and the phone or computer as one package -- man and machine. That package is called the endpoint. The soft switch connects endpoints.

Soft switches know:

  • Where the network's endpoint is
  • What phone number is associated with that endpoint
  • The endpoint's current IP address




AddThis Feed Button