Tuning Cisco IP Phone Voice Quality [Cisco IP SoftPhone]

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Troubleshoot

Echo from IP Phone to IP Phone

Complete these steps in order to troubleshoot echo on a Cisco IP phone:

Use the Volume buttons to adjust the volume to less than 75 percent on the calling and the called Cisco IP phones.
Press Settings on the IP phone.
Select the Save softkey.

Explanation

The two components that affect echo are amplitude (loudness of the echo) and delay (the time between the spoken value and the echoed sound). You can use suppressors or cancellers to control echo.

The two sources of echo are Hybrid echo and Acoustic echo.

Hybrid echo is caused by an impedance mismatch in the hybrid circuit, such as a two-wire to four-wire interface. This mismatch causes the transmit (Tx) signal to appear on the receive (Rx) signal.

Acoustic echo is caused by poor acoustic isolation between the earpiece and the microphone in handsets and hands-free devices.

Echo is perceived as annoying when all of these conditions are true:

Signal leakage between analog Tx and Rx paths
Sufficient delay in echo return
Sufficient echo amplitude

The echo is independent of the far-end phone volume level and depends only on the local phone level. In the past, side-tones were proportional to volume, this effectively masks the problem. This solution is not possible here because side-tones become too loud and the masks do not work as soon as the jitter buffer depth increases.

It is thought that there is an antenna effect in the cord.

Further Information

For additional troubleshooting information, locate the echo and suppress it. Refer to Echo Analysis for Voice over IP for assistance.

Voice Chopping or Breaking

In order to troubleshoot voice chopping or breaking, try to disable Voice Activity Detection (VAD).

Choose Service > Service Parameters on the Cisco CallManager.
Choose the server, and then choose Cisco Call Manager.
Under Clusterwide Parameters (Device-General), set Silence Suppression and Silence Suppression for Gateways to False.

This disables Silence Suppression on all devices. In other words, it turns VAD off.

Note: The Strip G.729 Annex B (Silence Suppression) from Capabilities service parameter works independently from the other system-wide parameters Silence Suppression and Silence Suppression for Gateways. Those parameters only set the boolean silence suppression in Skinny (SCCP) and MGCP, but does not affect the capabilities negotiation. Some devices do override the value of this boolean based on the negotiated capability.

Explanation

This problem can appear due to functionality of silence suppression/VAD processes.

The Pulse Code Modulation (PCM) signal first passes through a high-pass filter. The energy of each sample is measured, and the average speech power is calculated. If the power is greater than -31 dBm0 (dBm0 equals a digital milliwatt), the signal is recognized as speech.

When voice activity resumes after a period of silence (power less then -31 dBm0), a certain period of time is required in order to determine that voice resumes until silence suppression is turned off. During this period between when voice activity starts and silence suppression ends, sent packets are lost. Although the loss is only brief, the result is a noticeable degradation of quality of voice to the end user. This is observed more when there are short periods of silence between words (speech detector switches on and off quickly).

Further Information

If you require further troubleshooting, check for possible packet drops in the switching network. Check for buffer overflows and queuing and refer to the Cisco IP Telephony Quality of Service (QoS) Design Guide for further information.

Choppy Voice and Jitter Problems from Remote Site IP Phones with the G.729 Codec to the PSTN

Choppy voice is experienced for callers who use the G.729 codec in a remote site when they speak with external parties through the public switched telephone network (PSTN). Internal IP phone-to-IP phone connections and those that use the G.711 codec do not experience this problem, and the WAN bandwidth is enough for the voice calls in a remote site.

This problem can arise because the G.729 codec that is used by the remote site IP phone is G.792br8, which has Voice Activity Detection (VAD) functionality built into the codec. One of the frequent causes of jitter and choppy voice is VAD, as explained in the previous section.

In order to overcome this problem , set the Strip G.729 Annex B (Silence Suppression) from Capabilities parameter to True from the Cisco CallManager service parameter page. When this parameter is set to True, this codec is eliminated from the codecs available during codec negotiation. With this change implemented, Cisco CallManager can not enable VAD.

The G.729 codec can have multiple variances, which are termed as Annexes. AnnexB is G.729br8. With this codec, VAD can not be disabled. The Cisco CallManager always tries to negotiate the G.729br8 codec first. When you modify the Cisco CallManager service parameter, you instruct the Cisco CallManager not to use G.729br8 and instead use the G.729r8 codec, without any Annexes. The other option is to use a completely different codec, such as G.711ulaw.

Distorted, Incomplete or Delayed Voice

Press I on the Cisco 79xx twice during the call in order to display information on the call in progress. Check these items:

AvgJtr—The estimated average jitter observed in the last 16 Real-Time Transport Protocol (RTP) packets.
MaxJtr—The maximum jitter seen during the life of the RTP receive stream.

Explanation

Variance in IP transport time from packet to packet causes jitter.

Check that the size of the buffer and the difference between the average jitter value and maximum jitter value are not too high. If they are, there is a chance of a problem. This is because the swing is high and the First-In, First-Out (FIFO) might not have enough time to compensate. If the packets are stuck in FIFO, the delay of the stream causes the delay effect known as long distance calls. If packets arrive too late or too early to be useful and the jitter management mechanisms are unable to sort the arriving packets into their original order, the voice play out is distorted and incomplete.

Jitter is defined as a variation in the delay of received packets. At the sending side, packets are sent in a continuous stream with the packets spaced evenly apart. Due to network congestion, improper queuing, or configuration errors, this steady stream can become lumpy, or the delay between each packet can vary instead of remaining constant. There are many causes of jitter behavior of voice, but common ones are congested networks, number of hops over which voice travels or behavior of some queuing algorithms. Refer to Understanding Jitter in Packet Voice Networks for more information.

Further Troubleshoot

Refer to the Cisco IP Telephony QoS Design Guide for queuing problems.

Refer to Configuring QoS for IP Telephony for an understanding QoS for IP Telephony.

IP Phone Volume is Too Low

You experience a low volume on the IP phone even though the volume is increased to maximum through the volume button.

Explanation

This issue is occurs due to low gain of a signal that comes into the voice port of router. If the voice level is too low, you can increase the input gain with the input gain decibels command. Complete these steps in order to resolve this issue:

Issue this command in the voice port:

input gain decibels

Note: Gain, in decibels, to be inserted at the receiver side of the interface. Range is integers from -6 to 14. The default is 0.
The shut and no shut commands are required in order to accept the voice port changes.
Change values, place test calls, and adjust the signal as needed. Increase the input gain level by 1dB after each test call until optimal volume is reached.