Do your users complain of poor call quality? Do you want to find out if they’re imagining it or not?
As with many other things, our app makes this easy.
If you already know these fields well, then feel free to skip to the next section! Otherwise, read on for a bit of a description.
Cisco used to only provide jitter and latency information for calls. This was useful, but had some difficulties in actual use. It was hard to compare these for different length calls, and the actual metrics were only proxies for “possibly bad” calls. I mean, sure, lots of jitter is probably bad, but how much is lots? And what about small or medium amounts?
Later they combined these with the Mean Opinion Score (MOS) based scores: MLQK, MLQKav (average MLQK), MLQKmn and MLQKmx (min and max MLQK). This is a relatively simple system with values that are fairly easily grasped.
But the algorithm they use to determine MLQK doesn’t seem to be consistent across different codecs and using MLQK based scores isn’t easy when comparing calls of significantly different length. The scale leaves something to be desired too – 0 to 4.5 in Cisco’s case instead of 0 to 5, and many devices seem to only report 2 to 4.5. With it taking about 0.5 difference for the call to be noticeably better or worse, that doesn’t give a lot of range. Still, these were quite useful.
For various reasons, Cisco is now moving to concealed seconds based scores. CS (concealed seconds) is how many seconds of talk time was missing or garbled, but which Cisco “filled in” probably OK enough. The one to worry about is SCS (severely concealed seconds) which are seconds for which a part of the time was garbled enough that it was difficult or impossible to understand. On top of CS and SCS, we build a few fields that make it even easier to compare and contrast different calls with. CSR_overall and SCSR_overall. Both of these are ratios of concealed or severely concealed seconds over all call legs.
You can read more about each of these in our Home tab. In the bottom pane where there’s a list of fields, set the filter by area: dropdown to Call Quality. Yours should list 21, but it might vary depending on what data you actually have. Don’t forget there may be more than one page of results!
Typing a specific term into the search box right in that same row would let you filter down even farther, if you didn’t want to page around and knew what field you wanted to read up on.
(As with all screenshots on this site, click on it to get a larger version!)
Now that we know the fields, showing them in Browse Calls is really easy.
In the below screenshot I have added all of the quality fields. I have also removed some of the number fields and the cause_description field as well so that my tiny screenshots don’t get *too* cramped. You probably will leave cause_description, at least. 🙂
The get only dropdown is occasionally very important when browsing sparse data. Browse Calls is built to be fast, and one of the ways it does that is that it only by default looks back at the last few thousand call legs in any time period. You can see it read about 3000 records off disk and returned 290 calls in my test data for August 25th.
But if you are trying to find a needle in a haystack and your haystack is significantly larger than 1000 calls, you won’t get all the results you need until you flip that to a larger setting. Like in our case, I’ve got about 40,000 calls per day and later we’ll be filtering things to only show a small portion of those calls. If I left the dropdown at its default of only the last 1000 call legs, I’d just be missing a lot of my filtered data from the list.
Here I’ve changed it to all records and you can see that except for returning a lot more calls, nothing really changes. Later, this will be important.
Not surprisingly, Browse Calls acts a little like a spreadsheet. Click a column header to sort that column descending, clicking it again toggles it from descending to ascending and back again. For some reason folks forget you can click on time to change back to the original “by time” sort order.
Following the “spreadsheet” theme, there’s even an export button available. Second button to the left of Create Dashboard Panel looks like
and will just export the results as a CSV file that you can open in Excel, Google Sheets or even a text editor. Do note there are Splunk limitations on how many records you can export using this method, but it’s usually pretty high (By default up around 50,000 I believe).
That third call down (highlighted) is very interesting. Someone stayed on the phone for almost a minute and a half where nearly a minute of it – 56 of the 82 seconds – were unintelligible. It did end on a high note – the last 8 seconds had an MLQK of 3.6 which is generally fine. Though note the MLQKav gives the same story as our CS and SCS numbers at 2.1271, which is pretty poor.
The rest of the calls there are rather short which is to be expected – an MLQK of 2.0 or SCSR_overall of 50% or more means after a bit of trying to understand one another they just hung up. “What? Hello? What did you say? Oh, never mind I’ll call back in a few minutes.”
Oh, the fun we’ll have!
Let’s look for where MLQK is under N. Where N is whatever you would like.
This work exactly like the above. Let me erase my existing MLQK search filter and show you this too.
Let’s search for SCSR_overall over 30%. That’s where 30% or more of the call was garbled.
I’ve shown you how to filter to a certain subset of calls based on one criteria or another, but what if you wanted multiple search criteria?
Also easy – it’s exactly like above, only just filter it multiple times. The default boolean join is an AND, so if you have multiple terms they’ll be X AND Y (AND Z etc…)
Let’s say you want where MLQK was below 2.5 and also where MLQKav was above 3. This would be calls where the overall quality was OK (3 and above), but where the last 8 seconds was pretty bad (2.5 and under). Calls that “went downhill”.
So we just “AND”ed two filters together. Pretty simple.
Suppose you want to see where either they hung up in disgust because the last 8 seconds of the call was terrible OR where the entire call was pretty bad?
What we want here is to use a search filter like MLQK<“2.5” OR MLQKav<“3”, but can we?
You can add as many of those as you want. If you mix OR and the default AND together, be careful and parenthesize!
You can also filter by phone numbers. Here I just clicked on one of the numbers and am selecting see only calls to/from <number>
And that gives me just the one result.
You can add more numbers in; usually it’s easiest to just type them in with a comma between then. Wildcards are supported, so this here: 112233, 4545*,*5555 will find where the number is 112233, where it starts with 4545, or where it ends in 5555. That last option is handy if you don’t know for sure how the number looks in the CDR data. For instance, if my number was 7158917420 but I don’t know if UCM will report that as 17158917420 or 917158917420, I could just use *7158917420 to catch them all.
And by now, you should realize you could remove one or more of the search filters that are in place to “widen the scope” a bit if you wanted.
If you stumbled across this article and haven’t installed our trial yet, you should do so.
Download your 90 day trial license now.
Building a “report” of any of this is also real easy, so if you wanted a pretty chart out of MLQK values over time, or even of counts of the MLQK values (not over time), jump straight to step 4 in our Quick Wins blog to put it on a chart!
And, our docs on Quality also rehash similar information in a different way, so it might help too.
Lastly if you have any questions, about how to do other things – first search our documentation and blogs, but if you can’t find an answer send us an email at email@example.com.
And as always, if you have any feedback on the above instructions email me at firstname.lastname@example.org.