Section 9.2. Latency, Packet Loss, and Jitter

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:

• Can slow down the human conversation

• Can result in caller and receiver unintentionally interrupting each other

• Can exacerbate another Quality-of-Service problem: echo

• Can cause synchronization delays in conference-calling 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."

ITU-T recommendation G.114 defines acceptable latency budgets in various telephony applications.

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:

• Framing and packetization

• Software processing and PLC

• Jitter buffering

• Routing and firewall traversal

• Transcoding

• Media access and network interfacing

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

Codec	GSM	m Law	ALaw	G.726	LPC10	ILBC
GSM	N/A	4	4	12	14	59
m Law	10	N/A	1	10	12	57
ALaw	10	1	N/A	10	12	57
G.726	17	2	2	N/A	19	64
LPC10	18	10	10	18	N/A	65
ILBC	19	11	11	19	21	N/A
a Sample latency factors are from a Linux 2.4.20-6 on a Pentium III 600 mHz.

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.

9.2.1. Echo

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:

• Interfacing between TDM and VoIP endpoints or analog and VoIP endpoints. The more interface points in the network, the bigger pain echo is likely to be

• Long round-trip latency between caller and receiver. The higher the latency, the more annoying echo is likely to be

• Interfacing of a call path between two-wire analog and TDM or four-wire analog devices. In this case, echo is caused by an inability of the TDM or four-wire circuit to cancel the local side-tone signal on the two-wire device (side-tone is covered in the sidebar)

9.2.1.1 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.

9.2.1.2 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.

Side-Tone

One kind of echo is helpful. When you hear your own voice in the phone receiver, you have a tendency to assume the person on the other end of the call can hear you OK. When you don't hear yourself in the phone receiver, you tend to say, "Are you there? Can you hear me?" You're assuming that your partner can't hear you because you can't hear yourself. This "helpful echo" is caused by analog loopback in your own phone and is referred to as side-tone. Most late-model IP phones provide side-tone.

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:

 #define AGGRESSIVE_SUPPRESSOR