Best methods to troubleshoot yealink t58 not registering?

[ElementalWindX]

What are the best ways to troubleshoot a yealink t58w not registering with a vultr hosted 3cx instance? Newest debian version.


This is an office with multiple of these models installed. This is the only one having the issue. Ports are not conflicting. Rebooting the phone gets it to register fine. Some point in time it just loses the register.

Thanks.

 

[Alphabetic]

Check 3CX passes firewall test.

Check extension is enabled.

Check IP isnt blacklisted.

Run Wireshark on 3CX to see if it receives registration

Run Wireshark on firewall

Run Wireshark on Yealink.

see what's blocking it.

 

[SteveITS]

Are you using an SBC? (if not, try that, SBCs are designed to simplify connectivity)

 

[ElementalWindX]

Are you using an SBC? (if not, try that, SBCs are designed to simplify connectivity)

No. I never use an SBC, although I can't wait to start using the new alpha SBC method. I'm using the same method on this PBX I use on 30 other PBX's all hosted the same way on vultr.

In fact all phones work fine and all are setup the exact same way. It's just the one singular phone that exhibits this issue.

I've tried to replicate the problem on demand by restarting the 3cx services, the entire pbx, the server, even the firewall on the phones location, the core switch on the phones location. The phone itself several times.

The problem happens daily and the user claims it's when they first arrive in the morning and all they do is power cycle the phone and it is fine the rest of the day. The phone loses registration but maintains network connectivity perfectly fine. Really makes me think it's a firmware issue but all phones are on the same firmware version too.


This PBX has been in production for over a year and was running older Yealink T48 series phones perfectly fine. This problem only came up as we replaced those with the new T58w series phones simply because the owner wanted them.

 

[SteveITS]

We've used STUN sparingly, without issue as well. However per other posts here from 3CX their general stance seems to be "it will work until it doesn't, and good luck." If there was a PC on which you could install the SBC software, or spin up a Debian VM, it would be interesting to know if the problem goes away. If not, then it's something else, and you can turn off the SBC and factory reset the phone again.

For lack of a better idea I might ping the phone a few thousand times (3600 per hour) and try to see if the problem happens at the same time every day. Perhaps some sort of cmd file that pings a while, echos "time /t" and loops. Just brainstorming.

The 57W is on the update 6 list for the built in SBC, but the 58W is not. Maybe they'll add it later.

 

[JohnS_3CX]

I'd start by suggesting a full factory reset and reprovision, using the latest 3CX supported templates on V18 Update 5, and Yealink firmware 150.86.0.38

If you have the ability on your network hardware, here is one of the best methods you can use:

1. Put the phone on LAN (not WiFi for obvious reasons)
2. Mirror your network port and start a packet capture (using the phone MAC as a capture filter)
3. On the PBX machine, start another packet capture, you might want to use t-shark for this
4. Wait until the phone drops out, and stop the capture.

In the Mirrored port capture
Check to see if the phone is sending REGISTER messages to the 3CX IP.
It should send one roughly every minute.
See if it got any replies from the 3CX IP and what the replies contain.

In the PBX capture
Check based on equivalent timestamps, to see whether the REGISTER messages reached 3CX using the phone extension as a filter.
See what 3CX replied to the phone, but then go back to the original capture, to see if the reply ever found its way back to the phone.

It could be that the firewall/ISP is changing the Contact IP and or Port before forwarding the INVITE to 3CX, and the reply comes back to an invalid destination, which the firewall will drop. Restarting the phone "refreshes" the UDP session, and the problem temporarily goes away, but only so long as the firewall/ISP plays nice.

I think this method will get you as close to the truth as possible, although it does require some careful planning and patience.