Troubleshooting guide

4-24
Cisco Broadband Local Integrated Services Solution Troubleshooting Guide
OL-5169-01
Chapter 4 Troubleshooting with Call Flows
Voice Quality Problems
You can also adjust the receive level so that any reflected audio is reduced. It is very important to make
small adjustments at a time. Too much attenuation can make the audio impossible to hear at both ends.
Alternatively, you can contact the carrier and ask to have the lines checked. On a typical T1/PRI circuit
from the PSTN in North America, the input signal level should be -15 dB at the VoIP trunking gateways
for an originating audio source of 0dB, 1001 Hz tone (should expect 3-6 dB audio signal attenuation on
a IMT trunk) and a tail circuit limitation of 16ms (64 or 128ms depending on the gateway) for Cisco
VoIP trunking gateways echo cancellation. If the signal level is higher, echo can result.
Keep a log of all calls that experience echo. Record the time of the problem, the source phone number,
and the number called. Gateways have a fixed 16 ms of echo cancellation. If the delay in reflected audio
is longer than 16 ms, the echo canceller will not work properly. This should not be a problem for local
calls; long-distance calls should have external echo cancellation built into the network at the central
office. This is why it is important to note the external phone number of a call that experiences echo.
Voice Network Troubleshooting Procedures
Troubleshooting voice problems usually begins at one of the endpoints (either the trunk gateway or the
MTA) and works through the network to the other endpoint. Where you begin depends on the problem,
but most of the time you will not have access to the PSTN end-point. If customers complain that their
voices sound bad to others off the network, start troubleshooting at the MTA. If customers complain that
the voice quality they are hearing is poor, start at the trunk gateway.
• First, in order to successfully troubleshoot voice quality issues, you must have accurate information:
on-net number, number dialed (on-net or off-net), date and time, type of echo or voice quality issue,
and whether this is the first time the problem occurred when dialing this number. If available, the
type of phone used at the far end (cell phone, speaker phone, conference bridge, cordless, and so on).
• Second, you need to determine which trunk group/T1 this call used to reach the far end and check
the following configured values on the VoIP trunking gateway; input and output levels, echo
cancellation coverage (the default is 16 ms). The input and output levels should be 0 dB and the echo
cancellation coverage should be at least 32 ms but preferably 64 ms. If echo cancellation coverage
is below 32 ms, it needs to be changed to 64 ms. Global verification of all T1's echo cancellation
coverage values is recommended since these values are provisioned on a per T1 basis.
• Third, you should verify the CDRs generated ny the Cisco BTS 10200 and look for packet loss and
jitter values. These could indicate some network related issues that could impact voice quality.
If the customer is still experiencing echo, you should do a case-by-case analysis to determine if there is
any call pattern that could isolate the problem to a specific T1. Do not adjust gateway levels or contact
the Service Provider before opening a TAC case, unless you can provide them with a full description and
documentation of the echo problem. Level adjustments provide limited impact on the echo cancellers
ability to converge, so you do not want to fix one echo problem but create 10 new voice quality problems.
Starting at the MTA
If you are troubleshooting a VoIP over cable problem at the MTA, first determine whether it is an isolated
incident or a regular occurrence. If it is a regular occurrence, determine whether there is any pattern—all
the time, only at certain times of day, only on certain days, and so on. To do this, track performance of
the problem MTA over several days.
Here are some sources of data to review:
• Over at least a 24-hour period, look at the number of times the MTA resets, loss of synchronization
data, and time-outs. Regular resets indicate a problem. If they are occurring at a particular time of
day, look more closely at what is happening locally or on the network during this period.