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

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:

jitterbuffer=yes
maxjitterbuffer=1000
forcejitterbuffer=no
maxjitterinterps=10
resyncthreshold=-1


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.

Resources
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

Latest Articles

Follow Us On Social Media

Explore More