Dear User,
Regarding the voice quality issue that you reported, could you please provide the following information so I can troubleshoot?
Thanks,
Voice Engineer
If you are a voice engineer and have experience in troubleshooting voice quality issues, I believe you have written a similar email or had a conversation with end-users asking these questions. In my experience, it is a pretty rare case that the end-users can provide accurate answers to all of your questions. In some cases, a user might even report exaggerated statements thinking it will help to pressure and solve their issue quickly while it just puts voice engineers into a maze of voice troubleshooting labyrinth due to misleading information.
Voice engineers need to know what is going on at the site to start troubleshooting, but getting accurate first-hand information is often one of the most difficult parts of the voice troubleshooting world. Additionally, apart from those questions to an end-user, we need even more information, such as codec, jitter, packet loss, etc.
How do we get the best information?
➡️ Asking lines of questions to end-users?
➡️ RTMT Trace on CUCM?
➡️ Debug on a voice gateway?
➡️ Logs from a phone?
➡️ Or use of a CUCM native CDR tool?
And after all of this, you might not even find the call you are looking for - maybe the date/time provided by the end user is incorrect? Now what? Ask the user again? Send a tech to the site? Or maybe you drive to the site if it is close? Yeah fun time begins...
Let me show you how Call Record Analyzer can help.
Let's say that you receive an escalation from a helpdesk that a user experienced a voice quality issue yesterday. No specific time and no calling or called number provided (of course).
Take a look at the CRA reporting tool screenshot below (10 digits DID and IP have been blurred)
LOOK AT THAT!
You have the called number and calling number as well as date and time (up to the second)! If you have to work with a service provider who is asking for "fresh" call samples, you can give them instantly! You just need to know the extension of the phone that you are looking for to get this info. I bet all end-users should be able to provide their extension pretty easily.
HOW SWEET IS IT?
You have all the info on one page instead of having to ask users. Now, you have solid information to start investigation and troubleshooting. You probably want additional information, such as jitter, packet loss, latency, codec, etc. that you would collect from different places/resources in the voice environment. Well, you might have already noticed but some of that information is already displayed!
There is codec identifier, source and destination IP, and disconnect cause code. For now, you have to reference Cisco documentation to find the name of the codec HERE but it is still WAY better than going through traces and debugs to find it out. In addition to this information, you have access to even more stored in CRA. You can simply click a phone number on the report to pull the information like below:
At this point, you have most of the information you would need for troubleshooting. The only information you cannot probably get is a debug output on a live call, but most likely you do not even need to run a debug with the information available through CRA.
ADDITIONAL FUNCTIONALITY
There is another really cool feature that CRA has that I want to share.
Okay, we now have lots of information about calls to or from a specific number. That is good, but this phone number makes or receives dozens of calls a day! Do I need to go through all of the calls on the report to see which calls (out of dozens) I had an issue with jitter, packet loss, or latency? That will seriously hurt my eyes ~ so how about this instead?
Yeah! CRA can highlight calls with jitter, latency, or packet loss beyond normal VoIP thresholds! You can just click the "Check for Network Issues" button on the top of the page.
Highlighting those calls on the report seems to be such a simple concept, and it is extremely helpful and useful.
During troubleshooting you probably want to find out if the reported voice issue is affecting only a specific phone(s) or a large group of phones. If it is affecting just one phone, then hey, maybe it is just a Layer 1 issue or even the other side of the call. Try rebooting, swap handsets, and see what happens (and get a cup of coffee). But if it is a large group of phones being affected, then get a cup of coffee and start looking into the network infrastructure.
Again, this is simple information, but very useful. Without a tool like CRA, you have to ask users if other people are experiencing the same issue. However, there is not practical or reliable information in most scenarios.
So, here is an example of how to utilize this feature:
Just by looking at this page, not even having to look at anything else, you can tell that calls in this department (yes, you can create a group and run a report for that group only) are having an issue regardless of the phone number involved. This indicates that the issue might be related to the network for this department, such as QoS settings, bandwidth availability, etc.
CRA provides light for voice engineers to troubleshoot voice issues. Imagine how long and what it would take to get this much information on a voice issue if you are troubleshooting without a tool like CRA. You might still be exchanging emails or playing phone tag with an end-user trying to gather more information.
To learn more about how CRA may work for you, give us a shout.