9.2. Latency, Packet Loss, and Jitter
Latency (also called lag), being the chief cause of poor perceived call quality, is caused primarily by slow network links. End-to-end latency, in the case of VoIP, is the time it takes from the instant the caller utters something until the time the receiver hears that utterance. Research has established that round-trip latency less than 150 ms is not immediately noticeable, but latency higher than 150 ms is discouraged, and latency higher than 300 ms is considered unacceptable. (Cisco Systems states that round-trip latency higher than just 150 ms is unacceptable.)
Latency has the following effects on telephony applications:
The best ways to beat latency are to use low-packet-interval codecs and maintain fast network links, because QoS protocols alone cannot directly improve latency's impact. That is, they can't speed up your network. One negative effect of latency in telephony systems is echo. It's discussed in more detail in the following section, "Echo."
Latency is the enemy of VoIP, but it's also the way some codec-based solutions to packet loss and jitter are made possible. This is because those solutionsnamely, jitter buffers and packet loss concealment (PLC)are both sources of latency. In fact, many things contribute to latency:
Minimizing latency is an important way to maximize the VoIP network's perceived quality of service.
The two biggest sources of latency are framing/packetization, which can add up to 30 ms of latency, and routing, which can add 5-50 ms per hop. Another big contributor is transcoding. The sample latency factors produced by transcoding in Asterisk 1.01 are outlined in Table 9-3. Source codecs are shown in rows, and destination codecs in columns .
Table 9-3. Asterisk transcoding delays in milliseconds , by codec a
Packet loss is very damaging to VoIP calls. Its chief cause is network congestion. As shown in Figure 9-1, different codecs have different packet loss tolerances or error budgets. PLC is a feature of some codecs that allows perceptions of a quality breakdown to be minimized through vectoring algorithms. These codecs work by replacing the sound that would presumably have been produced by a packet that was lost with sound that is predicted based on the sequence of packets received before it and (when extensive buffering is used) after it. But even with PLC in force, packet loss rates on a VoIP network should be kept below 1%. While QoS measures can improve the packet loss problem by providing reserved bandwidth or precedence for voice packets, it's still a plain-old good idea to conserve available network capacity and keep packet loss rates down. A drawback of PLC is that it can increase latency. Experimentation with PLC-equipped codecs should be done to determine how negative the latency-impact PLC is in your VoIP network.
Jitter is a more complex problem than latency and packet loss. It's the variation in latency time from one packet to the next . It causes packets to arrive out of order, leaving gaps in the framing sequence of the voice signal. Jitter is at its worst when voice traffic must travel through several routers on the network. The more hops, the worse jitter can get. Different routers, especially those at ISPs, may be configured to queue and forward different kinds of traffic in different ways. Others may be load-balancing, which can contribute to jitter. The chief goal of QoS protocols is to eliminate jitter. Devices called jitter buffers, in endpoints and VoIP servers, can minimize the effect of jitter, too. But, like PLC measures, they do so by increasing latency.
When you hear the words you've just spoken repeated back to you a split second later on the telephone, you're experiencing echo . Chances are, if the echo occurs less than 150 ms from the time you actually said the words, then you won't notice it. But when the echo occurs above this threshold, it can be particularly annoying. Echo is an unfortunate by-product of the gateway electronics that bridge soft-based PBX systems to analog or TDM links. It is caused by three conditions, and it's at its worst when they exist together:
220.127.116.11 Hybrids and echo
There's a lot of physics at the heart of the echo problem. When resulting from legacy interface conversion, the echo problem usually lies in the quality of the analog interface, called a hybrid . Hybrids may have built-in echo-canceling abilities . Some hybrids are more susceptible to echo than others. Many have noted that Digium's TDMxxx hybrids are less echo-ridden than their X100P hybrids.
While onboard echo reduction may exist on some hybrids, good network design is a more strategic way to deal with the problem. The keys to removing echo are minimizing the use of gateway devices that use hybrids (which, today, are quite hard to avoid) and reducing latency as much as possible. QoS and CoS measures will help you do the latter.
18.104.22.168 Zaptel's echo suppression
When you use a network that has little or no CoS/QoS support, like the Internet, you can still do a few things to minimize echo. Most IP phones offer varying degrees of echo cancellation, and Asterisk has a built-in echo canceller for VoIP and Zaptel channels. By modifying the echotraining setting in zapata.conf , you can raise or lower the echo canceller's sensitivity to echo. Experiment with each interface to see what value works best.
There's also an aggressive suppressor algorithm availablebut you'll need to uncomment this header in /usr/src/zaptel/zconfig.h and recompile the Zaptel driver module in order to use it: