VoIPowering Your Office with Asterisk: 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:

  • 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&#151which,
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

Latest Articles

Follow Us On Social Media

Explore More