2006-10-02 - Making VoIP Calls Sound Good!
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:
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.
Signup here for your free news on new products and voip