How to Troubleshoot Video Conference Calls and Fix Jitter and Latency Issues

Everyone has had at least one (if not many) video conferencing experience that has scarred them for life. Sounds dramatic, but it’s true. One experience can and will absolutely impact future decisions. How many times have you hesitated to schedule a video meeting? Or gotten anxiety thinking about whether or not the network or video platform will perform as it should? Or what about when you arrived to a video meeting early to make sure everything is connected, the network was operational, and you’re able and ready to present content?

Yeah, those thoughts and behaviors don’t just come out of nowhere! 

What’s so interesting about this is that video issues and user complaints are always the same, and they fall into four distinct “buckets.”

1. the video call won’t connect
2. there is poor audio or video quality
3. the call disconnects while the video meeting is in session
4. or there is no audio, video or presentation sharing

Yet, these issues continue to plague UC, IT, and Network teams. Each one is it’s own, terrible video experience which leads to less video calls being scheduled for fear of poor performance or wasted productivity time and/or more support tickets and user complaints. Video call issues are no good no matter how you look at it.

• End User’s Perspective:  Having a poor video conferencing call leads to hesitation when scheduling future video calls. Who wants to have anxiety about looking like a fool when getting a video call started or waste time trying to troubleshoot, dial again, etc.
• UC, IT and Network Professional’s Perspective: Poor video call performance can lead to an influx of tickets. The worst part is, quite often these support tickets and complaints can be considered “stupid” fixes that could have been prevented if users didn’t get frustrated too quickly. Or, even worse, UC and IT teams simply do not have the time or information they need to effectively troubleshoot the video call and get things back on track quickly.
• The Company’s Perspective: Again, more video issues means less video calls being placed and/or more support tickets and user complaints. Either way, money and time are being not being spent wisely.

What’s (Technically) Happening With Your Video Conference

First things first, you have to understand what your dealing with before you can fix it.

In short, somewhere in the signal path between your endpoint camera (e.g., laptop, hardware, codec, etc) and the other person(s) endpoint, the data being exchanged is running into delays or congestion (this is why “the network” is so easily blamed). Data travels in sequential packets, and video call endpoints track these packets (a.k.a. “Packet Loss”) as well as the packets that arrive out of place (a.k.a. “Jitter”). Although online data traffic allows for you to simply resend the packets that were lost, video data does not. Video conferencing has a time dependency that is far more strict than when streaming content. There is no time to buffer because it’s unclear what is going to happen next. This means there is no way to simply resend lost packets because by the time they arrive, they are no longer useful.

Video Call Troubleshooting Tips (For Amateurs)

Here are three things anyone can do to fix a video call without having to contact a UC, IT or Network professional.

Lowering Device or Software Bandwidth: Check the bandwidth and resolution settings on your device or software. Most endpoints have a maximum bandwidth of 1920 kbps and that’s rarely necessary (or advisable). Lowering your device or software bandwidth to 1472 is hardly noticeable to the naked eye, but can save 24% bandwidth. This means fewer packets and less chance of packet loss. If you make this adjustment during a video call, you will likely see the call improve. Honestly, this is a very common problem since 1920 kbps is the default setting. Many video conferencing manufacturers want to show max performance or flaunt high numbers for marketing purposes.

Redial: The internet is a complex bunch of wires and switches with many possible paths for video streams. Sometimes a video call can simply get routed down a “bumpy road” that can really impact video call quality. In this case, take the simple fix and redial. Simply hanging up and dialing again means your call will probably travel through the web differently and, most likely, more efficiently. Taking this step and coupling it with step #1 (above) can really make a big impact.

Restart: It hurts to hear, we know! There is a reason you’re tired of hearing “turn it off and on again” is because – it works! This tactic is especially helpful when there is a pending software update is waiting to be installed and is mucking up your performance.

Video Call Issue Troubleshooting (For Admins)

Ok, here is where the magic happens. The following combines lessons from dozens of video conferencing and network administrators who have survived hundreds of horror stories and systems failures. Let’s take a look at how to troubleshoot a video call once it reaches the help desk. 

User-Error vs. System Error

Frist, you need to know when the problem is user-error versus system error.

MCU (a.k.a. “Bridge”): If the call is going through an MCU (or VMR) in your network, then you can check to see if the call is successfully pulling through that bridge.

1. Check Bridge Capacity: The first thing to check is the call capacity on the MCU. If it is close to the limit (>80% used), then the MCU may be rejecting calls due to lack of capacity. Sometimes MCUs will reserve ports for calls in progress in case one or two more people want to join without labeling them as officially “used.”
2. Review Call Statistics: While you’re checking call capacity on the MCU, pull individual call statistics. You can review which part of the call is specifically having problems. For instance, if it’s the “transmit” side of the video call, then the problem is at that end. If it is the receive side, then it might be an internal network issue.

Call Control: Every call goes through a call control, such as a VCS or Unified Call Manager. Sometimes the call control functionality is in the bridging and control service.

1. Capacity Limits: Call control devices have capacity limitations, so it’s important to check this although they don’t usually reserve extra ports like MCUs. By reviewing capacity limits, you’ll be able to determine if the call is being made internally, or if the call is traveling to an external network through some sort of border controller, thereby using a traversal license.
2. Traversal or Expressway?: In many cases, like VCS from Cisco, if a call goes through a Traversal or Expressway device the media is routed through the infrastructure. This means that all the call quality statistics are there for you to see and gives you another perspective on “where” in the network the issues might be happening.

Endpoint Settings: This may not be reasonable for you given that you may have received the information from the customer after the call was bad. If the call is active, you can log in to the endpoint via the Codec IP or a remote desktop application if it is software. All of these endpoints do track some statistics for calls in progress, allowing administrators to see if the errors are happening at the “far end” of the network.

Not finding an issue? If you can’t see anything that looks like a problem (e.g., video call errors, altered call settings, bad configurations, etc.) then chances are good this is a user-error. This means you’re going to want to confirm with the user the steps they went through, how they dialed into the meeting, and urge them to follow the “amateur” troubleshooting steps as outlined above;

• Lowering device/software bandwidth
• Redial
• Restart

It can feel like a vicious cycle, we know. However, in time, you can nip end-user issues in the bud. From there, you can focus on systematically start troubleshooting the video call and quickly determining if it’s an AV equipment issue, video platform problem, the network, or an issue on the far end.

Proactively Fix Video Quality Issues by Working Smarter

It’s rare to be able to diagnose a call issue definitively just by looking at that single call. What you really need to do is look at other calls happening at the same time to see if any of them are having similar problems. An easy way to do this is to use real-time monitoring and analytics to review call quality numbers in bulk.

• Packet Loss: Could be caused by a misconfigured network switch or heavy congestion at a network switch. Just like milk, anything over 2% could be bad for users.
• Jitter: Mostly caused by congestion. This occurs when packets are received out of the regular order. In Jitter, anything over 20ms is detectable, especially in the audio signal.
• Resolution: The key determinant of bandwidth is the resolution. 1920×1080 is usually the default, even though calls rarely require or achieve this amount. Most calls are fine with 720p or even 480 (also known as Standard Definition).
• Frame Rate: Usually you only want to know if the bare minimums are being met. Presentation sharing doesn’t need to refresh as often the video feed, so it can be around 5-7 fps. Video feeds are usually maintained at 30 fps as more changes occur in a video than in a static presentation. The frame rate is a function of bandwidth and resolution.
• Bandwidth: High bandwidth can be more susceptible to the effects of packet loss, but low bandwidth means that it can be hard to tell what is going on in the call and decreases the effectiveness of having a video meeting. Many modern endpoints will reduce the bandwidth automatically if they detect too much packet loss or jitter.

If the above list (or other industry terms in this post) have been a little over your head, check out our Unified Communications Encyclopedia of Essential Terms and Acronyms.

The Overlooked Teleconference Issues

Here are a few simple steps that frequently help us and our customers at Vyopta get their video conferencing network under control;

Check Device Firmware: One thing that many people do not check as frequently as they should is the firmware version of both the endpoints and the infrastructure devices in their network. For some reason, video infrastructure gets overlooked in the IT world. Usually, these updates can help with both call success, error logging (for troubleshooting) and security (updated encryption). Updating the firmware is usually pretty simple and fast compared to updating other network devices. You should make sure you can handle calls without that device for a short time.

Check Device Configuration: We all know it happens; someone on the team plays with some settings in order to help solve a live call problem and then they “forget” to reset to previous settings afterward. Inevitably, the next call inherits the difficulties, and nobody recorded the change. It is helpful in this case to have documented the configuration for your different pieces of infrastructure so that there is one authority on the topic.

Capacity Issues: There really isn’t much you can do immediately for capacity issues, unless you can go into Cisco’s older MCUs and click and drag calls onto different MCUs without disrupting the call. This is a very cool service that allows you to balance your load. Most modern MCUs do load balancing already, but it can help with older pieces of infrastructure like Polycom or Codian MCUs.!

Hopefully, this guide gives you some good ideas how you can solve video issues in less time! Feel free to let us know if you have any questions or comments, or a horror story of your own in the comments section below. We would love to hear from you.