No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CloudEC V600R019C00 Troubleshooting (Enterprise On-premises, Convergent Conference)

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
No Voice in a Conference

No Voice in a Conference

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 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.

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.

Diagnosis

Figure 1-1 Analysis of Typical Voice Fault Scenarios
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.

P2, The Voice Play Device of the Pickup Party's Endpoint Is Faulty

[Determination rule]

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]

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
P3, The Pickup Party's Endpoint Receives No Voice Packet

[Determination rule]

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.

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

[Determination rule]

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]

As shown in Figure 2 Counter indicating the number of voice packets received by the 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
Figure 1-5 Counter indicating the number of voice packets received by the endpoint on the network
P5, The SBC Sends No Voice Packet

[Determination rule]

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
P6, The Pickup Party's Endpoint Is Muted by the MCU

[Determination rule]

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.

P7, Other Participants Cannot Hear the Local Participant's Voice

[Determination rule]

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.

P8, The MCU Receives No Voice Packet from the Speaker

[Determination rule]

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]

As shown in Figure 1 Counter indicating the number of voice packets received by the 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
P9, The SBC Receives No Voice Packet from the Speaker

[Determination rule]

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]

As shown in Figure 1 Counter indicating the number of voice packets received by the 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
P10, The Speaker's Voice Collection Device Is Faulty

[Determination rule]

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.

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

[Determination rule]

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.

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

[Determination rule]

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.

Translation
Download
Updated: 2019-08-07

Document ID: EDOC1100059098

Views: 19567

Downloads: 12

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next