CloudEC V600R019C10 Troubleshooting (Enterprise On-Premises, IPT) PDF

CloudEC
V600R019C10
Troubleshooting (Enterprise On-

premises, IPT)
Issue 01
Date 2019-06-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://e.huawei.com
Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. i

CloudEC
Troubleshooting (Enterprise On-premises, IPT) Contents
Contents
1 Typical Troubleshooting Cases.................................................................................................. 1

1.1 SessionInsight Media Demarcation and Diagnosis........................................................................................................ 1
1.1.1 Analysis of Typical Voice Fault Scenarios.................................................................................................................. 1
1.1.1.1 No Voice in a Conference......................................................................................................................................... 1
1.1.1.1.1 Symptoms and Possible Causes.............................................................................................................................1
1.1.1.1.2 Processing Idea...................................................................................................................................................... 2
1.1.1.1.3 Diagnosis............................................................................................................................................................... 2
1. P1, The Local Participant Cannot Hear Other Participants' Voice................................................................................... 2
2. P2, The Voice Play Device of the Pickup Party's Endpoint Is Faulty...............................................................................2
3. P3, The Pickup Party's Endpoint Receives No Voice Packet........................................................................................... 3
4. P4, The MCU Sends No Voice Packet..............................................................................................................................4
5. P5, The SBC Sends No Voice Packet............................................................................................................................... 5
6. P6, The Pickup Party's Endpoint Is Muted by the MCU.................................................................................................. 6
7. P7, Other Participants Cannot Hear the Local Participant's Voice................................................................................... 6
8. P8, The MCU Receives No Voice Packet from the Speaker............................................................................................ 6
9. P9, The SBC Receives No Voice Packet from the Speaker..............................................................................................7
10. P10, The Speaker's Voice Collection Device Is Faulty...................................................................................................7
11. P11, The Speaker Performs a Muting Operation by Mistake......................................................................................... 8
12. P12, The Speaker's Endpoint Is Muted by the MCU......................................................................................................8
1.1.1.2 Intermittent Voice..................................................................................................................................................... 8
1.1.1.2.1 Symptoms and Possible Causes.............................................................................................................................8
1.1.1.2.2 Processing Idea...................................................................................................................................................... 9
1.1.1.2.3 Diagnosis............................................................................................................................................................... 9
1. P1, Other Participants' Voice Heard by the Local Participant Is Intermittent.................................................................. 9
2. P2, Voice Packets Received by the Local Participant Are Lost..................................................................................... 10
3. P3, Voice Packets Received by the SBC from the MCU Are Lost.................................................................................10
4. P4, The Local Participant's Voice Heard by Other Participants Is Intermittent..............................................................11
5. P5, Voice Packets Received by the MCU of the Local Participant Are Lost................................................................. 11
6. P6, Voice Packets Received by the SBC from the Endpoint Are Lost........................................................................... 12
1.1.1.3 Noise or Abnormal Volume.................................................................................................................................... 12
1.1.1.3.1 Symptoms and Possible Causes...........................................................................................................................12
1.1.1.3.2 Processing Idea.................................................................................................................................................... 12
1.1.1.3.3 Diagnosis............................................................................................................................................................. 13
Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. ii

CloudEC
1. P1, The Voice of the Local Participant Is Low and Cannot Be Heard Clearly by Other Participants............................13
2. P2, The Volume of the Collected Voice of the Local Participant Is Low....................................................................... 13
3. P3, The Noise of the Local Participant Is Loud and Cannot Be Heard Clearly by Other Participants.......................... 14
4. P4, The Noise of the Collected Voice of the Local Participant Is Loud......................................................................... 14
1.1.2 Analysis of Typical Video Fault Scenarios................................................................................................................15
1.1.2.1 Video Frame Freezing/Artifact............................................................................................................................... 15
1.1.2.1.2 Processing Idea.................................................................................................................................................... 15
1.1.2.1.3 Diagnosis............................................................................................................................................................. 16
1. P1, Frame Freezing Occurs in Other Participants' Video Viewed by the Local Participant...........................................16
2. P2, Packets Received by the Endpoint Are Lost............................................................................................................ 17
3. P3, Packets from the MCU to the SBC Are Lost........................................................................................................... 17
4. P4, Packets Received by the Endpoint Contain Bit Errors.............................................................................................18
5. P5, The Frame Rate of Video Sent by the MCU Is Low................................................................................................ 18
6. P6, Frame Freezing Occurs in the Local Participant's Video Viewed by Other Participants......................................... 19
7. P7, Packets Received by the MCU Are Lost..................................................................................................................19
8. P8, Packets from the Endpoint to the SBC Are Lost......................................................................................................20
9. P9, Packets Received by the MCU Contain Bit Errors.................................................................................................. 20
10. P10, The Endpoint Frequently Sends I Frames............................................................................................................ 21
11. P11, The Frame Rate of Video Sent by the Endpoint Is Low.......................................................................................22
1.1.2.2 No Image/Image Freezing...................................................................................................................................... 23
1.1.2.2.2 Processing Idea.................................................................................................................................................... 23
1.1.2.2.3 Diagnosis............................................................................................................................................................. 24
1. P1, No Image Can Be Viewed or Images Are Frozen in the Other Participants' Video Viewed by the Local Participant
............................................................................................................................................................................................ 24
2. P2, Packets Received by the Endpoint Are Lost............................................................................................................ 25
3. P6, Packets Received by the Endpoint Are Abnormal................................................................................................... 26
4. P7, The MCU Does Not Respond to the I Frame Requests........................................................................................... 27
5. P8, The MCU Software or Hardware Is Faulty.............................................................................................................. 28
6. P9, The SBC Loses I Frames or I Frame Requests........................................................................................................ 29
7. P10, No Image Can Be Viewed or Images Are Frozen in the Local Participant's Video Viewed by Other Participants
............................................................................................................................................................................................ 30
8. P11, Packets Received by the MCU Are Lost................................................................................................................ 30
9. P13, All Packets Forwarded by the SBC Are Lost.........................................................................................................31
10. P15, Packets Received by the MCU Are Abnormal.....................................................................................................33
11. P16, The Camera of the Endpoint Is Faulty..................................................................................................................34
12. P17, The SBC Loses I Frames or I Frame Requests.................................................................................................... 35
13. P18, The MCU Does not Enable Check for No Code Stream......................................................................................36
1.1.2.3 Low Video Definition/Smoothness.........................................................................................................................37
1.1.2.3.2 Processing Idea.................................................................................................................................................... 37
1.1.2.3.3 Diagnosis............................................................................................................................................................. 38
Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. iii

CloudEC
1. P1, Definition or Smoothness of Other Participants' Video Viewed by the Local Participant Is Low...........................38
2. P2, Improper Conference Template Settings Cause Poor Video Quality....................................................................... 39
3. P3, The MCU Frequently Sends I Frames, Causing Poor Video Quality.......................................................................39
4. P4, Forcible Adaptation of the MCU Causes Poor Quality............................................................................................40
5. P5, Bandwidth Reduction of the Recipient Endpoint Causes Poor Quality................................................................... 41
6. P6, Definition or Smoothness of the Local Participant's Video Is Low......................................................................... 42
7. P7, The Sending Frame Rate of the Endpoint Is Low.................................................................................................... 42
8. P8, The Sending Resolution of the Endpoint Is Low..................................................................................................... 43
9. P9, The Endpoint Frequently Sends I Frames................................................................................................................ 44
1.1.3 Analysis of Typical Presentation Fault Scenarios..................................................................................................... 45
1.1.4 Appendix A: Media Counter Details......................................................................................................................... 45
1.2 VM Management Failures............................................................................................................................................ 45
1.2.1 VM Faults.................................................................................................................................................................. 46
1.3 Server Management Failures........................................................................................................................................ 48
1.3.1 Replacing a Server.....................................................................................................................................................48
1.3.2 After the Host Is Replaced, the CloudMCU Must Be Reconfigured........................................................................ 49
1.3.3 New TMS Host Does Not Work After a Host Replacement..................................................................................... 50
1.4 Maintenance Faults of OMU........................................................................................................................................ 50
1.4.1 WebUI Troubleshooting.............................................................................................................................................50
1.4.1.1 Incorrect Display on the OMU Web Portal............................................................................................................ 50
1.4.2 Module Management Failures................................................................................................................................... 51
1.4.2.1 Module Failure....................................................................................................................................................... 51
1.4.2.2 Abnormal Module Backup..................................................................................................................................... 53
1.4.2.3 Incorrect Virtual Machine Time............................................................................................................................. 54
1.4.3 OMU Process Failures...............................................................................................................................................55
1.4.3.1 OMU Process Abnormal........................................................................................................................................ 55
1.4.3.2 Communication Failure Between the OMU and the Host......................................................................................55
1.4.4 OMU HA System Failures........................................................................................................................................ 57
1.4.4.1 Active/Standby OMU Switchover Failure............................................................................................................. 57
1.4.4.2 Automatic Active/Standby OMU Switchover Triggered....................................................................................... 59
1.4.4.3 Duration of Data Synchronization Between the OMUs is Too Long.....................................................................60
1.4.4.4 OMU Service Startup Failure................................................................................................................................. 61
1.4.5 License Failures......................................................................................................................................................... 62
1.4.5.1 License Activation Failure......................................................................................................................................62
1.4.5.2 License Control Items of the Source Version Are Displayed After an Upgrade.................................................... 66
1.4.6 Upgrade Failures........................................................................................................................................................67
1.4.6.1 Target Version Selection Failure.............................................................................................................................67
1.4.6.2 Connection to the MML Server Failed During the CGP Process Upgrade............................................................68
1.4.6.3 "Incorrect User Name or Password" Displayed During the Upgrade or Rollback.................................................68
1.4.6.4 Browser Failure During the Upgrade..................................................................................................................... 69
1.4.7 Patch Failures............................................................................................................................................................ 70
1.4.7.1 Patch Loading Failure.............................................................................................................................................70
Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. iv

CloudEC
1.4.7.2 Inconsistent Patch Status Between the OMU and the Host....................................................................................74
1.4.8 Performance Management Failures........................................................................................................................... 75
1.4.8.1 Unreliable Performance Measurement Result........................................................................................................ 75
1.4.8.2 Failure of Creating a Measurement Task................................................................................................................78
1.4.8.3 Incorrect Time Segment in a Measurement Result.................................................................................................79
1.4.8.4 Discontinuous Time Segments of Measurement Results....................................................................................... 80
1.4.8.5 Failure of Reporting Traffic Measurement Data to the OSS.................................................................................. 84
1.4.8.6 Performance Management System Login Failure.................................................................................................. 85
1.4.9 Command Failures.....................................................................................................................................................86
1.4.9.1 Message "Failed to send the request data" Returned..............................................................................................86
1.4.9.2 Message "Operation timed out" Returned.............................................................................................................. 87
1.4.9.3 Data Backup Failure............................................................................................................................................... 88
1.4.9.4 Failure of Step-by-Step Restoration....................................................................................................................... 91
1.5 LMT Failures................................................................................................................................................................ 93
1.5.1 Installation and Uninstallation Faults........................................................................................................................ 93
1.5.1.1 Prompted to Install JRE During JWS Installation.................................................................................................. 93
1.5.1.2 System Displays "Application Blocked by Security Settings" During JWS Installation.......................................96
1.5.1.3 System Displays "Downloading 7z tools fail" During the Client Installation Using JWS.................................. 102
1.5.1.4 Failure in Starting or Removing the Client through JWS.................................................................................... 103
1.5.2 Login Faults............................................................................................................................................................. 110
1.5.2.1 LMT Login Failure............................................................................................................................................... 111
1.5.2.2 Client Login Failure After the Floating IP Address of the OMU Is Changed......................................................120
1.5.3 Upgrade and Update Faults..................................................................................................................................... 122
1.5.3.1 LMT Client Update File Is Being Used by Another Program..............................................................................122
1.5.3.2 Writing the File Fails During an LMT Update..................................................................................................... 124
1.5.4 GUI Faults............................................................................................................................................................... 127
1.5.4.1 Abnormalities Occur on the LMT........................................................................................................................ 128
1.5.4.2 Navigation to the Help Webpage Was Canceled.................................................................................................. 131
1.5.5 FTP Tool Faults....................................................................................................................................................... 133
1.5.5.1 FTP Start Failure.................................................................................................................................................. 133
1.5.5.2 Directory Space Is Insufficient When Files Are Uploaded Using the FTP.......................................................... 136
1.5.5.3 System Displays an Upgrade Tool Update Failure or System Being Upgraded.................................................. 137
1.5.6 Other Faults............................................................................................................................................................. 138
1.5.6.1 Data Is Inconsistent Between Tables and Curves on Module Management Page of the LMT............................ 138
1.5.6.2 OMU Client on a Remotely Connected PC Cannot Provide the Predictive MML Command Input Function....139
1.6 Service NE Interconnection Faults............................................................................................................................. 143
1.6.1 MRP Interworking Fault..........................................................................................................................................143
1.6.2 CCF Interworking Fault...........................................................................................................................................144
1.6.3 Failed to Received CDRs on the CCF..................................................................................................................... 146
1.6.4 SIP Trunk Interworking Fault..................................................................................................................................148
1.6.5 Interworking Fault Between the uPortal and Peripheral NEs..................................................................................149
1.6.6 DR Network Data Synchronization Fault................................................................................................................150
Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. v

CloudEC
1.6.7 ECS Interworking Fault...........................................................................................................................................151

1.7 Service Faul................................................................................................................................................................ 152
1.7.1 Login and Registration Faults..................................................................................................................................152
1.7.1.1 Terminal HTTP Access Fault............................................................................................................................... 152
1.7.1.2 Login and Registration Fault................................................................................................................................ 153
1.7.1.3 SIP Registration Fault...........................................................................................................................................154
1.7.2 Voice Faults............................................................................................................................................................. 155
1.7.2.1 Announcement Playing Faults..............................................................................................................................155
1.7.2.1.1 Announcement Playing Fault Rectification Method......................................................................................... 155
1.7.2.1.2 Service Announcement Playing Fault............................................................................................................... 160
1.7.2.1.3 MRP Announcement Playing Fault................................................................................................................... 165
1.7.2.1.4 A Participant Tries Joining a Conference Using IVR But Is Prompted the Call Ends......................................184
1.7.2.2 Recording Failure................................................................................................................................................. 185
1.7.3 Service Provisioning Faults..................................................................................................................................... 186
1.7.3.1 Web-based Service Provisioning Fault................................................................................................................. 186
1.7.3.2 Exceeded Authorized Values During Service Provisioning................................................................................. 187
1.7.3.3 Service Provisioning on the uPortal Occasionally Fails.......................................................................................188
1.7.3.4 Failure to Query the Address Book Because a Host Is Replaced.........................................................................191
1.7.3.5 Failure to Query the Address Book Because a Host Is Faulty for a Long Time.................................................. 192
1.7.4 Conference Service Faults....................................................................................................................................... 192
1.7.4.1 Conference Routing Fault.....................................................................................................................................193
1.7.5 UC Service Faults.................................................................................................................................................... 193
1.7.5.1 Rich Media Faults.................................................................................................................................................193
1.7.5.1.1 Failed to Upload Rich Media Files....................................................................................................................193
1.7.5.1.2 Failed to Download Rich Media Files............................................................................................................... 194
1.7.5.2 iOS Push Function Is Unavailable........................................................................................................................195
1.8 Maintenance Faults.....................................................................................................................................................196
1.8.1 uPortal Operation Faults.......................................................................................................................................... 196
1.8.1.1 Failed to Display the Web Login Page................................................................................................................. 196
1.8.1.2 Web Login Failure................................................................................................................................................ 198
1.8.1.3 Web Page Debugging Window Is Displayed........................................................................................................200
1.8.1.4 Web Certificate Error............................................................................................................................................202
1.8.1.5 Data Import or Output Failure.............................................................................................................................. 210
1.8.1.6 Execution Return Result Is Empty on the sysPortal.............................................................................................212
1.8.2 USM Does Not Respond to SIP Messages.............................................................................................................. 213
1.9 Other Faults................................................................................................................................................................ 217
1.9.1 USM Does Not Respond to SIP Messages.............................................................................................................. 217
1.9.2 Failed to Clear Alarms Reported by the Original Active Node After a Switchover Between the Active and Standby
ECS Nodes........................................................................................................................................................................221
1.9.3 Built-in DNS Fault...................................................................................................................................................222
Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. vi

CloudEC
Troubleshooting (Enterprise On-premises, IPT) 1 Typical Troubleshooting Cases
1 Typical Troubleshooting Cases
1.1 SessionInsight Media Demarcation and Diagnosis
1.1.1 Analysis of Typical Voice Fault Scenarios

Typical voice fault scenarios include the following: no voice in a conference, intermittent
voice, noise, and abnormal volume. The following describes how to demarcate and diagnose
the fault in each scenario.
(You need to differentiate the scenario where no voice can be heard from that where the voice
is intermittent. In the scenario where no voice can be heard, a participant can hear no voice in
a long time. For example, a participant can hear no voice since the participant joins a
conference, or a participant can hear no voice for over 30 seconds. In the scenario where the
voice is intermittent, a participant can hear intermittent voice and cannot understand the exact
meaning.)
1.1.1.1 No Voice in a Conference
1.1.1.1.1 Symptoms and Possible Causes

Symptoms: In a multi-party conference or P2P call, a participant cannot hear other
participants' voice or cannot be heard by other participants.
Exceptions of the endpoints, transmission network, or media processing devices may cause no
voice in a conference. Common root causes are as follows:
[Endpoint problems]: The speaker performs an incorrect operation on the endpoint and the
endpoint is muted. The software or hardware of the pickup party's endpoint is faulty and there
is no voice output, for example, when the headset or stereo device is faulty. The software or
hardware of the speaker's endpoint is faulty and there is no voice input, for example, when the
microphone (MIC) is faulty.
[Transmission network faults]: Voice packets sent from the speaker to the MCU are lost.
Alternatively, voice packets sent from the MCU to the pickup party's endpoint are lost.
[Media processing device faults]: Upstream packets from the SBC are not correctly sent to the
MCU. Downstream packets from the SBC are not correctly sent to the endpoint. The MCU
Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 1

CloudEC
proactively mutes the local participant or other participants due to incorrect operations. The
MCU software or hardware is faulty, causing the failure to send voice frames.
1.1.1.1.2 Processing Idea

Serial conference voice processing includes multiple stages from collection of speaker signals
to playback on the pickup party's endpoint. The processing idea of no voice in a conference is
as follows: Analyze the fault cause stage by stage from the pickup party's endpoint in the
reverse direction of media processing based on the counter data collected in the
SessionInsight until the fault cause is detected.
1.1.1.1.3 Diagnosis
Figure 1-1 Analysis of Typical Voice Fault Scenarios
?.1. P1, The Local Participant Cannot Hear Other Participants' Voice
[Determination rule]
During a conference, if a participant cannot hear other participants' voice but voice
communication between the other participants is normal, you can determine that the
downstream path of the participant is abnormal. Therefore, the diagnosis process goes to this
branch.
?.2. P2, The Voice Play Device of the Pickup Party's Endpoint Is Faulty
The voice play device of the pickup party's endpoint is faulty. The final voice play level
(voice level(play)) of the pickup party's endpoint is used for determination. If there is no valid
voice packet input due to network, SBC, or MCU exceptions, the final voice play level of the
user is always invalid (0 to 5). If the final voice play level is valid (less than 90, generally 30
to 60) but the pickup party can still hear no voice, you can determine that the voice play
device of the pickup party's endpoint is faulty.
[Example]

CloudEC
As shown in Figure 1-2, select Decoding and Vioce Level(Decoding) for Counter receiving
settings to display statistics about the voice play module's voice level of the pickup party's
endpoint. Then, you can detect that the voice level mainly ranges from 30 to 50 in the fault
period, indicating that the input voice level is valid. In this case, if the user hears no voice,
you can determine that the user's voice play device is faulty.
Figure 1-2 Counter indicating the endpoint's voice play level
?.3. P3, The Pickup Party's Endpoint Receives No Voice Packet

The number of packets received by the pickup party's endpoint (Packets(Network
receiving)) is used for determination. In normal cases, the pickup party's endpoint receives
about 50 packets per second and the number of packets received by the pickup party's
endpoint increases continuously. If the number of received packets does not increase in the
fault period, you can determine that the fault occurs because the pickup party's endpoint
receives no voice packet.
[Example]
As shown in Figure 1 Counter indicating the number of voice packets received by the
endpoint, the number of packets received by the pickup party's endpoint does not increase
since about 17:02. Then, you can determine that the fault occurs because the pickup party's
endpoint receives no voice packet.

CloudEC
Figure 1-3 Counter indicating the number of voice packets received by the endpoint
?.4. P4, The MCU Sends No Voice Packet

The number of packets sent by the MCU (Packets(Network sending)) is used for
determination: In normal cases, the MCU sends about 50 packets per second and the number
of packets sent by the MCU increases continuously. In the call life cycle, if the number of
packets sent by the MCU does not increase or no data is reported (CHR data loss after the
MCU crashes or restarts), you can determine that the fault occurs because the MCU sends no
voice packet.
[Example]
endpoint on the network, the call lasts from 03:41 to 03:48 and the number of packets
received by the endpoint does not increase since about 03:45 based on endpoint data. As
shown in Figure 1 Counter indicating the number of voice packets sent by the MCU on
the network, the MCU does not report data. Then, you can determine that the fault occurs
because the MCU sends no voice packet.
Figure 1-4 Counter indicating the number of voice packets sent by the MCU on the network

CloudEC
Figure 1-5 Counter indicating the number of voice packets received by the endpoint on the network
?.5. P5, The SBC Sends No Voice Packet

The number of packets sent by the access side of the SBC (Packets(Access side(Sending))) is
used for determination. In normal cases, the SBC sends about 50 packets per second at the
access side. In the call life cycle, if the number of packets sent by the SBC is 0 or no data is
reported (CHR data loss after the SBC crashes or restarts), you can determine that the fault
occurs because the SBC sends no voice packet.
Note: The number of packets sent by the SBC is that collected in the current collection period,
while the number of packets sent by the MCU and endpoint is an accumulated value.
[Example]
As shown in Figure 1 Counter indicating the number of voice packets sent by the SBC,
the number of sent packets starts decreasing to 0 at about 09:26:30 based on SBC data. Then,
you can determine that the fault occurs because the SBC sends no voice packet.
Figure 1-6 Counter indicating the number of voice packets sent by the SBC

CloudEC
?.6. P6, The Pickup Party's Endpoint Is Muted by the MCU

The output voice level of the MCU mixer (Voice Level from Mixer) and pre-coding voice
level (Voice Level before Coding) are used for determination. If the output voice level of the
mixer is valid (30 to 60) and the pre-coding voice level is always invalid (0 to 5), you can
determine that the pickup party's endpoint is muted by the MCU.
[Example]
Obtain the MCU voice level counter data by referring to P2, The Voice Play Device of the
Pickup Party's Endpoint Is Faulty and determine whether the pickup party's endpoint is
muted based on the counter data.
?.7. P7, Other Participants Cannot Hear the Local Participant's Voice
During a conference, if a participant's voice cannot be heard by other participants but voice
communication between the other participants is normal, you can determine that the upstream
path of the participant is abnormal. Therefore, the diagnosis process goes to this branch.
?.8. P8, The MCU Receives No Voice Packet from the Speaker
The number of packets received by the MCU (Packets(Network receiving)) is used for
determination: In normal cases, the MCU receives about 50 packets per second and the
number of packets received by the MCU increases continuously. If the number of received
packets does not increase in the fault period, you can determine that the fault occurs because
the MCU receives no voice packet.
[Example]
MCU, the number of packets received by the MCU does not increase since about 09:38:40.
Then, you can determine that the fault occurs because the MCU receives no voice packet from
the speaker.
Figure 1-7 Counter indicating the number of voice packets received by the MCU

CloudEC
?.9. P9, The SBC Receives No Voice Packet from the Speaker
The number of packets received by the access side of the SBC (Packets(Access
side(Receiving))) is used for determination. In normal cases, the SBC receives about 50
packets per second at the access side. If the number of received packets is 0 in the fault
period, you can determine that the fault occurs because the SBC receives no voice packet
from the speaker.
[Example]
SBC, the number of packets received by the SBC is 0 from 16:48:50 to 16:50:20. Then, you
can determine that the fault occurs because the SBC receives no voice packet from the
speaker.
Figure 1-8 Counter indicating the number of voice packets received by the SBC
?.10. P10, The Speaker's Voice Collection Device Is Faulty

The voice collection level of the speaker's endpoint (Voice Level(Collection)) is used for
determination. In normal cases, the voice collection level ranges from 30 to 60. If the voice
collection level is invalid (0 to 5) in a long time, you can determine that the voice collection
device of the speaker is faulty.
[Example]
As shown in Figure 1 Counter indicating the voice collection level of the endpoint, the
voice collection level is invalid (0 to 5). Then, you can determine that the speaker's voice
collection device is faulty.

CloudEC
Figure 1-9 Counter indicating the voice collection level of the endpoint
?.11. P11, The Speaker Performs a Muting Operation by Mistake

The speaker endpoint's voice collection level (Vioce Level(Collection)) and voice encoding
level (Vioce Level(Coding)) are used for determination. If the voice collection level is valid
(30 to 60) and the voice encoding level is always invalid (0 to 5), you can determine that the
speaker performs a muting operation by mistake.
[Example]
Obtain the counter data of the endpoint's voice collection level and voice encoding level by
referring to P2, The Voice Play Device of the Pickup Party's Endpoint Is Faulty and
determine whether the speaker performs a muting operation by mistake based on the counter
data.
?.12. P12, The Speaker's Endpoint Is Muted by the MCU

The voice level after MCU decoding (Voice Level after Decoding) and pre-AGC voice level
(Voice Level before AGC) are used for determination. If the voice level after decoding is
valid (30 to 60) and the pre-AGC voice level is always invalid (0 to 5), you can determine that
the speaker's endpoint is muted by the MCU.
[Example]
Obtain the counter data of the voice level after MCU decoding and pre-AGC voice level by
referring to P2, The Voice Play Device of the Pickup Party's Endpoint Is Faulty and
determine whether the speaker's endpoint is muted by the MCU based on the counter data.
1.1.1.2 Intermittent Voice

Symptoms: In a multi-party conference or P2P call, other participants' voice heard by a
participant is intermittent or the participant's voice heard by other participants is intermittent.

CloudEC
Exceptions of the endpoints and transmission network may cause intermittent voice in a
conference. Common root causes are as follows:
[Endpoint problems]: Voice collected by the endpoint is intermittent due to interference from
the bluetooth and wireless MIC.
[Transmission network faults]: The transmission network fault, including packet loss from the
MCU to the SBC and from the SBC and the endpoint, is the most common cause for
intermittent voice.
Note: Detection of intermittent voice collected by the endpoint depends on the signal-layer
wave test whose performance overhead is large. In addition, no suitable algorithm is available
currently. Therefore, you cannot directly determine the cause currently. After you eliminate
problems on the network side, you can check for endpoint problems.

Check whether packets are lost at the media receiving end. If packets are lost, check for the
stage where the packets are lost.
1.1.1.2.3 Diagnosis
Figure 1-10 Intermittent Voice
?.1. P1, Other Participants' Voice Heard by the Local Participant Is Intermittent
During a conference, if other participants' voice heard by a participant is intermittent but

voice communication between the other participants is normal, you can determine that the
downstream path of the participant is abnormal. Therefore, the diagnosis process goes to this
branch.

CloudEC
?.2. P2, Voice Packets Received by the Local Participant Are Lost
Voice packets received by the local participant are lost. The packet loss rate of the pickup
party's endpoint (Loss(Network receiving)) is used for determination. When the network is
normal, the packet loss rate of the pickup party's endpoint is 0. Counter data of the pickup
party's packet loss rate indicates whether packets are lost on the network. If the user's MOS
trend is closely related to the packet loss rate, you can determine that packet loss causes
intermittent voice.
[Example]
As shown in Figure 1 Counters indicating the MOS and the loss rate of voice packets
received by the endpoint on the network, select Decoding, Network receiving and
MOS(Network receiving), RTT(Network receiving), Packets(Network receiving),
Loss(Network receiving), Bandwidth(Network receiving) for Counter receiving settings
to display statistics about the MOS and the loss rate of voice packets received by the endpoint
on the network. In the whole call life cycle, the MOS decreases for three times and the packet
loss rate increases each time when the MOS decreases. Then, you can determine that packet
loss causes intermittent voice.
Figure 1-11 Counters indicating the MOS and the loss rate of voice packets received by the endpoint on the
network
?.3. P3, Voice Packets Received by the SBC from the MCU Are Lost
Voice packets received by the SBC from the MCU are lost. The average loss rate of packets
received by the recipient at the core side of the SBC is used for determination. As shown in
Figure 1 Counter indicating the average loss rate of voice packets received by the SBC
on the network, the packet loss rate of the pickup party's endpoint is 0 when the network is
normal. Counter data of the SBC's packet loss rate indicates whether packets are lost on the
transmission network from the MCU to the SBC. If the trend of the pickup party endpoint's
packet loss rate is closely related to the SBC's packet loss rate, you can determine that loss of
voice packets received by the SBC from the MCU causes intermittent voice.
[Example]

CloudEC
Figure 1-12 Counter indicating the average loss rate of voice packets received by the SBC on the network
?.4. P4, The Local Participant's Voice Heard by Other Participants Is Intermittent
During a conference, if a participant's voice heard by other participants is intermittent but
voice communication between the other participants is normal, you can determine that the
upstream path of the participant is abnormal. Therefore, the diagnosis process goes to this
branch.
?.5. P5, Voice Packets Received by the MCU of the Local Participant Are Lost
Voice packets received by the MCU of the local participant are lost. The loss rate of voice
packets received by the MCU on the network (Loss(Network receiving)) is used for
determination. When the network is normal, the loss rate of voice packets received by the
MCU on the network is 0. Counter data of the MCU's packet loss rate indicates whether
packets are lost on the network. If the packet loss rate increases obviously, you can determine
that loss of voice packets received by the MCU causes intermittent voice.
Note: Currently, voice MOS calculation is not implemented in the MCU. Therefore, you can
only determine an approximate period where intermittent voice occurs based on the user
feedback.
[Example]
As shown in Figure 1 Counter indicating the loss rate of packets received by the MCU on
the network, select Network receiving, Decoding and RTT(Network receiving),
Packets(Network receiving), Loss(Network receiving) for Counter receiving settings to
display statistics about the packet loss rate of the recipient of the MCU on the network. In the
call life cycle, the packet loss rate increases obviously for three times. Then, you can
determine that packet loss causes intermittent voice.

CloudEC
Figure 1-13 Counter indicating the loss rate of packets received by the MCU on the network
?.6. P6, Voice Packets Received by the SBC from the Endpoint Are Lost
Voice packets received by the SBC from the endpoint are lost. The average loss rate of
packets received by the recipient at the access side of the SBC is used for determination. In
normal cases, the packet loss rate is 0. Counter data of the SBC's packet loss rate indicates
whether packets are lost on the transmission network from the endpoint to the SBC. If the
trend of the MCU's packet loss rate is closely related to the SBC's packet loss rate, you can
determine that loss of voice packets received by the SBC from the endpoint causes
intermittent voice.
[Example]
Obtain the counter data of the average loss rate of voice packets received by the SBC by
referring to P3, Voice Packets Received by the SBC from the MCU Are Lost and
determine whether voice packets received by the SBC from the endpoint are lost based on the
counter data.
1.1.1.3 Noise or Abnormal Volume

(The following takes input noise and MIC volume adjustment as examples.)
Symptoms: In a multi-party conference or P2P call, voice collection of some participants is

often abnormal, causing extremely low volume or a loud background noise. Therefore, such
participants' voice is difficult to hear.
The problems are mainly caused by endpoint settings or problems in the environment of the
MIC.

Currently, level counters for evaluating the voice and noise levels are defined for endpoints.
Such level counters can be analyzed to determine the cause of the preceding problems.

CloudEC
1.1.1.3.3 Diagnosis
Figure 1-14 Noise or Abnormal Volume
?.1. P1, The Voice of the Local Participant Is Low and Cannot Be Heard Clearly by Other
Participants
During a conference, if the voice of a participant cannot be heard clearly by all the other
participants but the communication of the other participants is normal, the diagnosis process
goes to this branch.
?.2. P2, The Volume of the Collected Voice of the Local Participant Is Low
The volume of the collected voice of the local participant is low. The comparison between the
voice collection level and voice sending level and MIC volume adjustment event are used for
determination. The volume of the voice collected by the MIC ranges from 1 to 100. A larger
value indicates a larger volume. During a call, if you can detect that the volume value is
small, for example, less than 20, in a volume adjustment event, the fault may be caused by
improper MIC volume settings. If no MIC volume adjustment event occurs during a call,
observe the relationship between the voice collection level and voice sending level. If the
voice sending level is much less than the voice collection level in a long time, you can
determine that the low volume is caused by improper MIC volume settings because the MIC
volume settings affect only the voice sending level but does not affect the voice collection
level.
[Example]
As shown in Figure 1 Endpoint volume adjustment counters, if you detect a MIC volume
adjustment event and the volume is finally adjusted to 5, you can determine that the fault is
caused by improper MIC settings. In addition, as shown in Figure 2 Counters indicating the
voice collection level and voice coding level of the endpoint, if you detect that the voice
sending level is much less than the voice collection level in a long time after volume
adjustment, you can further determine that the fault is caused by improper MIC settings.

CloudEC
Figure 1-15 Endpoint volume adjustment counters
Figure 1-16 Counters indicating the voice collection level and voice coding level of the endpoint
?.3. P3, The Noise of the Local Participant Is Loud and Cannot Be Heard Clearly by
Other Participants
During a conference, if the noise of a participant is loud and the voice of the participant
cannot be heard clearly by all the other participants but the communication of the other
participants is normal, the diagnosis process goes to this branch.
?.4. P4, The Noise of the Collected Voice of the Local Participant Is Loud
The noise of the collected voice of the local participant is loud. The noise collection level of
the endpoint is used for determination. If the noise collection level of the endpoint is close to
the threshold, you can determine that the noise of the collected voice is loud.
[Example]

CloudEC
As shown in Figure 1 Counter indicating the voice coding level of the endpoint, noises are
lower than 50 dB in normal cases and noises higher than 70 dB interfere chats. You can
determine whether the noise of the voice collected by the endpoint is loud based on the noise
collection level. Currently, the endpoint reports no noise collection level data. After the
endpoint reports the noise collection level, the voice coding level in the following figure is
changed to the noise collection level. Then, you can determine the problem cause accordingly.
Figure 1-17 Counter indicating the voice coding level of the endpoint
1.1.2 Analysis of Typical Video Fault Scenarios

Typical video fault scenarios include the following: video frame freezing/artifact, no video
image/video image freezing, and low video definition/smoothness. The following describes
how to demarcate and diagnose the fault in each scenario.
1.1.2.1 Video Frame Freezing/Artifact

Symptoms: In a multi-party conference or P2P call, frame freezing or artifact occurs in video
viewed by the local participant or other participants.
Exceptions of the endpoints, transmission network, or media processing devices may cause
frame freezing or artifact. Common root causes are as follows:
[Endpoint problems]: The frame rate of video sent by the endpoint is low. The endpoint
frequently sends I frames.
[Transmission network faults]: Packets received by the MCU are lost. Packets received by the
MCU contain bit errors. Packets received by the endpoint are lost. Packets received by the
endpoint contain bit errors.
[Media processing device faults]: The frame rate of video sent by the MCU is low.

Similar to voice processing, serial conference video processing includes multiple stages from
collection of speaker signals to playback on the pickup party's endpoint. The following figure
shows the process of a video conference.

CloudEC
The processing idea of frame freezing or artifact is as follows: Analyze the fault cause stage
by stage from the pickup party's endpoint in the reverse direction of media processing based
on the counter data collected in the SessionInsight until the fault cause is detected.
1.1.2.1.3 Diagnosis
Figure 1-18 Analysis of Typical Video Fault Scenarios
?.1. P1, Frame Freezing Occurs in Other Participants' Video Viewed by the Local
Participant
The user determines whether frame freezing occurs in other participants' video viewed by the
local participant.

CloudEC
?.2. P2, Packets Received by the Endpoint Are Lost

The number of lost network packets (Net Lost Packets(Network receiving)) and decoding
frame rate (Decode Frame Rate(Decoding)) of the pickup party's endpoint are used for
determination. In normal cases, the number of lost network packets is 0. If packets are lost,
the number of lost network packets is greater than 0 and the decoding frame rate of the pickup
party's endpoint decreases.
[Example]
As shown in Figure 1 Counters indicating the number of lost network packets received
by the endpoint and decoding frame rate, the number of lost network packets increases
from 0 to a value greater than 0 and the decoding frame rate of the pickup party's endpoint
decreases since 19:01. Then, you can determine that network packet loss causes video frame
freezing.
Figure 1-19 Counters indicating the number of lost network packets received by the endpoint and decoding frame
rate
?.3. P3, Packets from the MCU to the SBC Are Lost
The average loss rate of packets received by the SBC (video streams at the core side) is used
for determination. If the average loss rate of packets received by the SBC (video streams at
the core side) is greater than 0, packets from the MCU to SBC are lost.
[Example]
As shown in Figure 1 Counter indicating the average loss rate of video packets received
by the SBC, the average loss rate of video packets received by the SBC is greater than 0.
Then, you can determine that packets from the MCU to the SBC are lost.

CloudEC
Figure 1-20 Counter indicating the average loss rate of video packets received by the SBC
?.4. P4, Packets Received by the Endpoint Contain Bit Errors

The decoding frame rate (Decode Frame Rate) and number of decoding errors
(DstDecErrorCnt) of the recipient and the number of lost packets on the network (Net Lost
Packets) are used for determination. If the number of lost packets on the network is 0, the
number of decoding errors of the recipient increases unexpectedly, and the decoding frame
rate of the recipient decreases, the packets received by the endpoint contain bit errors.
[Example]
For details, see the example in P9, Packets Received by the MCU Contain Bit Errors.
?.5. P5, The Frame Rate of Video Sent by the MCU Is Low
The number of frames encoded and sent by the media source end (MCU), receiving frame rate
of the media receiving end (endpoint), and decoding frame rate at the media receiving end
(endpoint) are used for determination. If the decoding frame rate of the recipient, receiving
frame rate of the recipient, and total number of encoded and sent frames are low and the
frame rates are less than 10 fps, you can determine that frame freezing occurs because the
frame rate of video sent by the MCU is low.
[Example]
As shown in Figure 1 Counter indicating the frame rate of video encoded by the MCU,
the target number of frames to be encoded by the MCU is 30, but the actual number of frames
encoded by the MCU is 1. As shown in Figure 2 Counter indicating the frame rate of
video decoded by the endpoint, the number of frames decoded by the endpoint is 1. Then,
you can determine that the frame rate of video encoded by the MCU is low.

CloudEC
Figure 1-21 Counter indicating the frame rate of video encoded by the MCU
Figure 1-22 Counter indicating the frame rate of video decoded by the endpoint
?.6. P6, Frame Freezing Occurs in the Local Participant's Video Viewed by Other
Participants
The user determines whether frame freezing occurs in the local participant's video images
viewed by other participants and whether to go to the subsequent process.
?.7. P7, Packets Received by the MCU Are Lost

The number of lost network packets of the MCU (Net Lost Packets(Network receiving)) and
decoding frame rate of the recipient (Decode Frame Rate(Decoding)) are used for
determination. If the number of lost network packets increases unexpectedly and the decoding
frame rate of the recipient decreases, you can determine that network packet loss causes the
frame freezing.
[Example]

CloudEC
As shown in Figure 1 Counters indicating the loss rate of video packets received by the
MCU on the network and decoding frame rate, the value of Decode Frame
Rate(Decoding) decreases when the value of Net Lost Packets(Network receiving)
increases and the value of Decode Frame Rate(Decoding) is always low during continuous
packet loss.
Figure 1-23 Counters indicating the loss rate of video packets received by the MCU on the network and decoding
frame rate
?.8. P8, Packets from the Endpoint to the SBC Are Lost
The average loss rate of packets received by the SBC (video streams at the access side) is
used for determination. If the average loss rate of packets received by the SBC (video streams
at the access side) is greater than 0, packets from the endpoint to SBC are lost. [Example]
For details, see P2, Packets Received by the Endpoint Are Lost.
?.9. P9, Packets Received by the MCU Contain Bit Errors

The decoding frame rate (Decode Frame Rate(Decoding)) and number of decoding errors
(Decode Errors(Decoding)) of the recipient of the MCU and the number of lost packets on
the network (Net Lost Packets(Network receiving)) are used for determination. If the
number of lost packets on the network is 0, the number of decoding errors of the recipient
increases unexpectedly, and the decoding frame rate of the recipient decreases, the packets
received by the MCU contain bit errors.
[Example]
As shown in Figure 1-24, since 21:12, the number of decoding errors of the recipient
increases unexpectedly and the decoding frame rate of the recipient decreases, but the number
of lost packets on the network is still 0, indicating that the packets received by the MCU
contain bit errors.

CloudEC
Figure 1-24 Counters indicating the number of lost video packets received by the MCU on the network &
decoding frame rate & number of decoding errors
?.10. P10, The Endpoint Frequently Sends I Frames

The number of I frames sent by the media source end (endpoint) (I Frames(Coding)),
number of I frames actually received by the media receiving end (MCU) (Receive I
Frames(Decoding)), and decoding frame rate of the media receiving end (Decode Frame
Rate(Decoding)) are used for determination. If the number of I frames sent by the media
source end and the number of I frames actually received by the media receiving end are high
(frame rate up to 1 fps) and the decoding frame rate of the media receiving end decreases, you
can determine that frame freezing occurs because the endpoint frequently codes I frames.
[Example]
As shown in Figure 1 Counter indicating the number of I frames of video encoded by the
endpoint and Figure 1-26, the I frame rate in I Frames(Coding) and Receive I
Frames(Decoding) reaches 1 fps and the value of Decode Frame Rate(Decoding) decreases.
Then, you can determine that frame freezing occurs because the endpoint frequently codes I
frames.
Figure 1-25 Counter indicating the number of I frames of video encoded by the endpoint

CloudEC
Figure 1-26 Counters indicating the number of I frames of video decoded by the MCU & the decoding frame rate
?.11. P11, The Frame Rate of Video Sent by the Endpoint Is Low
The number of frames encoded and sent by the media source end (endpoint), receiving frame
rate of the media receiving end (MCU), and decoding frame rate of the media receiving end
(MCU) are used for determination. If the decoding frame rate of the recipient, receiving frame
rate of the recipient, and total number of encoded and sent frames are low and the frame rates
are less than 10 fps, you can determine that frame freezing occurs because the frame rate of
video sent by the endpoint is low.
[Example]
As shown in Figure 1-27 and Figure 1-28, the decoding frame rate of the recipient, receiving
frame rate of the recipient, and total number of encoded and sent frames are low and the
sending and encoding frame rate is less than 10 fps. Then, you can determine that frame
freezing occurs because the frame rate of video sent by the endpoint is low.
Figure 1-27 Counter indicating the number of frames of video encoded by the endpoint

CloudEC
Figure 1-28 Counters indicating the number of video frames received by the MCU & the decoding frame rate
1.1.2.2 No Image/Image Freezing

Symptoms: In a multi-party conference or P2P call, a participant cannot view other
participants' images or cannot be viewed by other participants or the image is frozen.
Exceptions of the endpoints, transmission network, or media processing devices may cause no
image in a conference. Common root causes are as follows:
[Endpoint problems]: The speaker performs an incorrect operation on the endpoint and the
camera is closed. The software or hardware of the speaker's endpoint is faulty and there is no
video input, for example, when the camera is faulty. Frames sent by the endpoint or gateway
are abnormal, causing the decoding failure.
[Transmission network faults]: Video packets sent from the speaker to the MCU are lost.
Alternatively, video packets sent from the MCU to the pickup party's endpoint are lost.
[Media processing device faults]: The MCU does not respond to I frame requests. The MCU
software or hardware is faulty, for example, causing device restarting. The SBC loses I frames
or I frame requests.

The processing idea of no image or image freezing in a conference is as follows: Analyze the
fault cause stage by stage from the pickup party's endpoint in the reverse direction of media
processing based on the counter data collected in the SessionInsight until the fault cause is
detected.

CloudEC
1.1.2.2.3 Diagnosis
Figure 1-29 No Image/Image Freezing
?.1. P1, No Image Can Be Viewed or Images Are Frozen in the Other Participants' Video
Viewed by the Local Participant
No image can be viewed or images are frozen in the other participants' video viewed by the
local participant. The receiving frame rate and decoding frame rate in the receiving direction
of the local participant are used for determination. If there is no valid video packet input due
to network, SBC, or MCU exceptions, the output decoding frame rate of the user is 0. If the
decoding frame rate is 0 and the receiving frame rate is valid (1 to 30), you can determine that
the decoding exception causes no image or image freezing.
[Example]
As shown in Figure 1 Counters indicating the number of video packets received by the
endpoint on the network & the decoding frame rate, select Decoding, Network receiving
and Decode Frame Rate(Decoding), Packets(Network receiving), Net Lost
Packets(Network receiving) for Counter receiving settings to display statistics about the
number of packets received by the recipient video module on the network and decoding frame
rate. The decoding frame rate in the fault period decreases to 0 fps, indicating that the
decoded image is frozen or no decoded image can be viewed. In this case, no image can be
viewed or images are frozen in the other participants' video viewed by the local participant.
You need to further determine the cause. For details, see P2, Packets Received by the
Endpoint Are Lost to P9, The SBC Loses I Frames or I Frame Requests.

CloudEC
Figure 1-30 Counters indicating the number of video packets received by the endpoint on the network & the
decoding frame rate
?.2. P2, Packets Received by the Endpoint Are Lost

of the local participant are used for determination. If the endpoint receives no video packet
due to network, SBC, or MCU exceptions, the user receiving frame rate and decoding frame
rate are 0. In the fault period, the number of packets received by the endpoint does not
increase, indicating that no video packet is received.
[Example]
As shown in Figure 1-31, select Network sending, Coding and Packets(Network sending),
Set Frame Rate(Coding), Encode Frames(Coding) for Counter sending settings to display
statistics about the number of frames of video encoded by and number of packets sent by the
MCU. The number of frames of video encoded by and number of packets sent by the MCU
increase continuously, indicating that encoding and sending of the MCU are normal. As
shown in Figure 1-32, select Decoding, Network receiving and Decode Frame
Rate(Decoding), Packets(Network receiving), Net Lost Packets(Network receiving) for
Counter receiving settings to display statistics about the number of network packets received
by the recipient's video module and the decoding frame rate. In the fault period, the decoding
frame rate decreases to 0 fps, indicating that the decoded image is frozen or no decoded image
can be viewed. If the number of packets received on the network in the fault period does not
increase, the pickup party receives no video packet. In this case, no image can be viewed or
images are frozen in the other participants' video viewed by the local participant. Then, you
can determine that there is no image or image freezing occurs because the endpoint receives
no video packet.

CloudEC
Figure 1-31 Counters indicating the number of frames of video encoded by & number of packets sent by the
MCU
Figure 1-32 Counters indicating the number of packets received by the endpoint on the network & the decoding
frame rate
Possible causes for the recipient endpoint failure to receive video packets are as follows: All
packets from the MCU to the SBC are lost; the SBC forwards no video packet; or all packets
from the SBC to the endpoint are lost. You need to further determine the cause. For details,
see P3, Packets from the MCU to the SBC Are Lost, P13, All Packets Forwarded by the
SBC Are Lost, and P2, Packets Received by the Endpoint Are Lost.
?.3. P6, Packets Received by the Endpoint Are Abnormal

of the local participant are used for determination. When the packets received by the endpoint
are abnormal, the decoding frame rate of the recipient is 0. In the fault period, the number of
packets received by the endpoint increases properly but the number of decoding errors
increases continuously.

CloudEC
[Example]
As shown in Figure 1-33, select Decoding, Network receiving and Decode Frame
Rate(Decoding), Receive Frame Rate(Decoding), Net Lost Packets(Network receiving)
for Counter receiving settings to display statistics about the receiving frame rate and
decoding frame rate of the recipient's video module. In the fault period, the decoding frame
rate decreases to 0 fps, indicating that the decoded image is frozen or no decoded image can
be viewed. In the fault period, the receiving frame rate is normal and the network packet loss
rate is 0, indicating that no packet is lost. In this case, no image can be viewed or images are
frozen in the other participants' video viewed by the local participant. Then, you can
determine that there is no image or image freezing occurs because the packets received by the
endpoint are abnormal. In this case, the number of received network packets increases
properly and the number of decoding errors increases continuously.
Figure 1-33 Counters indicating the video decoding frame rate & receiving frame rate of the
endpoint
?.4. P7, The MCU Does Not Respond to the I Frame Requests
of the local participant are used for determination. When the MCU does not respond to I
frame requests, the decoding frame rate of the recipient is 0. In the fault period, the number of
packets received by the endpoint increases properly. The endpoint continuously sends I frame
requests due to packet loss, but the number of I frames of video encoded and sent by the
MCU does not increase, indicating that the MCU does not respond to the requests.
[Example]
As shown in Figure 1-34, select Decoding and Req I Frames(Decoding) for Counter
receiving settings to display statistics about the number of I frame requests from the video
decoding module of the recipient. In the fault period, the number of I frame requests increases
continuously. As shown in Figure 1-35, the number of I frames of video encoded by the
MCU (I Frames(Coding)) does not increase continuously. In this case, no image can be
viewed or images are frozen in the other participants' video viewed by the local participant.
Then, you can determine that there is no image or image freezing occurs because the MCU
does not respond to I frame requests. In this case, the number of I frame requests received by
the MCU (I Frame Reqs(Coding)) increases continuously.

CloudEC
Figure 1-34 Counter indicating the number of I frame requests from the video decoding module of the endpoint
Figure 1-35 Counters indicating the number of I frames of video encoded by the MCU & the number of received
I frame requests
?.5. P8, The MCU Software or Hardware Is Faulty

local participant. The number of received packets, receiving frame rate, and decoding frame
rate in the receiving direction of the local participant are used for determination. When the
MCU software or hardware is faulty, multiple pickup parties in a conference receive no video
packet and the receiving frame rate and decoding frame rate are 0.
[Example]
As shown in Figure 1-36, select Decoding, Network receiving and Decode Frame
Rate(Decoding), Packets(Network receiving), Net Lost Packets(Network receiving) for
Counter receiving settings to display statistics about the number of received packets and
packet loss rate (number of lost packets) of the video modules of multiple pickup parties. In
the fault period, the number of received packets of each pickup party does not increase since a
time point, indicating that the MCU sends no video packet to each pickup party. In this case,

CloudEC
no image can be viewed or images are frozen in the other participants' video viewed by the
local participant. Then, you can determine that there is no image or image freezing occurs
because the MCU software or hardware is faulty. In this case, you can further check whether
the MCU sends video packets properly.
Figure 1-36 Counters indicating the number of video packets received by & number of lost video packets of the
endpoint
?.6. P9, The SBC Loses I Frames or I Frame Requests

of the local participant are used for determination. When the SBC loses I frames or I frame
requests, the number of I frames of video decoded by the recipient does not change. In the
fault period, the number of packets received by the endpoint increases properly. The recipient
continuously sends I frame requests but the number of I frames in the received video code
streams does not increase, causing the decoding failure.
[Example]
As shown in Figure 1-37, select Decoding and I Frames(Decoding), Req I
Frames(Decoding) for Counter receiving settings to display statistics about the number of I
frames of video decoded by the endpoint and number of I frame requests. If the endpoint
continuously sends requests for I frames but the number of decoded I frames does not change,
the intermediate NE loses I frame requests.

CloudEC
Figure 1-37 Counters indicating the number of I frames of video decoded by the endpoint & the number of sent I
frame requests
?.7. P10, No Image Can Be Viewed or Images Are Frozen in the Local Participant's Video
Viewed by Other Participants
No image can be viewed or images are frozen in the local participant's video viewed by other
participants. The receiving frame rate and decoding frame rate of the local participant in the
MCU are used for determination. If the MCU receives no valid video packet because the
network or the endpoint's camera is abnormal, the decoding frame rate of the local participant
in the MCU is 0. If the decoding frame rate is 0 and the receiving frame rate is valid (1 to 30),
you can determine that the decoding exception causes no image or image freezing. You need
to further determine the cause for no image or image freezing. For details, see P11, Packets
Received by the MCU Are Lost to P18, The MCU Does not Enable Check for No Code
Stream.
?.8. P11, Packets Received by the MCU Are Lost

MCU are used for determination. If the MCU receives no video packet, the user receiving
frame rate and decoding frame rate are 0. In the fault period, the number of packets received
by the MCU does not increase, indicating that no video packet is received.
[Example]
As shown in Figure 1-38, select Coding, Network sending and Send Frames(Coding) for
Counter sending settings to display statistics about the number of video frames and packets
sent by the endpoint. Then, you can detect that encoding and sending of the endpoint are
normal. As shown in Figure 1-39, select Network receiving, Decoding and
Packets(Network receiving), Net Lost Packets(Network receiving), Decode Frame
Rate(Decoding) for Counter receiving settings to display statistics about the number of
received network packets and decoding frame rate of the video module of the local participant
in the MCU. In the fault period, the decoding frame rate decreases to 0 fps, indicating that the
decoded image is frozen or no decoded image can be viewed. If the number of received

CloudEC
network packets does not increase in the fault period, the MCU receives no video packet. In
this case, no image can be viewed or images are frozen in the local participant's video viewed
by other participants. Then, you can determine that there is no image or image freezing occurs
because the MCU receives no video packet.
Figure 1-38 Counter indicating the number of video frames sent by the endpoint
Figure 1-39 Counters indicating the number of video packets received by the MCU & the decoding frame rate
Possible causes for the MCU failure to receive video packets are as follows: All packets from
the endpoint to the SBC are lost; the SBC forwards no video packet; or all packets from the
SBC to the MCU are lost. You need to further determine the cause. For details, see P8,
Packets from the Endpoint to the SBC Are Lost, P13, All Packets Forwarded by the
SBC Are Lost, and P7, Packets Received by the MCU Are Lost.
?.9. P13, All Packets Forwarded by the SBC Are Lost

MCU are used for determination. If the MCU receives no video packet, the user receiving

CloudEC
frame rate and decoding frame rate are 0. In the fault period, the number of packets received
by the MCU does not increase, indicating that no video packet is received. In this case, the
video source end sends packets properly.
[Example]
As shown in Figure 1-40, select Coding, Network sending and Send Frames(Coding) for
Counter sending settings to display statistics about the number of frames sent by the
encoding module of the endpoint. Then, you can detect that the number of sent frames
increases continuously, indicating that the frames are sent properly. As shown in Figure 1-41,
select Network receiving, Decoding and Packets(Network receiving), Net Lost
Packets(Network receiving), Decode Frame Rate(Decoding) for Counter receiving
settings to display statistics about the number of received network packets and decoding
frame rate of the recipient of the local participant in the MCU. In the fault period, the
decoding frame rate decreases to 0 fps, indicating that the decoded image is frozen or no
decoded image can be viewed. If the number of received network packets does not increase in
the fault period, the MCU receives no video packet. In this case, no image can be viewed or
images are frozen in the local participant's video viewed by other participants. Then, you can
determine that there is no image or image freezing occurs because all packets forwarded by
the SBC are lost.
Figure 1-40 Counter indicating the number of video frames sent by the endpoint

CloudEC
?.10. P15, Packets Received by the MCU Are Abnormal

MCU are used for determination. If packets received by the MCU are abnormal, the decoding
frame rate of the MCU corresponding to the participant is 0. In the fault period, the number of
packets received by the endpoint increases properly but the number of decoding errors
increases continuously.
[Example]
As shown in Figure 1-42, select Network receiving, Decoding and Packets(Network
receiving), Net Lost Packets(Network receiving), Decode Frame Rate(Decoding) for
Counter receiving settings to display statistics about the receiving frame rate and decoding
frame rate of the recipient's video module of the MCU. In the fault period, the decoding frame
rate decreases to 0 fps, indicating that the decoded image is frozen or no decoded image can
be viewed. In the fault period, the receiving frame rate is normal and the network packet loss
rate is 0, indicating that no packet is lost. In this case, no image can be viewed or images are
frozen in the local participant's video viewed by other participants. Then, you can determine
that there is no image or image freezing occurs because packets received by the MCU are
abnormal. In this case, the number of received network packets increases properly and the
number of decoding errors increases continuously.

CloudEC
?.11. P16, The Camera of the Endpoint Is Faulty

participants. The collection frame rate and encoding frame rate of the local participant's
endpoint and the number of encoded bytes are used for determination. When the camera of
the endpoint is faulty, the number of encoded bytes decreases obviously and the collection
frame rate and encoding frame rate are normal.
[Example]
As shown in Figure 1-43, select Collection, Coding and Set Frame Rate(Collection),
Output Frames(Collection), Bytes(Coding) for Counter sending settings to display
statistics about the number of frames collected by the sender's video module (Output
Frames(Collection)) and number of encoded bytes (Bytes(Coding)). In the fault period,
increase of the number of encoded bytes slows down greatly and the collection frame rate and
the number of collected frames changes slightly, the image complexity decreases (that is,
black screen or no image occurs). In this case, if no image can be viewed or images are frozen
in the local participant's video viewed by other participants, you can determine that the
camera of the endpoint is faulty.

CloudEC
Figure 1-43 Counters indicating the number of video frames collected by the endpoint & number of encoded
bytes
?.12. P17, The SBC Loses I Frames or I Frame Requests

participants. The receiving frame rate and decoding frame rate in the receiving direction of the
local participant are used for determination. When the SBC loses I frames or I frame requests,
the number of I frames of video decoded in the receiving direction of the MCU does not
change. In the fault period, the number of packets received by the MCU increases properly.
The MCU continuously sends I frame requests but the number of I frames in the received
video code streams does not increase, causing the decoding failure.
[Example]
As shown in Figure 1-44, select Decoding and I Frames(Decoding), Req I
Frames(Decoding) for Counter receiving settings to display statistics about the number of I
frames of video decoded by the MCU and number of I frame requests. If the MCU
continuously sends requests for I frames but the number of decoded I frames does not change,
the intermediate NE loses I frame requests.

CloudEC
Figure 1-44 Counters indicating the number of I frames of video decoded by the MCU & the number of sent I
frame requests
?.13. P18, The MCU Does not Enable Check for No Code Stream
MCU are used for determination. If the MCU does not enable check for no code stream and
the MCU does not hang up the participant after the endpoint leaves the conference, the image
of the local participant's video viewed by other participants is frozen.
[Example]
As shown in Figure 1-45, select Network receiving, Decoding and Packets(Network
receiving), Net Lost Packets(Network receiving), Decode Frame Rate(Decoding), Receive
Frame Rate(Decoding) for Counter receiving settings to display statistics about the number
of received network packets and decoding frame rate of the video module of the local
participant in the MCU. In the fault period, the receiving and decoding frame rates decrease to
0 fps, indicating that the decoded image is frozen or no decoded image can be viewed. If the
number of received network packets does not increase in the fault period, the MCU receives
no video packet. In this case, if no image can be viewed or images are frozen in the local
participant's video viewed by other participants, you can determine that the MCU does not
enable check for no code stream and that there is no image or image freezing occurs because
the MCU does not hang up the participant after the endpoint leaves the conference.

CloudEC
1.1.2.3 Low Video Definition/Smoothness

Symptoms: In a multi-party conference or P2P call, the definition or smoothness of other
participants' video viewed by the local participant is low.
Exceptions of the endpoints, transmission network, or media processing devices may cause
low video definition or smoothness. Common root causes are as follows:
[Endpoint problems]: The sending frame rate of the endpoint is low. The sending resolution of
the endpoint is low. Bandwidth reduction of the recipient endpoint causes poor video quality.
[Transmission network faults]: I frames are frequently encoded due to bandwidth restrictions
or packet loss on the transmission network, causing poor video quality.
[Media processing device faults]: Frequent I frame encoding or forcible adaptation of the
MCU causes poor video quality of the recipient.

The processing idea of low video definition or smoothness is as follows: Analyze the fault
cause stage by stage from the pickup party's endpoint in the reverse direction of media
processing based on the counter data collected in the SessionInsight until the fault cause is
detected.

CloudEC
1.1.2.3.3 Diagnosis
Figure 1-46 Low Video Definition/Smoothness
?.1. P1, Definition or Smoothness of Other Participants' Video Viewed by the Local
Participant Is Low
The definition or smoothness of other participants' video is low. The receiving frame rate,
decoding frame rate, and decoding resolution in the receiving direction of the local participant
are used for determination. If the video receiving resolution or frame rate of the recipient is
low due to network, SBC, or MCU exceptions or the resolution or frame rate does not
decrease obviously but the user feeds back that the video definition is low, you can determine
that the definition or smoothness of other participants' video is low. The counter data indicates
that the video decoding frame rate, video resolution, or video bit rate of the recipient is low.
For details about how to determine the fault cause, see P2, Improper Conference Template
Settings Cause Poor Video Quality to P5, Bandwidth Reduction of the Recipient
Endpoint Causes Poor Quality.

CloudEC
?.2. P2, Improper Conference Template Settings Cause Poor Video Quality
The definition or smoothness of other participants' video is low. The sending frame rate,
encoding frame rate, and encoding resolution in the sending direction of the local participant
are used for determination. When the conference template is improperly configured, the
resolution or bit rate of the video encoded and sent by the endpoint may be too low.
[Example]
As shown in Figure 1-47, select Collection, Coding and Output Width(Collection), Output
Height(Collection), Output Width(Coding), Output Height(Coding) for Counter sending
settings to display statistics about the encoding resolution of the endpoint's video sending
module. In the fault period, the resolution is less than VGA (640x480), indicating that the
definition of the decoded image is low. In this case, if the network condition is good and no
packet is lost, you need to check whether the poor video quality is caused by the low
resolution or bit rate setting in the conference template.
Figure 1-47 Counters indicating the endpoint's video encoding resolution
?.3. P3, The MCU Frequently Sends I Frames, Causing Poor Video Quality
decoding frame rate, and number of decoded I frames in the receiving direction of the local
participant are used for determination. When the MCU frequently sends I frames, the quality
of the video received by the endpoint may be poor.
[Example]
As shown in Figure 1-48, select Network sending, Coding and I Frame Reqs(Coding) for
Counter sending settings to display statistics about the number of I frame requests to the
video encoding module of the MCU. Then, you can detect that the number of I frame requests
increases continuously and the number of I frames of video encoded by the MCU increases
continuously (not displayed in the figure) in the fault period. In addition, as shown in Figure
1-49, select Decoding, Network receiving and Decode Frame Rate(Decoding), Net Lost
Packets(Network receiving), Receive Frame Rate(Decoding), Receive I
Frames(Decoding) for Counter receiving settings to display statistics about the receiving

CloudEC
frame rate and decoding frame rate of the endpoint. Then, you can detect that the decoding
frame rate decreases and the number of lost packets and number of decoded I frames increase
continuously, indicating that the MCU frequently sends I frames because of network packet
loss.
Figure 1-48 Counter indicating the number of I frame requests to the video encoding module of the MCU
Figure 1-49 Counters indicating the video decoding frame rate & receiving frame rate of the endpoint
?.4. P4, Forcible Adaptation of the MCU Causes Poor Quality

are used for determination. When the MCU performs forcible adaptation, the endpoint
receiving resolution may be low, causing poor video quality.
[Example]
As shown in Figure 1-50, select Network sending, Coding and Output Width(Coding),
Output Height(Coding), Set Bandwidth(Coding), Bytes(Network sending) for Counter

CloudEC
sending settings to display statistics about the video encoding module's resolution of the
MCU. Then, you can detect that the encoding resolution decreases from 1920x1080 to
1280x720 due to forcible adaptation of the MCU in the fault period. As shown in Figure
1-51, select Decoding, Network receiving and Width(Decoding), Height(Decoding),
Bytes(Network receiving) for Counter receiving settings to display statistics about the
decoding resolution and bit rate of the endpoint. Then, you can detect that the decoding
resolution decreases from 1920x1080 to 1280x720 and the corresponding bit rate
(Bytes(Network receiving)) increases slowly, indicating that the video quality in the period
deteriorates.
Figure 1-50 Counters indicating the MCU video encoding resolution
Figure 1-51 Counters indicating the endpoint's video decoding resolution
?.5. P5, Bandwidth Reduction of the Recipient Endpoint Causes Poor Quality
The definition or smoothness of other participants' video is low. The encoding bandwidth and
encoding resolution in the sending direction of the local participant's MCU are used for
determination. When the recipient endpoint sends bandwidth reduction feedback to the MCU

CloudEC
due to network restrictions, the resolution or bit rate of video encoded and sent by the MCU
may be too low.
[Example]
As shown in Figure 1-52, select Network sending, Coding and Output Width(Coding),
Output Height(Coding), Set Bandwidth(Coding), Bytes(Network sending) for Counter
sending settings to display statistics about the video module's encoding resolution and
bandwidth of the MCU. Then, you can detect that the resolution in the fault period decreases
from 1080p to 720p, indicating that the encoded video definition is low. However, the
network condition is good and no packet is lost. In this case, when the MCU sending
bandwidth reduces, you need to check the bandwidth feedback received by the MCU and
determine whether bandwidth reduction of the recipient endpoint causes poor video quality.
Figure 1-52 Counters indicating the MCU video encoding resolution
?.6. P6, Definition or Smoothness of the Local Participant's Video Is Low

The definition or smoothness of the local participant's video is low. The receiving frame rate,
in the MCU are used for determination. If the resolution or frame rate of video received by the
recipient is low due to endpoint or network exceptions or the resolution or frame rate does not
decrease obviously but users feed back that the video definition is low, you can determine that
the definition or smoothness of the local participant's video is low. The counter data indicates
that the video decoding frame rate, video resolution, or video bit rate of the corresponding
participant in the MCU is low.
For details about how to determine the fault cause, see P7, The Sending Frame Rate of the
Endpoint Is Low to P9, The Endpoint Frequently Sends I Frames.
?.7. P7, The Sending Frame Rate of the Endpoint Is Low

The definition or smoothness of the local participant's video is low. The encoding and sending
frame rates and resolutions of the local participant are used for determination. When the
endpoint's sending frame rate is low, the counter data indicates that both the encoding frame
rate of the endpoint and the decoding frame rate of the MCU are too low.

CloudEC
[Example]
As shown in Figure 1-53, select Collection, Coding and Send Frames(Coding) for Counter
sending settings to display statistics about the number of video frames sent by the endpoint.
Then, you can detect that the number of frames is 363 when the session lasts for 2 minutes in
the fault period. The frame rate is calculated as follows: 363/(2 x 60) = 3 fps. That is, the
sending frame rate is 3 fps. As shown in Figure 1-54, the receiving and decoding frame rates
of the MCU are also low, indicating that the sending frame rate of the source end is low.
Therefore, the smoothness of the local participant's video is low.
Figure 1-53 Counter indicating the number of frames of video encoded and sent by the endpoint
Figure 1-54 Counters indicating the video decoding frame rate & receiving frame rate of the MCU
?.8. P8, The Sending Resolution of the Endpoint Is Low

frame rates and resolutions of the local participant are used for determination. When the
endpoint's sending resolution is low, the counter data indicates that both the encoding
resolution of the endpoint and decoding resolution of the MCU are too low.

CloudEC
[Example]
As shown in Figure 1-55, select Collection, Coding and Output Width(Collection), Output
Height(Collection), Output Width(Coding), Output Height(Coding) for Counter sending
settings to display statistics about the video collection and encoding resolutions of the
endpoint. Then, you can detect that the endpoint's collection and encoding resolutions are
416x224 in the fault period, indicating that the sending resolution of the source end is low and
the decoding resolution of the MCU decreases. Therefore, the definition of the local
participant's video is low.
Figure 1-55 Counters indicating the endpoint's video encoding resolution
?.9. P9, The Endpoint Frequently Sends I Frames

frame rates and resolutions and the number of sent I frames of the local participant are used
for determination. When the endpoint frequently sends I frames, the definition or smoothness
of the local participant's video may be low.
[Example]
As shown in Figure 1-56, select Coding and I Frames(Coding) for Counter sending
settings to display statistics about the number of I frames of video encoded by the endpoint.
Then, you can detect that the number of I frames increases continuously in the fault period. In
addition, as shown in Figure 1-57, the number of I frames received and decoded by the MCU
increases continuously and the decoding frame rate (Decode Frame Rate(Decoding))
decreases, indicating that video smoothness is low because the endpoint frequently sends I
frames.

CloudEC
Figure 1-56 Counter indicating the number of I frames of video encoded by the endpoint
Figure 1-57 Counters indicating the MCU video receiving frame rate & the decoding frame rate
1.1.3 Analysis of Typical Presentation Fault Scenarios

Typical presentation fault scenarios include the following: no presentation, presentation
artifact/frame freezing, low presentation definition/smoothness, and long presentation latency.
For details, see the analysis of typical video fault scenarios.
1.1.4 Appendix A: Media Counter Details

Media Counter Details
1.2 VM Management Failures

CloudEC
1.2.1 VM Faults
Symptom
l In the Browse Alarms window of the LMT or on the Active Alarms page on the OMU
Web portal, ALM-9507 Virtual Machine Fault is present. You can choose Maintenance
> Active Alarms on the OMU Web portal to proceed to the Active Alarms page.
l In the MML Command - CGP or MML Command - ME window, DSP VM is run.
The Availability state for a VM in the command output is Fault, Shut off, or
Unknown, as illustrated in Figure 1-58.
Figure 1-58 DSP VM command output
Possible Causes
l The host running the VM is faulty.
l The virtualization software on the host running the VM is faulty.
l The resources, such as CPUs, on the host running the VM are insufficient.
l The VM on the host is different from configured.
l STP VM was run for the VM.
l The VM accidentally exited or stopped during its running.
l RST SERVER or POF SERVER was run for the host running the VM.
l The system was importing the image file to a VM for running applications independent
of CGP management.
Fault Diagnosis
1. Check whether ALM-9507 Virtual Machine Fault persists.
2. Check whether en-us_alarmref_0102720574.xml persists.

CloudEC
3. Check whether en-us_alarmref_0102720577.xml persists.
Procedure
Check whether ALM-9507 is present.
1 Check whether ALM-9507 Virtual Machine Fault is present in the Browse Alarms
window of the LMT or on the Active Alarms page on the OMU Web portal.
– Yes: Go to 2.
– No: Go to 3.
2 Rectify the fault by following the procedure for handling ALM-9507 Virtual Machine
Fault. Check whether this issue is resolved.
– Yes: No further action is required.
– No: Go to 3.
3 Check whether en-us_alarmref_0102720574.xml is present in the Browse Alarms
window (for the CGP) on the LMT or on the Active Alarms page of the OMU Web
portal.
– Yes: Go to 4.
– No: Go to 5.
4 Rectify the fault by following the procedure for handling en-
us_alarmref_0102720574.xml. Check whether this issue is resolved.
– No: Go to 5.
5 Check whether en-us_alarmref_0102720577.xml is present in the Browse Alarms
window of the LMT or on the Active Alarms page on the OMU Web portal.
– Yes: Go to 6.
– No: Go to 7.
us_alarmref_0102720577.xml. Check whether this issue is resolved.
– No: Go to 7.
Contact Huawei technical support engineers.
7 Use the Information Collection Tool to collect information about Common fault
analysis scenario.
8 Contact Huawei technical support engineers.
----End
Related Information
l en-us_alarmref_0102720568.xml

CloudEC
1.3 Server Management Failures
1.3.1 Replacing a Server
Symptom
Replace a server if it encounters an irreversible hardware fault or resource shortage.
Possible Causes
l The memory, CPU, NIC, hard disk, or power supply module of a server is faulty.
l The memory, CPU, NIC, or hard disk resources of a server are insufficient.
Procedure
Power off the server to be replaced.
1 Log in to the iBMC Web portal, and choose Power > Power Control > Normal Power
Off to power off the server. Then, remove all the network and power cables connected to
the server.
Configure the new server.

2 Power on the new server and change the iBMC IP address of the new server to that of the
server to be replaced. For more information on how to change the iBMC IP address, see
Changing the iBMC IP Address.
3 Configure RAID10 for the new server. For more information on how to configure
RAID10, see Configuring RAIDs.
4 The server automatically restarts and installs after the RAID configuration is completed.
Log in to the OMU Web portal to check the server status.
5 Wait approximately 1 hour and log in to the OMU Web portal to check the server and
VM status.
Verify that all VMs are in normal state and the OMU node in the application topology is
in green.

CloudEC
6 Choose Resource Management > Application Management on the OMU Web portal
to check that the status of all applications running on the new server is normal.
----End
Related Information
None
1.3.2 After the Host Is Replaced, the CloudMCU Must Be

Reconfigured
Symptom
After the host is replaced, CloudMCU configuration cannot be automatically restored, and the
CloudMCU cannot be used.

CloudEC
Possible Causes
After the host is replaced, CloudMCU configuration cannot be automatically restored.
Procedure
After the host is replaced, configure the CloudMCU again.
1.3.3 New TMS Host Does Not Work After a Host Replacement
Symptom
The FMT SERVER command is executed during the host replacement. However, after the
command is executed, the TMS host does not work.
Possible Causes
The VM where the TMS host is located is faulty.
Procedure
Step 1 Visit the Huawei technical support website.
Step 2 Enter TMS9950 in the search box, select the appropriate path from the drop-down list box,
and download required documents from the Documentation tab page.
Step 3 Restore the VM by following the instructions in TMS9950 V500R005C00SPC*** VM OS
Restoration Guide.
----End
1.4 Maintenance Faults of OMU
1.4.1 WebUI Troubleshooting
1.4.1.1 Incorrect Display on the OMU Web Portal
Symptom
The OMU Web portal is incorrectly displayed as follows:
l The page layout is in disorder.
l Some controls are missing.
l The page content is incorrect. For example, the web page still displays the original
content even if the web functions have been changed.
l A message indicating that the user has logged in to the system is displayed when the user
is forcibly logged out of the system and then attempts to re-log in to it.
Possible Causes
The data in the browser cache is not deleted.

CloudEC
Fault Diagnosis
The css, Javascript, and html data is kept in the browser cache, which must be cleared.
Procedure
1 Clear the browser cache and check whether the OMU Web portal is displayed correctly.
For Internet Explorer: Choose Tools > Clear History on the toolbar. On the displayed
dialog box, select all the items and click Yes.
– No: Go to 2.
2 Contact Huawei technical support engineers to rectify the fault.
----End
Related Information
None.
1.4.2 Module Management Failures
1.4.2.1 Module Failure
Symptom
l ALM-1003 Module Fault is displayed in the Browse Alarms window of the CGP.
l In the Module Management window, the Module State of the module on the CGP or
another managed element (ME) is Fault.
l In the MML Command - CGP window, run DSP MODULE to query the status of the
module. The command output indicates that the Availability state is Faulty or NULL.
Possible Causes
For details, see Possible Causes for ALM-1003 Module Fault.
Fault Diagnosis
l Operations, such as resetting and switchover, are performed on the module. After the
operations are complete, check whether the module recovers from the failure. If the
module recovers from the failure, no further action is required. If the module still fails,
rectify the faults by following the handling procedure.
l The module exceptionally stops, or the virtual machine (VM) running the module is
faulty.
Procedure
Check whether operations have been performed on the faulty module.
1 Check whether ALM-1003 Module Fault is displayed in the Browse Alarms window.

CloudEC
– Yes: Go to 2.
– No: Go to 8.
2 In the MML Command - CGP window, run LST OPTLOG to query the operation logs
for the ME with the ID 0.
3 Check the operation logs to determine whether STP MODULE or STP ME has been
executed.
– Yes: Go to 4.
– No: Go to 5.
4 In the MML Command - CGP window, run STR MODULE or STR ME to start the
module or the ME or VM where the module resides. Wait 5 minutes and check whether
ALM-1003 Module Fault is cleared.
– No: Go to 5.
5 Check the operation logs to determine whether operations, such as resetting or
switchover, have been performed on the faulty module or the VM.
– Yes: 6.
– No: Go to 7.
6 Wait until the operations are complete. Then, check whether ALM-1003 Module Fault is
cleared.
– No: Go to 7.
7 Rectify the fault by following the procedure for handling ALM-1003 Module Fault.
Then, check whether the module recovers from failure.
– No: Go to 8.
Check whether the module or the VM running the module is faulty.
8 Check whether en-us_alarmref_0080808796.xml is displayed in the Browse Alarms
window.
– Yes: Go to 9.
– No: Go to 10.
us_alarmref_0080808796.xml. Then, check whether the module recovers from failure.
– No: Go to 11.
10 Run RST MODULE to reset the active arbitration PMU module of the faulty module.
Wait 1 minute and run DSP MODULE in the MML Command - CGP window to
check whether the Availability state of the original faulty module is Normal.
– No: Go to 11.
Collect fault information.
11 Use the Information Collection Tool to collect information about Common fault
analysis scenario.

CloudEC

----End
Related Information
l ALM-1003 Module Fault
1.4.2.2 Abnormal Module Backup
Symptom
l ALM-9752 Module Backup Switch Off is displayed on the OMU client.
l In the Module Management window of the client, Backup Progress(%) of active and
standby modules of a service ME is not 100, and does not change within two minutes.
Possible Causes
l The backup function of the module is disabled.
l The standby module is faulty.
Fault Diagnosis
l Check whether the backup function of the module is disabled.
l Check whether the standby module is faulty.
Procedure
The backup function of the module is disabled.
1 In the MML Command - CGP window of the client, run DSP BAKMODE to check
whether Backup switch of the module is set to ON(On).
– Yes: Go to 3.
– No: Go to 2.
2 In the MML Command - CGP window of the client, run SET BAKMODE to set
Backup switch to ON(On) for the module. Check whether ALM-9752 Module Backup
Switch Off has been cleared.
– No: Go to 3.
The standby module is faulty.
3 Check whether ALM-1003 Module Fault is displayed on the OMU client.
– Yes: Go to 4.
– No: Go to 6.
4 Rectify the fault by following the procedure for handling the alarm ALM-1003 Module
Fault. Then, check whether ALM-1003 Module Fault has been cleared.
– Yes: Go to 5.
– No: Go to 6.
5 Check whether the alarm ALM-9752 Module Backup Switch Off has been cleared in
the Browse Alarms window.

CloudEC

– No: Go to 6.
Contact Huawei technical support.
6 Use the Information Collection Tool to collect items in Common fault analysis
scenario.
----End
Related Information
ALM-1003 Module Fault
1.4.2.3 Incorrect Virtual Machine Time
Symptom
l en-us_alarmref_0102720511.xml is displayed on the OMU client.
l The time displayed in the call detail record (CDR) is incorrect. For example, the end
time of a call is earlier than the start time.
l In the traffic measurement result, the value in the Credible column is Incredible
because of time transition.
l The time on the board running services is inconsistent with the time on the OMU. For
example, when you run DSP INTIME in the MML Command - CGP window to query
the System time of each board. The System time of each board or the time on a board is
more than 2 seconds earlier or later than the OMU time displayed in the command
output.
Possible Causes
For details, see Possible Causes for en-us_alarmref_0102720511.xml.
Fault Diagnosis
l The utility module used for time synchronization on the OMU is faulty.
l The communication between the OMU and other boards is interrupted.
Procedure
Step 1 Check whether en-us_alarmref_0102720511.xml is displayed in the Browse Alarms window
of the CGP.
l Yes: Go to Step 2.
l No: Go to Step 3.
Step 2 Rectify the fault by following the procedure for handling en-us_alarmref_0102720511.xml.
Then, check whether the fault is rectified.
l Yes: No further action is required.
l No: Go to Step 3.
Step 3 Use the Information Collection Tool to collect information about Common fault analysis
scenario.

CloudEC
Step 4 Contact Huawei technical support engineers.
----End
Related Information
en-us_alarmref_0102720511.xml
1.4.3 OMU Process Failures
1.4.3.1 OMU Process Abnormal
Symptom
l ALM-8600 Abnormal OMU Resources with Resource type as Process is displayed on
the OMU client.
l After DSP OMU is run, the output contains records whose Resource Type is Process
and Resource state is Faulty or Abnormal.
Possible Causes
l The program exits because of an internal error.
l The database is not working properly.
l The program files have corrupted.
Procedure
1 Use the Information Collection Tool to collect items in the following scenarios:
– Common fault analysis scenario
– Extended information for fault analysis scenario
----End
Related Information
None.
1.4.3.2 Communication Failure Between the OMU and the Host
Symptom
l On the Device Panel of the client, the process indicator of a configured board is gray.
l Running an MML command on the client times out. For example, running DSP
MODULE in the MML Command - CGP window of the client fails.
Possible Causes
l The network connection is interrupted.

CloudEC
l The network configuration is incorrect.
Fault Diagnosis
l Check whether the OMU services are operating properly.
l Check whether the communication over a single plane between the OMU and other hosts
fails.
l Check whether the communication between the OMU board and other hosts fails.
Procedure
Check whether the OMU services are operating properly.
1 In the MML Command - CGP window of the client, run DSP OMU to check whether
OMU base info is HA mode.
– Yes: Go to 2.
– No: Go to 3.
2 Check whether OMU status for one OMU is Active, and for the other is Standby.
– Yes: Go to 4.
– No: Go to 10.
3 Check whether OMU status is Active.
– Yes: Go to 4.
– No: Go to 10.
4 Check whether Resource state of the DCM process of the active OMU is Activated.
– Yes: Go to 6.
– No: Go to 5.
5 Use PuTTY to log in to the active OMU as user omu, and then run
stop_dcm;start_dcm to restart the DCM process. After the DCM process is restarted,
check whether its status is running.
– Yes: Go to 6.
– No: Go to 10.
Check whether the communication over a single plane between the OMU and other hosts fails.
6 Check whether ALM-9519 Single Plane Between OMU and Host Faulty is present in the
Browse Alarms window of the LMT or on the Active Alarms page on the OMU Web
portal. You can choose Maintenance > Active Alarms on the OMU Web portal to
proceed to the Active Alarms page.
– Yes: Go to 7.
– No: Go to 8.
7 Rectify the fault by following the procedure for handling ALM-9519 Single Plane
Between OMU and Host Faulty. Check whether this issue is resolved.
– Yes: Go to 8.
– No: Go to 10.
Check whether the communication between the OMU board and other hosts fails.
8 Check whether ALM-9520 Communication Failure Between the OMU and Host is
present in the Browse Alarms window of the LMT or on the Active Alarms page on the

CloudEC
OMU Web portal. You can choose Maintenance > Active Alarms on the OMU Web
portal to proceed to the Active Alarms page.
– Yes: Go to 9.
– No: Go to 10.
9 Rectify the fault by following the procedure for handling ALM-9520 Communication
Failure Between the OMU and Host. Check whether this issue is resolved.
– No: Go to 10.
Collect the relevant information.
scenario.
----End
Related Information
l ALM-9519 Single Plane Between OMU and Host Faulty
l ALM-9520 Communication Failure Between the OMU and Host
1.4.4 OMU HA System Failures
1.4.4.1 Active/Standby OMU Switchover Failure
Symptom
OMU switchover fails in the following conditions:
l ALM-8605 Swap Failure of the OMU HA System is displayed on the OMU client.
l Running SWP OMU in the MML Command - CGP window of the client fails.
Possible Causes
The probable causes of the fault are as follows:
l Certain resources on the standby OMU are faulty.

l Activation failure records exist on the standby OMU.
l Data is being synchronized from the active OMU to the standby OMU.
l Database synchronization is not completed.
l The OMU status is incorrect.
l The workspaces of the active and standby OMUs are inconsistent.
l The versions of the active and standby OMUs are inconsistent.
Fault Diagnosis
Rectify the fault based on the fault cause.

CloudEC
Procedure
Rectify the fault based on the fault cause.
1 Check whether ALM-8605 Swap Failure of the OMU HA System is generated.
– Yes: Go to 2.
– No: Go to 3.
2 Rectify the fault by referring to the handling procedure of ALM-8605 Swap Failure of
the OMU HA System. Then, check whether the fault has been rectified.
– Yes: Go to 13.
– No: Go to 14.
3 Perform operations based on the output of SWP OMU command.
– If the system displays that data is being synchronized, go to 4.
– If the system displays that the workspaces of the active and standby OMUs are
inconsistent, go to 4.
– If the system displays that the versions of the active and standby OMUs are
inconsistent, go to 4.
– If the system displays that the command cannot be executed under the current OMU
status, go to 8.
– If the system displays that the activation failure records exist, go to 9.
– If the system displays that certain resources failed to run properly, go to 9.
– If the system displays that the hardware resource is faulty, go to 9.
– If the system displays that the software is faulty, go to 14.
– If the system displays other outputs, go to 14.
4 Run LST SYNC to check the status of data synchronization.
5 Check whether the values of Progress for the File and Database records are 100%.
– Yes: Go to 6.
– No: Go to 4.
6 Check whether the output indicates that the information about the activated workspace or
version is inconsistent on the active and standby OMUs.
– Yes: Go to 7.
– No: Go to 14.
7 Run RST SYNC to re-initialize the synchronization data. Then, check whether the
command is successfully executed.
– Yes: Go to 12.
– No: Go to 14.
8 After about 30 seconds, run DSP OMU to check whether one OMU is in the active state
and the other is in the standby state and whether no resource is in Unknown state.
– Yes: Go to 12.
– No: Go to 14.
NOTE
The OMUs are not in stable active/standby state, or certain resources are in Unknown state.
Therefore, wait until the status of the OMUs turns to stable.
9 Check whether ALM-8600 Abnormal OMU Resources is generated.

CloudEC
– Yes: Go to 10.
– No: Go to 11.
10 Rectify the fault by referring to the handling procedure of ALM-8600 Abnormal OMU
Resources. Then, check whether the alarm has been cleared.
– Yes: Go to 11.
– No: Go to 14.
11 On the client, run CLR FAILFLG to clear the flag of a failure in activating resources on
the OMU.
12 Run SWP OMU again, and check whether the command is successfully executed.
– No: Go to 14.
13 Clear the alarm manually. No further action is required.
Collect relevant information, and contact technical support engineers.
scenario.
----End
Related Information
None.
1.4.4.2 Automatic Active/Standby OMU Switchover Triggered
Symptom
The following are some of the symptoms when an automatic OMU switchover occurs:
l ALM-8601 Swap of the OMU HA System is displayed on the OMU client.

l SWP OMU is not executed in the MML Command - CGP window of the client, but
the output of DSP OMU indicates that switchover occurs between the active OMU and
the standby OMU.
Possible Causes
The probable reasons for the automatic switchover are as follows:
l The OMU detects a resource exception and fails to activate the resource.
l The active OMU becomes abnormal, causing switchover between the active OMU and
the standby OMU.
Fault Diagnosis
Check whether the resources on the standby OMU are faulty.

CloudEC
Procedure
Step 1 Check whether ALM-8601 Swap of the OMU HA System is displayed on the OMU client.
l No: Go to Step 3.
Step 2 Handle the fault according to the handling procedure described in ALM-8601 Swap of the
OMU HA System. Then, check whether the fault has been rectified.
l No: Go to Step 5.
Step 3 Check whether ALM-8600 Abnormal OMU Resources is displayed on the OMU client.
l No: Go to Step 5.
Step 4 Handle the fault according to the handling procedure described in ALM-8600 Abnormal
OMU Resources. Then, check whether the fault has been rectified.
l No: Go to Step 5.
Step 5 Use the Information Collection Tool to collect items in Common fault analysis scenario.
Step 6 Contact Huawei technical support engineers to rectify the fault.
----End
1.4.4.3 Duration of Data Synchronization Between the OMUs is Too Long
Symptom
The synchronization duration of the HA system exceeds one hour. This is considered a long
synchronization duration.
The following conditions indicate that the HA system is synchronizing data.
l After SWP OMU is run in the MML Command - CGP window, the system displays
The OMU is synchronizing data.
l After RST SYNC is run in the MML Command - CGP window, the system displays
OMU is busy now.
l After LST SYNC is run in the MML Command - CGP window, Sync mode for files
under Active/standby OMU synchronization progress is always Full sync.
Possible Causes
The synchronization duration depends on the number and size of files to be synchronized. The
duration increases with the number and size of files. Generally, it lasts for about one hour.
You can identify the specific cause based on the output of LST SYNC.
Fault Diagnosis
l Check whether data synchronization is operating properly.
l Collect the relevant information, and contact technical support engineers to rectify the
fault.

CloudEC
Procedure
Check whether data synchronization is operating properly.
1 In the MML Command - CGP window of the client, run LST SYNC to query the
synchronization status.
2 Check whether Progress of the active/standby OMU synchronization is 100%.
– Yes: Go to 3.
– No: Go to 4.
3 Check whether the synchronization progress is 100% for multiple times (more than three
times), while the HA system is still synchronizing data.
– Yes: Go to 5.
– No: No further action is required.
4 Check whether the progress of the active/standby OMU synchronization does not change
for a long time (about one hour).
– Yes: Go to 5.
– No: No further action is required.
Collect relevant information, and contact technical support engineers.
scenario.
----End
Related Information
None.
1.4.4.4 OMU Service Startup Failure
Symptom
l The standby OMU restarts repeatedly.
l Two active OMUs exist.
Possible Causes
The active OMU is powered off or fault when the database being rebuilt.
Fault Diagnosis
To determine whether the OMUs are in active state, perform the following operations:
Log in to the two OMUs as user root by using the PuTTY tool.
Run QueryMirrorState to query the status of the OMUs. View the command outputs to
check whether the value of LOCAL_STATE is Activating or Active and the value of
REMOTE_STATE is Unknown or Breakdown. If yes, it indicates that the two OMUs are in
active state.

CloudEC
Procedure
Step 1 Log in to one of the two OMUs as user cgpexpert by using the PuTTY tool.
Step 2 Run su - root to switch to user root.
Step 3 Run displayOMU to check whether the database is started. If the command output shows that
the value of the Resource Type parameter is Database and that of the Resource state
parameter is Activated, it indicates that the database is started.
l No: Go to Step 5.
Step 4 Run omustatus to check whether the OMU services are started.
l No: Go to Step 8.
Step 5 Run ls -l /opt/HUAWEI/cgp/workshop/omu/data/pg_valid.ident to check whether the
pg_valid.ident file exists.
l No: Go to Step 6.
Step 6 Restore the OMU by referring to OMU Backup and RestorationOMU Restoration.
Step 7 Run displayOMU to check whether OMU services on two VMs are running properly.
l No: Go to Step 8.
Step 8 Check whether you have performed operation from Step 3 to Step 7 on two OMUs.
l No: Go to Step 9.
Step 9 Start PuTTY to log in to the other OMU as user cgpexpert, then switch to user root, and
perform Step 3 to Step 7.
----End
Related Information
None.
1.4.5 License Failures
1.4.5.1 License Activation Failure
Symptom
The license activation fails if the following message is displayed after ACT LICENSE is run
in the MML command window of the service ME on the client:
l The parameter of file name is invalid. The format must be similar to LICXXX.DAT.

CloudEC
l The license file does not exist.

l The license file is expired. So it is invalid.
l Failed to get the license control center information.
l Operation times out.
l The license is invalid because its ESN does not match.
Possible Causes
l The license file is named incorrectly. A license file name must be prefixed with LIC and
the file name extension must be .DAT, for example, LICXXX.DAT.
l The license file is not uploaded.
l The license to be activated has expired.
l The license control center is not specified.
l The module of the license control center is not running. As a result, commands issued to
the host are not processed within the specified time, and the OMU displays a timeout
message.
l The equipment sequence number (ESN) specified in the license file is different from the
ESN of the NE.
l The system time changes, which is later than the expiration time.
Fault Diagnosis
l Check whether the name of the license file is correct.
l Check whether the license file exists.
l Check whether the license has expired.
l Check whether a license control center is configured.
l Check whether a module is faulty.
l Check whether the ESN specified in the license file is the same as the ESN of the NE.
l Check whether the system time is later than the expiration time.
Procedure
Check whether the name of the license file is correct.
1 Run ACT LICENSE to check whether the command output is The parameter of
file name is invalid. The format must be similar to
LICXXX.DAT.
– Yes: Go to 2.
– No: Go to 5.
2 Start the FTP tool of the client to check whether the license file name in the License file
directory of Remote Directory is correct.
– Yes: Go to 23.
– No: Go to 3.
3 Start the FTP tool of the client to modify the license file name in the License file
directory of Remote Directory.
4 Run ACT LICENSE to activate the license again, and then check whether the fault has
been rectified.

CloudEC

– No: Go to 5.
Check whether the license file exists.
5 Run ACT LICENSE to check whether the command output is The license file
does not exist.
– Yes: Go to 6.
– No: Go to 8.
6 Start the FTP tool of the client to check whether the license file to be activated exists in
the License file directory of Remote Directory.
– Yes: Go to 23.
– No: Go to 7.
7 Start the FTP tool of the client to upload the license file to the License file directory and
run ACT LICENSE to activate the license again, and then check whether the fault has
been rectified.
– No: Go to 8.
Check whether the license file expires.
8 Run ACT LICENSE to check whether the command output is The license file
is expired, and thus is invalid.
– Yes: Go to 9.
– No: Go to 14.
9 In the MML Command - CGP window, run DSP TIME to check whether the system
time is later than the expiration time.
– Yes: Go to 10.
– No: Go to 12.
10 Check the system time.
a. In the MML Command - CGP window, run DSP TIME to check whether the
system time is consistent with the local time.
n Yes: No further action is required.
n No: Go to 10.(2).
b. Check whether ALM-8702 The OMU Failed to Synchronize Time with the NTP
Server, ALM-8703 The OMU Failed to Communicate with the NTP Server, or
ALM-8704 Time Offset with NTP Server Beyond Synchronize Threshold is
displayed in the Browse Alarms window of the client.
n Yes: Go to 10.(3).
n No: Go to 10.(4).
c. Rectify the fault by following the alarm help. Wait about 5 minutes, and check
whether the alarm is cleared and the system time is consistent with the local time.
n No: Go to 10.(4).
d. Run LST TZ to check whether the system time zone and DST are consistent with
the local time zone and DST.
n Yes: Contact Technical Support.

CloudEC
n No: Run SET TZ to reset the time zone and DST. Wait about 5 minutes and
check whether the system time is consistent with the local time.
11 In the MML Command - CGP window, run ACT LICENSE to reactivate the license.
Check whether the fault is rectified.
– No: Go to 12.
12 Apply for a new license. For details, see 24.
13 Run ACT LICENSE to activate the license, and then check whether the fault has been
rectified.
– No: Go to 14.
Configure a license control center.
14 Run ACT LICENSE to check whether the command output is Failed to get the
license control center information.
– Yes: Go to 15.
– No: Go to 17.
15 Configure a license control center for the corresponding ME. For example, if the ME is
the MSOFTX3000, run ADD CDBFUNC in the MML command window of the
MSOFTX3000 on the client. To configure a license control center for the GU-HLR-FE/
IMS-HSS-FE/USCDB, run SET LICCTRL in the MML command window of the
service ME on the client.
16 Run ACT LICENSE to activate the license again, and then check whether the fault has
been rectified.
– No: Go to 17.
Check whether a module is faulty.
17 Check whether ALM-1003 Module Fault is displayed in the Browse Alarms window of
the client.
– Yes: Go to 18.
– No: Go to 19.
18 Rectify the fault by following the procedure for handling ALM-1003 Module Fault.
Then, check whether ALM-1003 Module Fault is cleared.
– No: Go to 19.
Check whether the ESN specified in the license file is different from the ESN of the NE.
19 Run ACT LICENSE to check whether the command output is The license is
invalid because its ESN does not match.
– Yes: Go to 20.
– No: Go to 23.
20 Run DSP ESN to query the ESN.
21 Check whether the ESN in the command output is the same as that specified in the
license file.

CloudEC
– Yes: Go to 23.
– No: Go to 22.
22 Apply for a new license based on the ESN and run ACT LICENSE to activate the
license. Then, check whether the fault has been rectified.
– No: Go to 23.
scenario.
----End
Related Information
ALM-1003 Module Fault
1.4.5.2 License Control Items of the Source Version Are Displayed After an
Upgrade
Symptom
After a service ME is upgraded, the license control items of the source version are
unexpectedly displayed in the DSP LICENSE output, and these license control items are not
used in the target version.
Possible Causes
The license of the target version is not activated and the system still uses the license of the
source version. In this case, the license version displayed in DSP LICENSE is still the source
license version.
Fault Diagnosis
None
Procedure
Step 1 On the OMU client, open the File Transfer Service window and select License File in
Remote Directory. Then, check whether the license file to be activated is available.
l No: Go to Step 2.
Step 2 In the displayed File Transfer Service window, upload the required license file to the
License File directory.
Step 3 In the MML command window of the service ME, run ACT LICENSE to activate the
license.
Step 4 Run DSP LICENSE and check whether the fault is rectified.

CloudEC
l No: Go to Step 5.
----End
1.4.6 Upgrade Failures
1.4.6.1 Target Version Selection Failure
Symptom
After the login to the upgrade tool is successful, Target version in the Select Upgrade ME
window is null and the Select check box is unavailable.
Possible Causes
The target version package or upgrade package does not exist.
Fault Diagnosis
Check whether the target version package and upgrade package exist, and then rectify the
fault based on the query result.
Procedure
Step 1 In the MML Command - CGP window of the client, run LST PKG to check whether the
target version package and upgrade package of each ME exist.
l No: Go to Step 2.
NOTE
l The version package of the CGP is displayed under the software package list in the output of LST
PKG, and the upgrade package is displayed under the ME-related package list.
l The version packages and upgrade packages of other MEs are displayed in the ME-related package
list.
Step 2 Upload the correct target version package and upgrade package.
NOTE
For details about how to upload the packages, see Loading the Version Package and Upgrade
Package of the CGP and the Packages of Other Software in the CGP Upgrade Guide.
Step 3 Click , and check whether the target version is displayed.

l No: Go to Step 4.

CloudEC
----End
Related Information
None
1.4.6.2 Connection to the MML Server Failed During the CGP Process Upgrade
Symptom
When the CGP process is being upgraded, the message Failed to execute UPG ME%
%RETCODE =81 Can not connect to MML server is displayed.
Possible Causes
The mmlserver service is not started.
Fault Diagnosis
Upgrade the CGP process after the system restarts the mmlserver service.
Procedure
Step 1 Wait for one minute.
NOTE
The system periodically detects the process status. When detecting a process fault, the system
automatically restarts.
Step 2 Click Retry on the interface of the upgrade tool, and check whether the fault is rectified.
l No: Go to Step 3.
----End
Related Information
None
1.4.6.3 "Incorrect User Name or Password" Displayed During the Upgrade or

Rollback
Symptom
During the upgrade or rollback, the system displays that the user name or password is
incorrect.

CloudEC
Possible Causes
l The password is changed during the upgrade.
l The password is changed during the observation period.
l The password is changed during the rollback.
Fault Diagnosis
Change the password based on the actual condition, and then go to the upgrade or rollback
operations.
Procedure
Step 1 Close the browser, and then exit the upgrade tool.
Step 2 In the MML Command - CGP window of the client, run MOD PWD to change the current
password to the password that was used before the upgrade.
Step 3 Start the browser, and type the floating IP address of the OMU in the address bar to log in to
the upgrade tool again.
Step 4 Click Retry in the displayed dialog box, and check whether the fault is rectified.
l No: Go to Step 5.
scenario.
----End
Related Information
None
1.4.6.4 Browser Failure During the Upgrade
Symptom
When the browser fails during the upgrade, the following symptoms may occur:
l The browser closes unexpectedly.

l The browser does not respond for a long time.
l The interface of the browser cannot be maximized after being minimized.
l The white screen error occurs on the browser unexpectedly.
l The browser closes abnormally during the upgrade. If you re-login, the upgrade progress
is invisible, and the upgrade or rollback control page cannot be opened.
l After the upgrade or rollback, if you click Rollback or Upgrade on the left part of the
page, the system displays a message stating that the operation is not allowed.

CloudEC
Possible Causes
The CPU usage by the browser is excessively high.
Fault Diagnosis
Close the browser, log in to the upgrade tool again, and then check whether the previous
upgrade task is displayed.
Procedure
Step 1 Close the browser, and then exit the upgrade tool.
Step 2 Clear the buffer of the browser.
Step 3 Wait for 7 minutes, log in to the upgrade tool again, and then check whether the previous
upgrade task is displayed.
l No: Go to Step 4.
scenario.
----End
Related Information
None
1.4.7 Patch Failures
1.4.7.1 Patch Loading Failure
Symptom
If running LOD PATCH in the MML Command - CGP window of the client fails, one of
the following messages may be displayed:
l The specified patch name is invalid.
l The patch does not exist.
l The previous patch is not in Running state. Please run CON
PATCH to confirm it.
l The version of the patch to be loaded is earlier than the
existing version in the system.
l The specified module does not exist.
l Operation times out.
l Patch initializing, operation failed.
l The specified ME instance does not exist.

CloudEC
l Other messages.
Possible Causes
The cause of the fault may be one of the following:
l The patch name is incorrect.
l The patch does not exist.
l Certain patches in the system are not running.
l The version of the patch to be loaded is earlier than the version of the existing patch.
l It is found that the specified module number does not exist when installing the patch.
l One or several related processes running on the host are abnormal.
l A process is resetting. The process is loading patches from the OMU. In this case, the
patch loading command cannot be run.
l It is found that the specified ME ID does not exist when installing the patch.
l Process files for generating a patch package differ from those on the current system on
which a hot patch is to be loaded.
Fault Diagnosis
Based on the error message displayed on the client, rectify the fault following the handling
procedure.
Procedure
Check the message displayed on the client
1 Run LOD PATCH in the MML Command - CGP window of the client to load the
patch, and take an appropriate measure based on the message displayed on the client.
– If the displayed message is The specified patch name is invalid:
Go to 2.
– If the displayed message is The patch does not exist:
Go to 6.
– If the displayed message is The previous patch is not in Running
state. Please run CON PATCH to confirm it:
Go to 9.
– If the displayed message is The version of the patch to be loaded
is earlier than the existing version in the system:
Go to 14.
– If the displayed message is The specified module does not exist:
Go to 16.
– If the displayed message is Operation timeout:
Go to 19.
– If the displayed message is Patch initializing, operation failed:
Go to 19.
– If the displayed message is The specified ME instance does not
exist:

CloudEC
Go to 23.
– Other messages:
Go to 26.
Check whether the patch name is correct.
2 Run LST PKG in the MML Command - CGP window of the client to query the name
of the patch package to be loaded.
NOTE
A patch package should be named in format of ME type_Package_ME version SPCXXX.tar, in

which XXX refers to the number of the patch package and SPCXXX indicates the name of the
patch. For example, if a patch package is named CGP_V200R018C00_SPC501.tar, SPC501 is
the name of the patch.
3 Check whether the name of the hot patch in the patch package is the same as Patch
name defined by running LOD PATCH.
– Yes: Go to 26.
– No: Go to 4.
4 Correct the patch name.
patch again, and then check whether the fault is rectified.
– No: Go to 26.
Check whether the patch package exists.
6 Run LST PKG in the MML Command - CGP window of the client to check whether
the patch package to be loaded exists.
– Yes: Go to 26.
– No: Go to 7.
7 Use the FTP service of the client to upload the patch package to the Software package
(auto loading) directory of the server.
– No: Go to 26.
Check the status of the patch.
9 Run DSP PATCH in the MML Command - CGP window of the client to check
whether the loaded patch is in Deactivated or Activated state.
– Deactivated: Go to 10.
– Activated: Go to 12.
10 Run ACT PATCH and CON PATCH in the MML Command - CGP window of the
client to make sure that the patch is running.
– No: Go to 26.
12 Run CON PATCH in the MML Command - CGP window of the client to make sure
that the patch is running.

CloudEC
– No: Go to 26.
Check whether a patch of a later version exists.
14 Run DSP PATCH in the MML Command - CGP window of the client to check all
existing patches in the system.
15 Check whether the version of any existing patch is later than the patch to be loaded.
NOTE
– A greater patch number indicates a later patch version, for example, SPH002 is later than
SPH001.
– A later patch version includes all issues found in an earlier patch version.
– No: Go to 26.
Check whether the module for which the patch is to be installed exists.
16 Run LST MODULE in the MML Command - CGP window of the client to check
whether the module for which the patch is to be installed exists.
– Yes: Go to 26.
– No: Go to 17.
17 Run corresponding commands in the MML command window of the ME on the client to
add the module, process, or process group.
– No: Go to 26.
Check whether a module is faulty or resetting.
19 Run DSP MODULE in the MML Command - CGP window of the client to check the
state of the modules.
– The Availability state for some modules is Not ready: Go to 20.
– The Availability state for some modules is Faulty or the Active/Standby state for
some modules is not Active or Standby: Go to 21.
– The Availability state for all the modules is Normal and the Active/Standby state
for all the modules is Active or Standby: GO to: 26.
20 After about 2 to 3 minutes, the module resets. Run LOD PATCH in the MML
Command - CGP window of the client to load the patch again, and then check whether
the fault is rectified.
– No: Go to 26.
21 Rectify the fault. For details, see ALM-1003 Module Fault.
22 Run LOD PATCH in the MML Command - CGP window of the client to specify the
ME ID and load the patch again, and then check whether the fault is rectified.
– No: Go to 26.

CloudEC
Check whether the specified ME ID exists.

23 Run LST PKG in the MML Command - CGP window of the client to check the ME
version mapping the patch package.
24 Run LST ME in the MML Command - CGP window of the client to query the
corresponding ME ID based on the ME version queried in 23.
25 Run LOD PATCH in the MML Command - CGP window of the client to specify the
ME ID and load the patch again, and then check whether the fault is rectified.
– No: Go to 26.
Contact Huawei technical support engineers.
scenario.
----End
Related Information
None
1.4.7.2 Inconsistent Patch Status Between the OMU and the Host
Symptom
The DSP PATCH command is successfully executed in the MML Command - CGP
window of the client and Check module status is displayed as Inconsistent in the command
output.
Possible Causes
l A patch-related command with forcible parameters is run. For example, in the forcible
deletion command RMV PATCH, FORCE is set to YES.
l The patch is not successfully restored when the processes are reset.
Fault Diagnosis
The CGP provides a mechanism for automatically synchronizing the patch status in between
the OMU and host. The CGP detects the patch status every 10 minutes. On detecting an
inconsistency of patch status in between the OMU and the host, the CGP automatically
synchronizes the patch status. The synchronization principle is as follows: the patch status on
the OMU determines whether the patch is required on the host; when the patch exists on both
sides, the patch status on the host is used.
When the patch status is inconsistent, you can check whether the patch status can be
automatically synchronized by the periodical synchronization mechanism. If the patch status
cannot be synchronized, collect information for identifying faults.
Procedure
Step 1 Wait for 10 to 15 minutes, after the processes are reset and the automatic synchronization is
complete, run DSP PATCH to display the patch status.

CloudEC
Step 2 Check whether Check module status is Consistent in the command output.
l No: Go to Step 3.
Step 3 Use Information Collection Tool to collect items in Common fault analysis scenario.
----End
Related Information
None
1.4.8 Performance Management Failures
1.4.8.1 Unreliable Performance Measurement Result
Symptom
l When you query the result of an ordinary performance measurement task on the
performance management system, the displayed value in the Credible column is
Incredible.
l When you query the real-time result reported by a monitoring task, the displayed value
in the Credible column is Incredible.
Possible Causes
l The time zone is set or daylight saving time (DST) is used.
l A service process is faulty.
l A certain virtual machine (VM) is faulty.
l A service process switchover occurs.
l The active/standby switchover of the OMUs occurs.
Fault Diagnosis
The measurement results of ordinary and monitoring tasks displayed on the client come from
the PCDRs reported by host processes. According to the measurement template configured on
the host side, the performance measurement module collects statistics on the PCDRs reported
by the host to obtain values of Credible and measurement entities of a task. If the
measurement result is not reliable, analyze the PCDRs reported by the host and the running
status of the performance measurement module.
Procedure
Check whether the measurement result was generated in the first measurement period after the
measurement task was created.
1 On the performance measurement result page, check whether the measurement result
was generated in the first measurement period after the measurement task is created.

CloudEC
If the start time of the unreliable measurement result is earlier than or the same as the
time when the measurement task is created, you can infer that the measurement result is
generated in the first measurement period after the measurement task is created.
– Yes: Go to 2.
– No: Go to 3.
2 On the performance measurement result page, check whether the measurement result
generated in the next measurement period is reliable.
It is normal that measurement results are unreliable in the first measurement period as
the measurement period is incomplete.
– No: Go to 3.
Check whether the time zone or DST is set.
3 On the performance measurement result page, check whether the start time or end time
contains the identifier of time zone or DST in the measurement result.
For example, the time 2010-04-04 15:15:00 +09:00 DST includes the time zone and the
DST flag.
– Yes: Go to 4.
– No: Go to 5.
4 In the MML Command - CGP window of the client, run LST OPTLOG to query
operation logs to check the reported time segment of the unreliable performance
measurement result. In the command output, check whether the time zone and DST is set
by running SET TZ or whether the system time is changed by running SET TIME.
– No: Go to 5.
NOTE
It is normal that the measurement result is unreliable for the next measurement period after the
time zone and DST or the system time is changed.
Check whether a process is faulty.
5 In the MML Command - CGP window of the client, run DSP MODULE to check
whether Active/Standby state of a certain module is neither Active nor Standby.
– Yes: Go to 6.
– No: Go to 7.
6 Rectify the fault by referring to the handling procedure in the ALM-1003 Module Fault
alarm help. Then, check whether the displayed value in the Credible column is Credible
in the measurement result starting from the next measurement period after the alarm has
been cleared.
– No: Go to 7.
Check whether a board is faulty.
7 In the Browse Alarms window of the CGP on the client, check whether en-
us_alarmref_0102720430.xml is generated before and after the unreliable measurement
result is generated.

CloudEC
– Yes: Go to 8.
– No: Go to 9.
8 Rectify the fault by referring to the handling procedure in the en-
us_alarmref_0102720430.xml alarm help. Then, check whether the displayed value in
the Credible column is Credible in the measurement result starting from the next
measurement period after the alarm has been cleared.
– No: Go to 9.
Check whether a process switchover occurs.
9 In the MML Command - CGP window of the client, run LST EVTLOG to check
whether en-us_eventref_0080813304.xml is generated before and after the unreliable
measurement result is generated.
– Yes: Go to 10.
– No: Go to 11.
us_eventref_0080813304.xml event help. Then, check whether the displayed value in the
Credible column is Credible in the measurement result starting from the next
measurement period after the event has been cleared.
– No: Go to 11.
Check whether a switchover occurs on the active and standby OMUs.
11 In the Browse Alarms window of the CGP on the OMU client. Check whether
ALM-8601 Swap of the OMU HA System is generated before and after the unreliable
measurement result is generated.
– Yes: Go to 12.
– No: Go to 13.
12 Rectify the fault by referring to the handling procedure in the ALM-8601 Swap of the
OMU HA System alarm help. Then, check whether the displayed value in the Credible
column is Credible in the measurement result starting from the next measurement period
after the alarm has been cleared.
– No: Go to 13.
Collect the log information, and contact technical support engineers.
scenario and item PCDR Bill in Custom Scenario.
----End
Related Information
None

CloudEC
1.4.8.2 Failure of Creating a Measurement Task
Symptom
If creating a measurement task fails, the following information is displayed on the
performance management system:
l The total number of measurement tasks exceeds the upper
limit on system task resources. On the MML command
interface of the CGP, run LST TRFTASK to query all tasks
and then delete unnecessary measurement tasks.
l The server does not respond for a long time. Please check
the network.
l System is busy now. Please try again later.
l The system is initializing. Please wait.
Possible Causes
l The system displays the message The total number of measurement tasks
exceeds the upper limit on system task resources. On the
MML command interface of the CGP, run LST TRFTASK to query
all tasks and then delete unnecessary measurement tasks. It
indicates that the number of the registered measurement tasks has reached the maximum
limit.
l The system displays the message The server does not respond for a
long time. Please check the network. It indicates that the
communication between the Web server and the OMU, or the communication between
the OMU and the host, is interrupted because the performance measurement system is
faulty.
l The system displays the message System is busy now. Please try again
later. It indicates that other clients are submitting measurement tasks, or one client
has sent two consecutive measurement tasks within less than 4 seconds.
l The system displays the message The system is initializing. Please
wait. It indicates that the initialization of the system is not complete.
Procedure
Perform an operation based on the fault symptom.
1 Take an appropriate action based on the message displayed on the client.
– The system displays the message The total number of measurement
tasks exceeds the upper limit on system task resources.
On the MML command interface of the CGP, run LST TRFTASK
to query all tasks and then delete unnecessary
measurement tasks. Go to 2.
– The system displays the message The server does not respond for a
long time. Please check the network. Go to 4.
– The system displays the message System is busy now. Please try
again later. Go to 3.
– The system displays the message The system is initializing.
Please wait. Go to 4.

CloudEC
– The system displays other messages. Go to 7.

Delete unnecessary measurement tasks.
2 On the MML command interface of the CGP, run LST TRFTASK to query all
measurement tasks. Delete unnecessary measurement tasks. (Delete preferentially
measurement tasks whose calculate type is OMU if tasks whose calculate type is OMU
and Host are registered.) Then, create the required measurement task again and check
whether the task was successfully created.
– No: Go to 7.
Wait until other clients complete the creation of measurement tasks.
3 Wait for 5 seconds. Then, create the measurement task again and check whether the task
was successfully created.
– No: Go to 7.
Check whether the performance measurement module is operating properly.
4 Check whether ALM-8600 Abnormal OMU Resources exists. And whether Resource
name of this alarm is pm.
– Yes: Go to 5.
– No: Go to 7.
5 Rectify the fault by following the procedure for handling the alarm ALM-8600
Abnormal OMU Resources. After the fault has been rectified, create the measurement
task again and check whether the task is successfully created.
– No: Go to 6.
6 Wait for 5 minutes. Then, create the measurement task again and check whether the task
was successfully created.
– No: Go to 7.
Collect log information and contact technical support engineers.
scenario.
----End
Related Information
None
1.4.8.3 Incorrect Time Segment in a Measurement Result
Symptom
The reported time segment of a measurement result differs from the system time of the OMU.

CloudEC
Possible Causes
l The DST has been set in the system, or the system time or time zone has been changed.
l The time of the OMU has been manually changed.
Fault Diagnosis
Analyze the fault as follows:
l If the measurement result is unreliable, rectify the fault by referring to the handling
procedure in Unreliable Performance Measurement Result.
l If the measurement result is reliable, it indicates that the fault is caused by the setting of
the DST, the time zone, or both, or by a change in the OMU time.
Procedure
Step 1 On the Query page, check whether the displayed value in the Credible column is Credible in
the measurement result when the time changes.
l No: See Unreliable Performance Measurement Result.
Step 2 Check whether the reported time of the measurement result contains the time zone or DST
information.
NOTE
For example, the time information contains only the time zone information +08:00, contains only the
DST information +00:30 DST, or contains the time zone and DST information +08:30 DST.
l No: Go to Step 3.
Step 3 In the MML Command - CGP window of the client, run DSP TIME to check whether the
reported time in the measurement result is the same as the OMU time.
l No: Go to Step 4.
Step 4 Use the Information Collection Tool to collect items in Common fault analysis scenario
and item PCDR Bill in Custom Scenario.
----End
Related Information
None
1.4.8.4 Discontinuous Time Segments of Measurement Results
Symptom
The reported time segments of the measurement results are discontinuous.

CloudEC
Possible Causes
l A certain virtual machine (VM) is faulty.
l A certain host process is faulty.
l A certain host process is restarted.
l A process switchover occurs on the host.
l The performance measurement process is faulty.
l An active/standby OMU switchover occurs.
l The time zone or daylight saving time (DST) is set.
l The disk space of the OMU is full.
l The CPU of the OMU is overloaded.
Fault Diagnosis
The time of the measurement result displayed on the Web client of the performance
management system is determined by the time when the host reports the measurement result
and the settings of the time zone and DST.
If the reported time segments of the measurement results are discontinuous, check whether the
system time or time zone and DST has changed, whether the host modules and the
performance measurement process are operating properly, and whether an active/standby
switchover has occurred.
In addition, for an ordinary measurement task, if certain modules fail to report the results
within the specified period, the system displays the measurement results 7 minutes later,
which is another cause of the fault.
Procedure
Check the discontinuous reported time segment of the measurement results.
1 On the measurement result page of the performance management system, check the start
time and end time of the measurement result with discontinuous time segment.
2 In the MML Command - CGP window of the client, run LST OPTLOG to query
operation logs. In the command output, check whether the time zone and DST is set by
running SET TZ or whether the system time is changed by running SET TIME before
or after the discontinuous time segments are generated.
NOTE
It is normal that the reported time segments of the measurement results are discontinuous after the
change of the time zone and DST or system time.
– No: Go to 3.
3 Check whether the reported time segment of the discontinuous measurement result is
added with the time zone or DST information.
NOTE
If yes, the time zone or DST information is included after the date and time. For example, the time
information contains only the time zone information +08:00, contains only the DST information
+00:30 DST, or contains the time zone and DST information +08:30 DST.

CloudEC
– Yes: Go to 4.
– No: Go to 5.
4 Subtract the time zone offset and DST offset from the start time of the measurement
period, and then check whether the difference between the start time before and after the
subtraction equals a measurement period.
It is a normal phenomenon that the reported time segments of the measurement results
are discontinuous due to the DST setting.
– No: Go to 5.
Check whether the discontinuous reported time segment is caused by measurement result timeout.
5 On the performance management system, query the performance measurement results
that are generated 7 minutes later than the last measurement result. Then, check whether
an unreliable result is generated during the missed measurement time segment.
– Yes: To rectify the fault that a measurement result is unreliable, see 1.4.8.1
Unreliable Performance Measurement Result.
– No: Go to 6.
Check whether a service module is faulty.
6 Check whether ALM-1003 Module Fault is generated before the begin time and after the
end time in the period during which the measurement results with discontinuous time
segments are generated.
– Yes: Go to 7.
– No: Go to 8.
7 Rectify the fault by referring to the handling procedure in the ALM-1003 Module Fault
alarm help. Then, check whether the measurement result is reliable, starting from the
next measurement period after the alarm has been cleared.
– No: Go to 8.
Check whether a board is faulty.
8 In the Browse Alarms window of the CGP on the client, check whether en-
us_alarmref_0102720430.xml is generated before the begin time and after the end time
in the period during which the measurement results with discontinuous time segments
are generated.
– Yes: Go to 9.
– No: Go to 10.
us_alarmref_0102720430.xml alarm help. Then, check whether the reported time
segments of the measurement results are continuous, starting from the next measurement
period after the alarm has been cleared.
– No: Go to 10.
Check whether the performance measurement process is faulty.
10 Check whether ALM-8600 Abnormal OMU Resources is generated, and Resource
Name indicated by the alarm is pm.

CloudEC
– Yes: Go to 11.
– No: Go to 12.
11 Rectify the fault by referring to the handling procedure in the ALM-8600 Abnormal
OMU Resources alarm help. Then, check whether the measurement result is normal,
starting from the next measurement period after the alarm has been cleared.
– No: Go to 12.
Check whether an active/standby OMU switchover occurs.
12 Check whether ALM-8601 Swap of the OMU HA System is generated before the begin
time and after the end time in the period during which the measurement results with
discontinuous time segments are generated.
– Yes: Go to 13.
– No: Go to 14.
13 Rectify the fault by referring to the handling procedure in the ALM-8601 Swap of the
OMU HA System alarm help. Then, check whether the measurement result is normal,
starting from the next measurement period after the alarm has been cleared.
– No: Go to 14.
Check whether the disk space of the OMU is full.
14 Check whether en-us_alarmref_0102720382.xml is generated before the begin time and
after the end time in the period during which the measurement results with discontinuous
time segments are generated.
– Yes: Go to 15.
– No: Go to 16.
us_alarmref_0102720382.xml alarm help. Then, check whether the measurement result
is normal in the next measurement period after the alarm has been cleared.
– No: Go to 16.
Check whether the CPU of the OMU is overloaded.
16 In the MML Command - CGP window of the client, run DSP CPU to check the CPU
usage and whether en-us_alarmref_0096562150.xml is generated.
– Yes: Go to 17.
– No: Go to 18.
us_alarmref_0096562150.xml alarm help. Then, check whether the measurement result
is normal, starting from the next measurement period after the alarm has been cleared.
– No: Go to 18.

CloudEC
----End
Related Information
None
1.4.8.5 Failure of Reporting Traffic Measurement Data to the OSS
Symptom
l The measurement data is not reported to the OSS.
l The measurement data is not reported to the OSS in real time.
l Certain measurement data is not reported.
Possible Causes
l The measurement data is not reported constantly.
– The network communication is interrupted.
l The measurement data is not reported to the OSS in real time.
– The network communication is congested.
– The measurement data is not reported in real time due to unreliable measurement
data.
l Certain measurement data is not reported.
– The number of tasks has reached the maximum limit.
Procedure
The measurement data is not reported constantly.
1 On the OSS client, check whether the connection between the OSS and the CGP is
operating properly. For details, see Failure of Interworking with the OSS.
– Yes: Go to 5.
– No: See Failure of Interworking with the OSS.
The measurement data is not reported to the OSS in real time.
2 On the measurement result page of the performance management system, check whether
unreliable measurement data exists.
The unreliable measurement data may cause delay of data reporting. This is not a
problem.

– No: Go to 5.
Certain measurement data is not reported.
3 On the measurement result page of the performance management system, check whether
the measurement data of new measurement tasks is reported.
– Yes: Go to 5.

CloudEC
– No: Go to 4.
4 Delete optional tasks and add tasks again. Then, check whether the fault has been
rectified.
– No: Go to 5.
----End
Related Information
None
1.4.8.6 Performance Management System Login Failure
Symptom
When you try logging in to the performance management system, one of the messages is
displayed:
l The page cannot be displayed.

l webagt process internal error.
l The system is initializing. Please wait.
l The server has no response. Please check the network after the
system is in the loading state for a long time.
Possible Causes
l The page cannot be displayed: The OMU is not operating properly.

l webagt process internal error: The webagt process is not operating properly.
l The system is initializing. Please wait: The PM process is not completely started.
l The server has no response. Please check the network: The webagt process
is abnormal. This may be because an exception occurs when the OMU processes
messages for login to the performance measurement window and WebUI cannot receive
responds for the messages from the OMU. As a result, the system is in the loading state
for a long time.
Procedure
Perform an operation based on the fault symptom.
1 Log in to the PM client, and then take appropriate action based on the message displayed
on the client:
– The page cannot be displayed: Go to 2

CloudEC
– webagt process internal error: Go to 3

– The system is initializing. Please wait: Go to 4.
– The server has no response. Please check the network: Go to 3.
Check whether the OMU is not operating properly.
Resource state of the resource processes of the active OMU server is Activated.
– Yes: Go to 3.
– No: Go to 5.
Check whether the webagt process is operating properly.
Resource state of the resource named webagt of the active OMU server is Activated.
– Yes: Go to 4.
– No: Go to 5.
Wait for the PM process to start completely.
4 Wait for 5 minutes until the PM process is started completely. Try logging in to the PM
system again. Then, check whether the login was successful.
– No: Go to 5.
scenario.
----End
Related Information
None
1.4.9 Command Failures
1.4.9.1 Message "Failed to send the request data" Returned
Symptom
After an MML command is executed in the MML Command - CGP window of the client,
error 483006 Failed to send the request data is displayed.
Possible Causes
The module receiving the MML command is faulty.
Fault Diagnosis
Check whether the OMU modules are operating properly.

CloudEC
Procedure
Step 1 In the MML Command - CGP window of the client, run DSP OMU to check whether all the
modules are operating properly.
l No: Go to Step 2.
----End
Related Information
None
1.4.9.2 Message "Operation timed out" Returned
Symptom
After an MML command is executed in the MML Command - CGP window of the client,
error 483007 Operation timed out is displayed.
Possible Causes
The processing result from the corresponding module is not received within the specified
timeout duration.
Fault Diagnosis
l Check whether the timeout duration set for the MML command execution is too short.
l Check whether the OMU modules are operating properly.
Procedure
Step 1 Log in to HUAWEI Operation & Maintenance System. Choose Maintenance > Timeout
Settings and Timeout Settings dialog box is displayed, as shown in Figure 1-59. It is
recommended to set MML command timeout (seconds) to 600. The value of MML
command timeout (seconds) ranges from 20 to 7200, and the default value is 180.
Figure 1-59 Timeout duration setting

CloudEC
Step 2 After the setting, click OK.
Step 3 In the MML Command - CGP window of the client, run the MML command that has timed
out. Wait for 10 minutes, and then check whether Operation timed out is displayed.
l No: No further action is required.
Step 4 In the MML Command - CGP window of the client, run DSP OMU to check whether all the
modules are operating properly.
l No: Go to Step 6.
Step 5 In the MML Command - CGP window of the client, run the MML command that has timed
out. Wait for 10 minutes, and then check whether Operation timed out is displayed.
----End
Related Information
None
1.4.9.3 Data Backup Failure
Symptom
l Data backup to the local disk by running BKP SYS in the MML Command - CGP
window fails. The system displays a message indicating that the free disk space is
insufficient.
l Data backup to a network directory by running BKP SYS in the MML Command -
CGP window fails. The system displays a message indicating that the free disk space is
insufficient.
CGP window fails. The system displays a message indicating that connecting to the
backup server fails.
CGP window fails. The system displays a message indicating that uploading data to the
backup server fails.
Possible Causes
l The free disk space of the OMU virtual machine (VM) is insufficient.
l Links to the backup server are faulty or the FTP service is faulty.
l Uploading data to the backup server fails.

CloudEC
Fault Diagnosis
l Check whether the free disk space of the OMU is insufficient. If yes, free the disk space
to meet the requirements of data backup.
l Check whether links to the backup server are faulty. If yes, rectify the fault with the links
to the backup server.
l Check whether the FTP service is faulty. If yes, restore the FTP service.
l Check whether the backup directory permission is incorrectly configured or the free
space on the directory is insufficient. If yes, correctly configure the directory permission
or free directory space to meet the requirements.
Procedure
Confirm the causes
1 Determine the operation according to the backup type:
– LOCAL(Local disk): Go to 2.
– NET(Network disk): Go to 6.
The process of LOCAL(Local disk) backup failure
us_alarmref_0102720382.xml alarm help. In the MML Command - CGP window, run
BKP SYS with Backup type set to LOCAL(Local disk) and Backup content set to
ALL (database and files), to implement full system data backup. Check whether the
data backup is successful.
– Yes: The handling procedure is complete.
– No: Go to 3.
3 Run BKP SYS with Backup type set to LOCAL(Local disk) and Backup content set
to ALL (database and files), to implement full system data backup. Check whether the
system displays a message, indicating that the free disk space is insufficient.
– Yes: Go to 4.
– No: Go to 23.
4 Delete files in certain directories. On the main interface of HUAWEI Operation &
Maintenance System, choose Maintenance > File Transfer Service. The File Transfer
Service interface is displayed. Back up the files in the directories such as Software
package(auto loading), License file, and ISO file.
5 Then, delete the files in the directories. After the files are deleted, run BKP SYS with
Backup type set to LOCAL(Local disk) and Backup content set to ALL (database
and files) in the MML Command - CGP window, to implement full system data
backup. Check whether the data backup is successful.
– No: Go to 23.
The process of NET(Network disk) backup failure
6 Check the error info of BKP SYS in the MML Command - CGP window, perform the
following operations:
– The local disk space is insufficient: Go to 7.
– Logging in to the backup server fails: Go to 10.
– Uploading files to the backup server fails: Go to 20.

CloudEC
The local disk space is insufficient

7 Rectify the fault by referring to the handling procedure in the ALM-9605 Virtual
Machine Free Storage Space Insufficient alarm help. In the MML Command - CGP
window, run BKP SYS with Backup type set to NET(Network disk) (backup server-
related parameters are specified according to the backup server configuration), to back
up data to a network directory. Check whether the data backup is successful.
– No: Go to 8.
8 Delete files in certain directories. On the main interface of HUAWEI Operation &
Maintenance System, choose Maintenance > File Transfer Service. The File Transfer
Service interface is displayed. Back up the files in the directories such as Software
package(auto loading), License file, and ISO file.
9 Then, delete the files in the directories. After the files are deleted, run BKP SYS with
Backup type set to NET(Network disk) (backup server-related parameters are specified
according to the backup server configuration) in the MML Command - CGP window,
to back up data to a network directory. Check whether the data backup is successful.
– No: Go to 23.
Logging in to the backup server fails
10 Check whether the OMU normally interworks with the specified backup server.
– Yes: Go to 12.
– No: Go to 11.
11 Restore the connection between the OMU and the specified backup server.
12 Check whether the backup server port is enabled on the firewall.
– Yes: Go to 14.
– No: Go to 13.
13 Enable the backup server port on the firewall according to the software usage of firewall
on the backup server and OMU.
14 Run BKP SYS with Backup type set to NET(Network disk) (backup server-related
parameters are specified according to the backup server configuration) in the MML
Command - CGP window, to back up data to a network directory. Check whether the
– No: Go to 15.
15 Check whether the FTP service is normally running on the backup server according to
the software usage of ftp server.
– Yes: Go to 17.
– No: Go to 16.
16 Contact maintenance engineers of the backup server to rectify the fault.
17 Check whether the parameters such as Protocol type, FTP server IP address, FTP port
number, FTP user name, and FTP password are correctly configured for the backup
server. If not, reconfigure the parameters, and run BKP SYS with Backup type set to
NET(Network disk) (backup server-related parameters are specified according to the
backup server configuration) in the MML Command - CGP window. Check whether
the data backup is successful.

CloudEC

– No: Go to 18.
18 Check whether ALM-8600 Abnormal OMU Resources is generated.
– Yes: rectify the fault by referring to the handling procedure of ALM-8600
Abnormal OMU Resources, go to 19.
– No: Go to 19.
19 After the fault is rectified, run BKP SYS with Backup type set to NET(Network disk)
(backup server-related parameters are specified according to the backup server
configuration) in the MML Command - CGP window, to back up data to a network
directory. Check whether the data backup is successful.
– No: Go to 23.
Uploading files to the backup server fails
20 Contact maintenance engineers of the backup server to check whether a fault (local disk
insufficiency, incorrect configuration of FTP directory permission, or FTP service fault)
occurs on the backup server.
– Yes: Go to 21.
– No: Go to 23.
21 Contact maintenance engineers of the backup server to rectify the fault.
22 Run BKP SYS with Backup type set to NET(Network disk) (backup server-related
parameters are specified according to the backup server configuration) in the MML
Command - CGP window, to back up data to a network directory. Check whether the
– No: Go to 23.
----End
Related Information
en-us_alarmref_0102720382.xml
ALM-8600 Abnormal OMU Resources
1.4.9.4 Failure of Step-by-Step Restoration
Symptom
l The step-by-step restoration check performed by the OMU user fails, as shown in Figure
1-60.
Figure 1-60 Step-by-step restoration check failure

CloudEC
l The step-by-step restoration performed by the OMU user fails, as shown in Figure 1-61.
Figure 1-61 Step-by-step restoration failure
Possible Causes
l The free disk space of the OMU virtual machine (VM) is insufficient.
l The versions do not match.
Fault Diagnosis
l Free disk space to meet the requirements of step-by-step restoration.
l Replace a backup package that matches the current version, and then restore the data.
Procedure
Free disk space to meet the requirements of step-by-step restoration.
1 Run du -s -h /opt/HUAWEI/cgp/workshop/omu/share/backup to check the size of the
backup file, and run df -h /opt to query the size of the free space of the /opt directory.
Check whether the size of the free space of the /opt directory is six times larger than the
size of the backup file.
– Yes: Go to 3.
– No: Go to 2.
2 Rectify the fault by following the procedure for handling the alarm ALM-9605 Virtual
Machine Free Storage Space Insufficient. Check whether the alarm has been cleared.
– Yes: Go to 3.
– No: Go to 5.
3 Restore the system, and then check whether the restoration was successful.
– No: Go to 5.
Replace a backup package that matches the current version, and then restore the system.
4 Replace a backup package that matches the current version, and then restore the system.
Check whether the system was restored successfully.
– No: Go to 5.
----End
Related Information
ALM-9605 Virtual Machine Free Storage Space Insufficient

CloudEC
1.5 LMT Failures
1.5.1 Installation and Uninstallation Faults
1.5.1.1 Prompted to Install JRE During JWS Installation
Symptom
During the installation of the JWS, the system displays a message indicating that the JRE
must be installed first. The message is displayed when the JWS installation interface is not
displayed properly even after the JRE is installed, as shown in Figure 1-62.
Figure 1-62 Message indicating that the JRE should be installed first
NOTE
The Java Runtime Environment (JRE) is an integration of environments for running the Java program,
The OMU client supports JRE1.6, JRE1.7, and JRE1.8, but the iBMC of the OMU server only supports
JRE1.7 and JRE1.8. Therefore, JRE1.7 and JRE1.8 are recommended.
Possible Causes
Multiple JREs of different versions are installed on the PC, but the current JRE is not 32-bit
of the 1.7 or 1.8 version. Or the temporary files of browser are not cleared.
Fault Diagnosis
In the registry, check the current JRE version.
Procedure

CloudEC
1 Clear the proxy settings and the temporary files of browser, refresh the interface, and
check whether the JWS has been correctly installed.
– No: Go to 2.
2 On the PC, choose Start > Run. In the Run dialog box, type regedit, and press Enter to
open the Registry Editor window.
3 If 32-bit Windows is used, in the navigation tree, choose HKEY_LOCAL_MACHINE
> SOFTWARE > JavaSoft > Java Runtime Environment. If 64-bit Windows is used,
in the navigation tree, choose HKEY_LOCAL_MACHINE > SOFTWARE >
Wow6432Node > JavaSoft > Java Runtime Environment.
4 On the right of the Registry Editor window, check whether the value of
CurrentVersion is 1.7, or 1.8, as shown in Figure 1-63 or Figure 1-64.
Figure 1-63 Current JRE version (32-bit Windows)

CloudEC
Figure 1-64 Current JRE version (64-bit Windows)
– Yes: Go to 7.
– No: Go to 5.
5 On the PC, choose Start > Run. In the Run dialog box, type appwiz.cpl, and press
Enter to open the Add or Remove Programs window. Remove all the JREs installed on
the PC, as shown in Figure 1-65.

CloudEC
Figure 1-65 Adding or removing programs
6 Install the correct JRE on the JWS installation interface, refresh the interface, and check
whether the JWS has been correctly installed.
– No: Go to 7.
7 Take a snapshot of results generated in Figure 1-62 and Figure 1-63 or Figure 1-62 and
Figure 1-64.
----End
Related Information
None.
1.5.1.2 System Displays "Application Blocked by Security Settings" During JWS

Installation
Symptom
NOTE
This section takes JRE 1.7 as an example to describe the problem and the handling procedure.
During the installation of the Java Web Start (JWS), the system displays the message
"Application Blocked by Security Settings", as shown in Figure 1-66.

CloudEC
Figure 1-66 Application Blocked by Security Settings
Possible Causes
Java security settings are not configured on the Java runtime environment (JRE) installed on
the PC.
Fault Diagnosis
Check the Java security settings on the PC.
Procedure
1 On the PC running the HUAWEI Operation & Maintenance System, open the Control
Panel. Then, click the Java icon to display the Java Control Panel dialog box.
2 Click the Security tab, select Enable Java content in the browser, and set the Security
Level to Medium, as shown in Figure 1-67.
NOTE
If the Medium option does not exist, you do not need to set the Security Level.

CloudEC
Figure 1-67 Setting Java security level
3 Click Edit Site List. The Exception Site List dialog box is displayed. Click Add, enter
the IP address which was blocked, as illustrated in Figure 1-68 or Figure 1-69, and then
click OK to add this IP address to the exception site list.
Figure 1-68 Adding the JWS to the exception site list (1)

CloudEC
Figure 1-69 Adding the JWS to the exception site list (2)
4 Click OK to save the settings, as shown in Figure 1-70 or Figure 1-71.

CloudEC
Figure 1-70 Saving the Java security settings (1)

CloudEC
Figure 1-71 Saving the Java security settings (2)
5 Delete the temporary files generated by the browser. Restart the browser and open the
JWS page. Check whether the JWS installation can be continued.
– No: Go to 6.
6 Capture and save the full-screen snapshots of Figure 1-66 and Figure 1-67.
----End
Related Information
None.

CloudEC
1.5.1.3 System Displays "Downloading 7z tools fail" During the Client

Installation Using JWS
Symptom
When you use the JWS to install the OMU client, the system displays Downloading 7z
tools fail.
NOTE
The 7-Zip is a tool for free and used to compress and decompress files in multiple formats. For details
about the 7-Zip tool, access http://www.7-zip.org/.
Possible Causes
l The network quality is poor.
l Security software such as antivirus software prevents files from being transmitted.
l The firewall prevents files from being transmitted.
l The security level of the browser is too high.
l The Windows OS patch may not be correctly installed.
Fault Diagnosis
l Check the security setting of the firewall, antivirus software and browser.
l Check whether there is the Windows OS patch that has not been installed.
Procedure
Check whether security software such as antivirus software is running properly.
1 Choose Start > Run. The Run dialog box is displayed. Then, type msconfig in the
dialog box and click OK. The System Configuration dialog box is displayed.
NOTE
Windows 7 is used as an example for OS-related procedure.

2 Check whether the security software, such as antivirus software and network detection
software, are available in the list of the Service tab page in the System Configuration
window.
– Yes: Go to 3.
– No: Go to 4.
3 In the Service tab page, deselect security software, such as antivirus software and
network detection software, and click OK. Then, go to 4.
Check whether the firewall is enabled.
4 Choose Start > Control Panel > Windows Firewall. The Windows Firewall window is
displayed.
5 Check whether the firewall is enabled.
– Yes: Go to 6.
– No: Go to 7.

CloudEC
6 Select Off (not recommended) and click OK. Then, go to 7.

Check the security level of the browser.
7 Start the Internet Explorer, and choose Tools > Internet Options. The Internet Options
window is displayed.
8 Choose Security > Internet > Custom Level. The Security Settings dialog box is
displayed. Change the security level to Medium High or lower, and go to 9.
NOTE
For details about how to set the security level of other browsers, see the operation guide of those
browsers.
Check whether there is the Windows OS patch that has not been installed.
9 Check whether there is the Windows OS patch that has not been installed.
– Yes: Go to 10.
– No: Go to 11.
10 Install the security-related patch prompted by the system.
11 Restart your PC and check whether the OMU client can be installed by using JWS.
– No: Go to 12.
Collect log information and contact technical support engineers for assistance.
12 Collect the following information:
– Client logs: The client logs are stored in the Client run log folder\omu
\workspace1\client\tracefile directory. Alternatively, you can use the log
information collection tool on the LMT to collect logs about the LMT for fault
location.
– OMU server logs: Use the Information Collection Tool to collect items in
Common fault analysis scenario.
----End
Related Information
None.
1.5.1.4 Failure in Starting or Removing the Client through JWS
Symptom
NOTE
The following operations and snap-shots are based on JRE1.6.

l Starting or removing the JWS client by choosing Start > All Programs > HUAWEI
Operation & Maintenance System fails, as shown in Figure 1-72.
l After the JWS client is installed, the shortcut menu is not available from the Start menu.
l Installing the JWS by clicking the installation link on the installation interface fails, as
shown in Figure 1-73.

CloudEC
Figure 1-72 Failure in starting the application
Figure 1-73 Invalid shortcut
Possible Causes
l The JWS stores invalid data in the cache.
l During the first installation, creating a shortcut is not selected.
l The JNLP file is not correctly associated with the JAVAWS application.
Fault Diagnosis
Rectify the fault based on the error information.

CloudEC
Procedure
NOTE
l If the OMU floating IP address is an IPv4 address, enter https://floating IP address/jws/ (for
example, https://172.31.8.8/jws/) in the address box of your browser.
l If the OMU floating IP address is an IPv6 address, enter https://[floating IP address]:port/jws/ (for
example, https://[2001:db8:1::1]:9443/jws/) in the address box of your browser. The IPv6 floating
IP address must be included in square brackets.
l This section takes an IPv4 floating address as an example.
1 Rectify the fault based on the error message returned during the operation:
– If the starting or removing the JWS client by choosing Start > All Programs >
HUAWEI Operation & Maintenance System fails, go to 2.
– If the shortcut is not available from the Start menu after the JWS is installed, go to
2.
– If installing the JWS by clicking the installation link on the installation interface
fails, go to 11.
2 Choose Start > Run. In the Run dialog box, type javaws -viewer, and press Enter. The
Java Applet Cache Viewer window is displayed.
3 In the Java Applet Cache Viewer window, select applications related to the LMT and
click Remove Selected Entries, as shown in Figure 1-74.

CloudEC
Figure 1-74 Java Cache Viewer
4 Start browser and type https://Floating IP address/jws/ (for example, https://

172.31.8.8/jws/). Then, install the new version of the client through the JWS and check
whether the installation is successful.
– No: Go to 5.
5 Close the Java Applet Cache Viewer window. In the Java Control Panel window,
click Settings to open the Temporary Files Settings window, as shown in Figure 1-75.

CloudEC
Figure 1-75 Java Control Panel
6 In the Temporary Files Settings window, click Delete Files, as shown in Figure 1-76.

CloudEC
Figure 1-76 Temporary Files Settings
7 Select all items in the dialog box and click OK to delete all cache files. See Figure 1-77.
Figure 1-77 Delete Temporary Files
8 Start browser and type http://Floating IP address/jws/ (for example, http://172.31.8.8/

jws/). Then, install the new version of the client through the JWS and check whether the
installation is successful.
– No: Go to 9.
9 In the Temporary Files Settings window, check the directory where the temporary files
are stored. Double-click My Computer and switch to the directory to delete all
temporary files in the directory, as shown in Figure 1-78.

CloudEC
Figure 1-78 Temporary Files Settings
10 Start browser and type http://Floating IP address/jws/ (for example, http://172.31.8.8/

jws/). Then, install the new version of the client through the JWS and check whether the
installation is successful.
– No: Go to 16.
11 Right-click Install. The shortcut menu is displayed, as shown in Figure 1-79.
Figure 1-79 Shortcut menu
12 Choose Save Target As... from the shortcut menu. In the Save As dialog box, select a
directory, and click Save.

CloudEC
13 Right-click the saved file in the directory, and choose Open With in the shortcut menu.
The Open With dialog box displayed, as shown in Figure 1-80.
Figure 1-80 Open With dialog box
14 Select the Java(TM) web Start Launcher application and select Always use the
selected program to open this kind of file. Then, click OK to install the JWS. Check
whether the installation is successful.
– Yes: Go to 15.
– No: Go to 16.
15 Delete the downloaded JNLP file. No further action is required.
----End
Related Information
None.
1.5.2 Login Faults

CloudEC
1.5.2.1 LMT Login Failure
Symptom
l When you start the client of HUAWEI Operation & Maintenance System, enter the
correct user name and password, and then click Login. Then, the system displays any of
the following messages:
– Failed to initialize the communication environment.
Check that the communication security modes are
consistent and the required services are running
correctly.
– Failed to communicate with the server. Please check if
the network is connected or the service is running
properly.
– Failed to authenticate the ID certificate, or no
algorithm matches the peer.
l When you start the client of Huawei Operation & Maintenance System, enter the correct
user name and password, and then click Login. The login occasionally times out.
Possible Causes
l The lmtserver module fails to run properly.
l The security module fails to run properly.
l The free disk space is insufficient.
l A disk track is damaged.
l The database connection is incorrect.
l Authenticate the peer is enabled for the LMT, but the trust certificate is not configured
for the LMT.
l Authenticate the peer is enabled for the LMT, but the OMU certificate is still in the
certificate revocation list.
l Authenticate the peer is enabled for the OMU (through the OSS), but the certificate is
not configured for the LMT.
l The port (port 9101 or 11101) for logging in to the LMT is not enabled on the firewall.
l The OMU server and LMT use different SSL protocol versions.
Fault Diagnosis
Rectify the fault based on the error message returned by the system during the login.
Procedure
Rectify the fault based on the different error messages.
1 Rectify the fault based on the error message displayed during the login:
– Failed to initialize the communication environment.
Check that the communication security modes are

CloudEC
consistent and the required services are running

correctly: Go to 2.
– Failed to communicate with the server. Please check if
the network is connected or the service is running
properly: Go to 7.
– Failed to authenticate the ID certificate, or no
algorithm matches the peer: Go to 38.
– Others: Go to 42.
Check the configuration on the LMT.
2 Check whether the IP address of Server is the same as the floating IP address of the
OMU. For details on the IP address of Server, see Figure 1-81.
Figure 1-81 Login interface (1)
– Yes: Go to 5.
– No: Go to 3.
3 On the login interface, click the button on the right of Server, as shown in Figure 1-82.
The Server Management dialog box is displayed, as shown in Figure 1-83. Configure
the floating IP address of the OMU as the IP address of the server, or change the IP
address of the server to the floating IP address of the OMU.

CloudEC
Figure 1-82 Login interface (2)
Figure 1-83 Server Management dialog box
4 Log in to the client again, and check whether the login is successful.
– No: Go to 5.
Check the network connection.
5 On the PC, choose Start > Run. In the Run dialog box, type cmd, and press Enter to
open the cmd.exe window.
6 Run pingIP address. Here, IP address indicates the floating IP address of the OMU.
Then, check whether the network connection between the PC and the OMU server is
normal, that is, whether the output is consistent with that displayed in Figure 1-84.

CloudEC
Figure 1-84 Output of the ping command
– Yes: Go to 11.
– No: Go to 7.
7 Check whether the network cable of the PC is correctly connected.
– Yes: Go to 9.
– No: Go to 8.
8 Contact the network administrator to make sure that the network cable is connected
correctly.
9 Check whether the IP address of the PC belongs to the same gateway as the floating IP
address of the OMU.
– Yes: Go to 11.
– No: Go to 10.
10 Contact the network administrator to make sure that the IP address of the PC belongs to
the same gateway as the floating IP address of the OMU.
11 Run telnet IP address Port number command in the cmd.exe window. (IP address
indicates the floating IP address of the OMU and port number is 9101 or 11101.) Check
whether the port is enabled on the server, as shown in Figure 1-85 and Figure 1-86.
Figure 1-85 Success of running the telnet command

CloudEC
Figure 1-86 Failure in running the telnet command
– Yes: Go to 13.
– No: Go to 12.
NOTE
– 9101: Used for the LMT to set up connections with the OMU in ordinary mode.
– 11101: Used for the LMT to set up connections with the OMU in safety mode.
For the port information of the server, see OMU Communication Matrix.
12 Contact the customer to enable the port on the firewall, and then log in to the client
again. Then, check whether the login is successful.
– No: Go to 13.
Check whether there are records that indicate IP addresses conflict.
13 Select the OMU IP address and log in to PuTTY as user cgpexpert.
14 Run su - root to switch to user root.
15 Run QueryMirrorState and find the active OMU that is running in Active state.
16 Log in the active OMU using PuTTY. After 5 minutes, check whether the information of
IP address conflict of the active OMU is displayed, as shown in Figure 1-87.
Figure 1-87 IP address conflict
– Yes: Go to 17.
– No: Go to 19.
17 Contact the network administrator and check for fault based on the IP conflict
information. Then, replan the floating IP addresses of the OMU.

CloudEC
18 Use the new OMU floating IP address to log in to the client again. Check whether the
login is successful.
– No: Go to 19.
Check whether the lmtserver module is running properly.
19 Log in to the PuTTY tool as user cgpexpert using the IP address of the active OMU.
21 Run su - omu to switch to user omu, as shown in Figure 1-88.
Figure 1-88 Switching the user
22 Run status | grep -i lmtserver to check whether the system displays running, as shown
in Figure 1-89.
Figure 1-89 Checking the status
– Yes: Go to 25.
– No: Go to 23.
Start the lmtserver module manually.
23 Run svc_adm -cmd startsvc lmtserver and pid lmtserver in turn to check whether the
system displays running, as shown in Figure 1-90.

CloudEC
Figure 1-90 Checking the lmtserver module status
– Yes: Go to 24.
– No: Go to 42.
– No: Go to 25.
Check whether the security module is running properly.
25 Log in to the PuTTY tool as user cgpexpert using the IP address of the active OMU.
27 Run su - omu to switch to user omu.
28 Run status | grep -i security to check whether the system displays running, as shown in
Figure 1-91.
Figure 1-91 Checking the status
– Yes: Go to 31.
– No: Go to 29.
Start the security module manually.
29 Run svc_adm -cmd startsvc security and pid security in turn to check whether the
system displays running, as shown in Figure 1-92.

CloudEC
Figure 1-92 Checking the security module status
– Yes: Go to 30.
– No: Go to 42.
– No: Go to 31.
Check the disk space.
31 Run su - root and enter the password of user root to switch to user root.
32 Run df to check whether the disk usage is exactly 100%, as shown in Figure 1-93.
Figure 1-93 Check the disk space
– Yes: Go to 33.
– No: Go to 34.
33 Run cd /opt and then du -h |grep -i [0-9]G > diskinfo.txt, as shown in Figure 1-94, to
record the disk usage. Then go to 43.
Figure 1-94 Recording the disk usage
Check whether damaged disk tracks are available.

CloudEC
34 Run badblocks -sv /dev/sda to check whether damaged disk tracks are available.
– Yes: Go to 43.
– No: Go to 35.
Check the database.
35 Run su - omu to switch to user omu.
36 Run dbopt -b db_status to check whether the output displays db_status :NORMAL, as
NOTE
During execution of dbopt, the system accesses the customer's database for obtaining the user
password. Therefore, you must be authorized by the customer before using this command.
Figure 1-95 Checking the database
– Yes: Go to 37.
– No: Go to 42.
– No: Go to 42.
Configure the certificate.
38 Obtain the mapping identity certificate, trusted certificate, and revocation list from the
administrator of the OSS that manages the NE. Configure the certificate for the LMT.
For details, see Configuring a Digital Certificate for the OMU Client.
– No: Go to 40.
Select SSL options on the LMT.
40 Set Protocol Version to TLSv1.2 and set Algorithm Intensity to High. For details, see
Configuring the Secure Transmission Mode.
– No: Go to 42.
Collect log information and contact technical support engineers for assistance.
42 Collect the following information:
location.

CloudEC

----End
Related Information
None.
1.5.2.2 Client Login Failure After the Floating IP Address of the OMU Is Changed
Symptom
After the floating IP address of the OMU is changed, you cannot log in to the client, as shown
in Figure 1-96.
Figure 1-96 Client Login Failure
Possible Causes
l The IP address of the PC and the modified floating IP address are not in the same
network segment.
l The default gateway or the subnet mask (for an IPv4 address)/prefix length (for an IPv6
address) is incorrectly configured.
l The OMU services cannot be started because the floating IP address conflicts with the IP
address of the operating network (confirmed by the carrierenterprise).
l The IP address of Server on the login interface of the client is inconsistent with the
modified floating IP address.
Fault Diagnosis
None.
Procedure
Step 1 Check whether the IP address of the PC, modified floating IP address of the OMU are in the
same network segment.
Step 2 Use the PuTTY tool to log in to the VM running the OMU as user cgpexpert.
Step 3 Run su - root to switch to user root.
Step 4 Run setomuip –list. Then, check whether the values of IP address, IP subnet mask/IP
prefix length, and IP default gateway are the same as those planned by the carrierenterprise.

CloudEC
The output of setomuip -list is as follows:

The float IP information is as follows
IP address = 172.16.8.8
IP subnet mask = 255.255.0.0
IP default gateway = 172.16.0.1
l No: Go to Step 6.
Step 5 Check whether the value of IP address (in output of setomuip - list) conflicts with the
existing IP addresses in the carrierenterprise environment.
l No: Go to Step 8.
Step 6 Change the floating IP address of the OMUs by running the following command:
setomuip -float [floating IP address] [subnet mask/prefix length] [default gateway]
Script example 1:
setomuip -float 172.16.5.143 255.255.0.0 172.16.0.1
Script example 2:
setomuip -float 2001:db8:1::1 64 2001:db8:1::254
NOTE
If Subnet Mask/Prefix Length and Default Gateway are not set, the system retains the original values
of Subnet Mask/Prefix Length and Default Gateway.
The output is as follows:

The new floating IP address configuration is as follows. Please check whether it
is correct.
--------------------------------------------------------------------------------
Address:172.16.5.143, Subnet Mask:255.255.0.0, Default Gateway:172.16.0.1.
--------------------------------------------------------------------------------
1. Type yes to continue the operation. All the services running on the OMU will
be stopped.
2. Type no to cancel the operation.
Please input your choice[Yes, No]:
NOTE
The preceding output is only a snapshot of partial output.
Step 7 After confirming that the output is correct, type Y and press Enter.
Wait about 1 minute. If the following information is displayed, the floating IP address of the
OMUs is successfully changed.
NOTICE: STEP2:Stopping the OMU services ......
NOTICE: STEP3:Preparing to set the IP address ......
NOTICE: STEP4:The IP address is successfully set. Preparing to start services ..
....
NOTICE: End: The IP address is successfully set. Services are being started. You
can run the omustatus command to check the startup status of processes.
Then, proceed to Step 10.

Step 8 Check whether the IP address of Server on the login interface is the same as IP address in
the output of setomuip -list.

CloudEC
l No: Go to Step 9.
Step 9 Change the IP address of Server to the value of IP address in the output of setomuip -list.
Then, log in to the client again, and check whether the login is successful.
l No: Go to Step 11.
Step 10 After 2 minutes, log in to the client again. Then, check whether the login is successful.
l No: Go to Step 11.
----End
Related Information
None.
1.5.3 Upgrade and Update Faults
1.5.3.1 LMT Client Update File Is Being Used by Another Program
Symptom
When updating the client program, the system displays the message "The file is being used by
another program and the upgrade will be terminated. Stop all programs that may use this file,
and perform the upgrade again.", as illustrated in Figure 1-97.
Figure 1-97 Error message

CloudEC
Possible Causes
Another client or client program is running.
Fault Diagnosis
Check whether there is another running client or client program.
Procedure
Step 1 Check and exit running clients, as illustrated in Figure 1-98.
Figure 1-98 Exiting running clients
Step 2 Check and exit running client programs.

1. Right-click the blank area on the task bar and select Start Task Manager.
2. In the Task Manager dialog box, right-click lmt_client.exe and choose End Process
from the shortcut menu, as illustrated in Figure 1-99.

CloudEC
Figure 1-99 Stopping the running client programs
Step 3 Restart your PC.
Step 4 Update the client and check whether the message is displayed again.
----End
Related Information
None.
1.5.3.2 Writing the File Fails During an LMT Update
Symptom
During an LMT update, the system displays an error message indicating writing the file fails,
as illustrated in Figure 1-100. After the LMT is updated again, the upgrade succeeds.

CloudEC
Figure 1-100 Error message
Possible Causes
The network between the LMT and OMU server is unstable or abnormal.
Fault Diagnosis
Check the status of the network between the LMT and OMU server.
Procedure
Step 1 Check whether your local VPN is connected, as illustrated in Figure 1-101.

CloudEC
Figure 1-101 Reconnecting the VPN
l No: Click Connect to reconnect the VPN. Then, go to Step 2.
Step 2 Check whether the OMU server is pingable from your local PC.
1. Choose Start > Run. Enter CMD and press Enter. The CLI is displayed.
2. Run ping OMU server IP address, as illustrated in Figure 1-102. Check whether packet
loss occurs.

CloudEC
Figure 1-102 Pingable network between the LMT and OMU server
l No: Go to Step 3.
Step 3 Update the LMT again. Check whether the error message is displayed.
----End
Related Information
None.
1.5.4 GUI Faults

CloudEC
1.5.4.1 Abnormalities Occur on the LMT
Symptom
Abnormalities, such as gray screen of death, no response to MML commands, and re-login
failure after disconnection, occasionally occur on the LMT. Figure 1-103 shows the gray
screen of death, and the LMT does not respond to any operations.
Figure 1-103 Gray screen of death
Figure 1-104 shows that the LMT does not respond to MML commands.

CloudEC
Figure 1-104 No response to MML commands
Figure 1-105 shows that users cannot re-log in to the LMT after it is disconnected.

CloudEC
Figure 1-105 Re-login failure after disconnection
Possible Causes
The preceding issues occur because the memory is insufficient. The insufficient memory may
be caused in the following scenarios:
l The client has been running for a long time.

l Many clients are started.
l The system runs other programs that consume memory.
Fault Diagnosis
Check whether the client has been running for a long time or many clients are started. Check
whether java.lang.OutOfMemoryError: unable to create new native
thread is recorded.

CloudEC
Procedure
1 Close all clients that are running or other programs that consumes the memory.
2 Restart the client and check whether the fault is rectified.
– No: Go to 3.
----End
Related Information
None.
1.5.4.2 Navigation to the Help Webpage Was Canceled
Symptom
When you attempt to open an online help webpage, the help browser displays the message
Navigation to the webpage was canceled, as shown in Figure 1-106.

CloudEC
Figure 1-106 Navigation to the webpage was canceled
Possible Causes
The help browser does not obtain the resources before the time expires and then cancels the
navigation.

CloudEC
Fault Diagnosis
None.
Procedure
Step 1 Click Refresh the page in the Help Browser window. Then, check whether the online help is
displayed.
l No: Go to Step 2.
----End
Related Information
None.
1.5.5 FTP Tool Faults
1.5.5.1 FTP Start Failure
Symptom
When the FTP is started on the client, the system displays one of the following messages:
l The FTP connection fails to be established. Please check

whether the network status is normal.
whether the FTP service is normal.
l The CheckPoint service is enabled on the client. Please
disable the CheckPoint service.
the firewall settings between the client and the OMU.
l Failed to connect to the FTP server. Please check and try
again.
Possible Causes

l The FTP service is abnormal.
l The PC where the client is installed starts the Check Point SecuRemote Service and
Check Point SecuRemote WatchDog services.
l The FTP port used to establish control connection or data connection is disabled on the
firewall.

CloudEC
Fault Diagnosis
Rectify the fault based on the error message returned by the system during the operation.
Procedure
Rectify the fault based on different symptoms.
1 Rectify the fault based on the following symptoms:
– If the system displays The FTP connection fails to be
established. Please check whether the network status is
normal, go to 2.
established. Please check whether the FTP service is
normal, go to 5.
– If the system displays The CheckPoint service is enabled on the
client. Please disable the CheckPoint service, go to 8.
established. Please check the firewall settings between
the client and the OMU, go to 16.
– If the system displays Failed to connect to the FTP server.
Please check and try again, go to 2.
Check the network connection.
2 Log in to the client again, and check whether the login was successful.
– Yes: Go to 4.
– No: Go to 3.
3 Rectify the fault by referring to the handling procedure of the alarm 1.5.2.1 LMT Login
Failure.
4 Enable the File Transfer Service on the client again and then check whether the
operation is successful.
– No: Go to 24.
Check the Utility module.
5 Switch to the Browse Alarms window, and then check whether ALM-8600 Abnormal
OMU Resources is generated for the Utility module.
– Yes: Go to 6.
– No: Go to 24.
6 Rectify the fault by referring to ALM-8600 Abnormal OMU Resources, and then go to 7.
7 Enable the File Transfer Service on the client again, and then check whether the
operation is operating properly.
– No: Go to 24.
Check the services on the PC
8 On the PC, choose Start > Control Panel > Administrative Tools > Computer
Management. The Computer Management window is displayed.

CloudEC
9 In the left navigation tree, choose Computer Management (Local) > Services and
Applications > Services.
10 Double-click Check Point SecuRemote Service and Check Point SecuRemote
WatchDog in turn.
11 In the displayed Properties dialog box, click the General tab.
12 The Check Point SecuRemote Service and Check Point SecuRemote WatchDog
services must be temporarily stopped when the FTP service is in use. Set Startup Type
to Disabled.
13 Click OK, and close the Computer Management window.
14 Restart the PC.
15 Enable the File Transfer Service on the client again, and then check whether the
operation is operating properly.
– No: Go to 24.
Check the firewalls between the client and the OMU.
16 Disable the firewall on the PC, or enable the firewall to allow the FTP port and FTP
connection.
17 Based on the networking of the carrierenterprise, check whether a firewall exists
between the client and the OMU.
– Yes: Go to 18.
– No: Go to 24.
18 Obtain information from the carrierenterprise about whether the control port 990 and the
data port 989 are opened on the firewall.
– Yes: Go to 21.
– No: Go to 19.
19 Modify the firewall configuration to open the control port 990 and the data port 989 after
obtaining carrierenterprise's permission.
20 Enable the File Transfer Service on the client again and check whether the operation is
successful.
– No: Go to 21.
21 In the MML command - CGP window, run DSP FTPSVRCFG to query the control
port number and the data port number, and check whether the queried ports are opened
on the firewall.
– Yes: Go to 24.
– No: Go to 22.
22 Modify the firewall configuration to set the range of the queried control port and data
port after obtaining carrierenterprise's permission.
23 Enable the File Transfer Service on the client again and check whether the operation is
successful.
– No: Go to 24.

CloudEC
24 Collect the following logs depending on the troubleshooting progress.

\workspace1\client\tracefile directory. In addition, you can use the Log
Information Collection tool on the LMT to collect logs about the LMT for fault
location.
----End
Related Information
N/A
1.5.5.2 Directory Space Is Insufficient When Files Are Uploaded Using the FTP
Symptom
When files are uploaded to the /opt/pub/software/tmp/ directory by using the FTP service,
the system indicates that the directory space is insufficient.
Possible Causes
A maximum of 10 GB is allowed for the /opt/pub/software/tmp/ directory on the OMU
server. If the directory has consumed 10 GB space, files cannot be uploaded.
Fault Diagnosis
None.
Procedure
Step 1 Use the PuTTY tool to log in to the OMU as user cgpexpert with the IP address of the OMU.
Run su - root to switch to user root.
Step 2 Enter the /opt/pub/software/tmp/ directory. Run du -hs * to check whether there are
outdated files or directories that are oversized.
l No: Go to Step 5.1.
Step 3 Run rm -i File name to delete the outdated files or directories.
Step 4 Use the FTP to re-upload files. Then, check whether the fault is rectified.
Step 5 Collect log information and contact technical support engineers.
1. Collect the following information:

CloudEC
location.
2. Contact Huawei technical support engineers to rectify the fault.
----End
Related Information
None.
1.5.5.3 System Displays an Upgrade Tool Update Failure or System Being

Upgraded
Symptom
When you use File Transfer Protocol (FTP) service to upload the version package or remote
patch package, the system remains loading these packages and displays Failed to renew
upgtool or The system is being upgraded.
Possible Causes
If the upgrade tool is available in the remote patch package or version package, the original
upgrade tool is updated during the package uploading.
When the system is being upgraded or a patch is being installed, these packages fail to be
uploaded.
Fault Diagnosis
None.
Procedure
Step 1 Log in to OMU through web and click Patch & Upgrade Tool.
Step 2 Check whether a patch is being installed or the system is being upgraded.
Step 3 Click Continue or other related buttons to complete the patch installation or upgrade.
NOTE
For details about operations related to the patch installation or upgrade, see the section Patch
Installation in the Patch Update Guide or Remote Patch Update Guide of the corresponding version.
Step 4 Return the File Transfer Service window and re-load the remote patch package or version
package. Then, check whether the fault is rectified.

CloudEC
Step 5 Collect log information and contact technical support engineers.

1. Use the Information Collection Tool to collect items in Common fault analysis
scenario.
----End
Related Information
None.
1.5.6 Other Faults
1.5.6.1 Data Is Inconsistent Between Tables and Curves on Module Management

Page of the LMT
Symptom
If the Huawei Operation & Maintenance System has run for a long period of time, data
inconsistency may occur between the table and the curve displayed on the Module
Management page, as shown in Figure 1-107.
Figure 1-107 Data inconsistency between the table and the curve displayed on the Module
Management page

CloudEC
Possible Causes
The Huawei Operation & Maintenance System has run for a long period of time.
Fault Diagnosis
Check whether the Huawei Operation & Maintenance System has run for a long period of
time.
Procedure
Step 1 Deselect the module and select the module again, then check whether data in the table is
consistent with that in the curve:
l No: Go to Step 2.
Step 2 Close the Module Management page.
Step 3 Open the Module Management page again, select a module, and check whether data in the
table is consistent with that in the curve:
l No: Go to Step 4.
Step 4 Exit Huawei Operation & Maintenance System.
Step 5 Log in to Huawei Operation & Maintenance System.
Step 6 Open the Module Management page again, select a module, and check whether data in the
table is consistent with that in the curve:
l No: Go to Step 7.
----End
Related Information
None.
1.5.6.2 OMU Client on a Remotely Connected PC Cannot Provide the Predictive

MML Command Input Function
Symptom
On PC A, the predictive command input function on the MML Command - ME window of
HUAWEI Operation & Maintenance System is correct, as illustrated in Figure 1-108.

CloudEC
Figure 1-108 Correct predictive command input function
On PC B, access PC A's desktop remotely by running mstsc, as illustrated in Figure 1-109.
Figure 1-109 Remote desktop connection
After the remote connection is successful, the user who is using HUAWEI Operation &
Maintenance System on PC A is forced to log out. After the user re-logs in to HUAWEI
Operation & Maintenance System and opens the MML Command - ME window, the
command in the Command Input box is changed to lowercase letters, and the predictive
command input function becomes invalid. In addition, "Command Error!" is displayed after
the user attempts to run a command, as illustrated in Figure 1-110.

CloudEC
Figure 1-110 Invalid predictive command input
Possible Causes
l The settings for remote desktop connection are incorrect.
l A third-party remote connection tool, which is not recommended, is used to remotely
access a PC.
Fault Diagnosis
Check and correct the settings for remote desktop connection.
Procedure
Step 1 On the Local Resources tab in the Remote Desktop Connection dialog box, select On the
remote computer for Apply Windows key combinations, as illustrated in Figure 1-111.

CloudEC
Figure 1-111 Local Resources tab
Step 2 On the Experience tab, select all the options for Allow the following, as illustrated in Figure
1-112.

CloudEC
Figure 1-112 Experience tab
Step 3 Reconnect PC B remotely and check whether the predictive command input function is
normal.
l No: Go to Step 4.
----End
Related Information
None.
1.6 Service NE Interconnection Faults
1.6.1 MRP Interworking Fault
Symptom
The MRP is faulty, and resource operations fail.

CloudEC
Possible Causes
l The H.248 link for connecting to the MRP is faulty.
l The MRP stops providing services.
Troubleshooting Method
If you use the setup tool to install the MRP, the default data is configured after the installation.
In this case, the MRP is usable after being powered on. If the MRP is unusable, check the
network first.
Procedure
1. Check whether the default connection data is modified.
a. Check the operation history and verify that you have not modified the VM,
MADDR, and H.248 data on the USM using MML commands.
b. Check the operation history and verify that you have not modified the VM, ETHIF,
SIGADDR, and H.248 data on the MRP using MML commands.
c. If the data is modified, the default network may be affected. You need to restore the
default configuration on the USM and MRP.
2. Run the DSP H248 command to check whether the H.248 link is normal.
– Yes: Go to 3.
– No: Go to 4.
3. Run the DSP MGW command to check whether the MRP is running properly.
– No: Go to 4.
4. Check whether port 0 is connected to the network properly.
By default, the MRP uses port 0 (first port of the server) for communication.
– Verify that the first network port is connected to a network cable and is on the same
network as the MRP VM on all servers.
– Check whether a port fault alarm exists. If yes, clear the alarm by referring to the
CGP help.
1.6.2 CCF Interworking Fault
Symptom
The USM reports ALM-20022 All Links Between USM and Peer CCF Disconnected. This
alarm is also accompanied with multiple ALM-20008 Link Between USM and Peer CCF
Disconnected alarms.
Possible Causes
l The BSG process where all links between the USM and the CCF are located is faulty.
l The peer CCF is faulty.
l The IP address of a new device conflicts with that of the USM or CCF.
l The physical link between the USM and the CCF is faulty.

CloudEC
l Parameter settings are inconsistent between the USM and the CCF.
Check the preceding possible causes one by one.
Procedure
Rectify the fault.
1. Check whether the BSG process where all links between the USM and the CCF are
located is faulty.
– Yes: Go to 11.
– No: Go to 2.
2. Check whether the peer CCF is faulty.
– Yes: Contact Huawei CCF engineers.
– No: Go to 3.
3. Check whether parameter settings are consistent between the USM and the CCF.
– Yes: Go to 4.
– No: Set USM parameters based on the parameter settings on the CCF.
4. Check whether ALM-20008 Link Between USM and Peer CCF Disconnected or
ALM-3162 IP Address Conflict exists on the alarm console.
– If ALM-20008 Link Between USM and Peer CCF Disconnected exists, go to 5.
– If ALM-3162 IP Address Conflict exists, go to 6.
– If the preceding alarms do not exist, go to 8.
5. Clear ALM-20008 Link Between USM and Peer CCF Disconnected based on the
corresponding alarm handling procedure. Then go to 7.
6. Check new devices connected to the network and deactivate the device that causes the IP
address conflict.
7. Check whether the alarm is cleared on the alarm console.
– No: Go to 8.
Ensure that services can be used.
NOTE
If the alarm is not cleared for a long period of time, the usage of the USM bill pool continuously
increases. If the usage reaches a certain threshold, full-bill-pool call barring will take effect or
CDRs will be lost. Therefore, ensure that basic services are running properly before contacting
Huawei technical support engineers.
8. In the MML Command - USM window, run the LST RFPARAM command and check
the value of Bill pool full barring.
– If the value is Yes, go to 9.
– If the value is No, go to 10.
9. In the MML Command - USM window, run the MOD RFPARAM: FLBAR=N
command to allow calls to be connected when the bill pool is full.

CloudEC
If you allow calls to be connected when the bill pool is full, the CDRs of these calls will
be lost. Assess this operation in advance.
10. In the MML Command - USM window, run the MOD DMDEV: DN=x, DMPRI=x
command to manually switch services to the standby CCF. In the preceding command,
set DN to the device name of the standby CCF and DMPRI to a value lower than that of
the active CCF.
11. Collect alarm information, CCF run logs, and USM operation logs and contact Huawei
technical support engineers.
Restore the configuration.
12. If full-bill-pool call barring is enabled in the original configuration, run the MOD
RFPARAM: FLBAR=Y command in the MML Command - USM window after the
alarm is cleared to enable full-bill-pool call barring.
13. If full-bill-pool call barring is disabled in the original configuration and you have
manually switched services to the standby CCF, run the MOD DMDEV: DN=x,
DMPRI=x command in the MML Command - USM window to manually switch
services to the original CCF. In the preceding command, set DN to the device name of
the original CCF and DMPRI to a value lower than that of the active CCF.
1.6.3 Failed to Received CDRs on the CCF

Symptom
l There is a possibility that CDRs are stacked on the NE side and fail to be sent to the
CCF.
l There is a possibility that the CCF reports ALM-25131 Stopped Receiving CDRs.
l There is a possibility that the CCF reports ALM-25087 Diameter Link Abnormal.
Possible Causes
When the CCF fails to receive CDRs, the possible causes are as follows:
l The CCF stops receiving CDRs.
l Diameter links are faulty.
shows the flow for diagnosing CCF failure to receive CDRs in Figure 1-113.

CloudEC
Figure 1-113 The flow for diagnosis
Procedure
1. In the Alarm Browse window of the HUAWEI Operation & Maintenance System, check
whether ALM-25131 Stopped Receiving CDRs exists.
– Yes: Go to 2.
– No: Go to 3.
2. Rectify the fault by referring to the handling procedure of ALM-25131 Stopped
Receiving CDRs in the Alarm Help, and check whether the alarm is cleared.
– No: Go to 3.
3. Log in to CDR Query and Browse System and check whether new CDR files are
generated.
– No: Go to 4.
4. Choose Alarm > Browse Alarms. On the displayed Browse Alarms tab page, check
whether ALM-25087 Diameter Link Abnormal is generated.
– Yes: Go to 5.
– No: Go to 6.
5. Rectify the fault by referring to the handling procedure of ALM-25087 Diameter Link
Abnormal in the Alarm Help.
– No: Go to 6.
6. Perform the operations described in Collecting iCG9815 Information.

CloudEC
1.6.4 SIP Trunk Interworking Fault

Symptom
On the sysPortal home page, the SIP trunk interworking status is displayed as abnormal.
Possible Causes
l The data configuration is incorrect.
l The network is faulty.
l The peer device does not support OPTION heartbeat detection.
Generally, the SIP trunk is in UDP mode that is connectionless. To ensure security, Huawei
devices use OPTION messages to detect trunk status.
l When trunk heartbeat detection is disabled, the trunk status is normal.
l When the trunk is faulty, you can trace SIP messages to confirm the incorrect
configuration.
Procedure
1. Check the configuration.
– Log in to the sysPortal and access the SIP trunk configuration page.
– Only one USM local IP address exists. Therefore, focus on verifying that the remote
IP address and port number are the same as the peer end SIP trunk IP address and
port number that are actually used.
2. Trace SIP messages.
Enable SIP message tracing for the USM NE. (By default, OPTION messages are not
traced. You need to enable tracing for OPTION messages.) Check whether the
destination IP address is correct for OPTION messages and check whether the peer
device returns the 200 response.
– No: Go to 3.
3. Check the network status.
Log in to the HUAWEI Operation & Maintenance System and run the MML command
PING under NE 0 by setting Local IPv4 address to the signaling IP address of the USM
and Peer IPv4 address to the destination IP address.
If the following information is displayed, the destination IP address is reachable:
%%PING: SRN=0, SN=0, IPTYPE=IPV4, LOCALIP4="10.39.12.131",
PEERIP4="10.24.112.1", DATATYPE=DYNAMICLEN;%%
RETCODE = 0 Operation succeeded
The summary result is as follows

--------------------------------
Sent packets = 5
Received packets = 5
Packet loss ratio = 0
Maximum round time(ms) = 12
Minimum round time(ms) = 1
Average round time(ms) = 4
(Number of results = 1)

CloudEC
If the following information is displayed, the destination IP address is unreachable:

%%PING: SRN=0, SN=0, IPTYPE=IPV4, LOCALIP4="10.39.12.131",
PEERIP4="10.24.112.10", DATATYPE=DYNAMICLEN;%%
The summary result is as follows

--------------------------------
Sent packets = 5
Received packets = 0
Maximum round time(ms) = NULL
Minimum round time(ms) = NULL
Average round time(ms) = NULL
4. Check whether the peer device supports OPTION heartbeat detection. If no, disable the
trunk heartbeat function on the SIP trunk configuration page.
1.6.5 Interworking Fault Between the uPortal and Peripheral NEs
Symptom
l Recording rights fail to be configured. The system prompts you to check the file server
configuration.
l IP phones fail to be added. The system prompts you to check the TMS configuration.
Possible Causes
Peripheral NE configurations are missing or the configurations are incorrect.
Check the peripheral NE configurations as prompted.
Procedure
l Check the file server configuration.
a. Run the DSP FSLNK command in the HUAWEI Operation & Maintenance System
to view the file server status.
%%DSP FSLNK:;%%
RETCODE = 170636 The record does not exist.
b. If the file server is not configured, run the ADD FS and ADD FSLNK commands
to add the file server configuration.
%%ADD FS: FSNAME="1", FSTYPE=RECORD, MOUNTDIR="recording";%%
%%ADD FSLNK: LNKNAME="1", FSNAME="1", FSADDR="10.175.4.178", FSDIR="/opt/

voicefile";%%
c. If the file server status is abnormal, perform the following operations:

i. Check whether the file server configuration is correct. If no, modify the
configuration.
ii. Check whether the file server is reachable through the network. If no, rectify
any network fault.
iii. Verify that the client service is enabled for the PMU VM of the uPortal.

CloudEC
iv. Verify that the access rights and file read/write rights are enabled on the file
server.
ECGPVM-F63S05:/opt/UPORTAL2800/common/run_log/PMU # service nfsserver
status
Checking for kernel based NFS server:
idmapd running
mountd running
statd running
nfsd running
l Check the TMS configuration.

a. Run the LST SNECFG: NETYPE=TMSTR69 command in the HUAWEI
Operation & Maintenance System to view the TMS configuration.
%%LST SNECFG: NETYPE=TMSTR69;%%
b. If the TMS is not configured, add the TMS configuration.

%%ADD SNECFG: NETYPE=TMSTR69, SERVICENAME="tmstr.huawei.com",
ACCOUNT="tmstr069", PASSWORD="*****";%%
c. If the TMS is configured, check whether the TMS configuration is correct. If no,
modify the configuration.
1.6.6 DR Network Data Synchronization Fault

Symptom
l Real-time synchronization fails.
l Full verification fails. A message is displayed, indicating that no link is available.
Possible Causes
l Real-time synchronization fault:
a. The connection request is rejected. The peer site is not added to the whitelist.
b. The license is not configured or the ESN does not match the license.
c. The user name or password is incorrect.
d. No route is available.
e. The network is faulty, and the connection times out.
l Full verification fault:
The synchronization link fails to be set up.
a. Verify that the peer site is added to the whitelist.
b. Run the LST LICENSE command to verify that the license is configured and the
ESN matches the license.
c. Verify that the user name and password are correct.
d. Verify that the route is configured.
e. Verify that the network is connected.
Run the DSP SESSIONSTATU command to check the link status.

CloudEC
Procedure
1. Run the LST UPORTALACL command to check whether the peer site is added to the
whitelist.
– Yes: Go to 2.
– No: Run the ADD UPORTALACL command to add the peer site to the whitelist.
+++ USM/*MEID:5 MENAME:me_usm_5*/ 2017-02-25 10:59:28+08:0
O&M #262
%%LST UPORTALACL:;%%
No matching result is found

2. Run the LST LICENSE command to verify that the license is configured and the ESN
matches the license.
O&M #271
%%LST LICENSE:;%%
No matching result is found

3. Verify that the user name and password are correct.
4. Check the network and route.
Run the DSP SESSIONSTATU command to check the link status.
O&M #120
%%DSP SESSIONSTATU:;%%
The result is as follows

------------------------
local ip = 172.16.191.8
remote ip = 172.16.191.8
remote port = 8181
session type = SOUTHNE_TYPE_ATS
service type = WORKFLOW
process type = PMU
status = CONNECTED
error information = NULL
1.6.7 ECS Interworking Fault

Symptom

CloudEC
Possible Causes
l The interworking user name or password configured on the BMU is different from the
user name or password configured on the USM.
l The uPortal interworking IP address configured on the BMU is incorrect.
1. On the BMU home page, if "All disconnected" is displayed in USM Connection Status
and "Failed to verify the password or the account" is displayed in status details, the
interworking user name or password configured on the BMU is different from the user
name or password configured on the USM.
2. On the BMU home page, if "All disconnected" is displayed in USM Connection Status
and "Non-uPortal address or uPortal ACL is not configured" is displayed in status
details, the uPortal interworking IP address configured on the BMU is incorrect.
Procedure
Step 1 Log in to the BMU as the system administrator (default user name: admin).
Step 2 Click HOME.
Step 3 Check USM connection status and status details.
----End
1.7 Service Faul
1.7.1 Login and Registration Faults
1.7.1.1 Terminal HTTP Access Fault
Symptom
The message "Incorrect account or password." or "Server connection timed out. Check the
network settings." is displayed during terminal login or the login fails.
Possible Causes
l The user name or password is incorrect.
l The IP address or port number of the uPortal server is incorrectly configured.
l The network between terminals and the uPortal server is faulty.
l The terminal access configuration is incorrect and missing.
l Check the configuration.
l Check the network.

CloudEC
Procedure
Step 1 If the message "Incorrect account or password." is displayed, verify that the user name and
password are correct. Contact the administrator for confirmation if necessary.
Step 2 If the message "Server connection timed out. Check the network settings." is displayed, verify
that the IP address and port number of the uPortal server are correctly configured on the login
setting page.
Step 3 Use commands such as ping and telnet to check whether the network between terminals and
the uPortal server is connected. If no, rectify any network fault.
Step 4 View terminal login logs. Determine the step or process in which the login fails based on
exception information. Based on the log content, check whether the terminal access
configuration is incorrect or missing. Verify all related configurations.
----End
1.7.1.2 Login and Registration Fault
Symptom
In the ECS environment that uses the uPortal for authentication, the login fails on clients.
When the cause of disconnection between clients and the uPortal is ruled out, the message
"Server connection timed out. Check the network settings." is still displayed on clients. The
eServer may fail to interwork with the uPortal.
Figure 1-114 Server connection failure
Possible Causes
The possible causes are as follows:
l The IP address of the eServer is not added to the whitelist on the uPortal.
l The uPortal interworking IP address (or domain name) is not configured on the BMU, or
the current uPortal IP address carried in the token is not in the interworking IP address
list.
l The uPortal interworking IP address configured on the BMU does not match the token
addressing mode configured on the uPortal.
l A link problem exists between the eServer and the currently selected uPortal server. (The
eServer tries to connect to a uPortal server for up to two times. Generally, no link
problem exists.)

CloudEC
Generally, uPortal interworking problems are caused by incorrect configurations. Check
related configurations based on the network requirements.
If network problems occur or the uPortal service crashes, corresponding environment alarms
will be generated in the HUAWEI Operation & Maintenance System.
Procedure
Step 1 Verify that the IP address of the eServer is added to the whitelist on the uPortal.
Step 2 Verify that USM Address is correctly set on the Interconnection > USM Interconnection
page of the BMU. If a DNS server is used, check related configurations.
Step 3 Verify that the uPortal interworking IP address configured on the BMU matches the token
addressing mode configured on the uPortal. Currently, you cannot set the uPortal interworking
IP address to an IP address while setting the token addressing mode to domain name.
Step 4 Check related environment alarms in the HUAWEI Operation & Maintenance System.
----End
1.7.1.3 SIP Registration Fault
Symptom
A terminal fails to register with the USM.
Possible Causes
l Registration messages of the terminal are not sent to the USM.
l The registration function of the USM is faulty.
l The terminal is deregistered because the user logs in to another terminal.

l The number is not deregistered after being unbound from a terminal.
l Verify that the network is connected.
l Check the registration error code returned by the USM.
l Verify that the user has not logged in to another terminal.
l Check whether the number is successfully unbound from another terminal.
Procedure
1. Log in to the HUAWEI Operation & Maintenance System and click the Maintenance
tab.
2. Enable message tracing. (Select all messages including the registration message, which
is deselected by default.) Initiate registration on the terminal and check whether
registration messages are traced.
– Yes: Go to 3.

CloudEC
– No: Verify that the network is connected.

3. Obtain the error code returned by the USM for registration messages of the terminal.
Analyze the error code and warning information returned by the USM by referring to the
USM error code manual.
4. Check whether the user has logged in to another terminal.
If the USM returns error code 200, check whether the USM returns registration messages
for the same number from another address. If yes, the user has logged in to another
terminal.
5. Check whether the number is registered by another terminal.
If the USM returns 403 to the terminal registration message, the number is not
deregistered after being unbound from another terminal. To deregister the number,
perform the following steps:
– If the original terminal bound to the number can be found, deregister the number on
the terminal.
– If the original terminal bound to the number cannot be found, run the CNL
URCNL: TYPE=IMPU, IMPU="sip:user1@home1.com"; command on the
CSC to deregister the number.
1.7.2 Voice Faults
1.7.2.1 Announcement Playing Faults
1.7.2.1.1 Announcement Playing Fault Rectification Method
Symptom
l A user fails to hear the announcement.
l The announcement heard by the user is different from the expected announcement.
l The voice quality is poor.
l The user fails to schedule a conference.
l The user fails to participate in a conference.
Possible Causes
l A user fails to hear the announcement.
– The AS does not apply for the announcement.
– The MRFP fails to collect digits.
– The MRFP does not load the voice file.
– The MRFP resources are insufficient.
– The MRFP language type is configured improperly.
– The network between the terminal and the MRFP is faulty.
– The calling party hears repeat announcements indicating call failure when calling a
user in the CS domain.
l The announcement heard by the user is different from the expected announcement.
– The AS applies for an incorrect announcement.

CloudEC
– The announcement playing file is not recorded properly.

– The network quality between MRFP and the terminal is poor.
– The network quality between the MRFP bearer gateway and the terminal is poor.
l The user fails to schedule a conference.
– MRFP resources are insufficient.
– The terminal capacity cannot support the service.
l The user fails to participate in a conference.
– MRFP resources are insufficient.
– The terminal codec type does not meet the requirements that are specified when the
conference is scheduled.
A user needs to locate the faulty NE to rectify the announcement playing failure.
If a user fails to hear the expected announcement, the troubleshooting procedure is shown in
Figure 1-115.

CloudEC
Figure 1-115 Troubleshooting procedure for the failure in hearing the announcement
NOTE
Perform the following steps to locate the NE where the announcement playing fails:
l Determine whether the AS receives an INVITE 200 OK message.
l Determine whether the AS receives an INFO 200 OK message (XML contained in the message
carries result response ="200").
l Determine whether the AS receives an INFO message from the MRFC indicating the announcement
playing failure.

CloudEC
If the announcement is different from the expected announcement, the troubleshooting

procedure is shown in Figure 1-116.
Figure 1-116 Troubleshooting procedure for wrong announcement
For poor voice quality, check the network quality between MRFP and the terminal, and the
network quality between the MRFP bearer gateway and the terminal.
For the failure in scheduling a conference, check whether the MRFP resources are sufficient
and the terminal supports the conference function.
For the failure in participating in a conference, check whether the MRFP resources are
insufficient and the terminal codec type is set properly.
Procedure
Check the alarms.
1. Huawei maintenance engineers need to check whether the announcement alarms are
displayed on the HUAWEI Operation & Maintenance System. For details, see Alarm
Browsing.
Alarms of the announcement playing failure are shown in Table 1.
Homing ME Related Alarms

of Alarms
AS ALM-20030 All Links Disconnected in a DNS Server
ALM-20031 A Link Between USM and DNS Disconnected
ALM-20053 Disconnection of the USM from the S-CSCF or MRFC
CSCF ALM-10705 All Links Between MRFC and DNS Disconnected
ALM-10704 Link Between MRFC and DNS Disconnected
ALM-10703 HTTP or HTTPS Connection Faulty

CloudEC
Homing ME Related Alarms

of Alarms
ALM-11000 H.248 SCTP Link Failure
ALM-11002 H.248 SCTP Link Congestion
ALM-11004 MGW Out Of Service
MRFP ALM-125156 ARP Probe Failure
ALM-61510 H.248 signaling link fault
ALM-63003 VPU Media resource overload
– Yes: Rectify the fault by following the handling procedures of alarms and go to 2.
– No: Go to 3.
2. Check whether the fault has been rectified.
– Yes: The alarm handling is complete.
– No: Go to 3.
3. Rectify the fault according to the fault symptom.
– A user fails to hear the announcement: Go to 4.
– The announcement heard by the user is different from the expected announcement:
Go to 9.
– The voice quality is poor: For details, see 1.7.2.1.3 MRP Announcement Playing
Fault.
– The user fails to schedule a conference: For details, see MRP Announcement
Playing Fault.
– The subscriber fails to participate in a conference: For details, see MRP
Announcement Playing Fault.
4. Create a message tracing tack on the AS to check whether the AS sends the INVITE
message of an announcement request.
NOTE
The Subscriber IMPU message trace task can be created by referring to Creating a Tracing Task. If
the failure reoccurs after the message trace task is created, check whether the AS sends the
INVITE message of the announcement according to the message tracing information.
– Yes: Go to 5.
– No: The AS announcement playing failure occurs.
5. Check whether the non-direct connection mode is used between the AS and the MRFC.
Log in to the HUAWEI Operation & Maintenance System, and open the MML
Command - USM window. Run LST MRFMODE to check whether the Connection
mode is DIRECT.
6. Check whether the AS receives an INVITE 200 OK message for the request of
announcement playing.
– Yes: Go to 7.
– No: The MRFP announcement playing failure occurs. For details, see MRP6600
Announcement Playing Failure.

CloudEC
7. Check whether INFO 200 message received by the AS is correct.

Check whether xml contained in the INFO 200 message carries result response ="200".
NOTE
If the MRFP announcement playing fails, an INFO 200 message can be returned. However, the
message does not carry result response ="200". The cause value varies according to different
reasons.
– Yes: Go to 8.
– No: The MRFP announcement playing failure occurs. For details, see MRP6600
8. Check whether the AS receives an INFO message from the MRFC indicating the
announcement playing failure after sending an INFO 200 message.
– Yes: The MRFP announcement playing failure occurs. For details, see MRP6600
– No: Go to 9.
9. Perform the message trace on the AS to check whether the announcement URI is proper
in the INFO message sent from the AS to the MRFC.
NOTE
The Subscriber IMPU message trace task can be created by referring to Creating a Tracing Task. If
the failure reoccurs after the message trace task is created, check whether the announcement URI
is correct in the INFO message sent from the AS to the MRFC.
Check the announcement URI of the INFO message.
– Yes: The MRFP failure occurs. For details, see MRP6600 Announcement Playing
Failure.
– No: The AS failure occurs.
– No: Go to 11.
11. Contact Huawei technical support engineers.
1.7.2.1.2 Service Announcement Playing Fault
Symptom
l The AS fails to send the announcement request message.
l The AS applies for an incorrect announcement.
Possible Causes
l The AS fails to send the announcement request message.
– The DNS is not configured properly.
– In the non-direct connection mode, the S-CSCF route address is not configured
between the AS and the MRFC.
– The announcement data is not configured.
l The AS applies for an incorrect announcement.
A user performs an incorrect service operation.

CloudEC
Figure 1-117 Troubleshooting procedure for the AS announcement request failure
For the troubleshooting of the wrong announcement, check whether the service operation is
correct.
Procedure
1. Determine the troubleshooting procedure based on the failure type:
– The AS fails to send the announcement request message: Go to2.
– The AS applies for an incorrect announcement: Go to 18.

CloudEC
2. Check whether the MRF address is set to a domain name.

Log in to the HUAWEI Operation & Maintenance System, and open the MML
Command - USM window. Run LST MRF to check whether the value of MRF
address type is Domain Name.
%%LST MRF:;%%
The result is as follows:

-------------------------
MRF name = MRF_0
MRF address type = Domain Name
IP address = NULL
MRF domain name = mrfc.example.com
MRF IP mode = ACTIVE
MRF description = NULL
Record address = file://provisioned
Record name = RECORD
Maximum record duration = 600
Terminal key = NUMBER #
Clear data buffer flag = TRUE
Break by key flag = TRUE
S-CSCF Route Address = NULL
MRF TYPE = MSML1.1
Record codec = CODEC_PCMA
Reserved = 0
--- END
– Yes: Go to 3.
– No: Go to 9.
3. Rectify the fault according to the DNS server type.
– Embedded DNS: Go to 6.
– External DNS: Go to 4.
4. Log in to the HUAWEI Operation & Maintenance System, and open the MML
Command - USM window. Run DSP DNSLNK to check whether Link status is Link
state ok.
%%DSP DNSLNK:;%%

-------------------------
DNS server name = DNSSERVER
DNS link name = DNSLINK
DNSlink state = Linkstate ok
– Yes: Go to 8.
– No: Go to 5.
5. Run LST DNSLNK to check whether the DNS configuration record is correct. Check
whether Local port number, Peer IP and Peer port number are consistent with the
planned parameters. Run LST DNSLNK. The result is as follows:
%%LST DNSLNK:;%%

-------------------------
DNS link name = DNSLINK
DNS server name = DNSSERVER
DNS server group name = DNSGROUP

CloudEC
BSG module number = 23

Protocol type = TCP protocol
Recursion flag = No
Address type = IPV4
Local IP = 10.12.13.102
Localport number = 3999
Peer IP = 10.12.22.13
Peerport number = 19005
--- END
– Yes: Go to 8.
– No: Run RMV DNSLNK to remove the DNS configuration record. Then run ADD
DNSLNK to add the DNS service information as required. Go to 7.
6. Check whether the embedded DNS is configured properly. For details, see Embedded
DNS Failure of the USM.
– No: Go to 8.
Run LST MRFMODE to check whether the value of Connection mode is INDIRECT.
%%LST MRFMODE:;%%

-------------------------
MRF mode index = 0
Connection mode = DIRECT
Support option = NOT SUPPORT OPTION
--- END
– Yes: Go to 20.
– No: Go to 10.
Run LST MRFMODE to check whether the value of Connection mode is INDIRECT.
%%LST MRFMODE:;%%

-------------------------
MRF mode index = 0
Connection mode = DIRECT
Support option = NOT SUPPORT OPTION
--- END
– Yes: Go to 10.
– No: Go to 13.
10. Check whether the S-CSCF route address is configured.
Run LST MRF to check whether the value of S-CSCF Route Address is NULL.
%%LST MRF:;%%

-------------------------

CloudEC
MRF name = MRF_01

MRF address type = Domain Name
IP address = NULL
MRF domain name = mrfc.example.com
MRF IP mode = ACTIVE
MRF description = NULL
Record address = file://provisioned
Record name = RECORD
Maximum record duration = 600
Terminal key = NUMBER #
Clear data buffer flag = TRUE
Break by key flag = TRUE
S-CSCFRoute Address = NULL
MRF TYPE = MSML1.1
Record codec = CODEC_PCMA
Reserved = 0
--- END
– Yes: Go to 11.
– No: Go to 13.
11. Run MOD MRF to configure the S-CSCF route address.
– No: Go to 13.
13. Create a message trace task on the AS to record the cause value contained in the Oxx
message received by the AS indicating the announcement playing failure. A 183
message is as follows:
%%LST IPRT:;%%

-------------------------
IFM module number = 52
Address type = IPV4
IP address = 10.11.9.130
Subnet mask = 255.0.0.0
--- END
14. Check whether the announcement playing failure is on the MO side.

– Yes: Go to 15.
– No: Go to 18.
15. Run LST CVTOTID to check whether the failure processing data is configured.
The command output is as follows:
%%LST CVTOTID:;%%

-----------
Causevalue Cause in reason header Release position Tone ID Tone group
number
1236 65534 65534 15 65534

1237 65534 65534 15 65534
......
65534 8 65534 25 65534
65534 17 65534 8 65534
......

CloudEC
According to the cause value recorded in 13, locate the record corresponding to Cause in
reason header. Check whether Cause value is set to 65534.
– Yes: Go to 16.
– No: Go to 20.
16. Check whether the value of Tone ID is the same as data planning.
– If the parameter is not specified, specify this parameter by referring to Configuring
Announcement Data: Go to 17.
– If the parameter is specified incorrectly, modify the configuration of this parameter
by running MOD CVTOTID: Go to 17.
– The parameter is specified correctly: Go to 20.
– No: Go to 20.
18. Check whether the service operation is correct.
NOTE
Check whether the service operation is correct according to the relevant feature description after
understanding the used service. For example, a user wants to deactivate the CFU service.
However, another announcement is heard due to the wrong access code.
– Yes: Go to 20.
– No: Perform the operation based on the correct method, and then go to 19.
– No: Go to 20.
1.7.2.1.3 MRP Announcement Playing Fault
Symptom
If any of the following conditions exists, it indicates that the announcement playing failure in
the MRP6600 has occurred.
l Announcement playing fails.

l Digit collecting fails.
l Users cannot hear voice.
Possible Causes
l If announcement playing fails, the possible causes are as follows:
– Tone materials do not exist.
– The announcement playing failure in the network file server (NFS) is caused by
incorrect link configuration of the NFS server.
l If digit collecting fails, the possible causes are as follows:
– The IP network between the MRFP and the terminal failed.

CloudEC
– The RFC2833 digit collecting terminal does not carry the attribute defined in
RFC2833.
– The value of RFC2833 PayloadType is incorrect, or RFC2833 PayloadType is not
carried.
– Dual tone multi-frequency (DTMF) digit collecting operations are performed for
non-G.711 users.
l If users cannot hear voice, the possible cause is as follows:
– The IP network between the MRFP and the terminal failed.
l If the voice quality is poor, the possible causes are as follows:
– The quality of the network between the MRFP and the terminal is poor.
– The quality of the network between the gateway connected to the bearer interface of
the MRFP and the terminal is poor.
Figure 1-118 shows the troubleshooting procedure for the announcement playing failure in
the MRFP.
Figure 1-118 Troubleshooting procedure for the announcement playing failure

CloudEC
Procedure
1. Check the failure symptom
Failure Description Operation Step
Symptom
Announce The announcement playing failure 2

ment causes users to fail to hear voice.
playing Rectify the signaling fault.
fails.
Digit The digit collecting failure causes 11

collecting users to fail to hear voice. Rectify
fails. signaling and bearer fault.
Users Rectify the bearer fault. 18

cannot hear
any voice.
The voice Rectify the bearer fault. 21

quality is
poor.
2. Log in to the HUAWEI Operation & Maintenance System.

3. Create a call trace task and an internal trace task.
a. Enter the trace interface.
In the HUAWEI Operation & Maintenance System window, click the
Maintenance tab. Choose Service Navigation > Trace > MRP6600. Expand
CMU TRACE, and then double-click CALL to create a call message trace task.
See Figure 1-119.
Figure 1-119 Creating a call trace task
b. Create an H.248 trace task.

In the CALL Tracing dialog box, set Trace Type to the default value H248. Then,
click OK. See Figure 1-120.

CloudEC
Figure 1-120 Creating an H.248 trace task
c. Create an internal trace task.

In the CALL Tracing dialog box, set Trace Type to INTERNAL. Then, click OK.
See Figure 1-121.

CloudEC
Figure 1-121 Creating an internal trace task
4. Check whether the MRFP receives H248_ADD_REQ and H248_MOD_REQ messages,

and whether the MRFP transmits H248_ADD_RESP, H248_MOD_RESP, and
H248_NOTIFY_REQ messages.
Figure 1-122 shows the H.248 messages in the trace task.
Figure 1-122 H.248 messages in the trace task
a. Check whether the MRFP receives H248_ADD_REQ or H248_MOD_REQ

messages.
n Yes: Go to 4.2.

CloudEC
n No: Rectify the fault according to Interworking Failure of the MRP6600

(MRFP).
b. Check whether the MRFP transmits H248_ADD_RESP, H248_MOD_RESP, or
H248_NOTIFY_REQ messages.
n Yes: Go to 5.
n No: Go to 26.
5. Check whether the response messages or reported messages of the MRFP carry error
codes and error texts.
Use H248_MOD_RESP as an example. Click the H248_MOD_RESP message as
shown in Figure 1-123. Then, check for the error code and text carried in the
H248_MOD_RESP message. See Figure 1-124.
NOTE
The H248_NOTIFY_REQ message shown in Figure 6 is not used to return an error code but to
report a failure event. For details about the message, see Figure 1-125.
Figure 1-123 H.248 messages in the trace task
Figure 1-124 Error in the H248_MOD_RESP message

CloudEC
Figure 1-125 Initiative reported message
– Yes: Go to 6.
– No: Go to 26.
6. Check the type of the message that carries the error code and error text.
– H248_ADD_RESP: Go to 7.
– H248_MOD_RESP: Go to 8.
– H248_NOTIFY_REQ: Go to 9.
7. Check the error code and error text carried in the H248_ADD_RESP message.
– If errorCode is 455 and errorText is Property illegal in this Descriptor, go to 26.
– If errorCode is 501 and errorText is Not Implemented. Remote codec
unsupported, check whether codecs that the MRFP does not support are
configured on the MRFC. For details, see Check the configuration of gateway
resources.
– If errorCode is 625 and errorText is license out of range. Out of License
Range(Item:AUDIO-CVT CHN), determine the license items to be applied for
according to License Control Item Description and then see the License Operation
Guide released with the version software to apply for a license.
– If errorCode is 510 and errorText is Insufficient resources.Out of IP resource,
go to 7.a.
– If errorCode is 500 and errorText is Internal software failure in the MG.
Receive error response message from HRU:M93,E78, go to 7.h.
– If errorCode is 500 and errorText is not Internal software failure in the MG.
Receive error response message from HRU:M93,E78, go to 26.

CloudEC
NOTE
Item:AUDIO-CVT CHN in the error description indicates the restricted license item. Mapping of
the restricted license items is as follows:
l AUDIO-PLAY CHN: number of AudioPlay channels
l AUDIO-CONF CHN: number of AudioConference channels
l VMRFP SUM: number of Virtual MRFP
l WBAMR CHN: number of WB-AMR codec channels
l ILBC CHN: number of ILBC codec channels
a. In the MML Command - MRP6600 window, run LST MEDADDR to check

whether IPv4 gateway in the command output is correct.
If the command is successfully executed, the command output example is displayed
as follows:
%%LST MEDADDR: ADDRNAME="MEDADDR";%%

------------------------
Media address name = MEDADDR
HRU module No. = 451
Main interface name = ethif_med
Address type = IPV4
IPv4 address = 192.168.150.10
IPv4 address mask = 255.255.255.0
IPv4 gateway = 192.168.150.1
IPv6 address = NULL
IPv6 prefix length = 0
IPv6 gateway = NULL
Audio packet protocol type = DSCP
Audio packet IPQOS value = NULL
--- END
NOTE
The preceding output is used as an example to analyze the gateway resolution status (IPv4
gateway column) of each IPv4 address.
l The interface with IPv4 address set to 10.0.0.1 is a loopback interface. You do not need
to pay attention to the resolution status of the gateway address of the loopback
interface.
l If a gateway address is displayed in the IPv4 gateway column mapping to the IPv4
address column, the gateway address is successfully resolved.
l If - is displayed in the IPv4 gateway column mapping to the IPv4 address column, the
gateway address fails to be resolved
n Yes: It indicates that the gateway address mapping to the interface can be
resolved and that the link between the interface and the gateway is normal. In
this case, go to 7.c.
n No: It indicates that the gateway address corresponding to the interface cannot
be resolved. In this case, go to 7.b.
b. Troubleshoot the interworking failure according to Interworking Failure of the
MRP6600 (MRFP). Then, check whether the announcement playing failure has
been rectified.
n No: Go to 7.c.
c. Check whether bearer interfaces are reserved.

CloudEC
Run LST RSVPORT to check whether Start port is 0 and whether End port is
65535.
n Yes: Go to 7.d.
n No: Go to 7.f.
d. Cancel the bearer interface reservation.
Run RMV RSVPORT to cancel the bearer interface reservation. Then, check
whether the announcement playing failure has been rectified.
n Yes: Go to 7.e.
n No: Go to 7.f.
NOTE
You can run ADD RSVPORT to reserve only certain interfaces at a site. If all
interfaces are reserved, bearer channels fail.
e. Check whether the NFS server plays an announcement.
n Yes: Go to 7.f.
n No: Go to 8.
f. Run DSP FSSTS to check whether FS status is Enable.
If the command is successfully executed, the command output example is displayed
as follows:
%%DSP FSSTS:;%%

------------------------
File server name VPU module No. FS status
FS0 651 Enable

FS1 651 Enable
FS2 651 Enable
FS0 652 Enable
FS1 652 Enable
FS2 652 Enable
--- END
n Yes: Go to 26.
n No: Go to 7.g.
g. Troubleshoot the interworking failure according to Interworking Failure of the
MRP6600 (MRFP). Then, check whether the announcement playing failure has
been rectified.
n No: Go to 26.
h. Check whether the peer device uses an odd port number.
Check whether the port number carried in remoteDescriptor of the message is an
odd number.
n Yes: Go to 7.i.
n No: Go to 26.
Figure 1-126 shows an example message.

CloudEC
Figure 1-126 Checking the port number used by the peer device
i. Change the port number used by the peer device to an even number.
j. Check whether the announcement playing failure has been rectified.
n No: Go to 26.
8. Check the error code and error text carried in the H248_MOD_RESP message.
– If errorCode is 455 and errorText is Property illegal in this Descriptor, go to 26.
– If errorCode is 501 and errorText is Not Implemented. Remote codec
unsupported, check whether codecs that the MRFP does not support are
configured on the MRFC. For details, see Check the configuration of gateway
resources.
– If errorCode is 625 and errorText is license out of range.Out of License
Range(Item:AUDIO-CVT CHN), see the License Control Item Description
released with the version software to apply for a license.
– If errorCode is 602, go to Commissioning the Interworking Between the MRP6600
and a File Server.
– If errorCode is 605, go to 8.a.
– If errorCode is 500 and errorText is Internal software failure in the
MG.TdSubMsg:M218,E13318, go to 8.c.
– If errorCode is 510, go to 10.f.
a. Check the language type.
In the MML Command - MRP6600 window, run LST LANGTYPE to check
whether Language type string is the language type carried in the
H248_MOD_REQ message. See Figure10 Language type carried in the
H248_MOD_REQ message.
Figure 1-127 Language type carried in the H248_MOD_REQ message

CloudEC
If the command is successfully executed, the following command output is

displayed:
%%LST LANGTYPE:;%%

------------------------
Language type string Language type ID
en 1
zh 2
n Yes: Go to 26.
n No: Go to 8.b.
b. Specify the language type.
In the MML Command - MRP6600 window, run ADD LANGTYPE to set the
language to the planned one. Then, check whether the announcement playing failure
has been rectified.
n No: Go to 26.
c. Check whether the voice file is absent.
i. Check the var field in the H248_MOD_REQ message. This section uses the
H248_MOD_REQ message in a fixed intelligent network (IN) tone as an
example. The var field contains information such as language type string, tone
ID, and tone type, as shown in Figure11 var field in the H248_MOD_REQ
message.
Figure 1-128 var field in the H248_MOD_REQ message
NOTE
The information contained in the var field is described as follows:

l t=tone: The tone type is fixed IN tone.
l tid=298: The tone ID is 298.
l lang=en: The language type string is en.
ii. In the MML Command - MRP6600 window, run LST LANGTYPE with
Language type string set to the language type string in the var field in the
H248_MOD_REQ message and check the value of Language type ID in the
command output. If the command is successfully executed, the following
command output is displayed:
%%LST LANGTYPE: LSTRING="en";%%

------------------------
Language type string = en
Language type ID = 1
Language type description = NULL

CloudEC
--- END
iii. In the MML Command - MRP6600 window, run DSP TONEFILE with
Language type ID set to the language type ID obtained in 8.c.ii, and VPU
module No. set to 651. Then check whether the command output contains a
record where the values of Tone ID and Tone type are the same as those in the
var field.
displayed:
%%DSP TONEFILE: VPUMID=651, CODEC=AMR, AMRRATE=AMR_RATE_4_75;%%

------------------------
VPU module No. = 651
Version = MRP6600V500R008C00
Timestamp = 2014-07-22 11:01:33
Codec = AMR
Rate = 4.75kbps
Number of tones = 2
Number of this language = 2
The result is as follows1

-------------------------
Language type ID Service type Tone ID Tone type
1 0 0 fix
1 0 1 fix
--- END
○ Yes: Go to 26.
○ No: Go to 8.d.
d. Re-create a tone package according to service requirements. For details, see
Creating MRFP Static Tone Files and Creating MRFP Local Media Files. Then,
load the tone package. For details, see Loading MRFP Tone Files.
Then, check whether the announcement playing failure has been rectified.
n No: Go to 26.
9. Check whether the error code 616 is carried in the H248_NOTIFY_REQ message. See
Figure 1-123.
– Yes: Go to 10.
– No: Go to 26.
Check the cause why the error code 616 is carried in the H248_NOTIFY_REQ message.
10. Check the location of the announcement playing file.
a. Check the location of the announcement playing file delivered in the
H248_MOD_REQ message. SeeFigure12 File placing in the NFS server
andFigure13 File placing in the MRFP

CloudEC
Figure 1-129 File placing in the NFS server
Figure 1-130 File placing in the MRFP
n LOCAL: Go to 10.b.
n FILE: Go to 10.d.
b. In the MML Command - MRP6600 window, run DSP LOCALFILE to check
whether the announcement playing file specified in the H248_MOD_REQ message
is the file specified by Filename. See Figure 1-134.
displayed:
%%DSP LOCALFILE: VPUMID=652, CODEC=AMR, AMRRATE=AMR_RATE_4_75;%%

------------------------
VPU module No. = 652
Version = MRP6600V500R008C00
Timestamp = 2014-07-22 14:45:50
Codec = AMR
Rate = 4.75kbps
Number of tones = 2

------------------------
Size(Byte) Filename
181784 local://wav2/048.wav
110448 local://wav2/049.wav
--- END
Yes: Go to 10.f.
n No: Go to 10.c.
c. In the MML Command - MRP6600 window, run LOD LOCALFILE to add the
required file. Then, check whether the announcement playing failure has been
rectified.
n No: Go to 10.f.
d. Log in to the NFS server.
Log in to the NFS server in Secure Shell (SSH) mode by using the PuTTY tool.
For details on how to use the PuTTY tool, see Using the PuTTY.
Figure 1-131 shows the location of the announcement playing file specified in the
H248_MOD_REQ message.

CloudEC
Figure 1-131 H248_MOD_REQmessage
n Enter the user name root for login as, and press Enter.
n Enter the password huawei for password, and press Enter.
n Enter cd /directory holding the file to access the directory.
Check whether the announcement playing file exists in the directory.
n Yes: Go to 10.f.
n No: Go to 10.e.
e. Upload the announcement playing file to the NFS server according to steps in under
Installation and Commissioning > Initial Configuration > Configuring the
Basic Data > Configuring the Interworking Data > Configuring the Built-in
NFS of the OSG9930 Product Documentation. Then, check whether the
announcement playing failure has been rectified.
n No: Go to 10.f.
f. Check the usage of the configured codec resources.
Run DSP MRSTS in the MML Command - MRP6600 window to view codec
resource information about Total resource capability, Idle resource capability,
and Fault resource capability.
n If Total resource capability is 0, go to 26.
n If Idle resource capability is 0, go to 26.
n If Fault resource capability is greater than or equal to 20% of Total resource
capability, go to 26.
g. Check whether the announcement playing failure is rectified.
n No: Go to 26.
11. In the MML Command - MRP6600 window, run PING to ping the terminal's IP
address. Check whether Packet loss ratio is 0.
If the command is successfully executed, the following command output is displayed:
%%PING: IPTYPE=IPV4, IP="10.3.21.55", SRCIP="10.3.21.54";%%

------------
Local IP address = 10.3.21.54
Number of sent packets = 4
Number of received packets = 4
Maximum round time = 20
Minimum round time = 10
Average round time = 15

------------

CloudEC
Round time (ms) TTL
0 255
10 255
10 255
0 255
– Yes: Go to 13.
– No: Go to 12.
12. Rectify the fault on the IP network between the terminal and the gateway according to IP
Network Failure. Then, check whether digit collecting is successful.
– Yes: Go to 17.
– No: Go to 13.
13. Contact the technical support engineers of the terminal to check the type of the
transmitted digit.
– RFC2833 digit collecting: Go to 14.
– DTMF digit collecting: Go to 15.
14. Troubleshoot the RFC2833 digit collecting failure.
a. Contact the network administrator to check whether packet loss occurs on the
bearer network.
n Yes: Go to 14.b.
n No: Go to 14.c.
b. Rectify the fault on the IP network between the terminal and the gateway according
to IP Network Failure. Then, check whether the digit collecting failure has been
rectified.
n Yes: Go to 17.
n No: Go to 14.c.
c. Check whether the H248_ADD_REQ message received by the MRFP carries the
attribute defined in RFC2833. See Figure15 Content of theH248_ADD_REQ
message.

CloudEC
Figure 1-132 Content of theH248_ADD_REQ message
n Yes: Go to 14.d.
n No: Go to 26.
d. Check whether the value of RFC2833 PayLoadType carried in the
H248_ADD_REQ message received by the MRFP is the same as that of RFC2833
PayLoadType carried in the bearer message transmitted by the terminal.
n Capture the IP packets transmitted to the MRFP, and then identify the IP
packets that are transmitted by the terminal. Select the RFC2833 packets. The
Payload type=RTP Event is RFC2833 packets. See Figure 16. Figure 17 shows
the contents of the RFC2833 packets.
Figure 1-133 RFC2833 packets

CloudEC
Figure 1-134 Contents of theRFC2833 packets
Check whether the value of RFC2833 PayLoadType carried in the

H248_ADD_REQ message received by the MRFP is the same as that of RFC2833
PayLoadType carried in the bearer message transmitted by the terminal.
n Yes: Go to 14.e.
n No: Contact technical support engineers of the terminal.
e. Check whether the RFC2833 packets comply with telecommunications standards.
The following requirements are defined by the standards of telecommunications
networks:
n Each digit must correspond to at least one RFC2833 packet that carries the end
flag.
n The timestamps of all RFC2833 packets for the same digit must be the same.
Figure 1-135 RFC2833 packets

CloudEC
Figure 1-136 Contents of theRFC2833 packets
Check whether the RFC2833 packets transmitted by the terminal comply with RFC
2833 telecommunications standards. See Figure 1-135 and Figure 1-136.
n Yes: Go to 14.f.
n No: Contact technical support engineers of the terminal.
f. Check whether the timestamps of all RFC2833 packets for two identical
consecutive digits are the same. Figure 19 shows the timestamps of the RFC2833
packets.
n Yes: Contact technical support engineers of the terminal.
n No: Go to 26.
15. Check whether the voice codec used by the terminal is G.711.
Check whether the value of the field marked with red in the H248_ADD_RESP message
is 0 or 8 (G.711μ or G.711A).
Figure 1-137 H248_ADD_RESPmessage
– Yes: Go to 26.
– No: Go to 16.
16. Troubleshoot the DTMF digit collecting failure of non-G.711 users.
DTMF digit collecting is not supported by non-G.711 users. You need to contact
technical support engineers of the terminal to change the codec used by the terminal or
apply for RFC2833 digit collecting. Then, check whether the digit collecting failure has
been rectified.

CloudEC
– Yes: Go to 17.
– No: Go to 26.
17. Check whether the announcement playing failure has been rectified.
– No: Go to 26.
The result is as follows(0)

---------------------------

---------------------------
Round time (ms) TTL
0 255
10 255
10 255
0 255
– Yes: Go to 26.
– No: Go to 19.
19. Rectify the fault on the IP network between the terminal and the gateway according to IP
Network Failure. Then, check whether the users can hear voices.
– Yes: Go to 20.
– No: Go to 26.
– No: Go to 26.

---------------------------

CloudEC

---------------------------
Round time (ms) TTL
0 255
10 255
10 255
0 255
– Yes: Go to 22.
– No: Go to 24.
22. Capture the IP packets transmitted to the MRFP, and then identify the IP packets that are
transmitted by the terminal. Check whether the Lost RTP packets value is 0.
– Yes: Go to 23.
– No: Go to 24.
23. Check whether the network jitter is within the jitter range allowed by the MRFP.
– Yes: Go to 26.
– No: Go to 24.
24. Rectify the fault on the IP network according to IP Network Failure. Then, check
whether the voice quality is good.
– Yes: Go to 25.
– No: Go to 26.
– No: Go to 26.
1.7.2.1.4 A Participant Tries Joining a Conference Using IVR But Is Prompted the Call
Ends
Symptom
When the USM and MRP are deployed separately, the MRP is interconnected with the NFS
properly and plays announcements properly.
After the USM is redeployed and NFS connection is configured, the FS is available, but it
fails to play announcements. A message is displayed, indicating that the announcement file
does not exist. In fact, the announcement file can be queried on the server.
Possible Causes
The MRP mounting is abnormal. As a result, announcements fail to be played due to a link
fault.
In the scenario where the USM and MRP are deployed separately, if the link between the
USM and MRP is abnormal after the USM is redeployed, you can restart the MRP.

CloudEC
Solution
Step 1 Log in to the Huawei Operation & Maintenance System as the admin user and access the
MML Command - CGP window.
Step 2 Run the RST ME command by setting ME IDto the ID of the MRP6600 NE to restart the
MRP.
NOTE
To query the ID of the MRP6600 NE, run the LST ME command.
----End
1.7.2.2 Recording Failure
Symptom
Recording fails.
Possible Causes
l The number of concurrent recording channels reaches or exceeds the number of
concurrent recording ports supported by the license.
l MRP resources are insufficient.
l The NFS is disconnected.
l The NFS disk space is insufficient.
l The NFS is overloaded in input/output (I/O).
l Other NFS faults occur, such as a rights-related fault.
l Log in to the NMS and check whether the following alarms exist:
– ALM-20002 License Resource Number Reaching/Beyond Pre-Alarm Threshold
– ALM-108125 Idle Media Resource not enough
– ALM-10032 Connection Between the UPortal and File Server Abnormal
l Log in to the NFS and check related configurations, such as the free disk space, server
performance, and permission on the shared folder.
Procedure
Step 1 If ALM-20002 License Resource Number Reaching/Beyond Pre-Alarm Threshold exists,
too many users are recording calls concurrently. Assign recording service right properly and
revoke the recording right from unnecessary numbers to reduce the number of concurrent
recording channels. Alternatively, apply for a license that supports a higher number of
concurrent recording channels.
Step 2 If ALM-108125 Idle Media Resource not enough exists, ask users to record calls when
there are idle media resources. If media resources become insufficient frequently, you are
advised to expand the MRP capacity.
Step 3 If ALM-10032 Connection Between the UPortal and File Server Abnormal exists, rectify
the fault by referring to the solution for the alarm.

CloudEC
Step 4 Check the free disk space of the NFS. If the disk space is insufficient, periodically delete
recording files from the NFS or expand the NFS capacity.
Step 5 Check the input/output operations per second (IOPS) of the NFS. The IOPS of the NFS must
be greater than or equal to the number of concurrent recording channels supported by the
license multiplied by 6.
Step 6 Check the USM and file server configurations. For details, see "Recording > Feature
Configuration" in the Feature Guide.
----End
1.7.3 Service Provisioning Faults
1.7.3.1 Web-based Service Provisioning Fault
Symptom
Service provisioning fails on uPortal pages.
For example, recording rights fail to be configured, and the system prompts you to check the
file server configuration.
Figure 1-138 Failed to configure recording rights
Possible Causes
The configuration is incorrect.
Check the configuration as prompted.

CloudEC
Procedure
Step 1 If there is specific error description about the service provisioning fault, check the
configuration as prompted.
For example, check the file server configuration as prompted for a recording rights
configuration failure.
Step 2 If there is no specific error description, collect error logs and check the logs for the specific
cause.
Log in to the HUAWEI Operation & Maintenance System and run the GET LOG command
under the USM NE by setting the log type to run log. After the command is executed, use the
HUAWEI Operation & Maintenance System to download log files. For details, see the
command reference. Focus on the log files for the PMU.
Figure 1-139 Running the GET LOG command
----End
1.7.3.2 Exceeded Authorized Values During Service Provisioning
Symptom
When you perform service provisioning for a resource item on the uPortal, a message is
displayed indicating that the resource item exceeds the authorized value.
For example, when you create numbers, the number quantity exceeds the authorized value.

CloudEC
Figure 1-140 Message indicating that the number quantity exceeds the authorized value
Possible Causes
The license file is not loaded or license resources are insufficient.
Verify that the resource item does not exceed the limit based on the organization to which the
resource item belongs.
Procedure
Step 1 Check whether the license file is loaded. If no, obtain and upload the license file.
Step 2 Check whether the existing resource item is close to the limit specified in the license. If the
license does not meet the current requirements, apply for a license file that supports more
resources and loads the license file.
----End
1.7.3.3 Service Provisioning on the uPortal Occasionally Fails
Symptom
During service provisioning on the uPortal, the BMU fails to be connected occasionally.
Possible Causes
The MAC address segments configured in different OMU systems during CGP installation
conflict. As a result, MAC addresses of VM network ports in different OMU systems conflict.
MAC address conflict will cause abnormal packet sending and receiving through service IP
addresses of the corresponding network ports.
1. Run the DSP IPINFO command under the CGP on the LMT to query the VM network
port corresponding to the faulty IP address.
DSP IPINFO: DEPLOYTYPE=VM, VMNAME="ec_ecs_oracle_m-1", IPITERM=IP;

CloudEC
+++ CGP/*MEID:0 MENAME:Enhanced site management*/ 2018-01-02

21:19:09+08:00
O&M #341
%%DSP IPINFO: DEPLOYTYPE=VM, VMNAME="ec_ecs_oracle_m-1", IPITERM=IP;%%
IP address is as follows
------------------------
Local IP address Mask/Prefix-length Device interface
172.16.191.96 255.255.0.0 BASE1

172.17.191.96 255.255.0.0 BASE2
172.18.191.96 255.255.0.0 FABRIC1
172.19.191.96 255.255.0.0 FABRIC2
10.102.20.31 255.255.0.0 VNIC1
127.0.0.254 255.255.255.255 vn0
fe80:0000:0000:0000:0ae8:4fff:fe7d:1fca 64 BASE1
fe80:0000:0000:0000:0ae8:4fff:fe7d:1fcb 64 BASE2
fe80:0000:0000:0000:0ae8:4fff:fe7d:1fcc 64 FABRIC1
fe80:0000:0000:0000:0ae8:4fff:fe7d:1fcd 64 FABRIC2
fe80:0000:0000:0000:4ef9:5dff:fe00:1916 64 VNIC1
fe80:0000:0000:0000:4ef9:5dff:fe00:1917 64 VNIC2
fe80:0000:0000:0000:0200:00ff:fe00:0000 64 vn0
--- END
In the preceding information, the value of Device interface corresponding to
10.102.20.31 is the VM network port corresponding to the faulty IP address.
2. Run the LST VNET command under the CGP to query the MAC address of the faulty
network port based on the VM network port found in the previous step
LST VNET: VMNAME="ec_ecs_oracle_m-1", VMPORTNAME=VNIC1;
08:25:30+00:00
O&M #596
%%LST VNET: VMNAME="ec_ecs_oracle_m-1", VMPORTNAME=VNIC1;%%

------------
ME ID = 301
Virtual machine name = ec_ecs_oracle_m-1
Virtual machine port name = VNIC1
MAC address = 4C:F9:5D:00:18:E9
Location description = Host-ECS_ALLINONE/IP-10.102.20.202
Host port name = Port2
Network name = NULL
VLAN ID = 0
--- END
3. Run the LST VNET command on the LMT of another OMU system on the same layer-2
switching network, enter the MAC address found in step 2, and check whether there is
any result. If there is any result, MAC address conflict exists.
07:42:09+00:00
O&M #443
%%LST VNET: MACADDR="4C:F9:5D:00:18:E9";%%

------------
ME ID = 5
Virtual machine name = VM_CLOUDMCU
Virtual machine port name = VNIC2
MAC address = 4C:F9:5D:00:18:E9
Location description = Host-CloudMCU_Server/IP-10.102.23.204

CloudEC
Host port name = Port2

Network name = NULL
VLAN ID = 0
--- END
Solution
Step 1 Run the LST MACPOOL command under the CGPs of two OMU systems and check
whether the MAC address segment (specified by Start MAC and End MAC) of one OMU
system conflicts with that of the other OMU system.
LST MACPOOL:;
20:13:19+08:00
O&M #67
%%LST MACPOOL:;%%

------------
Start MAC = 4C:F9:5D:00:18:DA
End MAC = 4C:F9:5D:00:28:79
Sum = 4000
Free = 3924
--- END
LST MACPOOL:;
20:13:19+08:00
O&M #99
%%LST MACPOOL:;%%

------------
Start MAC = 4C:F9:5D:00:18:DA
End MAC = 4C:F9:5D:00:28:79
Sum = 4000
Free = 3900
--- END
The query result indicates that the MAC address segments configured in the two OMU
systems conflict.
Step 2 Adjust the MAC address segments based on the network data plan. To adjust the MAC
address segments, you need to re-deploy the OMU system and service NEs. Deploy the OMU
system by referring to section Installing the OMU in the corresponding product
documentation and then deploy related service NEs.
NOTE
OMU system re-deployment will cause reinstallation of all service NEs based on the OMU system and
interruption of services on all service NEs of the OMU system. Therefore, re-deploy the OMU system
during off-peak hours.
----End

CloudEC
1.7.3.4 Failure to Query the Address Book Because a Host Is Replaced
Symptom
After a host (a maximum of two USMHTTP VMs are deployed) is faulty, the address book
fails to be queried after the host is replaced.
Possible Causes
The address book data uses N+1 backup. The address book data is stored on each USMHTTP
VM, and each VM stores only part of the address book data. When two USMHTTP VMs are
faulty, some address book data may be lost or the cluster status may be abnormal.
Run the GET LOG: LT=ALL; command to obtain the run logs of all USMHTTP VMs and
check whether exception logs exist in RUNLOG\elasticsearch.
Solution
Step 1 Run the DSP SERVER command to check the host status, which is faulty.
DSP SERVER:;
22:12:16+00:00
O&M #96
%%DSP SERVER:;%%

------------------------
Host name Availability state
EC_IPT_BASE_B_Server FAULT
omu_server1 Normal
--- END

22:48:04+00:00
O&M #126
%%DSP SERVER:;%%

------------------------
Host name Availability state
EC_IPT_BASE_B_Server FAULT
EC_IPT_BASE_B_Server_BAK Normal
omu_server1 Normal
omu_server2 Normal
Step 2 Replace the faulty host board.
Step 3 After the host is replaced, run the FMT SERVER command to format the replaced host.
22:41:47+00:00
O&M #86

CloudEC
%%FMT SERVER: SERVERNAME="EC_IPT_BASE_B_Server", FORCEFMT=YES,CONFIRM=Y;%%


------------------------
Command execution phase = Resetting
--- END
Step 4 Run the DSP MODULE: DEPLOYTYPE=HOST; command to check whether all modules
on the host are running properly.
Step 5 After the query result shows that the host status is normal, run STR REDUNDANCE to
resynchronize data to the ES.
----End
1.7.3.5 Failure to Query the Address Book Because a Host Is Faulty for a Long
Time
Symptom
The address book fails to be queried because a host (a maximum of two USMHTTP VMs are
deployed) is faulty for a long time.
Possible Causes
The address book data uses N+1 backup. The address book data is stored on each USMHTTP
VM, and each VM stores only part of the address book data. When two USMHTTP VMs are
faulty, some address book data may be lost or the cluster status may be abnormal.
Run the GET LOG: LT=ALL; command to obtain the run logs of all USMHTTP VMs and
check whether exception logs exist in RUNLOG\elasticsearch.
Solution
Step 1 Run the DSP MODULE: DEPLOYTYPE=HOST; command to check whether all modules
after host replacement are running properly.
Step 2 After the query result shows that the host status is normal, run STR REDUNDANCE to
resynchronize data to the ES.
----End
1.7.4 Conference Service Faults

Conferences on the USM use different networks based on the service scenario. Therefore,
before troubleshooting, determine whether the service scenario is on-premises or hosted.
In the on-premises scenario, the USM provides the conference control capability and
interworks with the MS to provide data and video conference capabilities. In the hosted
scenario, the MediaX provides the conference control capability, the USM only delivers
resource control operations on the MediaX to the MCU through channels.

CloudEC
In the on-premises and hosted scenarios, the USM also provides the conference routing
function. Therefore, you need to trace messages for a conference service fault to determine
whether the fault is a routing fault or a resource request fault.
1.7.4.1 Conference Routing Fault
Symptom
According to message tracing, messages for inviting external users cannot be routed to
terminals, or the USM returns exceptions to messages sent by terminals for joining
conferences.
Possible Causes
The conference routing function is faulty.
Determine the abnormal NE based on message tracing. If the USM is abnormal, local the
specific fault based on the error code.
Procedure
1. Trace IMPU messages to determine the abnormal NE.
Trace IMPU messages based on the user number to determine the NE that sends the first
exception message (such as the BYE message or an error code that is greater than or
equal to 300). If the USM is abnormal, go to the next step. If another NE is abnormal,
locate the fault by referring the help document of the NE.
2. Check the error code manual for the call failure cause.
Analyze the error code that is greater than or equal to 300 and the warning information
by referring to the USM error code manual. Obtain the cause and handling suggestion.
1.7.5 UC Service Faults
1.7.5.1 Rich Media Faults
1.7.5.1.1 Failed to Upload Rich Media Files
Symptom
Rich media files of a specified type fail to be uploaded. A message indicating a sending
failure or timeout is displayed, and no other sending status notification is displayed.
Possible Causes
The file type is added as a forbidden type in the Client Management > Client Parameters >
File transfer parameters > forbitfileext parameter on the BMU.

CloudEC
Figure 1-141 File transfer parameters
Clients receive the status code returned by the UMServer and display the corresponding
operation notification. However, if clients fail to synchronize parameter settings from the
BMU, clients cannot process the status code indicating that file transfer is forbidden.
Procedure
Step 1 Check UMServer service logs. If the message "client preupload file Type is forbiden.
fileName" is displayed, the file type is forbidden.
UMServer service log file path: /opt/eSpace_UC/eSpace_UC_Server/Logs/UMServer/
umserver.log
Step 2 If the file type is forbidden, modify the Client Management > Client Parameters > File
transfer parameters > forbitfileext parameter on the BMU to remove the file type.
----End
1.7.5.1.2 Failed to Download Rich Media Files
Symptom
Rich media files fail to be downloaded. The message "Area restriction. Some members fail to
receive messages." is displayed.

CloudEC
Figure 1-142 Area restriction 01
Figure 1-143 Area restriction 02
Possible Causes
Area restriction is configured for the areas of the sender and recipient.
Remove the area restriction configured for the areas of the sender and recipient.
Procedure
Area restriction applies to areas instead of users. The area restriction is removable in either of
the following ways:
l The recipient switches to a non-restricted area and receives the rich media files.
l Modify the area control policy.
1.7.5.2 iOS Push Function Is Unavailable
Symptom
After the eSpace Mobile is switched to the background on an iOS device, the system fails to
push messages to the eSpace Mobile.
Possible Causes
The possible causes are as follows:
l Related ports are blocked on the firewall.
l The iOS push certificate expires.
1. Check the network between the MAA and the Apple Push Notification service (APNs).
2. Verify that the iOS push certificate is valid.

CloudEC
Procedure
Step 1 Run the following commands on the MAA to check the network between the MAA and the
APNs.
ping api.push.apple.com
ping api.development.push.apple.com
NOTE
l In the preceding commands, api.push.apple.com and api.development.push.apple.com are the

domain name of the APNS.
l If the connection fails, contact the administrator to open the port 443.
Step 2 Check the iOS push certificate.

1. Log in to the BMU management system as the admin user.
2. Choose System > Push Certificate Management > iOS Service Configuration.
3. On the iOS Certificate Information tab page, view the iOS certificate information, as
If the certificate expires, obtain the latest iOS push certificate from the latest version or
patch version package.
Figure 1-144 Viewing the iOS certificate information
----End
1.8 Maintenance Faults
1.8.1 uPortal Operation Faults
1.8.1.1 Failed to Display the Web Login Page
Symptom
The web login page fails to be displayed.
Possible Causes
l The network is faulty.
l The uPortal has not started or fails to start.

CloudEC
l Verify that uPortal server is reachable through the network.
l Verify that the uPortal processes are running properly.
l Collect uPortal logs and check for obvious failure logs.
Procedure
Step 1 Use commands such as ping and telnet to check whether the network between terminals and
the uPortal server is connected. If no, rectify any network fault.
Step 2 Check whether the uPortal server is reachable from the browser through the network. Focus
on the proxy configuration on the browser. If the uPortal server is unreachable, modify the
browser configuration.
Step 3 Verify that the uPortal processes are running properly.
Log in to the HUAWEI Operation & Maintenance System, choose Device Panel > Module
Management, select the corresponding USM NE, and check the process status.
Figure 1-145 Module Management
Step 4 View run logs, check for obvious exceptions, and check related configurations based on
exception logs.
under the USM NE by setting the log type to run log.

CloudEC
Figure 1-146 Run the GET LOG command
Step 5 In the HUAWEI Operation & Maintenance System, choose Maintenance > File Transfer
Service, and download uPortal log files.
Figure 1-147 Downloading log files
----End
1.8.1.2 Web Login Failure
Symptom
When you log in to the uPortal, a message is displayed indicating that the user name or
password is incorrect or a system exception occurs.
Possible Causes
l The user name or password is incorrect.
l A system exception occurs.

CloudEC
l Verify that the user name and password are correct.
l View uPortal logs and check for obvious exceptions.
Procedure
Step 1 Verify that the user name and password are correct. If you forget the password, contact the
enterprise administrator to reset the password.
Step 2 View log files. If there are obvious exceptions, check the system configuration based on
exception information.
under the USM NE by setting the log type to run log.
Figure 1-148 Running the GET LOG command
Step 3 In the HUAWEI Operation & Maintenance System, choose Maintenance > File Transfer
Service, and download uPortal log files.

CloudEC
----End
1.8.1.3 Web Page Debugging Window Is Displayed
Symptom
The web page debugging window is displayed.
Figure 1-150 Debugging window
Possible Causes
l The browser has a compatibility issue.

CloudEC
l Characters on the web page are not defined, are invalid, or have other problems.
l Use mainstream and stable browser versions instead of outdated or unstable versions.
l Disable script debugging.
Procedure
Step 1 Use a browser of the supported version to open the page.
The uPortal supports the following browsers: Google Chrome 46.0 and later, Mozilla Firefox
41.0 and later, and Internet Explorer 9.0, 10.0, and 11.0.
Step 2 For Internet Explorer, choose Tools > Internet Options. In the Browsing area on the
Advanced tab page, select Disable script debugging (Internet Explorer) and Disable script
debugging (Other), as shown in Figure 1-151.
Figure 1-151 Internet Options dialog box
Step 3 Click OK. Restart Internet Explorer for the setting to take effect.
----End

CloudEC
1.8.1.4 Web Certificate Error
Symptom
When you log in to the uPortal, a certificate error page is displayed, as shown in Figure
1-152.
Figure 1-152 Certificate error
Possible Causes
The certificate expires or no certificate is unavailable.
Verify that the certificate is valid.
Procedure
Step 1 Check the certificate.
1. Open Internet Explorer and choose Tools > Internet Options. In the Internet Options
dialog box, click the Security tab, deselect Enable Protected Mode, and click OK.
Close Internet Explorer.
NOTE
For the Windows 7 operating systems, you must deselect Enable Protected Mode before you can
install the certificate.
2. Open Internet Explorer, enter https://IP address:Port number (for example, https://
10.175.4.178:28443) in the address box, and press Enter. The certificate error page is
displayed.

CloudEC
Figure 1-153 Certificate error
3. Click Continue to this website(not recommended) on the certificate error page. The
uPortal login page is displayed with a Certificate Error warning displayed in the address
box.
Figure 1-154 Login page
4. Click Certificate Error in the address box. The Certificate Invalid dialog box is
displayed.

CloudEC
Figure 1-155 Certificate Invalid dialog box
5. Click View certificates. The Certificate dialog box is displayed.
Figure 1-156 Certificate dialog box
6. Click the Certification Path tab and view the certificate status.

CloudEC
Figure 1-157 Certification Path tab page
7. Click the General tab and view certificate information.

CloudEC
Figure 1-158 General tab page
Step 2 Install a certificate.

1. Click Install Certificate. The Certificate Import Wizard dialog box is displayed.

CloudEC
Figure 1-159 Certificate Import Wizard dialog box
2. Click Next. On the Certificate Store page, click Place all certificates in the following
store.

CloudEC
Figure 1-160 Certificate Store page
3. Click Browse, select Trusted Root Certification Authorities, and click OK.
Figure 1-161 Select Certificate Store dialog box
4. Click Next. The Completing the Certificate Import Wizard page is displayed.

CloudEC
Figure 1-162 Completing the Certificate Import Wizard page
5. Click Finish. The Security Warning dialog box is displayed.

6. Click Yes. The message "The import was successful" is displayed.
7. Click Yes to complete the certificate import.
8. Close all pages that are displayed in the preceding operations and restart Internet
Explorer for the imported SSL certificate to take effect.
Step 3 Configure the browser.
1. Choose Tools > Internet Options. The Internet Options dialog box is displayed.
2. Click the Advanced tab and deselect Allow active content to run in files on My
Computer*.

CloudEC
3. Click the Security tab, select Enable Protected Mode, and click OK.
NOTE
– For the Windows 7 and Windows Vista operating systems, you must deselect Enable
Protected Mode before you can install the certificate.
– For the Windows 2000, and Windows 2003 operating systems, skip this step.
Step 4 Restart Internet Explorer and log in to the uPortal.
----End
1.8.1.5 Data Import or Output Failure
Symptom
An enterprise administrator fails to import or export enterprise users or export operation logs
on the uPortal.
Possible Causes
In Internet Explorer, Use SSL 2.0 is selected in the Internet Options dialog box.

CloudEC
The uPortal does not support SSL 2.0. Verify that Use SSL 2.0 is deselected in the Internet
Options dialog box.
Procedure
Step 1 Open Internet Explorer and choose Tools > Internet Options. The Internet Options dialog
box is displayed.
Step 2 Check whether Use SSL 2.0 is selected in the Security area. If yes, deselect it and restart
Internet Explorer for the setting to take effect.
----End

CloudEC
1.8.1.6 Execution Return Result Is Empty on the sysPortal
Symptom
On the sysPortal, a module reports an error, indicating that the execution return result is
empty.
Possible Causes
The bmserver module is not started.
l Collect uPortal logs and check for obvious failure logs.
l Check whether the bmuserver module is running properly.
Procedure
Step 1 Log in to the OMU and run the ps -ef | grep bmu command to check the bmuserver module
status.
Step 2 Run the start_bmuserver command as the omu user to start the bmuserver module.
Step 3 Check the bmuserver module status again.

CloudEC
Step 4 After the bmuserver module is started, log in to the sysPortal and check whether all modules
are running properly.
----End
1.8.2 USM Does Not Respond to SIP Messages

Symptom
Based on message tracing on the peer device, the USM does not respond to SIP messages sent
by the peer device.
Procedure
Step 1 In messages traced on the peer device, check whether the destination IP address is the
signaling IP address of the USM and the port number is 5060.
l If the destination IP address or port number is incorrect, change the destination IP
address or port number.
l If the destination IP address and port number are correct, go to Step 2.
Step 2 Trace SIP messages on the USM and check whether the messages are received by the USM at
the service layer.
2. Click the Maintenance tab at the bottom of the window.

CloudEC
Figure 1-165 Navigation window
3. Click the USM NE, double-click SIP, enter the remote IP address, and click OK.
4. Perform related service operations, for example, initiate a call.
5. If the message tracing result is displayed in the right pane, go to Step 3.
6. If no message tracing result is displayed in the right pane, go to Step 4.
Step 3 Trace IMPU messages on the USM.
3. Click the USM NE, double-click IMPU, enter the user IMPU number, and click OK.

CloudEC
Figure 1-166 Tracing IMPU messages

5. Search for information generated at the corresponding time point. If the fault can be
located based on the information, rectify the fault. If the fault cannot be located, contact
Step 4 Trace IP address on the CGP and check whether the messages are received by the USM.
3. Click the CGP NE, double-click IP, set related parameters, and click OK.
Set key parameters as follows:
– ME ID: Select the ID of the USM NE.
– VM Name: Select the VM where the active IFM module is located.
– Port Name: Select VNIC4.
– IP1 address: Enter the signaling IP address of the USM.
– IP2 address: Enter the peer IP address.
– IP direction: Select BIDIRECTIONAL.
– Combination: Select UDP.

CloudEC
Figure 1-167 Tracing IP messages

5. If no message tracing result is displayed in the right pane, check the network.
Step 5 Run the ACT SYSLOG command under NE 0.
l Deployment type: Select VM.
l Virtual machine name: Select the VM corresponding to the IFM module where the
signaling IP address is located.
l Level: Select DEB(Debugging).
Step 6 Download log files to the local PC.
1. In the HUAWEI Operation & Maintenance System, choose Maintenance > File
Transfer Service. The File Transfer Service window is displayed.
2. Download USM NE debug logs generated in the time period when IP messages are
traced.

CloudEC
Step 7 Search for SIP message header fields of the corresponding type in the log files that are
downloaded.
l If SIP message header fields of the corresponding type are found in the log files, locate
the fault based on log information. If the fault cannot be located, contact Huawei
l If SIP message header fields of the corresponding type are not found in the log files, go
to Step 8.
DEB M2008P000F63S01M 2017-03-25 08:48:48 [dpumain.c:394]
<DpuTptdUdpIpv4RecvProcForMccp> recv ipv4 message
<DpuTptdUdpIpv4RecvProcForMccp> OPTIONS sip:
Step 8 Run the SET USMSIPCFG:; command under the USM NE to reopen the port. Repeat Step 4
through Step 7. If the fault persists, contact Huawei technical support engineers.
----End
1.9 Other Faults
1.9.1 USM Does Not Respond to SIP Messages
Symptom
Based on message tracing on the peer device, the USM does not respond to SIP messages sent
by the peer device.
Procedure
Step 1 In messages traced on the peer device, check whether the destination IP address is the
signaling IP address of the USM and the port number is 5060.
l If the destination IP address or port number is incorrect, change the destination IP
address or port number.

CloudEC
l If the destination IP address and port number are correct, go to Step 2.

Step 2 Trace SIP messages on the USM and check whether the messages are received by the USM at
the service layer.
Figure 1-169 Navigation window
3. Click the USM NE, double-click SIP, enter the remote IP address, and click OK.
6. If no message tracing result is displayed in the right pane, go to Step 4.
Step 3 Trace IMPU messages on the USM.
3. Click the USM NE, double-click IMPU, enter the user IMPU number, and click OK.

CloudEC
Figure 1-170 Tracing IMPU messages

5. Search for information generated at the corresponding time point. If the fault can be
located based on the information, rectify the fault. If the fault cannot be located, contact
Step 4 Trace IP address on the CGP and check whether the messages are received by the USM.
3. Click the CGP NE, double-click IP, set related parameters, and click OK.
– ME ID: Select the ID of the USM NE.
– VM Name: Select the VM where the active IFM module is located.
– Port Name: Select VNIC4.
– IP1 address: Enter the signaling IP address of the USM.
– IP2 address: Enter the peer IP address.
– IP direction: Select BIDIRECTIONAL.
– Combination: Select UDP.

CloudEC
Figure 1-171 Tracing IP messages

5. If no message tracing result is displayed in the right pane, check the network.
Step 5 Run the ACT SYSLOG command under NE 0.
l Deployment type: Select VM.
l Virtual machine name: Select the VM corresponding to the IFM module where the
signaling IP address is located.
l Level: Select DEB(Debugging).
Step 6 Download log files to the local PC.
1. In the HUAWEI Operation & Maintenance System, choose Maintenance > File
Transfer Service. The File Transfer Service window is displayed.
2. Download USM NE debug logs generated in the time period when IP messages are
traced.

CloudEC
Step 7 Search for SIP message header fields of the corresponding type in the log files that are
downloaded.
l If SIP message header fields of the corresponding type are found in the log files, locate
the fault based on log information. If the fault cannot be located, contact Huawei
l If SIP message header fields of the corresponding type are not found in the log files, go
to Step 8.
<DpuTptdUdpIpv4RecvProcForMccp> recv ipv4 message
<DpuTptdUdpIpv4RecvProcForMccp> OPTIONS sip:
Step 8 Run the SET USMSIPCFG:; command under the USM NE to reopen the port. Repeat Step 4
through Step 7. If the fault persists, contact Huawei technical support engineers.
----End
1.9.2 Failed to Clear Alarms Reported by the Original Active

Node After a Switchover Between the Active and Standby ECS
Nodes
Symptom
After an active/standby switchover, alarms reported by the original active node before it
becomes the standby node are not cleared.
Possible Causes
l The alarm verification function does not clear alarms if the verification object does not
exist. That is, when the original active node stops providing services and cannot respond
to the alarm verification function, alarms will not be cleared.
l The CGP allocates different module numbers to hosts that provide the same service. A
host can report or clear only alarms about itself. Therefore, alarms reported by the active
node cannot be cleared by the standby node.

CloudEC
Fault Locating
Step 1 Log in to the HUAWEI Operation & Maintenance System and choose Alarm > Browse
Alarms.
Step 2 Double-click an alarm. In the Alarm Details dialog box, view the name of the VM that
generates the alarm in Location Info and check whether the alarm is reported by the original
active or standby node.
----End
Fault Rectification
If the alarm is reported by the original active node, ignore the alarm. No further action is
required.
1.9.3 Built-in DNS Fault

Symptom
The embedded DNS of the USM is faulty. The DNS resolution fails, or the resolved address is
incorrect.
Possible Causes
l The naming authority pointer (NAPTR) is incorrectly configured.
l The SRV record is incorrectly configured.
l The resource record (DNSRSC) is incorrectly configured.
Troubleshooting procedure: Orderly check the configuration information of the NAPTR, SRV
record, and DNSRSC.
Procedure
Check the configuration information of the NAPTR.
1. Check whether the domain name to be resolved is correctly configured with the NAPTR.
Run LST DNSNAPTR to check whether the Domain Name parameter in the returned
result contains a domain name to be resolved. If the record exists, check whether the
Replacement parameter is correct. For example, if the domain name to be resolved is
scscf-0.home1.com, the value of the Replacement parameter should be
_sip._udp.scscf-0.home1.com.
%%LST DNSNAPTR:;%%

-------------------------
NAPTR Record ID Domain Order Prefer Flag Service
Regular Expression Replacement
0 scscf-0.home1.com 0 0 S SIP+D2U
NULL _sip._udp.scscf-0.home1.com
1 scscf-1.home1.com 0 0 S SIP+D2U
NULL _sip._udp.scscf-1.home1.com

CloudEC
--- END
– If the configuration is correct, go to 2.

– If the configuration is incorrect, run MOD DNSNAPTR to modify the parameter.
Then go to 2.
– If the parameter is not configured, configure the embedded DNS according to
Configuring Data for Interworking with Embedded DNS. No further action is
required.
2. Check whether the SRV record of the DNS service record is correctly configured.
Run LST DNSSRVP to check the record in the returned result. Check whether the
Domain Name parameter (Replacement in 1) is configured. If the parameter is
configured, check whether Port and Target parameters are correctly configured.
%%LST DNSSRVP:;%%

-------------------------
SRV Record ID = 0
Domain = _sip._udp.scscf-0.home1.com
Priority = 0
Weight = 0
Port = 5060
Target = scscf-0.home1.com
--- END
– If the configuration is correct, go to 3.

– If the configuration is incorrect, run MOD DNSSRVP to modify the parameter.
Then go to 3.
– If the parameter is not configured, run ADD DNSSRVP to configure the SRV
record information. Then go to 3.
3. Check whether the DNSRSC is correctly configured.
Run LST DNSRSC to check the record in the returned result. Check whether the
Domain parameter (Target in 2.) is configured. If the parameter is configured, check the
IP Address parameter is correctly configured. For example, if the IP address of
scscf-0.home1.com is configured as 192.168.1.4, instead of the planned IP address
192.168.1.5, the IP address is incorrectly configured.
%%LST DNSRSC:;%%

-------------------------
Domain = scscf-0.home1.com
Address type = IPV4
IP Address = 192.168.1.4
--- END
– If the configuration is incorrect, run RMV DNSRSC to remove the DNSRSC

information and then run ADD DNSRSC to add the correct information.
– If the parameter is not configured, run ADD DNSRSC to configure the DNSRSC
information.

CloudEC V600R019C10 Troubleshooting (Enterprise On-Premises, IPT) PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CloudEC V600R019C10 Troubleshooting (Enterprise On-Premises, IPT) PDF

Uploaded by

Copyright:

Available Formats

CloudEC

Troubleshooting (Enterprise On-

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. i

1 Typical Troubleshooting Cases.................................................................................................. 1

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. ii

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. iii

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. iv

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. v

1.6.7 ECS Interworking Fault...........................................................................................................................................151

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. vi

1 Typical Troubleshooting Cases

1.1 SessionInsight Media Demarcation and Diagnosis

1.1.1 Analysis of Typical Voice Fault Scenarios

1.1.1.1 No Voice in a Conference

1.1.1.1.1 Symptoms and Possible Causes

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 1

1.1.1.1.2 Processing Idea

Figure 1-1 Analysis of Typical Voice Fault Scenarios

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 2

Figure 1-2 Counter indicating the endpoint's voice play level

?.3. P3, The Pickup Party's Endpoint Receives No Voice Packet

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 3

?.4. P4, The MCU Sends No Voice Packet

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 4

?.5. P5, The SBC Sends No Voice Packet

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 5

?.6. P6, The Pickup Party's Endpoint Is Muted by the MCU

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 6

?.10. P10, The Speaker's Voice Collection Device Is Faulty

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 7

?.11. P11, The Speaker Performs a Muting Operation by Mistake

?.12. P12, The Speaker's Endpoint Is Muted by the MCU

1.1.1.2 Intermittent Voice

1.1.1.2.1 Symptoms and Possible Causes

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 8

1.1.1.2.2 Processing Idea

Figure 1-10 Intermittent Voice

During a conference, if other participants' voice heard by a participant is intermittent but

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 9

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 10

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 11

1.1.1.3 Noise or Abnormal Volume

1.1.1.3.1 Symptoms and Possible Causes

Symptoms: In a multi-party conference or P2P call, voice collection of some participants is

1.1.1.3.2 Processing Idea

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 12

Figure 1-14 Noise or Abnormal Volume

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 13

Figure 1-15 Endpoint volume adjustment counters

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 14

1.1.2 Analysis of Typical Video Fault Scenarios

1.1.2.1 Video Frame Freezing/Artifact

1.1.2.1.1 Symptoms and Possible Causes

1.1.2.1.2 Processing Idea

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 15

Figure 1-18 Analysis of Typical Video Fault Scenarios

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 16

?.2. P2, Packets Received by the Endpoint Are Lost

Issue 01 (2019-06-15) Copyright © Huawei Technologies Co., Ltd. 17

?.4. P4, Packets Received by the Endpoint Contain Bit Errors