3CX 16.0.4 Random call interruptions

[dynamarine]

Hello,

After an update of our 3CX version to version 16.0.4.493 on hosting machine with windows 10 pro we have repeatedly random call interruptions for both internal and external calls using yealink phones of various types (T21P,T23G,T27G,T28P). The same problem does not occur when using android 3cx client on our mobile phones.
We have done the below after the update:

• Upgrade yealink firmware for all phones to latest version. Factory reset configuration and reprovision.
• Port redirection in our Router Vigor2760 for ports 5001(tcp), 5090(tcp/udp) and open port range 9000-10999.
• We have binded every phone IP to MAC in router.

We have tried all the below as a solution:

• Change Priority for External Calls in Settings General tab to PCMU, PCMA, GSM, G729, G722, OPUS but no change identified so we reverted.
• Test line speed during a call and it is as expected.
• Turn off McAfee Firewall on hosting machine - nothing changed. Turn on McAfee and open ports 5000,5001,5090 (tcp), 5060,5090,9000-10999(udp) - same issue.

We would appreciate if you could help us.

Thanks in advance.

 

[cobaltit]

So McAfee should be removed completely. I don't think you need to bind any MAC in the firewall (not sure what that means anyways unless you are talking about DHCP reservation) if the PBX is in-house and on the same network as the phones. What does call interruptions mean? The calls drop? Audio issues? Does the firewall checker pass?

 

[dynamarine]

Hello,
Thanks for your response.
The McAfee existed when we had the old version of 3cx and no problem occurred.
The MAC binding we did was on our router not firewall and yes we did it for dhcp reservation.
The PBX is in house and on the same network as the the phones. What i mean by interruptions is that the voice is interrupted and we can hear half parted conversation. Some times it is impossible to understand what the speaker said. The firewall checker on 3cx shows no errors.
Thank you.

 

[JohnS_3CX]

Hi @dynamarine

Please provide detailed info as per here:
https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

And in addition, you should also describe your network layout and the specs of your PBX machine (cpu/ram, os and whether there is anything else running off that machine)

 

[AWS2P]

Do you have enough bandwith on your ISP Line on both ways ?

 

[dynamarine]

The information requested are the below:

• 3CX Version: Professional Perpetual 16.0.4.493
• Server OS: Windows 10 professional
• The 3cx server is hosted in a local physical machine
• IP Phones: Yealink SIP-T21P (34.72.0.93), SIP-T23G(44.84.0.95),SIP-T28P(2.73.0.60), SIP-T27G(69.84.0.95), SIP-T21P_E2(52.84.0.95)
• Provisioning Method: Local(LAN)
• Trunk Provider or Gateway Make/Model: Patton ISDN-BRI
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

Our line is a 50MB line. Speed test resulted in 44.63 Down and 3.91 Up which is as expected for a line as such.
Please advise accordingly because the issue remains.
Thanks.

 

[JohnS_3CX]

If you are using BRI I guess the internet connection will not be cause for concern.

Also if the apps don't cut out, the machines specs are also not going to be of concern most likely.

I suspect the network leg that connects the phones with the PBX may be at fault here.

An easy way to check:

1.) In a problematic call where you hear the other person cutting out, go check the call recording. You will probably hear their voice without interruptions there, confirming that the PBX has received it correctly from the BRI link, but also suggesting that the Yealink did not receive it.

2.) You can do the same exact test while running a capture on the Yealink GUI, which will confirm the suspicion that the phone did not receive the voice packets. At this point, go and troubleshoot your network because you would have confirmed that:

• BRI got the remote audio
• PBX Sent it to the Yealink
• Yealink did not get the RTP packets

 

[dynamarine]

Hello,
We identified after the check you mentioned that the PBX receives it correctly from the BRI link.
So i guess we need to troubleshoot our network. Actually we have already checked everything we knew. We ll check again.
Thank you all for your replies.
Best regards.

 

[eddv123]

Agree with @JohnS_3CX the BRI gateway will not be the problem here, and even if you want to check this you can run the command lines on this guide which will display a lot of information such as MOS score, traffic information etc https://en.wikipedia.org/wiki/Mean_opinion_score

Debug commands: https://www.patton.com/support/kb_art.asp?art=446&p=128

The only question I would pose is how is the gateway setup ? using supported methods or manually ? also which model are you using ? https://www.3cx.com/voip-gateways/smartnode-isdn/

 

[JohnS_3CX]

Try to enable "PBX Delivers Audio" on the gateway under your management console > SIP Trunks > Patton > Options tab. This has a similar effect to enabling recordings, as the audio passes via the PBX first. So if that didn't help I don't think this will either.

While you are at it, check to see if there is any SIP-ALG or SIP Helpers running on any of the network equipment. Sometimes it's something silly like a bad ethernet cable or patch panel, or something in the link between the phones switch, and the rest of the network's switch.

 

[eddv123]

While you are at it, check to see if there is any SIP-ALG or SIP Helpers running on any of the network equipment.

Interesting points, I worked with a network recently that was doing something similar and cutting off calls with a 3CX SBC, on logging into the SBC (on Windows) and running an IP Scan and traceroute it was discovered that the 3rd party IT had introduced more layer 3 devices in the path toward the edge router/firewall, one of these devices was in fact cutting the TCP pin-hole used by the device and thus causing drops.

 

[JohnS_3CX]

Yeah this happens, sometimes its little things you would not even consider ie. adding a small router to gain a few extra ports, but using the WAN port to bridge it to the rest of the LAN. You introduce more natting and more firewall layers causing the phones to work fine when calling the outside world, but having no audio when calling local extensions that are not connected to the same router. Let's see what @dynamarine finds..