Yealink phones not provisioning, RPS delivered successfully

[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.