Phone registration dropping off

[MGAU]

Hi all,

Currently having issues with one end user where their deskphones are dropping off randomly and then won't register until we power cycle their router.
Details are as follows:

-3cx, google cloud hosted
-Version 18.0 update 3 (build 461)
-2 extensions, each with a Yealink T-54W phone connected, running latest firmware i believe (no option to update firmware or warning in, 3cx about the phones)
-Internet is a standard high speed broadbrand, leading directly into a Netgear Nighthawk AX6600 router (this unit specifically https://www.netgear.com/au/home/wifi/routers/rax70/), running latest firmware
-Router has SIP alg disabled
-Firewall check tool in 3cx passes
-Exact same setup with same sip/trunk provider deployed for a number of other clients no issues but all with unifi routers
-Yealink T-54W phones, provisioned via "Direct SIP - Stun Remote"
-G729 and pcma codec

More details of issue
-One phone (randomly one or other) will drop off and wont reconnect/register account on a weekly basis. Need to power cycle router to get both phones working again
-Voice calls sometimes has a period of dropout where one end cannot hear the other end, and this will last typically for a second or two, the call does not drop and audio will reconnect and work again
-Audio while working, works perfect

Things we've tried
-At first tried all the usual steps of latest firmware etc and power cycle equipment multiple times
-Have set router to give each phone a reserved LAN ip based on their mac address
-In phone provisioning for each extension in 3cx, have given each phone a unique "local sip port of phone" and "local RTP audio ports start and end" (gave 20 each for this)
-In router, have port forwarded these unique port number and port ranges to the two reserved LAN IPs of each phone
-Reprovision phones after moving away from the standard settings from 3cx (the local sip port of phone and local RTP audio ports)


Is there anything else i need to set in the Yealink phones as i have given them different local sip port of phone and local RTP audio ports.
Does anyone else have any other ideas/suggestions of things we could try or even better have run into the issue and managed to fix it ?
I did find this thread which is what prompted me to try unique local sip port and local rtp audio ports - https://www.3cx.com/community/threads/phone-drop-offs-with-netgear-nighthawk-x4s-d7800.54620/

Any help most appreciated, im pretty novice at 3cx.

Thanks very much.

 

[ElementalWindX]

This sounds very similar to my issue. Did you ever find a solution? https://www.3cx.com/community/threa...alink-t58-not-registering.118073/#post-547705

 

[JohnS_3CX]

Hi @MGAU

You are describing the classic symptoms of STUN.

When V18 Update 6 comes out (fairly soon) this will no longer be a problem for you, because the T54W is capable of running the 3CX SBC on-board.

Keep an eye on our blog posts for when update 6 comes out, and you will be able to easily convert the phone to SBC mode which should almost certainly solve the issues you described. If you have other non-SBC capable phones at the same site, the T54W will be able to act as their local SBC too, bridging them up to your cloud PBX and bypassing any router / ISP / NAT issues that are most likely causing the drop outs.

For now, please prepare by upgrading your PBX to V18 Update 5 (build 418).

 

[QueBall]

@ElementalWindX
SBC is the best if more than a single phone is present at the same site.

I found this suggestion for changing the NAT mode of Netgear routers to fix gaming issues. Probably has similar effect for direct SIP connections. It could be too aggressive on blocking the inbound packets.

Basically go to Advanced->WAN->Nat Filtering and change it from secured to open mode, apply and reboot everything.


Using unique SIP and RTP ports is required if using direct SIP. Your ISP may also have some funky behaviour here. If the ISP is not supplying a routable address and uses a carrier grade NAT you basically will always have problems unless you deploy an SBC on the site. So if the WAN port on your router is getting some "private" ip range then your ISP is doing carrier grade NAT and SBC is a hard requirement. The version 6 with integrated SBC on those Yealinks will be a cheap and easy solution.
If you have any virtualization servers on the local site you can throw up a VM with the linux SBC appliance running on site, or if they have a spare Raspberry Pi 4 you can get it running as an SBC (too hard to find these new right now due to supply issues). Or just some old off lease mini PC like HP elitedesk 800 g3 makes a great little appliance. If you have one with vpro feature like the elitedesk 800 you can configure vpro to run headless and remote control it with mesh commander. Or you can just stick a dummy VGA or displayport plug in the back and it can run off in a corner (I like the vpro models so you can remotely fix things)

Also,
Try changing the ports again, after you check the WAN setting on the Netgear router for it's NAT setting.
Throw the ports up into high port ranges and maybe you can avoid whatever ISP funkiness is happening to you here if it was not the router NAT setting.
Do not use the lower ranges below 1024. Maximum is 65535 so something closer to the higher end. But generally random. Trying to avoid any conflicts or router port blocking.
Here is a handy tool: https://it-tools.tech/random-port-generator

Hope that helps.

 

[Charles_3CX]

With the release of update 6, the T54w can be used as a router phone (built-in sbc), and the other devices provisioned through it. Ruling out the need for any port forwarding for stun connected devices.

See here: https://www.3cx.com/docs/manual/ip-phones/