VoIPowering Your Office with Asterisk: Making VoIP Calls Sound Good

By Carla Schroder | Oct 2, 2006 | Print this Page
http://www.enterprisenetworkingplanet.com/unified_communications/VoIPowering-Your-Office-with-Asterisk-Making-VoIP-Calls-Sound-Good-3635376.htm

I know, last week I promised to write about getting SIP to navigate NAT firewalls. The neat thing about SIP is it's a peer-to-peer protocol, so you don't need an Asterisk server—or any kind of server—to make Internet phone calls. Unfortunately the task has left me daunted and dented, but not permanently. Soon I promise to reveal all.

Meanwhile, let's talk about Asterisk sound quality. There are a lot of factors that affect it, enough to drive you back to the days of smoke signals and interpretive dance. But take courage, there a number of things you can do to get your call quality up to snuff.

Latency, packet loss, jitter, and echo are the four primary bad actors in the VoIP sound world. The first two have long been facts of Internet life, but they don't matter much for data traffic. Data transfers are not time sensitive in the way that voice traffic is, so they tolerate the overhead of TCP and any extra time required to route around trouble spots. The idea is to get there with all bits present, even if it takes a little longer. You don't notice latency on a data transfer unless it's extreme.

Here are a few of the everyday indignities suffered by data packets:

  • Load sharing and load balancing.
  • These are very good for data traffic, but introduce all sorts of delays and inconsistencies into voice traffic
  • Routing table updates
  • These don't take long, but the updates are given high priority, so delays are introduced
  • Route flapping
  • Traffic is flung willy-nilly amongst alternate routes, usually as a response to a problem like a hardware failure or a mis-configuration
  • Link Congestion
  • There is always a bit of delay as packets pass through different interfaces. For example, it takes a 1500-byte packet about 8 milliseconds to pass through a T1 interface. (This is due to the serialization delay, or the time it actually takes to shove the packet through, for those who want the gory details.) If ten data packets are queued ahead of a voice packet, that's an additional 80-millisecond delay.
    Additionally, queueing and caching are used extensively on data networks. Your bits are temporarily corraled and lined up in holding pens at many different chokepoints: broadband modems, firewalls, and routers, until the poor things are released and sent on their way. Again, no problem for data traffic, but not so good for voice traffic.

Latency and jitter are the evil twins of bad call quality. Depending on whose definition you like, they either are or aren't the same thing. Latency is the length of time it takes for packets to travel from endpoint to endpoint. Jitter—which, in practical terms, manifests as an unstable sound signal—is created by queuing, contention, and network congestion. Jitter can be constant or variable. Jitter needs to be less than 100 milliseconds, or you're going to notice it. Softphones tend to experience more jitter than hardphones because of CPU contention.

The long-term solution is a better-quality Internet, with fatter backbone pipes and real QoS (quality of service.) We should see considerable improvement as IPv6 is implemented, because it offers genuine QoS, more efficient routing, and less reliance on NAT (network address translation). QoS in IPv4 is pretty much a joke; many routers don't support it, and even where it is supported, there are several competing, incompatible implementations. If your friendly neighborhood service provider offers real IPv6 service, hop aboard and start getting familiar with it.

Network congestion is a VoIP killer. DSL and cable Internet can be wildly variable, depending on traffic levels and the quality of the provider. Nice dedicated bandwidth like T1/E1 smooths out a lot of the bumps. But don't overlook congestion on your own LAN—giving your VoIP traffic its own dedicated lines means your voice calls won't have to compete with file downloads, Web surfing, email, and all that.

Typically the biggest trouble spots are the "last mile" links, or the physical line from your provider's network to your network. These are prone to all manner of troubles—age, neighbor mischief, and neglect.

Smoothing out the bumps
One important step in combatting the evils of jitter is making sure your own network is squeaky clean. Fortunately this is something you control. If you still have some hubs hanging around, get rid of the silly things. The last thing you want on any network are collision domains; that's so last-millennium. Look for bad cabling—got anything older than Cat5e hanging around? Chuck it. If you can, upgrade to Gigabit Ethernet. It's not that expensive anymore, and it makes a real difference for your local voice traffic.

Give your VoIP traffic its own dedicated Internet link. Hardware makes a big difference. Good hardphones do a lot of work—they smooth out echo and jitter, translate codecs, and automatically prioritize voice packets.

Softphones vary considerably in how they handle call quality. You'll have try them out to see which ones work best for you. Good-quality headsets make a noticeable difference.

Sound on Linux PCs present some special challenges, because of several different available sound subsystems. Next week we'll learn how to configure sound on both Linux and Windows for quality and convenience, and look at some Asterisk tweaks for conquering the Bad Sound Demons.

Resources
Gigabit Ethernet For the Frugal Admin
Understanding Delay in Packet Voice Networks