Best Practices in Troubleshooting a Video Call Part 1

Whether you are an on-site or remote participant, a video call gone wrong leaves a lasting impression on any meeting. To ensure that there’s a flawless collaboration environment is a challenging job to do, but it’s always the goal for a UC engineer. However, we live in a world where so many factors help build the equation of a perfect video call that it’s often not achieved, and that some sort of troubleshooting has to take place. So, what do you do when you’re experiencing a faulty call, topped with frustration, mixed with uncertainty of what to do to troubleshoot a video call?

In a video call experiencing an issue, the UC engineer will pinpoint to four key areas as to what is actually taking place. In this two-part series, we’re outlining the typical scenarios in which a video call wouldn’t connect, along with the best ways to troubleshoot.

Video Call Can’t Connect

Scenario #1: You and your colleagues have a one o’clock scheduled to go over the next big presentation that you are set to deliver at 3pm. You go to connect and nothing. No screen, no ring, nothing. You just can’t connect. This scenario usually points to an end-user issue. To troubleshoot, we suggest:

• Confirm the address
• Redial
• Check on the dial plan
• Use Vyopta’s CPM Monitoring™ module to check the endpoint registration

If any of those troubleshooting tips solves your issue, then pack it up, and call it a day as your job is done. Or, at least most IT teams wish it were that simple. But, sometimes, after doing a quick check, none of those solutions seemed to work to which you then should ask: was the call internal or external? If it was internal, it’s important to check your internal resources, confirming that the meeting was scheduled properly and that the line was available. That should take care of it.

• External video calls that can’t connect require a bit more digging. To troubleshoot, we suggest:
• Ensuring the domain is video enabled. There’s nothing like calling an address with no endpoint available.
• Test dialing from another endpoint
• Test dialing another “good” external number

If none of these work and you still can’t connect, it’s time to bust out the big guns that can help investigate, because it’s a much bigger issue that can’t be solved ad hoc.

Video Call Disconnected

Scenario #2: There’s nothing more frustrating that being on a highly productive video collaboration call and all of a sudden the screen goes blank. We like to compare it to building steam on a train, it takes a long time to get up to speed and to all of a sudden stop causes a catastrophic delay in advancing to the next destination. So, it’s time to troubleshoot and see if you can’t right this proverbial train onto the right tracks again. This scenario suggests it’s a call issue. To troubleshoot, we suggest:

• Checking on capacity and status
• Capacity Limits

Once you’ve given that a check, IT teams get a better understanding of the lay of the land and can tell immediately if it can be resolved or not immediately. But, sometimes that information isn’t so clear, and they’ve got to press further.

In this case, investigate if the call was ad hoc or scheduled. In an ad hoc call, you can see if someone hung up, or if the endpoint crash log reflects any significant findings. If it were schedule, identifying the call end time and if the user had back to back scheduled calls would be helpful to know because a yes to these questions typically solves the problem.

In the unfortunate case that it did not, then the culprit if a network issue. Which just so happens to be the hardest to troubleshoot, which we cover in our next blog series post.

We’ll highlight our next two cases to troubleshoot which includes the aforementioned network issue in our Best Practices in Troubleshooting a Video Call Part 2 follow up blog.

Ready to avoid the heat of a faulty video call? Learn more about how Vyopta’s CPM Monitoring™ locates problematic calls quickly so users can troubleshoot quality issues, failures and user errors immediately.