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


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


The call between TE30 and Polycom MCU is successfully set up, but the call is disconnected at a specified time

Publication Date:  2019-08-16 Views:  205 Downloads:  0

Issue Description

A local TE30 is deployed on the customer's intranet with the IP address 172.*.*.165 and static NAT to the public network with the IP address 212.*.*.149. The remote end is an MCU of another vendor.

The customer has not established his own independent network or VPN, so the port of the operator MCU is rented, and a virtual conference room is established by the operator. The local terminal and the other terminal use the H.323 mode to make calls to the virtual conference room. The line and MCU ports are provided by the carrier.

The user initially called by SIP, but the call fails. Then, the subscriber registers with the GK in H.323 mode and uses the H.323 protocol to make calls. The local terminal number and call number are provided by the carrier.

The device can successfully register with the GK server, and the call is successful. In addition, the device can hear the greeting and background music from the MCU of the peer carrier as well as view the image processed by the MCU. However, after about 20 seconds, the call is automatically disconnected, and a message is displayed indicating that the call ends normally. This is the symptom of each call.

The following figure shows the networking diagram.

Alarm Information

No alarm is generated.

Handling Process

1. Confirm with the relevant personnel of the carrier and learn that they have also rented that to other offices in the same way, which is normal. Therefore, there is no problem in the configuration of MCU, and the MCU has both registration and code stream forwarding functions.

2. Try to reduce the call bandwidth, change the video and audio resolution, select Support H460, and deselect Huawei GK. However, the problem is not solved.

3. Try to use the device of other vendors, use the soft terminal of vendor P, and use the same IP address and NAT mode, use H323 mode to call successfully and will not be hung up. So it is inferred that the customer's network side configuration basically has no problem.

4. Analyze the signaling messages of the TE30. It is found that the initial registration message and the H225 protocol of the call signaling are normal. In the last step of the H245 protocol, when the logic channel is opened, the reject message is displayed. It is inferred that the remote end rejects the message and hangs up the conference.

5. It is hung up after the call had been set up for 20sand it is judged that a certain timing mechanism has caused this problem. The TE30 has a default setting for sending a keep-alive packet periodically. Different vendors have different ways to handle the keep-alive packet. The device of the P-sharer may reject the keep-alive package therefore the conference is hung up.

6. Log in to the TE30 terminal as the debug user in SSH mode and run the set Q931Keepalive 0 command to disable the function of periodically sending Keep-Alive packets.

7. Perform the call test again. The call is successful and the call is not disconnected. The problem is solved.

Root Cause

The TE30 has the function of sending Keep-Alive packets by default. The mechanism for processing the Keep-Alive packet by different vendors is unavailable. The device of the P vendor may reject the Keep-Alive packet. As a result, the conference is ended.


Log in to the TE30 terminal as the debug user in SSH mode and run the set Q931Keepalive 0 command to disable the function of periodically sending Keep-Alive packets. Therefore, the non-Huawei device will not proactively disconnect the conference because it does not receive such packets.


The connection problems of calls with vendors’ devices such as the call is hung up after 20s occur frequently, in this case, check whether the fault is caused by certain mechanisms of the terminal when the line is normal.