Yealink phones not provisioning, RPS delivered successfully

[ITSupport94]

Hi,

We’re trying to migrate our 3cx server from Windows Server 2016 to Server 2022, were installing 3cx as a fresh install and restoring from backup.

The restore is all successful and the phones work, however we use hotdesking in our environment, meaning the some of the phones need to be reprovisioned daily, some more than once a day.

This is where we have hit a roadblock with provisioning, on the new server phones all work fine for calls etc, I can re-provision all the devices once but never a second time, or provision any new phones, also meaning we cannot use Hotdesking.

We're getting the messages RPS Request for Yealink (MAC:XX:XX:XX:XX:XX:XX) IP Phone of User (XXX) delivered successfully, but the phones do nothing.

I’ve factory reset some devices, removed them from their userr and attempted to provision to no success, also tried logging into the phones UI and adding the provision link & Auto-provision also to no success.

Reverting back to the old 3cx server hosted on Server 2016 and things work again. We just cannot get the new server to provision the phones.

The phones can access the internet on the VLAN, Access the PBX on HTTPS, we are using a trusted cert by Yealink from GoDaddy specific to the FQDN.

Environment Details:
3CX Version: 18.0 Update 9 Build 31
Server OS: Windows Server 2016/2022
3CX Server hosted on-prem with FQDN & Split-DNS is enabled
IP phones: Yealink T-19P E2, T-31P, T-31G, T-33G
Provisioning Locally
Trunk Prov: Gamma Business Communications
Firewall Checker Passed
No Custom Templates


How do i proceed as i cannot move servers still, or even think about upgrading to v20 untill we know this all works.

 

[sjackson0109]

Why on earth would a incorrect firmware trigger a blacklist of the public IP - the logic here is shocking.

Imagine a 3CX ENT edition customer.. with 300x handsets, all registered. dozens of inbound GEO numbers, calls active all the time. Some point down the line, their IT staff (perhaps not an IT department).. erase config (power+speaker) restoring to firmware recovery partition. Handset boots, RPS redirects, and the handset provisions, reboot later and the handset attempts to register..
for the good deed of "trying to help provision a handset"... they run the risk of "knocking out the entire business for 24 hours". UTTERLY CRAZY

 

[SteveITS]

It's not a goal...I presume 3CX tells the phone to be a router phone, and the old firmware doesn't know how to do that correctly. Thus it fails to connect/log in, and after "n" attempts those failures trigger the block.

If you set up a separate SBC (or get one router phone configured) you can provision other phones through that via plug and play. (router phones have a limit of 10) Then upgrade firmware on those phones through 3CX in a few clicks. Then if desired delete that phone and re-add as another router phone.

A company with 300 phones may want to Allow their office IP so it isn't blocked, which can be done on a self hosted server.

It would be ideal if the older phone failed to connect but did not trigger a block, yes. I suspect distribution has to work through a lot of phones with older firmware before that's not a problem.

 

[sjackson0109]

I have resolved my provisioning issue, but my comments re poor registration-related blacklisting is still valid. 3CX need to address this.

Yealink Maintenance firmware:
https://support.yealink.com/en/portal/docList?archiveType=software&productCode=9f9590f420350430
v108.86.0.90 - doesn't work

https://www.3cx.com/docs/phone-firmwares/#:~:text=Yealink T46U
v108.86.0.93 - does work

*assuming i get a new public IP address*

 

[sjackson0109]

I get it, if the 'router phone' is on the same layer 2 vlan, it will respond to DHCP REQUESTS where option 43="yealink" returning option 66 and or 120... I get it.

But Enterprise customers place traffic management policies, and prevent PCs on adjacent switch ports from talking to one another... so this wouldn't work. Every handset would login to an SBC, in a separate VLAN, and DHCP options would handle the initial ZTP process...


"n" attempts... yeah n=3. Handsets register every 10 seconds after booting, so within a mere 30 seconds the public ip is blocked.

 

[bitn2]

Its pretty easy... RTFM... Sorry to say that, but thats not the fault of 3cx. You just need to follow every step in the manual and you dont get any problems.

 

[sjackson0109]

3cx are at fault. the IP blocking due to unsupported firmware - thats on their development team.

Upgrading firmware - 3CX does this automatically (i watched it upgrade the firmware immediately as i strated the provision-now from the admin webpage on the handset).. but it "upgraded" the handset to v108.55.0.15... Clealy behind.. Why would it do that?

Have any of you used Polycom Provisioning Service? Or AudioCodes? Firmware upgrades can be entirely autonomous. ZTP/RPS.. easy.. messing with DHCP scope custom options... unnecessary (although still supported if you buy after-market models that are not setup for ZTP with the vendor).

 

[bitn2]

What ever... Just follow the manuals and everything works fine. If you dont want to, have a look for a different pbx.

 

[sjackson0109]

Wonderful response man.
Manuals are in place to "get started". They are not the ONLY source of information. Thats the reason for this forum to exist - is it not?
So to tell someone to 'look at a different pbx' is just unnecessary.

Yes i'm frustrated, i've wasted time, yes i'm ranting on here (as do soo many others, by reading the forum posts).. why am i any different to you @bitn2?

I ask questions - and you respond "what ever". Does that mean you don't know the answer, or refuse to answer? Why bother typing a reply if you are not supporting, thats on you.

Having provisioned audiocodes, polycom, cisco and granstream and other models over my two decades in industry.. 3CX are doing a lot of things here that are "non-defacto". You personally @bitn2 may not agree. But others in this thread have already confirmed they agree. Blocking the public IP of clients registrering repeatedly and failing for ANY reason, is a BAD idea. Block the sip extension/user maybe? I explained this in too much detail to care anymore.