When you first learn about ‘jitter’, you might think it’s a resurgence of a 1940’s dance craze. Happy people dancing around is not what results from a network that has problems with jitter – unhappy users complaining about poor quality VoIP/UC and video sessions are the real-world result.
What is Jitter?
In a perfect world, packets transmitted every 10ms should arrive at their destination every 10ms so the listener has a perfect experience. This would equate to a jitter of 0ms because there is no variability in the received packets.
In the real world, some packets may be delayed, thus causing some packets to arrive late, with the packets behind them all being bunched up and arriving too soon behind them. It’s like the chocolate factory where you want the chocolates to arrive once every five seconds so you can wrap them. If there is a delay and no chocolates show up, then the workers get a break and have nothing to do. When the chocolates start showing up again, they are all bunched together and some have to be discarded in order to “catch up”.
This “break”, and the discarded chocolates, all equates to missing audio and video information that the receiving codec can’t process.
Related Post: Intro to Voice Quality: Jitter
What Does Jitter Sound Like?
Jitter affects real-time protocols like VoIP and video by creating drop-outs, clipped words, and video artifacts. It ends up sounding the same as if there was packet loss, but there are no actual lost packets – just delayed ones that are too late to be used by the receiving codec.
What is Acceptable Jitter?
In general, jitter should be below 30ms when received by the endpoint.
Most video and audio codecs can deal with a certain amount of jitter, and some are better at handling jitter than others. Devices contain jitter buffers that are used to reduce the effect of jitter. If jitter is higher than 30ms, then the codec in the receiving endpoint will have problems splicing the conversation back together to have the audio sound smooth to the listener. All of this re-assembly of the conversation has to be done in real time. As a result, a jitter buffer can only accomplish so much repair before it has to give up and discard a packet that arrived out of its time window.
How Do You Detect Jitter?
Jitter can be detected in a variety of methods:
- Packet capture: Software like Wireshark can detect jitter by looking at the inter-packet gap between one direction of Real Time Protocol ("RTP") packets. Packet captures should be done as close to the receiving endpoint as possible to get a correct jitter measurement. If a capture is performed in the middle of the conversation, and the jitter is caused closer to the destination , the capture may not see or detect any jitter. Related article: 5 Reasons Why Troubleshooting VoIP Problems with Wireshark doesn’t work
- CDR Records: CDR records on phone systems may show jitter numbers, or sometimes just “peak jitter” during a call. Related post: The Tools Needed for VoIP Troubleshooting, Part Three: CDR Analysis
- RTP-XR Reports: If your phone system supports RTP-XR (RFC-3611 & RFC-7005), then the RTP-XR records will report real-time jitter buffer usage and drops.
- Call Simulation: If you run a call simulator across a network, it should show jitter between sent packets. In many cases, this is the simplest way to detect jitter, as it can be seen during the simulation test. Related post: VoIP Network Assessments—When It Comes to Call Quality, Faster is Better
What Causes Jitter?
When packets are sent over a network interface, it must put the packet into a queue to be transmitted. If the queue is empty (no other packets to be sent), then the packet can be immediately dispatched to the network.
| Note: | If the interface is configured to run 10meg or 100meg half-duplex, then there is a chance for collisions to occur. This has the potential to add a few microseconds of delay, as the collision backoff algorithm will delay a random number of Ethernet timeslots. This delay is insignificant and won’t add to jitter or latency calculations, but may add to packet loss. For more information, check Wikipedia: Carrier-sense multiple access with collision detection. |
If there are other packets to be sent, then the queue may get very long and jitter will increase as the VoIP packets are stuck inside buffers. This is made worse if there are data packets, as they tend to be larger (1518 bytes) and will create more delay.
| Note: | Jumbo frames may be configured on interfaces. These permit payloads of 9018 bytes and larger to be sent on links. This can further exacerbate jitter if there is a lot of jumbo data frames on links that are also configured for VoIP. For more information about Jumbo frames, check Wikipedia: Jumbo Frames. |
This “queueing delay possibility” will occur on every network interface involved along the path through the network. This means that there may be hundreds of interfaces involved in passing traffic for a VoIP/UC or video call, and each of them may be queuing other packets that will create a little bit of jitter for the conversation.
| Note: | Jitter is exponentially worse on slower links that are congested. This is due to serialization delay of getting the data on the wire. Even if an interface has low utilization and is not dropping packets due to bandwidth limitations, it may still be causing problems for jitter. Increasing bandwidth will help improve this and reduce jitter. |
Jitter can also be caused by CPU limitations on network devices. If a network device is “CPU bound” and is not using hardware ASIC chips to route or switch packets, the CPU may become a stalling point, thus causing some packets to be slowed down on their way to the destination.
Preventing Jitter Problems
Preventative steps to avoid creating jitter in networks are:
- Enable QoS on bandwidth constrained links: If you have network links that are 10Mbps or slower, QoS should be enabled to give priority to VoIP/UC/Video packets. VoIP and UC packets are usually DSCP tagged with decimal 46 for Express Forwarding or ‘EF’. The QoS should respect these tags and always give these packets priority by sending them before any data packets are sent.
- Track DeferredTransmissions SNMP error counters across the network: The DeferredTransmissions counter tracks how many times a packet could not be immediately transmitted and had to be stored in a buffer. This buffering activity may add a few milliseconds or more to a packet’s travel, thus increasing jitter. If you are aware where this is happening, you can either increase bandwidth on the link or add QoS to reduce the chance that VoIP/UC is affected by a bandwidth limitation. Related post: The Tools Needed for VoIP Troubleshooting, Part Four: SNMP Collectors
- Track Router CPU Utilization on all VoIP/UC Involved Routers and Firewalls: If a router slows down because its CPU is spiked for a few milliseconds, that can create jitter problems downstream.
- Reduce Latency to help tame Jitter: If you can reduce overall latency in your network, it will also help reduce jitter. For example: If you have a hub and spoke MPLS environment, and one remote office calls another remote office, the traffic must go back to headquarters and then back out to the remote office. If you work with your MPLS provider to enable a full-mesh MPLS environment, then each remote office can directly send traffic to the other remote office. This will dramatically reduce latency, and also any potential jitter problems as well.
Troubleshooting Jitter Problems
Troubleshooting where jitter is coming from can be challenging due to the number of network interfaces and devices that need to be checked.
Troubleshooting Jitter can be a two-step process:
- Narrow the scope of the problem: You can use a single-ended call simulator (like the call simulator included with PathSolutions TotalView®) to perform test calls to midpoints in the network to determine if jitter is present or not. For example, if you test to the far-end of your MPLS link and determine that jitter is stable to that location, yet shows significant jitter spikes when you test to the next-hop router and every device beyond that point, TotalView is very quick to determine that the jitter is coming from the network segment between the MPLS and the far-end router. Related post: Are VoIP Problems Driving You Nuts?
- Investigate the involved Network Devices for Buffering, QoS, and CPU spikes: Each of the involved devices in this segment should be checked to see if they have any DeferredTransmissions, CPU spikes, utilization problems, or slow interfaces that have incorrectly configured QoS.
|
Notes: |
VPN tunnels will typically add latency and jitter to a conduit due to the encryption overhead that is typically performed on tunnels. Involved firewalls should have their CPU tracked to make sure they are not having problems with the encryption activities for the VPN tunnels. End station clients running VPN software might also create significant jitter if the CPU spikes due to other applications running at the same time. |
Since Jitter is a sporadic problem, you may not be able to find the source of the problem if you don’t have a historical perspective of the above information.
Remember that Jitter is Additive
A little bit of jitter detected on a single router or switch may not be of much concern, but consideration should be given to its affect throughout the entire network. If a little bit of jitter is added during each step across the network, you may end up with some very large jitter swings (between 5ms and 50ms) at the remote end of the network.
Additionally, if you reduce jitter in the parts of the network that you control, it will help reduce the effect of jitter added in parts of the network that you do not control: SIP Trunks, and VPN tunnels.
Overall, jitter can be prevented if the right information is brought to bear about your network’s performance.
Interested in learning more? Download our VoIP troubleshooting white paper.r
