Any built-in tools for monitoring call quality (live) on CUCM server (10.5) ?

[voip7372]

Hi

I know about and use the RTMT, but that only seems to show me the calls after they've completed and no info about the call quality such as info on jitter and packet loss.  Are there any built-in tools for CUCM 10.5 that can monitor calls live on the server (not monitoring at a router/gateway because I want to see info on tandem calls on SIP trunks I have that are passing through the CUCM server to another entity).

For example, what I would love to be able to do is the following...

1. Watch live calls as they're setup to troubleshoot failed calls, like calls that never complete for various reasons

2. Watch live calls to see if there is jitter or packet loss on certain calls

3. Watch live calls to see what digits the calling entity is sending to CUCM

Again, I'm asking about looking at the server itself, not monitoring a router/gateway.  The calls I'm interested in are tandem calls that come in to CUCM on SIP trunks and then go right back out of CUCM to another entity, like Microsoft Unified Messaging server, for example.  

Is there a way to do this type of monitoring using the command line interface (via VMWare, for the CUCM server in question)?  What about some other tool from Cisco that could be downloaded separately?  

Thanks for your help.  I'm just looking for more ways to monitor and troubleshoot any problems we might encounter.  This sort of thing is very easy to do on an Avaya server I manage, but I'm struggling to find the right tools and right methods to monitor/troubleshoot the calls on CUCM server.  

[Manish Gogna]

Hi,

There are no such options on CUCM to provide call quality details of live calls. You may look at the CMR data but that will be for completed calls.

HTH

Manish

[voip7372]

Thanks.  Does that also include any info about the call quality for those completed calls?   I mean, anything about packet loss and jitter for example?

[Manish Gogna · Accepted solution]

Yes, it contains info about jitter , latency , packets received , packets lost etc

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/8_0_2/cdrdef/cdradmin/cdrcmrf.html

Manish

[voip7372]

Ok, thanks.   I just looked at the CMR report from our system.  I see many calls in the report, but the fields shown below are all blank, as if there's no data for those fields.  I would have expected to see something there, but is that totally normal for those fields to be blank in some situations, even the "orignumberPacketsReceived" field?  

orignumberPacketsSent

orignumberOctetsSent

orignumberPacketsReceived

orignumberOctetsReceived

orignumberPacketsLost

destnumberPacketsSent

destnumberOctetsSent

destnumberPacketsReceived

destnumberOctetsReceived

destnumberPacketsLost

origjitter

destjitter

origlatency

destlatency

[Manish Gogna]

For CMR data to be populated, the "Call Diagnostics Enabled" service parameter needs to be enabled.

Manish
 

[voip7372]

Perfect, thanks.  I'll enable that :-)

The attached image shows how it was set....so I changed it to Enabled regardless of CDR enabled flag.   Is that correct/proper?  

[Manish Gogna]

Yes, this will generate CMR irrespective of whether CDR is enabled or not. Please remember there are certain types of calls for which CMR may not be generated, try generating reports for a few diff types of calls / endpoints and check the results.

Manish

[voip7372]

Sorry, one more question.  I still don't see any data in those fields after making the change I mentioned above.  Is there anything else I need to check or does something need to be reset for this change to be implemented?   I do see data in the other fields that show the numbers dialed, originating device, etc....but not data about packets received/sent, etc. I'm talking about the CMR report, not the CDR report, just so you know for sure I'm looking at the correct report.  I know the CDR report is not designed to show the packets received, etc.  

EDIT:  FYI - The CDR Enabled Flag is also set to 'True'.   For the record.  

The system is definitely creating the CMR reocrds....but the only 'problem' I see is that the info about latency, packet loss, jitter and other things like that are blank in the reports.  there's just no data for those fields.  

[voip7372]

I found it!  :-)

Go to the CDR Analysis and Reporting page and then go to System > Scheduler > CDR Load.  UNcheck the 'Load CDR Only' box and then click update.   A few minutes later the CMR data for the jitter, etc will begin to show up in the reports.  

Help page says:

"Under the default setting, only CDR records continuously load. The CMR records do not load. You must manually uncheck the Load CDR only check box to force the CMR records to continuously load with the CDR records"

[Manish Gogna]

That's right, it should do the trick.

Manish

[voip7372]

Sorry, I'm full of questions today :-)

I'm looking at the report now and I was wondering what the values mean for Jitter and Latency.  For example, if there's a 5 in the OrigJitter field, does that mean 5% or something else?  What about a 13 in the OrigLatency field?  What exactly does 13 mean in this case?  If there's a document that describes all this, I can look at that if you point me in the right direction.  Thanks

Update:

Looks like I found it, but it's not exactly as clear as I was hoping for :-)

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/10_0_1/cdrdef/CUCM_BK_CBB143DE_00_cucm-cdr-administration-guide-100/CUCM_BK_CBB143DE_00_cucm-cdr-administration-guide-100_chapter_0111.html

For example:  Jitter

This field provides an estimate of the statistical variance of the RTP data packet interarrival time, measured in milliseconds and expressed as an unsigned integer. The interarrival jitter J specifies the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver, compared to the sender for a pair of packets. RFC 1889 contains detailed computation algorithms. The value remains zero if the connection was set in "send only" mode.

[Manish Gogna]

Hi,

There are many links on the internet about this but i found the following one as easily  understandable by everyone.

Latency
A measure of the delay in a call. We measure both the round-trip delay between when information leaves point A and when a response is returned from point B, and the one-way delay between when something was spoken and when it was heard. The largest contributor to latency is caused by network transmission delay. Round-trip latency affects dynamics of conversation and is used in our MOS calculations. One-way latency is used for diagnosing network problems.

With round trip latencies above 300 msec or so, users may experience annoying talk-over effects.

Jitter
Jitter refers to how variable latency is in a network. High jitter, greater than approximately 50 msec, can result in both increased latency and packet loss. Let's see how.

When talking to someone it's important that they hear what you say in the same order that you say it, otherwise they won't understand what you're telling them. Unfortunately, jitter causes packets to arrive at their destination with different timing and possibly in a different order than they were sent (spoken), with some arriving faster and some slower than they should.

To correct the effects of jitter, VoIP endpoints collect packets in a buffer and put them back together in the proper timing and order before the receiver hears them. This works, but it's a balancing act. Processing that buffer adds delay to the call, so the bigger the buffer, the longer the delay. Remember the effects of latency? Keep in mind, no matter how big the buffer is, it is finite in size. If voice packets arrive when the buffer is full then packets are dropped and the receiver will never hear them. These are called discarded packets.

Packet Loss
Just as it's important to hear what someone says in the order they say it, it's also important to hear all of what they're saying. If you miss one out of every 10 words or 10 words all at once, chances are you're not going to understand much of the conversation. This is packet loss some of the voice packets are dropped by network routers or switches that become congested (lost packets), or discarded by the jitter buffer (discarded packets).

Knowing the average packet loss for a call gives you an overall sense for the quality of the call. A call with less than 1 percent average packet loss will always sound better than a call with 10 percent loss. But average loss doesn't tell the whole story. You need to know what type of packet loss you encountered.

There are two kinds of packet loss: "random" and "bursty". Think about two calls each with average 1 percent packet loss. Call A loses one in every 100 packets over the entire call (random loss) while Call B loses 100 packets in two clumps at the beginning and the end of the call (bursty loss). Which call would you rather have? That's why we report not just the average packet loss but also the type of loss and information on any bursts of packet loss during your call (reported as loss periods). It matters.

HTH

Manish

[voip7372]

Thanks