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.
HTH.
Regards,
Bill
Please remember to rate helpful posts.
