UMG8900 Voice Failure Troubleshooting
43
HUAWEI TECHNOLOGIES CO., LTD. www.huawei.com HUAWEI Confidential Security Level: Public UMG8900 Voice Failure Troubleshooting
description
UMG8900 Voice Failure Troubleshooting Upon completion this course, you will be able to:One-way audio failure troubleshooting methodsEcho failure troubleshooting methodsNoise failure troubleshooting methods
Transcript of UMG8900 Voice Failure Troubleshooting
Location update procedure and troubleshootingOne-way audio failure
troubleshooting methods
Echo failure troubleshooting methods
Noise failure troubleshooting methods
HUAWEI TECHNOLOGIES CO., LTD.
Chapter 2 Call Accompanied by Echoes
Chapter 3 Cross-talking
Symptom
*
One-way Audio or No Audio
*
Possible Causes
The common causes of one-way audio or no audio are as follows:
Access faults on the TDM side
Faults in the interconnected device such as the base station controller (BSC) or in the device on the network such as the public switched telephone network (PSTN)
Incorrect TDM cable connection, for example, crossed pairs of TDM cables or inconsistent configurations of the TDM interfaces on the UMG8900 and the interconnected device
Faults in internal TDM processing on the UMG8900
TDM timeslot management error
Incorrect cascading optical fiber connection or cascading board failure on the UMG8900
Faults in the hardware of the TDM switching network boards such as the TNU, TNB, TNC, and TCLU, or the TDM resource boards such as the E32, T32, S1L, S2L, and PIE on the UMG8900
Poor-quality IP bearer network
The bearer interface on the UMG8900 does not receive packets from the interconnected device or the interconnected device does not receive packets from the UMG8900.
Incorrect interconnection parameters on the IP side
*
One-way Audio or No Audio
The general troubleshooting procedure is as follows for One-Way Audio Failure in TDM-IP Paths
Assume that user B can hear user A but user A cannot hear user B if one-way audio occurs. To locate the fault, perform the following operations:
Create user message trace tasks on the MGC and the UMG8900:
Perform a dialing test and keep the call connected when one-way audio occurs:
Obtain the termination ID (TID) used by the caller and the callee from the traced messages and check for the corresponding physical timeslot on the UMG8900:
Perform an inloop or outloop for the timeslot used by the caller and the callee and locate where the fault occurs:
If the fault occurs outside the UMG8900, check the cable connection outside the UMG8900 or check the interconnected device; if the fault occurs on the UMG8900, check the UMG8900:
*
Trace the messages
On the LMT of the MGC, create a task.
Create a user call trace task on the UMG8900.
*
Trace the messages
Perform a dialing test by using the traced user number.
When one-way audio or no audio occurs, keep the call connected.
*
Trace the messages
Determine the TID used by the caller and the callee on the UMG8900. Run DSP CTXINFO to query for the TID used by the caller and the callee on the UMG8900.
The output description of the TID(Low) column is as follows:
The TID that starts with 0x40 corresponds to a TDM termination.
The TID that starts with 0x30 corresponds to an IP termination.
*
Locate the fault on the TDM side of user B.
*
Locate the fault on the TDM side of user B.
Perform an outloop for the TDM termination on user B side. The b point in Figure shows the position of the outloop. Run LOP E1 to perform a channel outloop.
LOP E1: FN=X, SN=Y, LOC=PORT, MODE=SCHOLOP, PN=Z, CN=S;
Figure Loopback on the TDM side
X is the number of the frame that houses the TDM interface board (E32/S2L/S1L) where the TID of user B is located.
Y is the number of the slot that houses the TDM interface board where the TID of user B is located.
Z is the number of the interface where the TID of user B is located on the TDM interface board.
*
Locate the fault on the TDM side of user B.
After the outloop for user B, check whether user B can hear his/her own voice.
Yes -> 14
No -> 12
Run DSP E1PORT to query for the settings of the TDM interface. Check whether the related settings on the interfaces of the UMG8900 and its interconnected device are consistent.
Yes -> 13
No -> Contact technical support engineers of the interconnected device on user B side, and execute 13.
Check whether the TDM cable connection on the two interconnected devices are incorrect. For example, check whether crossed pairs of TDM cables are present; check whether the TDM cable connection between the transmitting and receiving interfaces on the two interconnected devices is incorrect.
Yes -> Contact technical support for the interconnected device on the user B side and modify the TDM connection, and execute 14.
No -> 14
Cancel the outloop on user B side. Run LOP E1 to cancel the outloop on user B side.
*
Locate the fault on user A side.
Determine the bearer access mode on user A side.
IP mode -> 27
TDM mode -> 16
Run LOP E1 to perform an inloop for user A. The a and a1 points in Figure show the positions of the inloop. Perform inloops segment by segment along the TDM path.
*
Locate the fault on user A side.
After the inloop for user A, check whether user B can hear his/her own voice.
Yes -> 20
No -> 18
Run DSP E1PORT to query for the settings of the TDM interface. Check whether the related settings on the interfaces of the two interconnected devices are consistent.
Yes -> 19
No -> Contact technical support engineers of the interconnected device on user A side, and execute 19.
Check whether the TDM cable connection on the two interconnected devices are incorrect. For example, check whether crossed pairs of TDM cables are present; check whether the TDM cable connection between the transmitting and receiving interfaces on the two interconnected devices is incorrect.
Yes -> Contact technical support for the interconnected device on the user A side and modify the TDM connection, and execute 20.
No -> 20
Run LOP E1 to cancel the inloop on user A side.
*
Locate the fault in TDM processing on the UMG8900
Check whether the related alarms are generated. Run LST ALMAF to check whether the following alarms are generated:
ALM-0818 Cascading link connection fault
Clock related alarms on the CLK, and NETs.
Yes -> Handle the alarms according to the alarm help -> 22
No -> 23
Check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 23
Yes -> 25
No -> 24
Clear the fault in the cascading and check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 25
Locate the fault in TDM processing on the UMG8900
Check whether a board on the path between the two TDM interface boards is faulty. Run SWP BRD to switch the master and slave boards on the path between the two TDM interface boards in the sequence from the TNU on the caller side, BLU in the central switching frame, TNB in the central switching frame, BLU in the central switching frame, to the TNU on the callee side.
After you switch one pair of master and slave boards, check whether the fault of one-way audio or no audio is rectified.
Yes -> 26
No -> 38
Replace the faulty board, that is, the master board before the switchover. After the board starts normally, perform a dialing test and check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 38
Locate the fault in the IP bearer network.
Determine the local and remote IP addresses. Run DSP TERMINFO to query for the information about the IP termination, including the local and remote IP addresses, of the call.
*
Locate the fault in the IP bearer network.
Run PING to ping the remote IP address. PING: BT=HRB, SN=X, NUM=32, IP="XX.XX.XX.XX", PKTSIZE=200;
Check whether the ping packets are returned normally.
Yes -> 30
No -> Contact Huawei technical support engineers to locate the fault in the IP transport network.
Check the duplex mode of the IP bearer interface. Run DSP IPIF to check whether the duplex mode of the IP bearer interface is full-duplex.
Yes -> 32
No -> 31
Change the duplex mode of the IP bearer interface. Run MOD IPIF to change the duplex mode of the IP bearer interface to full-duplex.
Clear the statistics about the IP bearer interface. Run CLR IPIFSTS to clear the statistics about the IP bearer interface.
Check the status of the IP bearer interface. After 10 seconds, run DSP IPIF to query for the status of the IP bearer interface and check whether a large number of error packets, for example, cyclic redundancy check (CRC) error packets, are present.
Yes -> Contact Huawei technical support engineers to locate the fault in the IP transport network.
No -> 34
.
Check the attributes of the IP termination in the traced H.248 messages.
*
.
Change the payload type of the codec to be consistent with the payload type on the interconnected device. Run SET PAYLOADTYPE to change the payload type of the codec. Then, perform a dialing test and check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 36
Check whether the payload type of the IP termination conflicts with the payload type of RFC2833 or RFC2198 packets. Run LST RFC2833 to query for the values of Named Packet Payload Type and Tone Packet Payload Type. Run LST TCPARA to query for the value of RFC2198 redundant RTP payload type. Check whether the payload type of the IP termination conflicts with the payload type of RFC2833 or RFC2198 packets.
Yes -> 37
No -> 38
Change the payload type. The settings of payload types must be consistent on the entire network. Determine whether to modify the payload type of the IP termination, or the payload type of RFC2833 or RFC2198 packets according to the planning. Run SET PAYLOADTYPE to modify the payload type of the IP termination. Run SET RFC2833 to modify the payload type of RFC2833 packets. Run SET TCPARA to modify the payload type of RFC2198 packets. Check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 38
.
Collect fault information and contact Huawei technical support engineers.
The software abnormality is complex. Therefore, you need to collect sufficient information, including running logs, operation logs, call logs, system logs, and alarm information, for fault location.
Run the following command to collect operation logs: LST LOG: LTP=OPER, CNT=1000;
Run the following command to collect running logs: LST LOG: LTP=RUN, CNT=1000;
Run the following command to collect call logs: LST LOG: LTP=CALL, CNT=1000;
Run the following command to collect system logs: LST SYSLOG: CNT=1000;
End.
One-Way Audio Failure in TDM-TDM Paths
Fault Symptom
2. Fault Analysis
The possible causes of one-way audio faults in TDM paths are as follows:
Fault in the interworking device
Crossed pairs of TDM cables or inconsistent configurations of the TDM
interfaces on the UMG8900 and the peer device
Incorrect connections of optical fibers of the UMG8900
Fault in the TDM switching network board or TDM resource board of the
UMG8900
Introduction to loopback
A loopback refers to a troubleshooting technique in which a data flow is returned to its source so that the data flow can be analyzed for fault location at a certain end.
After the loopback function is enabled on an interface, all services specific to the interface are interrupted. Therefore, enable the loopback function only when you locate faults, and disable the loopback function after the loopback test is complete.
The UMG8900 supports three types of loopback modules:
TDM loopback (the loopback on the TDM interface board)
IP loopback (the loopback on the IP interface board)
ATM loopback (the loopback on the ATM interface board)
*
One-Way Audio Failure in TDM-TDM Paths
Step 1: Check whether the fault is caused by device A if user A cannot hear the voice of
user B.
To locate the fault, you can perform an inloop on device A that does not use any
EC resources. If user A cannot hear his/her own voice after the inloop, it indicates that the fault is
caused by device A interconnected with the UMG8900. The possible causes are
as follows:
Wrong connections of TDM cables. Check the cable connections between
the UMG8900 and device A.
Inconsistent configurations of the TDM interfaces.
*
One-Way Audio Failure in TDM-TDM Paths
Step 2 Perform an outloop on the interface of the UMG8900 on the side of device A.
*
One-Way Audio Failure in TDM-TDM Paths
Step 3 Perform an inloop on the interface of the UMG8900 on the side of device B.
If user A cannot hear his/her own voice and the UMG8900 does not use any EC resource, it indicates that the UMG8900 is faulty. If user A can still hear his/her own voice, it indicates that the bearer path along user A, device A, and the UMG8900 is normal. In this case, check whether the cable connections between the UMG8900 and device B are correct and whether device B is normal.
*
One-Way Audio Failure in TDM-TDM Paths
Step 4 Record voices on the TDM interface through which the UMG8900 is interconnected with device B.
*
One-Way Audio Failure in TDM-TDM Paths
Step 5 Perform an inloop on the TDM interface through which the UMG8900 is interconnected with device A. Then, record the voices on the TDM interface to locate the device that introduces the fault.
*
One-Way Audio Failure in TDM-TDM Paths
Step 6
Determine whether the optical fiber connections of the UMG8900 are correct by checking whether "ALM-0818 Fault of CASCADE CONFLICT" is generated and whether the transmitting and receiving of the TDM cascading optical fibers are consistent with those of the TDM cascading optical interfaces of the peer device and consistent with MML configurations.
b. You can check whether one-way audio is caused by board faults by querying information about active alarms. To check whether a failure mode effective analysis (FMEA) alarm is generated, you need to collect information about active alarms related to the TDM interface board that connects device A and device B, active alarms related to the master and slave TNUs in the frame where the TDM interface board is located, and active alarms related to the
TNUs and BLUs in the central switching frame.
c. You can check whether the clock of the CLK is synchronous with that of the
*
Fault Symptom
Fault Analysis
The possible causes of one-way audio in IP-IP paths are as follows:
The UMG8900 does not receive any packet from the peer end or the peer end does not receive any packet from the UMG8900.
2) The packets from the IP side are discarded during the check because of errors.
3) The bearer table of the upper layer control software is configured incorrectly, and thus the packets are discarded. The bearer table includes the bearer processing information that is negotiated by the upper layer control software when the call is connected. Therefore, the wrong configurations of the bearer table may be due to failure of the upper layer control software.
4) The packets are discarded because the GE plane of the UMG8900 fails.
*
One-way Audio or No Audio
One-Way Audio in IP-IP Paths
For causes 1), 2), and 5), you need to capture packets on the mirrored bearer interface of the UMG8900 or record voices on the UMG8900 to check whether the UMG8900 receives any packets from the peer end or check whether the packet contents are correct.
For cause 3), you need to query the bearer table of the one-way audio session, and then submit the table to Huawei R&D engineers.
*
Echo
Symptom
Echo is the reflected copy of one's voice heard some time later and a delayed version of the original
While effective, this approach leads to several problems:
Double-talk: It is fairly normal in conversation for both parties to speak at the same time, at least briefly. Because each echo suppressor will then detect voice energy coming from the far-end of the circuit, the effect would ordinarily be for loss to be inserted in both directions at once, effectively blocking both parties. To prevent this, echo suppressors can be set to detect voice activity from the near-end speaker and to fail to insert loss (or insert a smaller loss) when both the near-end speaker and far-end speaker are talking. This, of course, temporarily defeats the primary effect of having an echo suppressor at all.
Clipping: Since the echo suppressor is alternately inserting and removing loss, there is frequently a small delay when a new speaker begins talking that results in clipping the first syllable from that speaker's speech.
*
Possible Cause
The two factors of echoes in a communication network are as follows:
1. Echo sources
Echoes occur due to low-quality handsets, cross-talking of handsets, or echoes in surroundings are called acoustic echoes. Acoustic echoes easily occur for a poor-quality phone in handfree mode, cordless telephone, personal handyphone system, teleconferencing terminal, or PC phone.
Echoes caused by the hybrid, which is the transformer that joins the two-wire analog local loop to the four-wire transmission network, are called electrical echoes.
2. Long network delay
*
The common causes of echoes are as follows:
Echoes are acoustic echoes. Acoustic echoes are usually not handled on the media gateway (MGW).
The echo canceller chip on the MGW is faulty.
The echo cancellation (EC) configurations are incorrect. For example, the echo canceller is disabled; EC parameters such as the bypass EC switch are incorrect; the tail length of the echo canceller is insufficient; EC option is set to YES.
*
Echo
A mobile station (MS) calls another MS and the two MSs are controlled by one MGW
*
Echo
An MS calls a fixed-line phone in the public switched telephone network (PSTN).
*
The general troubleshooting procedure is as follows:
Rectify the fault in the echo canceller chip on the UMG8900:
Rectify the EC configurations:
Check whether EC resources are added to the UMG8900 during the call:
*
Echo
Check whether the echo canceller chip on the UMG8900 is faulty.
Check whether the echo canceller chip is faulty. If echoes occur sporadically or periodically, the EC chip on the VPU or ECU is faulty. Run DEA BRD to deactivate the VPU or ECU. Then, perform dialing tests to check whether echoes still occur sporadically or periodically.
*
Check whether the EC configurations on the UMG8900 are correct.
Run LST ECPARA to check settings of the bypass EC switches.
LST ECPARA: BT=VPU;
LST ECPARA: BT=ECU;
The bypass EC switch on the VPU or ECU is enabled or disabled
Change the EC tail length. Run SET ECPARA to change the EEC tail length from 64 ms to 128 ms. Then, perform a dialing test to check whether echoes still occur.
Check whether EC option is set to YES. Run LST ECPARA to check whether EC option is set to YES.
*
Echo
Check whether EC resources are added to the UMG8900 during the call.
Create a user call tracing task on the UMG8900. Perform a dialing test by using the traced user number. When echoes occur, keep the call connected.
Check whether EC resources are added for the call by analyzing H.248 signaling messages. Check whether EC resources are added in the ADD REQ and MOD REQ messages
3. enable the EC function on the MGC
*
Echo
Check whether EC resources are added to the UMG8900 during the call.
*
Echo failure troubleshooting methods
Noise failure troubleshooting methods
HUAWEI TECHNOLOGIES CO., LTD.
Chapter 2 Call Accompanied by Echoes
Chapter 3 Cross-talking
Symptom
*
One-way Audio or No Audio
*
Possible Causes
The common causes of one-way audio or no audio are as follows:
Access faults on the TDM side
Faults in the interconnected device such as the base station controller (BSC) or in the device on the network such as the public switched telephone network (PSTN)
Incorrect TDM cable connection, for example, crossed pairs of TDM cables or inconsistent configurations of the TDM interfaces on the UMG8900 and the interconnected device
Faults in internal TDM processing on the UMG8900
TDM timeslot management error
Incorrect cascading optical fiber connection or cascading board failure on the UMG8900
Faults in the hardware of the TDM switching network boards such as the TNU, TNB, TNC, and TCLU, or the TDM resource boards such as the E32, T32, S1L, S2L, and PIE on the UMG8900
Poor-quality IP bearer network
The bearer interface on the UMG8900 does not receive packets from the interconnected device or the interconnected device does not receive packets from the UMG8900.
Incorrect interconnection parameters on the IP side
*
One-way Audio or No Audio
The general troubleshooting procedure is as follows for One-Way Audio Failure in TDM-IP Paths
Assume that user B can hear user A but user A cannot hear user B if one-way audio occurs. To locate the fault, perform the following operations:
Create user message trace tasks on the MGC and the UMG8900:
Perform a dialing test and keep the call connected when one-way audio occurs:
Obtain the termination ID (TID) used by the caller and the callee from the traced messages and check for the corresponding physical timeslot on the UMG8900:
Perform an inloop or outloop for the timeslot used by the caller and the callee and locate where the fault occurs:
If the fault occurs outside the UMG8900, check the cable connection outside the UMG8900 or check the interconnected device; if the fault occurs on the UMG8900, check the UMG8900:
*
Trace the messages
On the LMT of the MGC, create a task.
Create a user call trace task on the UMG8900.
*
Trace the messages
Perform a dialing test by using the traced user number.
When one-way audio or no audio occurs, keep the call connected.
*
Trace the messages
Determine the TID used by the caller and the callee on the UMG8900. Run DSP CTXINFO to query for the TID used by the caller and the callee on the UMG8900.
The output description of the TID(Low) column is as follows:
The TID that starts with 0x40 corresponds to a TDM termination.
The TID that starts with 0x30 corresponds to an IP termination.
*
Locate the fault on the TDM side of user B.
*
Locate the fault on the TDM side of user B.
Perform an outloop for the TDM termination on user B side. The b point in Figure shows the position of the outloop. Run LOP E1 to perform a channel outloop.
LOP E1: FN=X, SN=Y, LOC=PORT, MODE=SCHOLOP, PN=Z, CN=S;
Figure Loopback on the TDM side
X is the number of the frame that houses the TDM interface board (E32/S2L/S1L) where the TID of user B is located.
Y is the number of the slot that houses the TDM interface board where the TID of user B is located.
Z is the number of the interface where the TID of user B is located on the TDM interface board.
*
Locate the fault on the TDM side of user B.
After the outloop for user B, check whether user B can hear his/her own voice.
Yes -> 14
No -> 12
Run DSP E1PORT to query for the settings of the TDM interface. Check whether the related settings on the interfaces of the UMG8900 and its interconnected device are consistent.
Yes -> 13
No -> Contact technical support engineers of the interconnected device on user B side, and execute 13.
Check whether the TDM cable connection on the two interconnected devices are incorrect. For example, check whether crossed pairs of TDM cables are present; check whether the TDM cable connection between the transmitting and receiving interfaces on the two interconnected devices is incorrect.
Yes -> Contact technical support for the interconnected device on the user B side and modify the TDM connection, and execute 14.
No -> 14
Cancel the outloop on user B side. Run LOP E1 to cancel the outloop on user B side.
*
Locate the fault on user A side.
Determine the bearer access mode on user A side.
IP mode -> 27
TDM mode -> 16
Run LOP E1 to perform an inloop for user A. The a and a1 points in Figure show the positions of the inloop. Perform inloops segment by segment along the TDM path.
*
Locate the fault on user A side.
After the inloop for user A, check whether user B can hear his/her own voice.
Yes -> 20
No -> 18
Run DSP E1PORT to query for the settings of the TDM interface. Check whether the related settings on the interfaces of the two interconnected devices are consistent.
Yes -> 19
No -> Contact technical support engineers of the interconnected device on user A side, and execute 19.
Check whether the TDM cable connection on the two interconnected devices are incorrect. For example, check whether crossed pairs of TDM cables are present; check whether the TDM cable connection between the transmitting and receiving interfaces on the two interconnected devices is incorrect.
Yes -> Contact technical support for the interconnected device on the user A side and modify the TDM connection, and execute 20.
No -> 20
Run LOP E1 to cancel the inloop on user A side.
*
Locate the fault in TDM processing on the UMG8900
Check whether the related alarms are generated. Run LST ALMAF to check whether the following alarms are generated:
ALM-0818 Cascading link connection fault
Clock related alarms on the CLK, and NETs.
Yes -> Handle the alarms according to the alarm help -> 22
No -> 23
Check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 23
Yes -> 25
No -> 24
Clear the fault in the cascading and check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 25
Locate the fault in TDM processing on the UMG8900
Check whether a board on the path between the two TDM interface boards is faulty. Run SWP BRD to switch the master and slave boards on the path between the two TDM interface boards in the sequence from the TNU on the caller side, BLU in the central switching frame, TNB in the central switching frame, BLU in the central switching frame, to the TNU on the callee side.
After you switch one pair of master and slave boards, check whether the fault of one-way audio or no audio is rectified.
Yes -> 26
No -> 38
Replace the faulty board, that is, the master board before the switchover. After the board starts normally, perform a dialing test and check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 38
Locate the fault in the IP bearer network.
Determine the local and remote IP addresses. Run DSP TERMINFO to query for the information about the IP termination, including the local and remote IP addresses, of the call.
*
Locate the fault in the IP bearer network.
Run PING to ping the remote IP address. PING: BT=HRB, SN=X, NUM=32, IP="XX.XX.XX.XX", PKTSIZE=200;
Check whether the ping packets are returned normally.
Yes -> 30
No -> Contact Huawei technical support engineers to locate the fault in the IP transport network.
Check the duplex mode of the IP bearer interface. Run DSP IPIF to check whether the duplex mode of the IP bearer interface is full-duplex.
Yes -> 32
No -> 31
Change the duplex mode of the IP bearer interface. Run MOD IPIF to change the duplex mode of the IP bearer interface to full-duplex.
Clear the statistics about the IP bearer interface. Run CLR IPIFSTS to clear the statistics about the IP bearer interface.
Check the status of the IP bearer interface. After 10 seconds, run DSP IPIF to query for the status of the IP bearer interface and check whether a large number of error packets, for example, cyclic redundancy check (CRC) error packets, are present.
Yes -> Contact Huawei technical support engineers to locate the fault in the IP transport network.
No -> 34
.
Check the attributes of the IP termination in the traced H.248 messages.
*
.
Change the payload type of the codec to be consistent with the payload type on the interconnected device. Run SET PAYLOADTYPE to change the payload type of the codec. Then, perform a dialing test and check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 36
Check whether the payload type of the IP termination conflicts with the payload type of RFC2833 or RFC2198 packets. Run LST RFC2833 to query for the values of Named Packet Payload Type and Tone Packet Payload Type. Run LST TCPARA to query for the value of RFC2198 redundant RTP payload type. Check whether the payload type of the IP termination conflicts with the payload type of RFC2833 or RFC2198 packets.
Yes -> 37
No -> 38
Change the payload type. The settings of payload types must be consistent on the entire network. Determine whether to modify the payload type of the IP termination, or the payload type of RFC2833 or RFC2198 packets according to the planning. Run SET PAYLOADTYPE to modify the payload type of the IP termination. Run SET RFC2833 to modify the payload type of RFC2833 packets. Run SET TCPARA to modify the payload type of RFC2198 packets. Check whether the fault of one-way audio or no audio is rectified.
Yes -> 39
No -> 38
.
Collect fault information and contact Huawei technical support engineers.
The software abnormality is complex. Therefore, you need to collect sufficient information, including running logs, operation logs, call logs, system logs, and alarm information, for fault location.
Run the following command to collect operation logs: LST LOG: LTP=OPER, CNT=1000;
Run the following command to collect running logs: LST LOG: LTP=RUN, CNT=1000;
Run the following command to collect call logs: LST LOG: LTP=CALL, CNT=1000;
Run the following command to collect system logs: LST SYSLOG: CNT=1000;
End.
One-Way Audio Failure in TDM-TDM Paths
Fault Symptom
2. Fault Analysis
The possible causes of one-way audio faults in TDM paths are as follows:
Fault in the interworking device
Crossed pairs of TDM cables or inconsistent configurations of the TDM
interfaces on the UMG8900 and the peer device
Incorrect connections of optical fibers of the UMG8900
Fault in the TDM switching network board or TDM resource board of the
UMG8900
Introduction to loopback
A loopback refers to a troubleshooting technique in which a data flow is returned to its source so that the data flow can be analyzed for fault location at a certain end.
After the loopback function is enabled on an interface, all services specific to the interface are interrupted. Therefore, enable the loopback function only when you locate faults, and disable the loopback function after the loopback test is complete.
The UMG8900 supports three types of loopback modules:
TDM loopback (the loopback on the TDM interface board)
IP loopback (the loopback on the IP interface board)
ATM loopback (the loopback on the ATM interface board)
*
One-Way Audio Failure in TDM-TDM Paths
Step 1: Check whether the fault is caused by device A if user A cannot hear the voice of
user B.
To locate the fault, you can perform an inloop on device A that does not use any
EC resources. If user A cannot hear his/her own voice after the inloop, it indicates that the fault is
caused by device A interconnected with the UMG8900. The possible causes are
as follows:
Wrong connections of TDM cables. Check the cable connections between
the UMG8900 and device A.
Inconsistent configurations of the TDM interfaces.
*
One-Way Audio Failure in TDM-TDM Paths
Step 2 Perform an outloop on the interface of the UMG8900 on the side of device A.
*
One-Way Audio Failure in TDM-TDM Paths
Step 3 Perform an inloop on the interface of the UMG8900 on the side of device B.
If user A cannot hear his/her own voice and the UMG8900 does not use any EC resource, it indicates that the UMG8900 is faulty. If user A can still hear his/her own voice, it indicates that the bearer path along user A, device A, and the UMG8900 is normal. In this case, check whether the cable connections between the UMG8900 and device B are correct and whether device B is normal.
*
One-Way Audio Failure in TDM-TDM Paths
Step 4 Record voices on the TDM interface through which the UMG8900 is interconnected with device B.
*
One-Way Audio Failure in TDM-TDM Paths
Step 5 Perform an inloop on the TDM interface through which the UMG8900 is interconnected with device A. Then, record the voices on the TDM interface to locate the device that introduces the fault.
*
One-Way Audio Failure in TDM-TDM Paths
Step 6
Determine whether the optical fiber connections of the UMG8900 are correct by checking whether "ALM-0818 Fault of CASCADE CONFLICT" is generated and whether the transmitting and receiving of the TDM cascading optical fibers are consistent with those of the TDM cascading optical interfaces of the peer device and consistent with MML configurations.
b. You can check whether one-way audio is caused by board faults by querying information about active alarms. To check whether a failure mode effective analysis (FMEA) alarm is generated, you need to collect information about active alarms related to the TDM interface board that connects device A and device B, active alarms related to the master and slave TNUs in the frame where the TDM interface board is located, and active alarms related to the
TNUs and BLUs in the central switching frame.
c. You can check whether the clock of the CLK is synchronous with that of the
*
Fault Symptom
Fault Analysis
The possible causes of one-way audio in IP-IP paths are as follows:
The UMG8900 does not receive any packet from the peer end or the peer end does not receive any packet from the UMG8900.
2) The packets from the IP side are discarded during the check because of errors.
3) The bearer table of the upper layer control software is configured incorrectly, and thus the packets are discarded. The bearer table includes the bearer processing information that is negotiated by the upper layer control software when the call is connected. Therefore, the wrong configurations of the bearer table may be due to failure of the upper layer control software.
4) The packets are discarded because the GE plane of the UMG8900 fails.
*
One-way Audio or No Audio
One-Way Audio in IP-IP Paths
For causes 1), 2), and 5), you need to capture packets on the mirrored bearer interface of the UMG8900 or record voices on the UMG8900 to check whether the UMG8900 receives any packets from the peer end or check whether the packet contents are correct.
For cause 3), you need to query the bearer table of the one-way audio session, and then submit the table to Huawei R&D engineers.
*
Echo
Symptom
Echo is the reflected copy of one's voice heard some time later and a delayed version of the original
While effective, this approach leads to several problems:
Double-talk: It is fairly normal in conversation for both parties to speak at the same time, at least briefly. Because each echo suppressor will then detect voice energy coming from the far-end of the circuit, the effect would ordinarily be for loss to be inserted in both directions at once, effectively blocking both parties. To prevent this, echo suppressors can be set to detect voice activity from the near-end speaker and to fail to insert loss (or insert a smaller loss) when both the near-end speaker and far-end speaker are talking. This, of course, temporarily defeats the primary effect of having an echo suppressor at all.
Clipping: Since the echo suppressor is alternately inserting and removing loss, there is frequently a small delay when a new speaker begins talking that results in clipping the first syllable from that speaker's speech.
*
Possible Cause
The two factors of echoes in a communication network are as follows:
1. Echo sources
Echoes occur due to low-quality handsets, cross-talking of handsets, or echoes in surroundings are called acoustic echoes. Acoustic echoes easily occur for a poor-quality phone in handfree mode, cordless telephone, personal handyphone system, teleconferencing terminal, or PC phone.
Echoes caused by the hybrid, which is the transformer that joins the two-wire analog local loop to the four-wire transmission network, are called electrical echoes.
2. Long network delay
*
The common causes of echoes are as follows:
Echoes are acoustic echoes. Acoustic echoes are usually not handled on the media gateway (MGW).
The echo canceller chip on the MGW is faulty.
The echo cancellation (EC) configurations are incorrect. For example, the echo canceller is disabled; EC parameters such as the bypass EC switch are incorrect; the tail length of the echo canceller is insufficient; EC option is set to YES.
*
Echo
A mobile station (MS) calls another MS and the two MSs are controlled by one MGW
*
Echo
An MS calls a fixed-line phone in the public switched telephone network (PSTN).
*
The general troubleshooting procedure is as follows:
Rectify the fault in the echo canceller chip on the UMG8900:
Rectify the EC configurations:
Check whether EC resources are added to the UMG8900 during the call:
*
Echo
Check whether the echo canceller chip on the UMG8900 is faulty.
Check whether the echo canceller chip is faulty. If echoes occur sporadically or periodically, the EC chip on the VPU or ECU is faulty. Run DEA BRD to deactivate the VPU or ECU. Then, perform dialing tests to check whether echoes still occur sporadically or periodically.
*
Check whether the EC configurations on the UMG8900 are correct.
Run LST ECPARA to check settings of the bypass EC switches.
LST ECPARA: BT=VPU;
LST ECPARA: BT=ECU;
The bypass EC switch on the VPU or ECU is enabled or disabled
Change the EC tail length. Run SET ECPARA to change the EEC tail length from 64 ms to 128 ms. Then, perform a dialing test to check whether echoes still occur.
Check whether EC option is set to YES. Run LST ECPARA to check whether EC option is set to YES.
*
Echo
Check whether EC resources are added to the UMG8900 during the call.
Create a user call tracing task on the UMG8900. Perform a dialing test by using the traced user number. When echoes occur, keep the call connected.
Check whether EC resources are added for the call by analyzing H.248 signaling messages. Check whether EC resources are added in the ADD REQ and MOD REQ messages
3. enable the EC function on the MGC
*
Echo
Check whether EC resources are added to the UMG8900 during the call.
*
