Bad MOS, but no interface errors/counters

[r.nagaraj]

Hello,

We had a very bad MOS on our Audio, but we do not seen any interface errors/counters.

Our SIP carrier also checked & advised that there were no interface errors/counters observed on their Cisco Aggregation switch & hence concluded there is no issue.

My question: Is it evident enough that if there is no Interface errors (CRC, input, frame..) there cannot be voice quality issue?

Could there be other possibilites like Codec mismatch, Loss packets, delayed packets, Jitters which would cause low MOS?

Unfortuately, by the time issue got escalated to us & we started checking, voice quality resumed & we could not capture traffic for detailed analysis.

Awaiting your expert views..

Thanks

Raj

[Manish Gogna]

Hi Raj,

Codec mismatch would actually lead to call drop if transcoder is not invoked. The symptoms of voice quality like echo, robotic voice, choppy sound, hissing etc actually give some indication of which parameter to look into. Here is a good link

http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/30141-symptoms.html

Regarding MoS, there is a very good link for capturing voice quality related metrices on the gateway as per the following

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_nano/configuration/15-mt/nanocube-config-15-mt-book/voi-nanocube-voice-quality-monitoring.html

Manish

- Do rate helpful posts -

[r.nagaraj]

Thanks Manish, good articles indeed.

The symptom we had was silence for 4-5 seconds in the call intermittently. My question was to know if this kind of issue is noticable on the physical interface errors?

excerpt of show interface <int>

!

     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 47 multicast, 0 pause input
     0 input packets with dribble condition detected
     67449768 packets output, 5907182491 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

!
 

Thanks again in advance

Raj

[Manish Gogna]

Hi Raj,

In case of silence it is important to know which party is not able to hear during that period. Suppose the IP phone user is not able to hear the PSTN caller, then you can start by pressing the "?" on the IP phone to see if the Rx packets is increasing. If that's not possible due to short duration of silence then you need to set up a packet capture at appropriate points in the call flow  to see if there is a loss of RTP packets during the call. It is a hop by hop approach to determine where the rtp is getting lost either due to a firewall or any routing issues. The interface errors will not provide any specific information about the silence on calls.

HTH

Manish

[r.nagaraj]

Hi Manish,

That is exactly what I wanted to confirm.

The scenario is a SIP trunk connected to Cisco Switch & inside has a audio bridge. All the parties on the bridge heard silence intermittently. I agree with your approach, but as mentioned before, it happened for a brief time & we do not have live RTP captures nor we are able to reproduce it now.

Much appreciated.

Raj