Solved Unable to provision some Yealink hardphones

[Beuningen IT]

Hi there,

We have a really strange issue at one of our customers. We are unable to provision some Yealink phones in their 3CX environment, this only seems to affect two Yealink T42G's that they are using. We host their server in our own cloud and everything worked fine for the last half year. Last week we upgraded v16 to v18 and it seems that this caused the issues below.

The customer called this morning that two of their phones stopped working. We've been onsite and replaced them both with other T42G's. They worked without any issues.

Randomly both phones dropped their registration and gave an “No service” error. Autoprovisioning stopped working. Even if you push the autoprovisioning through the webbrowser it doesn’t do anything after a factory reset. Keep in mind that other T42G's are just working fine. We've tried the following things;

- Resetting the phones to factory default
- Removed and reassigned the phones within 3CX
- Put the phones on static IP-addresses
- Tried multiple firmwares
- Unpacked a brand new Yealink T53 which seems to work fine
- Tested the phones in a different environment (our own office)
- Added the phones to our own 3CX enviroment (works just fine like it should)
- All IP's are in the allowlist and we do not see any errors in the logfiles

To be honest, we don't know what to do next. Is there anything we can check on the logs for instance to check for autoprovisioning issues? Or are both phones bricked/broken? That's weird, because they work in our own environment. We're seeing "RPS request for Yealink T42S IP Phone of <xxx> delivered successfully" messages in the logging, so that would indicate it should work. But it doesn't. It just doesn't.

• 3CX Version: 18.0 Update 1 (Build 237)
• Server OS: Debian 10
• Is the 3CX Server Hosted and where? Hosted in Vultr
• IP Phone Make/Model/Firmware version, Yealink T42G, firmware 29.83.0.130
• Provisioning Method: Both STUN and SBC
• Trunk Provider or VoIP Gateway Make/Model, CM.com Trunking
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

 

[SteveITS]

What build of 18? Is the Let's Encrypt hotfix installed? (it's in update 1)

 

[Beuningen IT]

What build of 18? Is the Let's Encrypt hotfix installed? (it's in update 1)

Yes, it is. It's running the newest version (18.0 Update 1 Build 237).

 

[JohnS_3CX]

If it is cloud hosted, are you provisioning all phones using the SBC setting here?



If so, then I would be interested in learning how you ended up with an HTTP FQDN instead of HTTPS in that field as that should not be possible.

Also mention if you have more than a single NIC on that machine.

Please read this and provide us with details so we can understand your setup
https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

 

[Beuningen IT]

If it is cloud hosted, are you provisioning all phones using the SBC setting here?

View attachment 25418

If so, then I would be interested in learning how you ended up with an HTTP FQDN instead of HTTPS in that field as that should not be possible.

Also mention if you have more than a single NIC on that machine.

Please read this and provide us with details so we can understand your setup
https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

I've added all the details to the topicstart. I'm sorry, I edited my second post as it seemed that the issues were fixed, but they weren't so please ignore that part. There is no second NIC on the machine. It's a really basic VPS that had Debian 9 with 3CX v16 from the start (half a year ago) which we updated to Debian 10 with 3CX v18.

Edit: I've also added some more information in the topicstart.

 

[JohnS_3CX]

I think under the circumstances we should start narrowing things down by ensuring the following

1. Phones must be on firmware found here, not Lydis or any other firmware version or variant

2. The phones should be configured using SBC (not STUN, it will throw a wrench in the troubleshooting process)

3. We must double-check that the FQDN in the previously mentioned post is showing correctly before proceeding

4. The SBC IP must be confirmed before typing it in (you can see it in the SIP trunks > SBC > Local IP)

 

[Beuningen IT]

I think under the circumstances we should start narrowing things down by ensuring the following

1. Phones must be on firmware found here, not Lydis or any other firmware version or variant

2. The phones should be configured using SBC (not STUN, it will throw a wrench in the troubleshooting process)

3. We must double-check that the FQDN in the previously mentioned post is showing correctly before proceeding

4. The SBC IP must be confirmed before typing it in (you can see it in the SIP trunks > SBC > Local IP)

1. We use the official 3CX firmwares.
2. Yes, everything is set to SBC.
3. The FQDN is https://<companyname>.my3cx.nl/provisioning/xxxxxxxxxxxx
4. Yes, that is correctly configured.

 

[Beuningen IT]

I've had a private conversation with JohnS. He has analyzed the pcap files that were coming from the Yealink phones. He immediately told me it had to do with the Let's Encrypt certificates. As soon as we've renewed them everything worked fine again.

Thanks once again JohnS for the support on this one, it was a hard one, but luckily we got it solved!