When asked about the top three network problems that cause bad voice quality, network engineers frequently respond with “Loss, Jitter, and Latency.” Today, we’ll take a brief moment to explain jitter, and why it causes such a headache for VoIP networks.
Since few vendors take the time to explain what these terms mean, and many sales people have only memorized them as industry “buzzwords,” we’ll take today’s post to provide a practical explanation for our readers.
Too Many Triple Espressos
While jitter may sound like a great description of the symptoms of that one guy in the office who has downed a few too many triple espressos, the term has a very specific definition for network engineers.
Out of Order
When your voice, or any audio stream, gets sent using VoIP technology, it generally gets recorded and sent across the network in small ‘snippets’ of between 10 and 30 milliseconds (.01 to .03 of a second). In order to reproduce the sound at the other end, these recordings should arrive in order, so that all of the noises can be reproduced faithfully at the far end. You might think of it a bit like chopping this paragraph into individual words and sending them in separate envelopes. If there was no way to re-assemble the words into the correct order, it would be impossible for an average person receiving them to make any sense of what the writer was attempting to say. For this reason, Real-Time-Protocol numbers these mini-recordings to assist the other end’s efforts to play them back in the correct order. (As an aside, in addition to acting like page-numbers in a book, these number sequences also help us to detect when there are missing bits of audio in the stream of snippets to be re-assembled and played at the far end of a call).
Jitter = Delay Variation
At this point, you may be wondering what causes the packets containing these snippets to arrive out of order. The one word answer is jitter:
- When network and other delays are constant, every packet sent takes exactly the same amount of time and packets arrive in the order that they were sent.
- When the delay across a network varies widely, some packets may take 150 milliseconds to arrive, while others, taking only 60 milliseconds, may arrive ahead of the slower packets, causing the snippets to arrive at their destination in a different order from which they were sent.
Why Am I Stuck In Traffic or Causes of Jitter
In the course of an hour-long VoIP conversation, the delay across the network may swing wildly, from near-instantaneous to over ¼ of a second. The more changes that occur in delay, the more packets arrive out of order.
These rapid swings in network delay can be caused by a number of factors. Just like many morning commuters, the packet may get stuck waiting in a router buffer when a surge of other network traffic is attempting to cross a slower-speed Wide-Area-Network link. Whether there is too much traffic at times or the link is too slow, network bottlenecks are frequent sources of unpredictable delays. Bursts of traffic may also cause random delays for a handful of packets, increasing jitter.
If different packets take different routes, they may arrive at different times. This can be caused by parallel routes to the same destination, load-sharing, or route tables changing the path that a packet takes when getting to its destination. (We’ve all seen this when we wait in line at the grocery store – whichever line we get in always seems to come to a screeching halt!). A ‘flapping’ route, where a low-delay link is available intermittently every few seconds, can wreak havoc on the best efforts of equipment to maintain a predictable delay and to keep audio packets arriving in order.
One common mistake network managers make when looking for jitter problems is to not measure delay frequently enough. If you look at network delay once per hour, you will be unlikely to notice changes of delay that occur three times per second – despite hundreds of swings in delay times, the network delay at 2 p.m. may be very close to the network delay at 3 p.m. If delay is not measured frequently enough, jitter will only likely be detected by the network manager when frustrated users complain of random echoing and ‘drop-outs’ of silence that appear in their calls.
Please wait… Buffering…
Once we identify and correct any temporary network impairments, removed traffic bottlenecks, and architected our network properly (to the best of our budget) we will almost inevitably wind up with some residual (left-over) jitter. How do VoIP devices deal with out-of-order packets? One method is known as the “jitter buffer.” A jitter buffer acts as a “waiting room,” allowing packets to be swapped back into their original order. In figure 2, the receiving VoIP device has a two-packet jitter buffer. The good news? This allows the device to swap two out-of-order packets back in to their original sequence. The bad news? This waiting room enforces a mandatory wait based on the number of chairs — the receiving device must wait until the buffer is filled with two packets before it begins playing any audio. (Many of you have seen a similar effect waiting for web-based videos to load.) A two-packet jitter buffer forces a two-packet long delay on the line. If you are using 10ms packets, this will insert an additional 20ms delay. For 30ms packets, this inserts an additional 60ms delay. As discussed in previous articles, too much delay results in bad voice quality.
Figure 3 shows a larger three packet jitter buffer handling a VoIP connection with even greater jitter, causing packets to arrive even more out-of-order than figure 2. In this case, the larger jitter buffer adds more delay but is able to compensate for packets further out of order. As we know from previous discussions ((hyperlink:echo blog entry)), if this longer buffer causes excessive delay, voice quality will degrade.
No Buffer: Let It Be
What if packets arrive out-of-order but creating a jitter buffer adds too much delay? There is one other common option: In some cases, calls will sound comparatively better if out-of-order packets are merely discarded (or dropped). This technique may cause a one or two packet long ‘dropout’ silence (cellphone users may describe this as “cutting out,” but has the benefit of not adding any additional delay to a call that might be at near maximum delay already.