cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
419
Views
0
Helpful
3
Replies

Wrong service quality info from 1040 Sensor & CDR report

asarlo
Level 1
Level 1

Hello, I have a customer with CUOM & CUSM 2.0.1, CUCM 5.1. They look for the reports from the 1040 Sensors & CDR for the same call and they said both are reporting "critical service quality issue", a mos = 1.2 and they told the calls are ok, the user didn't report any voice quality issue. I'am attaching the event report for 1 call :

** This message is generated from Cisco Unified Operations Manager **

EVENT ID = 0001EXE

ALERT ID = 00003GQ

CREATION TIME = Wed 03-Sep-2008 21:47:00 GMT

STATUS = Active

SEVERITY = Critical

MANAGED OBJECT = 443

EVENT DESCRIPTION = Critical Service Quality Issue::Destination=443;Destination IP Address=10.196.88.135;Destination Type=IP Phone;Destination Model=7906;Switch For Destination=N/A;Destination Port=N/A;SourceEndPoint=10.196.88.4;Source IP Address=10.196.88.4;Source Type=VoiceGateway;Source Model=N/A;Switch For Source=N/A;Source Port=N/A;Detection Algorithm=ITU G.107 - 1040 Sensor based voice quality;MOS=1.2;Critical MOS Threshold=3.5;Cause=Packet Loss;Codec=G711Ulaw 64k;Jitter=1 ms;Packet loss=1400 Packets;Sensor MAC=001120FFD92C;Number of suppressed traps=0;Suppression start time=Wed 20-Aug-2008 12:35:05 GMT;Suppression end time=Wed 03-Sep-2008 21:46:59 GMT;

** Related Tools **

What could be the reason ? we also upgrade the 1040 Sensor firmware to the last available (SvcMonAA2_42.img).

Thanks a lot for your help ?

3 Replies 3

spaladug
Level 1
Level 1

The service quality alert is from a record from the 1040 sensor. In the alert it says there was a loss of 1400 packets. To troubleshoot the issue you will need to recreate a call and get a packet capture of the same traffic that is mirrored to the 1040 and then see if there are really 1400 packets lost in the 60 second time interval. The 1040 calculates the packet loss by looking at the sequence numbers in the RTP header of each packet. Also any packets that arrive out of order (ex. more than 20ms delay for G711) are also counted as lost.

We recreate a call and get different packet captures. When we capture just traffico from ports connected to IP telephones, the RTP packets are ok. But when we capture traffic from the H.323 VoIP gateway to/from an IP Telephone, it shows many packets coming in wrong sequence. But the customer told me the user didn't perceive any problem with the voice quality. What can I do to resolve this issue ?

Thanks a lot !!!

Regards, Anacelia

There is nothing that we can change on the 1040 sensor or CUSM to account for this. You should go the route of correcting the rtp packets going out of sequence as that looks like a QOS issue on the gateway.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: