Hack83.Sniff Out Jittery Calls with Ethereal

Hack 83. Sniff Out Jittery Calls with Ethereal

I have seen the enemy, and its name is Jitter.

One of the biggest concerns when using VoIP is packet jitter. Jitter is the difference in time that packets take to arrive at the final destination. The greater the difference, the worse your calls will sound, and the more you'll want to hang up that phone and return to a traditional telephone system. But it doesn't have to be that way. Instead of throwing your hands up and giving up on the converged network dream, you can just get serious about the jitter problem, and the first step is identifying instances of jitter on your network.

You've seen how to do this in a "big-picture fashion" using RRDtool and sip_ping.pl [Hack #75], but that technique has a few shortcomings. Though it gives you a long-term assessment of jitter conditions on the network, it doesn't do so using RTP, the protocol that carries real voice payloads, and it takes samples only every five minutes, meaning that you can't assess the jitter conditions for any given call. This is where Ethereal can really help you out.

6.13.1. Identify Jitter

If you've looked at "Graph Latency and Jitter" [Hack #75], you've already seen the face of the enemy. With some help from Ethereal, you can zero in on jitter and prepare to squash it like a bug.

When you're examining jitter, you're mainly concerned with RTP packets. To use Ethereal here, you must first locate an RTP packet in the trace file screen. (You'll need to have grabbed a packet sniff like the one you grabbed in "Peek Inside of SIP Packets" [Hack #81].) Once you find an RTP packet in the trace file screen, navigate to Statistics RTP Stream Analysis. Figure 6-12 shows the report analysis.

Figure 6-12. An Ethereal RTP stream analysis lets you know if you have the jitters

By examining the stream analysis, you can see that, at least in this particular sequence, the jitter is nearly nonexistent, staying well below a rate of 1 ms. In a problem scenario, jitter would need to be 10 to 20 ms at a minimum to be audibly perceived (of course, the codec has a lot to do with how much jitter the human ear can tolerate; G.711 is highly resilient to jitter, and G.729 is less so).

6.13.2. The Jitter Solution

Once you've got the jitters, the only way to get rid of them is to implement QoS at the points on your network from which jitter is originating. Typically, these are routers, VoIP servers, or extremely busy switches. More than a dozen different QoS specifications are available (among them DiffServ, RSVP, VLAN, and IP Precedence, to name a few), and there are probably twice that many ways to implement them. So how do you choose?

Good question. There's no simple answer, because each specification is aimed at a different solution. RSVP is a bandwidth reservation technique for WANs, and Virtual LAN (VLAN) is a traffic-segmentation technique for LANs. Both have implications for QoS that are deserving of their own book (I like the hardcover classic, Quality of Service (Cisco)).

Jitter might in fact be a losing battle, depending on how you use VoIP and where your VoIP calls travel. If they go across a network jurisdiction that's out of your control, like the Internet, it might be impossible to provision QoS, and you might never get acceptable voice quality. The moral of this story is very basic: you can perfect VoIP quality on private, controlled networks, but on the Internet, it's a crapshoot.

Joel Sisko