VoIPowering Your Office with Asterisk: Making VoIP Calls Sound Good, Part 2

Monday Oct 9th 2006 by Carla Schroder

Jitter results from voice packets traveling over unpredictable connections. The way to eliminate it is buffering—giving late packets a chance to catch up.

Last week we took a look at the various factors that can affect VoIP sound quality, and shared some infrastructure tips for improving the sound quality of your VoIP calls. Having a clean, not-overloaded network is the most important factor. But there are a number of tweaks you can try on your VoIP gear to compensate for less-than-ideal conditions. Today we'll look at some more ways to help make your calls sound more professional and assured, and less like you're driving over a bumpy road.

There are three possible devices to deal with: media gateways, your Asterisk server, and your endpoints, or IP telephones. (All the cool kids say "endpoints." I'm fine with "phones.") If you are using a media gateway, start there. If not, your Asterisk server has a built-in jitter buffer.

Good softphones and hardphones have adaptive jitter buffers and may not need any tweaking at all. This is the best scenario, because running around fiddling with mass endpoints isn't all that fun. You can turn on echo cancellation on your phones on an as-needed basis. There's no downside to having it on by default on hardphones, since they perform the heavy lifting of call processing, but echo cancellation eats up more CPU cycles on softphones.

Remember, this is only for incoming calls—anyone you call has to deal with their own call-quality issues.

If you're feeling a bit grumbly at having to fiddle with VoIP call quality, just keep in mind that traditional telephone networks experience all of these problems as well. The difference is we've had 130 years to refine our telephone networks.

Adjusting jitter buffers
Jitter buffers trade off between sound quality and delay. A larger buffer means less jitter but more delay. You can buffer VoIP calls until the sound is perfect, but at the price of long delays. Start with 100 milliseconds, then increase it, as necessary, in 100-millisecond intervals. 1,000 milliseconds is the maximum practical value; you'll notice it, but it shouldn't be too horrid.

The Asterisk jitter buffer is linited to the IAX channels at present, but starting with version 1.4M is going to be all shiny and improved—and support more channels. Version 1.4 is still in beta, so feel free to download and play with it, or just read the documentation in the tarball. For now, we'll stick with the 1.2 jitterbuffer (as Asterisk refers to the jitter buffer) configuration. Open /etc/asterisk/iax.conf and go to the jitterbuffer section:

; You can adjust several parameters relating to the jitter buffer.
; The jitter buffer's function is to compensate for varying
; network delay.
Here is a sample configuration:
This turns on the jitterbuffer and sets the maximum size.

If forcejitterbuffer=yes is used, it turns on jitterbuffering no matter what, even when it normally would not be used. Most times you won't want to do this, because jitterbuffering should preferably be done on the endpoints themselves, or as close to them as possible. If you're having a lot of jitter problems, it's worth a try; you can always turn it off.

maxjitterinterps is an interesting option for dealing with clients that don't correctly indicate silences. Interpolation fills in missing packets with packets that were delivered successfully; a rather mash-n-patch technique. Clients are supposed to send CNG/DTX frames to indicate silence. Not all of them do this, so turning this on prevents silences from being misinterpreted as missing packets. The default value is 10; try lower values if it's not quite working correctly.

resyncthreshold will cause the jitterbuffer to re-synchronize the transmission when it notices a large change in delay. It assumes that the timestamps are wrong. The threshold for triggering a re-sync is twice the measured jitter plus the resync threshold that you set. If you want to try this, set the value to at least the maximum size of your jitterbuffer. -1 turns it off.

Linux sound servers
Linux comes with a number of sound subsystems that are powerful, flexible, and a bit vexing to get the hang of. (Just like most Linux applications.) The only one you need is ALSA- the Advanced Linux Sound Architecture. If your Asterisk server or Linux PCs with softphones have aRtsd (the KDE sound server) or the Enlightened Sound Daemon (ESD), which comes with the Gnome desktop, disable or uninstall them. ALSA does everything you need, and then some. aRtsd and ESD are fine for ordinary multimedia and present friendly interfaces, but they add complexity—and worst of all, latency—that Number One Enemy of VoIP sound quality.

Additionally, don't use OSS (Open Sound System) because it is obsolete. ALSA provides an OSS emulator for applications and devices that think they need OSS, like the Asterisk console. (See /etc/asterisk/alsa.conf.)

Windows sound
Microsoft Windows has a single sound system, so no worries there. However, this will change rather radically in Vista, and may continue to change even after it is out of beta, so keep your eyes peeled for relevant documentation.

Fine-Tuning Voice over Packet Services
See the example /etc/asterisk/iax.conf for jitterbuffer help
See the doc/README.jitterbuffer in the source tarball for Asterisk 1.2
See the doc/jitterbuffer.txt in the source tarball for Asterisk 1.4
Configuring multiple Linux sound devices with .asoundrc
Notes on kernel OSS emulation
Vista audio enhancements revealed

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved