Voice Clipping

Unanswered Question
May 22nd, 2010


Scenario is we have  installed Call managers at Delhi (Rohini) Location it is central location for all over India through WAN link, the issue i am facing is we have  installed IP Phones in Okhla (delhi) which is connected through WAN to the call managers in Rohini.The problem is when a call made from rohini to Okhla IP phone then Okhla guy is able hear voice through IP phone but at rohini side Voice is clipping..(voice is not clear)

we have checked there is no issue with the bandwidth also n/w is also clear (no firewall restrictions)......What it is....can anybody help????



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
James Hawkins Sat, 05/22/2010 - 05:23


The first thing to do is to determine that the problem is for all phones at Rohini rather than just one.

If that is the case then you need to start collecting data and checking whether things are operating as you assume they are.

For instance, is the voice traffic following the path you believe - use traceroute from a device on the voice VLAN at either end of the link.

Are the phones using the codec that you anticipate - on most 7900 series phones you can check this by pressing the help button twice whilst a call is active.

Are the phones reporting packet loss and/or jitter? - you can see this on the phone by pressing the help button twice as above. Alternatively you can enable the QRT tool to collect this data.


This should be enough to get you started.

Check out the Troubleshooting Guide for Cisco Unified Communications Manager document for your CUCM release for more detailed troubleshooting info.

kakkargaurav Sat, 05/22/2010 - 05:49

thanks James for your solution,

But i have found one more thing that whenever i am pinging my server (call managers) from okha through WAN i am getting ping response b/w 85% and 90% but if i ping any other application server from okhla i m getting 100% response .So this could be an issue......

James Hawkins Sat, 05/22/2010 - 05:56


It could be an issue but remember that call setup traffic (SCCP on TCP port 2000) goes from phone to server and call payload traffic (RTP on UDP ports between 16384 and 32768) flows directly between phones. If you are hearing clipping then it suggests a problem with payload rather than signalling.

It would be a good idea to resolve the server PING issue first though. I would start by checking that the server and switch to which it connects have matching speed and duplex settings.

David Hailey Sat, 05/22/2010 - 06:12

If you are running a Linux version of CUCM (6x or higher), the irregularity in ping response is actually normal.  We have observed this on numerous systems.  Pings from the same LAN are all acknowledged and you'll see 100% response.  However, pings over WAN, VPN, etc (i.e., another network/subnet/etc) will occassionally be dropped.  This is discussed in the SRND I believe as it is essentially a mechanism used to avoid a remote DoS attack.


William Bell Sat, 05/22/2010 - 07:26

You have to approach this issue by trying to determine the scope (harken back to James' original reply, +5 James). From your OP, you said that when two phones are talking to each other, one phone has good audio while the other does not.  Taking this in the most literal sense means that either something is wrong with the phone exhibiting the issue or the network path from the remote party to the phone where the clipping is present.

To determine Scope, you have to look for common patterns:

1. Is the issue only one phone?  If so, the issue is that particular phone.  Maybe the handset, cord, something silly or something bad like a corrupt DSP.  It could also be the switch port the phone is connected to.  Check for interface errors, check duplexity, check speed.

2. If it is more than one phone:

- Is it all phones in one site?

- Is it just one model of phone?

- Is it just phones on a particular switch?

- Is it just phones on a particular switch module?

It would also be a good idea to understand time and frequency of the issues in question.

In regards to the "ping" timeouts from the CUCM.  Hailey brings up a good point (+5 to the H man) in that you cannot rely on ping to give you an idea of what to expect from call signaling or RTP media.  IOW, if QoS is setup correctly the pings from your CUCM nodes to a remote, non-voice node would be best effort, while signaling and media use a higher priority traffic class.  The SRND recommends that you use the closest network device to the CUCM nodes for any ICMP testing.  Using extended ping commands you can also force a type of service (using 3 and 5 will map you to the appropriate DSCP values if you are following Cisco best practices).

That being said, I wouldn't go to this nebulous ping testing and qos checking level just yet.  Check your physical layer first.  If the issue is impacting one phone.  Look at the phone, the cables, the handset, and the switch port.  If it is more than one phone and you can localize to an area on your network.  Look at the uplink(s) from this portion of the network and the next layer 2 and/or layer 3 hop in the network.  If the issue is one-way only, you may want to look at fiber connections between devices.  While copper connections could exhibit the same issue, it is much easier for one of the fiber strands to be damaged in some way. 

Check interface counters on all inter-switch/inter-device connections.  You are looking for line errors.  If your environment is small, this will be quick.  If it is large, you may want to look at network management tools and/or sed/awk/etc..

If the physical layer pans out, then start looking at your QoS.  Check the config first.  9 out of 10 times the config is just wrong and it is easier to look than to checks statisics and then look.  Once you look and find the config is straight, then start looking for queue drops.

With the little info we have so far, I am leaning to physical layer issue of some type.



Please remember to rate helpful posts.

James Hawkins Sat, 05/22/2010 - 06:40

Thanks David - a new one on me so +5.

Interestingly if you ping the CUCM server form a Windows workstation the response tends to be 100%.

If you ping from a Cisco switch or router the ping packets are sent at a faster rate triggering the CUCM DoS  protection mechanism.


This Discussion