Table of Contents

Voice Troubleshooting Overview

Basic Requirements for Voice Traffic

Common Problems Affecting Voice Traffic

Finding Problems with Cisco IP Phones

What to Do First
Troubleshooting IP Phones

Finding Problems with Trunks and VICs

Troubleshooting VICs
Trunk Guidelines

Troubleshooting T1 Trunk Problems
Troubleshooting ISDN Problems

Solving Voice Problems

This chapter explains how to solve problems associated with trunks and the transmission of voice packets over phone lines. It includes the following sections:

• Voice Troubleshooting Overview

• Finding Problems with Cisco IP Phones

• Finding Problems with Trunks and VICs

Voice Troubleshooting Overview

Transmission of voice and data across an internetwork differs in a number of ways, such as the following:

• TCP-based data applications react to dropped packets, while UDP-based voice applications can only conceal dropped packets. Data applications respond to dropped packets with some degree of correction because often they are TCP-based (TCP resends dropped packets). Voice (which relies on the best-effort transmission of UDP) cannot truly respond to and recover from packet loss, although in some cases the complex algorithms underlying voice transmission can conceal packet loss.

• Voice is sensitive to delays, but data is not. Delay-insensitivity means that data applications can tolerate delay well because they are not real-time-based. Voice responds negatively to delay, creating so-called "holes" in the transmission as heard by the receiver.

Basic Requirements for Voice Traffic

Voice traffic is intolerant of packet loss and delay primarily because these conditions degrade the quality of voice transmission delivered to the listener. Delay must be constant for voice applications. The complete end-to-end delay budget for voice traffic cannot exceed 200 milliseconds (ms). As a result, voice traffic passing through a network with congestion or other problems is much more likely to be adversely affected than data traffic passing through the same network.

Common Problems Affecting Voice Traffic

The following factors can affect voice quality:

• Delay is the time it takes for packets to travel between two endpoints. Delay manifests itself when long pauses in conversation cause the person listening to start to talk before the other person is finished.

---

Note   You can measure delay by using ping tests at various times of the day with different network traffic loads. (For more information about ping, see "Using Extended ping Tests" in Chapter 7, "How to Solve Serial Connection Problems.")

---

• Echo causes a caller to hear the sound of their own voice. In most cases, the echo comes back too quickly to be noticed by the caller, but the greater the delay, the greater the likelihood that echo will be noticeable. (Another important factor is the length of the connection—on international calls, for example, echo is far more likely to be noticeable than it is on local calls.)

---

Note   Your telephone service provider uses echo cancellation technology to reduce the effects of echo. An echo canceller monitors a caller's speech. If that caller's speech echoes, it generates and transmits a signal that is sent back to the caller to cancel out the echo. The amount of time that it takes the echo canceller to locate the echo and learn how to generate its opposite signal is called convergence time (typically less than one second). During convergence, the caller hears echo, which should gradually decrease in amplitude to zero when convergence is complete.

---

• Jitter is a variable-length delay that can cause a conversation to break and become unintelligible. Jitter is not usually a problem with Public Switched Telephone Network (PSTN) calls because the bandwidth of these calls is fixed. However, in VoIP networks where existing data traffic might be bursty, jitter can occur.

• Latency is the amount of time between when a device requests access to a network and when it is granted permission to send. End-to-end latency describes the overall delay associated with a network.

• Serialization occurs when an MRP or router attempts to send both voice and data packets out of the same interface. In general, voice packets are very small (80 to 256 bytes), while data packets can be very large (1,500 to 18,000 bytes). On relatively slow links, such as WAN connections, large data packets can take a long time to transmit onto the network. When these large packets are mixed with smaller voice packets, the excessive transmission time can lead to both delay and jitter. The time that it takes to put voice traffic onto a transmission line depends on the data volume and the speed of the line—for instance, it takes about 5 ms to send a 1024-byte packet on a 1.544-Mbps T1 line.

---

Tips You can use compression to reduce the size of voice transmissions. Many different compression algorithms are available, such as conjugate structure algebraic code-excited linear predictive (CSA-CELP). CSA-CELP requires only 8 Kbps of bandwidth, which is eight times less than that required by traditional pulse code modulation (PCM).

---

---

Caution Use compression carefully. The more that a digital VoIP packet is compressed, the greater the likelihood that voice quality will decrease.

---

• Loss occurs when networks drop voice packets. Packet loss is most likely to occur where the network connects to the WAN, although it can occur anywhere in the network.

• Noise (or distortion) is a problem that users commonly describe with terms such as "muffled," "tinny," or "scratchy." Noise is typically a result of compression, decompression, packet loss, or echo cancellation.

Finding Problems with Cisco IP Phones

This section describes problems associated with Cisco IP Phones.

What to Do First

When problems are reported that might be related to an Cisco IP Phone, the first things you should look for include the following:

• If more than one phone reports a service outage or there is evidence of degraded service, verify that the Cisco CallManager software is properly configured and otherwise functioning normally. If you suspect that there is a problem with the MRP, see "Troubleshooting MRPs and WICs" in Chapter 5, "How to Solve Hardware Problems."

• Verify that the phone has power and that it is properly configured.

• Verify that the phone is properly connected and inspect the cable for damage.

Note   For a list of Cisco IP Phone error codes and status codes, refer to the Cisco CallManager 3.0 Remote Serviceability Users Guide.

Troubleshooting IP Phones

Use Table 10-1 to find the probable cause and solutions for problems associated with Cisco IP Phones.

Table 10-1: Cisco IP Phone Problems and Solutions

Symptom	Possible Cause	Solutions
A working Cisco IP Phone stops functioning when it is moved to a new physical location. Status code 04025 is displayed when you press **.	There is a connectivity problem between the Cisco IP Phone and the IP network. The Cisco IP Phone may be using a static address, preventing the network from communicating with it in its new location.	If the Cisco IP Phone is configured to use a static IP address, modify its IP address to reflect the new location. (Refer to the Cisco CallManager documentation.)
A Cisco IP Phone does not accept a new static IP address.	User input error during Cisco IP Phone configuration	When configuring the Cisco IP Phone, after entering the last octet of the IP address, ensure that you press the asterisk (*) key, not the number sign (#) key. Pressing the * key saves your configuration.
Users of a Cisco IP Phone hear echo.	A dirty or noisy line is causing reflection The signal is coming in too "hot"	Verify that amplitude of the inbound signal is 15 dB. If the signal is coming in too hot, reduce the amplitude of the transmit signal. If the listener on the opposite end of the connection hears echo, contact your telephone service provider to determine what level of echo cancellation is in place.
Users of the Cisco IP Phone hear a noise when the speakerphone is in use. The noise is not heard when using the handset.	Speaker phone circuitry problem	Replace the Cisco IP Phone.
Users of a Cisco IP Phone hear a crackling noise on both the handset and the speaker phone.	Power problem	Verify that there are no problems with the Catalyst 3524-PWR XL that is powering the Cisco IP Phone. (Refer to the Catalyst 3524-PWR XL documentation.)

Finding Problems with Trunks and VICs

This section describes problems associated with voice interface cards (VICs) installed in MRPs and the trunks connected to VICs.

Troubleshooting VICs

Table 10-2 lists symptoms and possible solutions for problems associated with digital signal processors (DSPs). DSPs are microprocessors that MRPs use to handle voice-processing tasks such as compression.

Table 10-2: VIC Problems and Solutions

syslog Message	MRP LED Status Change	Possible Cause	Solutions
DSPALARM, VTSP (All calls through affected VIC are dropped)	ALARM: on (amber)	DSP VTSP error	Verify that the DSP is functioning properly by placing a call through the affected voice interface. Copy the error message exactly as it appears and contact your technical support representative.
DSPALARM, HTSP (All calls through affected VIC are dropped)	none	DSP HTSP error	Verify that the DSP is functioning properly by placing a call through the affected voice interface. Copy the error message exactly as it appears and contact your technical support representative.

Trunk Guidelines

Trunks connect the Cisco ICS 7750 to other PBXs (or similar equipment) or to the central office (CO) at the telephone service provider. A trunk may go down temporarily and come back up shortly without intervention. However, if the trunk remains down or transitions constantly in and out of service, you must find and correct the problem. Use the loopback tests described in this section to isolate the faulty component. A loopback test is a software or hardware test that alters the flow of data so that an electronic signal is returned to its sender.

Trunks can be directly connected or they can be connected with data service unit/channel service unit (DSU/CSU) devices through telephone lines. A trunk interface loop occurs in the circuitry within the Cisco ICS 7750 and does not involve components external to the system.

Most trunk failures are temporary and caused by problems on the telephone company line. A trunk is usually returned to service within three minutes without any intervention on your part and before the telephone company finds anything wrong. If a trunk is reported down, you should wait at least ten minutes to make sure that the problem is not temporary.

If the trunk does not come up within 10 minutes, you must identify the failed portion of the trunk. To do this, run a series of loopback tests to segment the trunk from end to end, starting at the MRP connected to it and progressing outward from the Cisco ICS 7750. This process tests each segment in sequence to find the exact location of the failure.

Note   For information about loopback tests over serial lines, see "Loopback Tests" in Chapter 7, "How to Solve Serial Connection Problems." For information about solving problems with WICs, see "Troubleshooting MRPs and WICs" in Chapter 5, "How to Solve Hardware Problems."

Troubleshooting T1 Trunk Problems

Table 10-3 lists symptoms and possible solutions for problems associated with T1 trunks and the VICs connected to them.

Troubleshooting ISDN Problems

Table 10-4 lists symptoms and possible solutions for problems associated with Integrated Services Digital Network (ISDN) and ISDN VICs.

Posted: Mon Oct 2 13:53:08 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.