Solved AX83H's accounts deregistering and dropping Wi-Fi

[jarrah]

We have about 30x AX83H's connected on our network via our SBC(Rasberry Pi 5) and are having a number of issues with them deregistering or dropping WiFi completely. They are VLANed to their own network. Sometimes they will deregister and stay connected to the WiFi, and will take a reboot to come back, and sometimes they appear to just completely drop off the WiFi, again a reboot fixes this, but until this point they just stay offline. This often occurs when they are just sitting in their charging cradle with good connectivity WiFi-wise (AP in the same room, full bars etc). Sometimes we even get phones that are showing registered on the device but offline in the PBX, again a reboot fixes this.

We've also been having issues with them roaming between AP's, calls will drop and not come back, or one user will be able to hear the other. We have BSS and fast roaming on our network, I am unsure if this is an issue separate to the aforementioned

We also have about 8 other IP Phones that are wired in (Yealink and a SNOM) and have had no issues with any of them.

Has anyone else been having any sort of issues like this?
I'll try and pull the logs from the handset next time I get one deregister.

 

[JohnS_3CX]

Hi Jarrah,

We can’t assist with network troubleshooting, but if you believe your network is solid, your best bet is to open a ticket with Yealink. Be ready to share device logs if they ask.

For reference, I’ve used AX83H and AX86R without issues, they stay online and don’t drop. But every network’s different, so your setup may have unique factors.

If WiFi congestion is a problem, consider DECT phones as they run on separate frequencies and tend to be more reliable as a result: https://www.3cx.com/sip-phones/yealink-dect-phones/

 

[jarrah]

Hey John,

Thanks for reaching out. Thought it was worth asking regardless. I will pursue them directly.

 

[North40IT]

We have about 30x AX83H's connected on our network via our SBC(Rasberry Pi 5) and are having a number of issues with them deregistering or dropping WiFi completely. They are VLANed to their own network. Sometimes they will deregister and stay connected to the WiFi, and will take a reboot to come back, and sometimes they appear to just completely drop off the WiFi, again a reboot fixes this, but until this point they just stay offline. This often occurs when they are just sitting in their charging cradle with good connectivity WiFi-wise (AP in the same room, full bars etc). Sometimes we even get phones that are showing registered on the device but offline in the PBX, again a reboot fixes this.

We've also been having issues with them roaming between AP's, calls will drop and not come back, or one user will be able to hear the other. We have BSS and fast roaming on our network, I am unsure if this is an issue separate to the aforementioned

We also have about 8 other IP Phones that are wired in (Yealink and a SNOM) and have had no issues with any of them.

Has anyone else been having any sort of issues like this?
I'll try and pull the logs from the handset next time I get one deregister.

Jarrah,

I wanted to reach out to see if you made any headway with your issues as we are having the same issues with our AX83H's at multiple sites. Our logs show nothing but good traffic but when our employees move from AP to AP there is chance that the call with drop, fade in and out, or take 1-3 seconds before audio continues. All of the sites are running Windows Based SBCs and are on version 18.1.36. All of our wired IP phones work flawlessly. We have the entire phone system on their own Vlan as well.

We recently swapped from the DECT solution to a full Wi-Fi solution as the DECT system was even more unreliable.

 

[jarrah]

Hey there,

Not as of yet, I've reached out to Yealink support and am just in the process of setting up a syslog server to get them some records. Will keep you posted.

 

[jarrah]

Jarrah,

I wanted to reach out to see if you made any headway with your issues as we are having the same issues with our AX83H's at multiple sites. Our logs show nothing but good traffic but when our employees move from AP to AP there is chance that the call with drop, fade in and out, or take 1-3 seconds before audio continues. All of the sites are running Windows Based SBCs and are on version 18.1.36. All of our wired IP phones work flawlessly. We have the entire phone system on their own Vlan as well.

We recently swapped from the DECT solution to a full Wi-Fi solution as the DECT system was even more unreliable.

Not the reply you probably want but we moved to Build 20.0.7.1060 and things have been a lot more stable here, especially with the issue of phones deregistering and never coming back on their own!

 

[North40IT]

Yealink provided me with a test firmware for the issue this morning (180.87.254.806). So I am going to apply that to some of my phones today to see if this stops the problems.

 

[JoshWS]

We had a similar issue. For us the fix turned out that we couldnt use the Yealink AX83H's as router phones. We were getting lots of errors in the SBC logs. We we routed them behind a router phone on the LAN, this issue resolved itself.

 

[VoIPexpert]

Yealink provided me with a test firmware for the issue this morning (180.87.254.806). So I am going to apply that to some of my phones today to see if this stops the problems.

how did the firmware worked out?

 

[North40IT]

how did the firmware worked out?

We've seen less drops from the phones and less disconnects but it has not solved the problems entirely. I've supplied them additional diagnostics data and I am waiting to see if they are going to send me another incremental upgrade or if they need more information from me.

 

[VoIPexpert]

which access points are you using? Is fast roaming activated? I have environments with TP-Link Access Points and no Problems. In other networks with sophos APs we have massiv problems. I think it is related to the WLAN network. We will also do some bigger tests next week

 

[North40IT]

which access points are you using? Is fast roaming activated? I have environments with TP-Link Access Points and no Problems. In other networks with sophos APs we have massiv problems. I think it is related to the WLAN network. We will also do some bigger tests next week

We are using Cambium XE3-4 APs and we have tried Fast Roaming both on and off and didn't see any sort of improvement or degradation at the time. I am getting reports that the Firmware they provided us with is working better. Just not perfect.

 

[VoIPexpert]

do youn have a download link for the firmware?

 

[North40IT]

For anyone following this topic we identified an issue with our Wifi setup. We had too many SSIDs broadcasting in our retail spaces which was causing our beacon overhead to be between 80%-140% depending on the site. With that we had too many signals in the air competing with each other. We reduced it to one standard SSID and one SSID using ePSK. This consolidated everything down to around 5%-10% beacon overhead. Once we did that and got the firmware loaded onto the phones my sites are reporting zero to no problems.

I know this isn't a 3CX issue and a Wifi issue but hopefully this helps someone else out.

 

[VoIPexpert]

what kind of access points are you using? I got Firmware AX83(AX83,AX86)-180.87.254.807 from yealink but still problems. The customer has only two SSIDs broadcasting. Audio from one side will drop compleatly in the phone call.

 

[North40IT]

We are running Cambium XE3-4 internal and XV2-2TO external. Auto channel scan and auto power adjustments are enabled and run nightly. We had to turn off 802.11k/v/r as we had older legacy gear it was causing issues with. We also disabled 2.4Ghz and only have 5Ghz broadcasting as having both broadcasting the SSIDs were still causing co-channel interference. Everything is routed to an SBC and then that goes back to our PBX over the WAN.

We also added the following to our company template at Yealink's direction in an attempt to get the phones to make a better AP jump:

network.wifi.bgscan_short_interval = 5
network.wifi.bgscan_long_interval = 300