An Introduction to Jitter for Unified Communications
by Team AppNeta on

Jitter is a term used to describe variation in the arrival times of packets over a network. In packet switched networks, it is sometimes referred to as packet delay variation. Generally caused by congestion in the IP network, jitter can be a serious issue for interactive real-time traffic, e.g. VoIP. This article discusses how jitter is measured in PathView, and how PathView can be used to assess a network readiness for VoIP traffic.

Why does jitter matter?

Imagine the following situation: it’s Friday afternoon, and the phone rings. It’s your largest customer. Unfortunately, you’re on your office VoIP network, which you recently decided to merge with the general office network, and half the office is watching March Madness. Your customer sounds irate, but you can’t really tell. “support … downtime … hadn’t responded … can you handle it?”. After a couple failed exchanges, they hang up.

What they really said was “I had the greatest experience with your support team this week. We had 3 days of downtime, and they worked us through a problem on our side, something that the other vendors hadn’t responded to or even tried to fix. I’d love to expand your coverage to the rest of our business [a 5x increase!]. I wanted to talk to our sales rep first, but she’s on vacation. Can you handle it?”

Their voice had been distorted, and you misread excited for irritated. The phone system was dropping words, but only enough to make you panic. There you were, thinking you were in trouble, when you in fact just hung up on a multi-million dollar order.

How does PathView measure jitter?

Fortunately, that poor quality can be quantified using jitter. For data traffic, PathView measures jitter by determining the mean absolute packet delay variation using the mean RTT and the minimum RTT of a burst of data packets.

For Voice traffic (e.g. VoIP), PathView measures jitter in one of two modes: single-ended or dual-ended. Practically, this is based on whether PathView has control of just one of the endpoints (single-ended), or can measure from both sides simultaneously (dual-ended).

For a single-ended path, jitter is calculated by determining the mean absolute packet delay variation using the mean RTT and the minimum RTT of a series of voice packets.

For a dual-ended path, jitter is calculated by means of instantaneous packet delay variation (difference between successive packets).  The instantaneous jitter is the difference between the receive and transmit interval for a packet.  Jitter is determined by the average difference between the instantaneous jitter and the average instantaneous jitter.

Assessing a Network Readiness for VoIP

Measuring the absolute jitter is useful, but how do we tie it back to VoIP quality, in particular? Measuring the instanteous latency is valuable, but more often, we want to know beforehand if a network can handle the voice traffic. The best way to test this is, well, to load test it directly. Specifically, let’s generate SIP or H.323 voice traffic using PathView Voice. A number of other widely used voice codecs are also supported (e.g. G.711, G.729).

Let’s start with simulating jitter.  The linux kernel tc utility can be used:

[code light="true"]
# tc qdisc add dev eth2 root handle 1: netem delay 10ms 20ms distribution normal
# tc qdisc add dev eth2 parent 1:1 pfifo

This configures the interface with a 10 ms delay and +- 20 ms variable delay.  We use a normal delay distribution because network delay is rarely uniformed.  Also, the pfifo queue is used to prevent packet reordering.

We then setup a basic PathView Voice test using the G.711 codec to run for 5 minutes.  The following charts show the results of this test.  Some key observations are as follow:

  • Voice jitter ranges from 13.9 ms to 19.0 ms (as expected).
  • There are some packet discards.
  • There is no packet reordering.
  • Voice MOS ranges between 3.4 to 4.4 (max).  It’s worth noting that MOS gets slightly choppy from time to time.  A MOS score of 4.4 is deemed to be excellent for G.711.  A score of 3.4 is between fair (slightly annoying) and good (perceptible but annoying).

It is clear that jitter can have a significant impact on a network readiness for VoIP traffic.

unified communications monitoring

Figure 1 - AppView Voice Test Summary

unified communications monitoring

Figure 2 - Voice Jitter and Packet Discards

voip jitter

Figure 3 - Voice Packet Reordering and MOS

Mitigating Jitter

Some well-known techniques to mitigate the effects of jitter are:

  • Jitter buffers
  • QoS

Jitter buffers are used to remove the effects of jitter so that asynchronous packet arrivals are changed to a synchronous stream. The jitter buffer trades off between delay and the probability of interrupted playout because of late packets (discard).

QoS is a way of marking packets so that real-time or business-critical packets (such as voice traffic) are given higher priority than other packets (such as file downloads or HTTP traffic). Specifically, voice traffic should be marked to DSCP EF per RFC 3246.  Voice traffic signalling should be marked to DSCP CS3 or DSCP AF31.

PathView Voice allows configurable jitter buffer size and QoS codes for voice traffic and signalling.  This creates realistic simulated voice traffic to test a network readiness for VoIP.


Filed Under: Networking Technology, Performance Monitoring

Tags: jitter , monitoring technology , NPM , PathView , voip