Cisco IP Telephony Troubleshooting Guide for Cisco CallManager Release 3.0(1)
mismatch). Make sure that the traffic is not crossing any shared-media device, such as a hub. There could also be situations where the traffic is taking a slower path through the network than expected. If QoS has been configured correctly, then the possibility exists that there is no call admission control. Depending on your topology, this can be accomplished through the use of Locations in Cisco CallManager Administration configuration, or by using a Cisco IOS router as a gatekeeper. In any case, you should always know how many calls could be supported across your WAN. If possible, test this by disabling silence suppression as described earlier, then place calls between the two sites. Do not place the calls on hold or on mute, since this will stop packets from being transmitted. With the maximum number of calls across the WAN, the calls should all have acceptable quality. Test to make sure that a fast busy is returned when trying to make one more call.
Crackling
Another “poor quality” symptom may be a crackling, which is sometimes caused by a defective power supply or some kind of strong electrical interference close to the phone. Try swapping the power supply and moving the phone around.
Check Your Loads
You should also always check the phones and gateways to ensure the latest software loads are in use. When in doubt, check CCO (Cisco Connection Online at www.cisco.com) for the latest software loads, new patches, or release notes relating to the problem.
Echo
Echo (also known as “talker echo”) occurs when a talker’s speech energy, transmitted down the primary signal path, is coupled into the receive path from the far end. The talker then hears his or her own voice, delayed by the total echo path delay time.
John | Tx | | | | Rx | Jane |
Rx | | Voice Network | Tx |
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | |
In the diagram above, John’s voice (in blue) is being reflected back. This can happen but go unnoticed in a traditional voice network because the delay is so low. To the user, it sounds more like a side-tone than an echo. In a VoIP network, it will always be noticeable, since packetization and compression always contribute enough delay. The important thing to remember is that the cause of the echo is always with analog components and wiring. For instance, IP packets cannot simply turn around and go back to the source at a lower audio level. The same is impossible on digital T1/E1 circuits. So on a call from one Cisco IP Phone to another, there should never be any problem. The only exception may be if one party is using a speakerphone that has the volume set too high or some other situation where an audio loop is created.
When troubleshooting echo problems, make sure that the phones that are being tested or examined are not using the speakerphone, and that they have the headset volume to reasonable
© 2000 Cisco Systems, Inc. | 25 |