Skip to main content
Cisco Meraki Documentation

What is Jitter?

In simple terms, jitter can be described as the varied delay between received packets. To better describe this, consider a telephone call: voice is converted to digital bits (1’s and 0’s) and is encapsulated and sent across the network from source to destination. At the receiving end, the packets are de-encapsulated and converted back to an analog frequency which can then be heard on the receiving phone. These packets should (and are expected to) travel at evenly distributed times, but there are occasions when they can arrive at irregular intervals due to various network issues.

For example, if voice packets are transmitted every 10 milliseconds. It would stand to reason, then, that they would be received at 10ms intervals. However, what if  packets are seen arriving after 20ms and others after 40ms, or perhaps several packets don’t arrive when expected and then suddenly they arrive all at once. This variation in the delay of received packets is known as jitter. The variation is not necessarily the result of packets being dropped, but it makes any conversation or video feed sound or appear as if they were.

Jitter (2).png

How to Mitigate Jitter

Network congestion, faulty queuing and configuration errors are several factors which can contribute to jitter in a network.


  • A well-planned and well-designed LAN should experience minimal jitter. Ensuring there is enough bandwidth and good physical network connections throughout the topology helps mitigate potential network jitter.
  • Network health monitoring tools can be used to detect congestion in a network. If jitter or congestion is the result of a poorly designed network, then the issue may persist and reappear.
  • Setting alert thresholds to warn of possible congestion on a link would allow an administrator to tackle the issue before it has a serious impact on end users. If link utilization is 80% or over, this is a good indication that a high level of jitter exists.
  • Buffers can be used to alleviate jitter but they are not a long-term solution. A buffer will collect and delay incoming packets, correct any out-of-sequence errors and will forward them at evenly spaced time intervals. By implementing quality of service (QoS), buffers can be used to manage VoIP traffic or other high-priority packets which when identified are immediately processed and sent out.
  • In situations where there is significant jitter, instead of creating delays in the buffer, it may be better to drop packets or create a fixed buffer size. If buffers are full they will be unable to contain all arriving packets.


WAN networks can experience significant jitter, especially when traffic has multiple paths and hops to a destination, or when load balancing through two comparable paths. However, there are several countermeasures that can be adopted to minimize these effects:

  • Implement QoS via a service provider as part of a managed service.
  • Utilize MPLS circuits. MPLS minimizes the effects of jitter by providing guaranteed QoS.
  • Use WAN virtualization - WAN virtualization tackles congestion-based jitter as it occurs by measuring one-way latency across all paths and will migrate data onto another path if it detects significant jitter.

Determining Acceptable Levels of Jitter

It is unlikely that a given network will experience zero percent jitter in all circumstances throughout the day. Jitter is expected to some degree and should be managed, not eliminated. Knowing this, how would an administrator determine an acceptable level of jitter for their network, or for certain services within the network that may be sensitive to jitter?


Every network administrator wants to ensure they are providing consistent high quality voice traffic, but at times this can be easier said than done. Many factors can affect voice quality within a network and the most common metrics used to measure voice quality are jitter and latency. Network congestion or slow speeds may result in packets being received in a different order from how they were sent or being dropped; either way, this will affect voice quality.

Jitter in excess of 40ms can cause severe degradation in the quality of a call. Cisco's Enterprise QoS Solution Reference Network Design Guide suggests the following guidelines for voice:

  • Delay (one-way): 150 ms or less
  • Jitter: 30 ms or less
  • Loss: 1% or less


Jitter can hinder video and gameplay and impede on the expectations of your users. For interactive video streams, jitter should not exceed 30ms. For streaming video such as Netflix, HBO, NowTV and Amazon Prime, jitter is far better tolerated because video streaming is unidirectional and when using a large buffer more data can be cached. Videoconferencing is more complicated as it utilizes bidirectional streaming. Real-time conferencing and high bitrate video can encounter noticeable issues when jitter is present within a network.

The most notable symptoms of jitter is frozen or jerky video. A general rule of thumb is to ideally keep jitter for video between 30-50 ms.


The most common cause of jitter is network congestion at an egress point within a network, be it a switch, a router or even a firewall interface. For the most part jitter buffers will be incorporated to mitigate or smooth over any issues, but excessive jitter can cause these buffers to overflow, which in turn will cause packets to be lost. Conversely, if the buffer size is too large then the network will experience excessive latency.

Calculating Jitter

Most use cases requiring the measurement of jitter are likely to be concerning measuring some form of UDP traffic, such as RTP and SIP. This is easily performed and analyzed in Wireshark.


In the example below, an RTP stream can be seen:

Screen Shot 2020-02-20 at 3.15.46 PM.png


Navigate to Telephony > RTP > Stream Analysis:

Screen Shot 2020-02-20 at 3.21.32 PM.png

This will analyze the RTP stream for max jitter, packets lost, and other statistics:

Screen Shot 2020-02-20 at 3.22.45 PM.png

The example above shows a mean jitter of 18.02 ms, well within the acceptable limits of what a good RTP stream should look like.

  • Was this article helpful?