V18 update5 EOL Yealink phones

[Dupablada]

The following phones appear to be going EOL with the latest update:

• Yealink EOL series: T29G, T41P, T42G, T46G, T48G, W52P (DECT), W56P (DECT)

Will the T46U be supported? About to make an order for a client and don't want to get caught out.

 

[CentrexJ]

The following phones appear to be going EOL with the latest update:

• Yealink EOL series: T29G, T41P, T42G, T46G, T48G, W52P (DECT), W56P (DECT)

Will the T46U be supported? About to make an order for a client and don't want to get caught out.

Yes the "U", "W" and also the no longer sold "S" models are still supported and work great with 3CX.

Its the G and P series that are no longer supported due to their age and not supporting the latest systems.

 

[N_G]

These phones are not going eol with update 5. It's not 3cx that makes these decisions. These phones are end of life for several years now and these decisions are made by yealink. These are old phones, it's just confusing that new ones are named 46u and old one 46g. The difference in name is too small. The 46u should have been called 66u or something but this is a marketing decision by yealink.

 

[N_G]

So we have received a reply from Yealink that these phones will not be updated. So T48G and T46G can not be provisioned with 3CX U5 and up. You will have to manually configure the phones.

 

[rc179]

I can appreciate the situation with the naming of the phones, but there are a lot of these phones out there and losing the deprovision functionality is a pretty big deal to those of us managing many systems, often with limited access to the local network.

You provided information on the basic registration via the phones web interface, but this leaves a big question on the BLF keys. If I configure these via the MC either on a new role out or change them later, is the phone going to be updated. Or are we going to have to go to each phone individually and manually change the BLF key settings? I know I could build out my own provisioning server, but one big plus to 3CX was I didn't have to build my own system.

Also, losing the hot desking is going to cause some issues. A site that is 3 years old or less and uses hot desking, will have to be told they need to buy new phones. Not many businesses plan on that expense in so short a time. Small sites may decide to go with a service that includes phones like Comcast, or some one-man-shop's role out of Asterisk. Larger ones will look at the increased cost when looking at larger systems, make 3CX not as clear a winner as before.

Just something to think about. I'd be curious to know what the rational was to losing these features.

 

[cjt]

So we have received a reply from Yealink that these phones will not be updated. So T48G and T46G can not be provisioned with 3CX U5 and up. You will have to manually configure the phones.

We have updated to U5 and our T46G phones are still re-provisioning and rebooting from the phones menu in the admin console, and they can be controlled with CTI through the windows app.

So if there is a problem with T46G and U5 I've not found it, which I'm happy with

 

[rc179]

We have updated to U5 and our T46G phones are still re-provisioning and rebooting from the phones menu in the admin console, and they can be controlled with CTI through the windows app.

So if there is a problem with T46G and U5 I've not found it, which I'm happy with

That's confusing because it looked to me like this page says just the opposite with instructions on the provisioning and the known limitations at the bottom. Maybe someone from 3CX could clarify.
https://www.3cx.com/sip-phones/manually-provision-yealink/

 

[SweetAction]

That's confusing because it looked to me like this page says just the opposite with instructions on the provisioning and the known limitations at the bottom. Maybe someone from 3CX could clarify.
https://www.3cx.com/sip-phones/manually-provision-yealink/

I think cjt is using local lan provisioning, which uses http currently:


That won't work forever - per Nick (in a thread I opened in partner forum when u5 came out about this)

Well via the local lan is going away as well very soon btw. But yes for now it only affects cloud installs.

Best to have a plan forward so you don't get caught out when local LAN goes away too. Replacement phones seem to be the safe bet right now.

My AM at Yealink and their Tech lead were unaware of this but looking at it now. I suspect the answer will remain the same, since Nick said that Yealink won't publish new firmware to address and Nick likely has a higher level contact at Yealink then myself

So we have received a reply from Yealink that these phones will not be updated. So T48G and T46G can not be provisioned with 3CX U5 and up. You will have to manually configure the phones.

 

[rc179]

Is the lack of provisioning/re-provisioning simple because the phone doesn't support TLSv1.2 and the update removes support for the older version? I understand that it's nice to know that there will be future updates for the phone, but if it works now it should continue to work without them, and phone sets have a long lifetime.
I'm hesitant to suggest it, because I don't want to offend the guys at 3cx, but why not leave in the TLS support and avoid the whole issue. If it's a security concern, put in a checkbox to allow or not. Or maybe limit the older TLS to just older phones.
Don't know what that would take, just trying to suggest a solution and not just be complaining.
I can't emphasize enough how not being able to set/reset the BLFs in bulk is going to create a huge time sink.

 

[cjt]

Yes we are using local lan provisioning. I hadn't realised that the issue didn't affect local LAN provisioned phones, I hadn't read that clarification anywhere. Anyway so that is good for the time being, but it would be good to understand when this is likely to be changed and the implications for our setup to a different provisioning method and requirement to replace all our phones.

 

[pangel]

-snip-
Is the lack of provisioning/re-provisioning simple because the phone doesn't support TLSv1.2 and the update removes support for the older version?
I'm hesitant to suggest it, because I don't want to offend the guys at 3cx, but why not leave in the TLS support and avoid the whole issue. If it's a security concern, put in a checkbox to allow or not.
-/snip-

From another thread, of the same issue:

Its not only related to TLS 1.2.

As for the checkbox, there is already a setting for this - it's the "SSL/SecureSIP Transport and Ciphers" under Anti-Hacking. This is already necessary for some EOL phones, and poses security risks outside of Local LAN.

Keep in mind that EOL status is not a 3CX decision, and contact from both partners here on the forum and Nick Galea himself have received a similar reply; Yealink won't be releasing new firmware to fix it.
Editing things like BLFs will be a huge time sink indeed, but such is always the case for unsupported or EOL phones that have to be provisioned manually. There are many newer models on the supported phone list that will save you a lot of time and issues in the long run. T4xG series got their EOL announcement from Yealink 2 years ago now, and 2 new iterations of the lineup (T4xS, T4xU) have been released since.

 

[rc179]

From another thread, of the same issue:

As for the checkbox, there is already a setting for this - it's the "SSL/SecureSIP Transport and Ciphers" under Anti-Hacking. This is already necessary for some EOL phones, and poses security risks outside of Local LAN.

I believe that is for SIP signaling, which still works on the EOL phones, not for provisioning which I believe is over https.

Editing things like BLFs will be a huge time sink indeed, but such is always the case for unsupported or EOL phones that have to be provisioned manually. There are many newer models on the supported phone list that will save you a lot of time and issues in the long run. T4xG series got their EOL announcement from Yealink 2 years ago now, and 2 new iterations of the lineup (T4xS, T4xU) have been released since.

Keep in mind that this also means the BLF setting in the client app won't work either, so your users will see these but they will STOP working. People often notice things not working if they used to, and this will generate service calls.

And in the phone world, the idea that you would replace all the phone sets every 2 or 3 years would be seen as ridiculous. And this is what people are used to.
I'd love to hear the technical reason for dropping the feature, then maybe I'd understand, just them being EOL and not having firmware updates isn't a technical reason for dropping a feature. I've seen plenty of EOL equipment just keep working with no drop in features.

There are some very technical people here, I'm sure many would understand why this had to be, if 3cx would share with us what the issue is.

 

[JohnS_3CX]

I believe that is for SIP signaling, which still works on the EOL phones, not for provisioning which I believe is over https.

Not quite. This purely for TLS connections, which is what the phone uses for remote provisioning over HTTPS.

Keep in mind that this also means the BLF setting in the client app won't work either, so your users will see these but they will STOP working. People often notice things not working if they used to, and this will generate service calls.

This is a misunderstanding. The BLFs in the Desktop client will not stop working.

If it's a security concern, put in a checkbox to allow or not.

There is a checkbox, it has existed since at least V15.5 in the security settings.

There are some very technical people here, I'm sure many would understand why this had to be, if 3cx would share with us what the issue is.

As simply as possible: 3CX is moving forward, and is removing the LESS secure methods of TLS because you may be vulnerable to attacks. This is something that the whole industry follows and we need to follow it too.

Phones that do not support the more secure TLS methods are now incapable of making an HTTPS connection to 3CX. This means that provisioning cannot take place, but SIP runs just fine because it does not use HTTPS.

You have the choice to reduce your own security and keep provisioning those phones:

 

[mcsphones]

We too have probably 900-1000+ T29G phones in the wild. We've been replacing them and doing new installs with the T46U, but the T29G's were still sold as new by distributors until late 2020 so it seems a little premature to sunset their support, especially since they "work fine" in a small LAN 3CX environment.

 

[JohnS_3CX]

We too have probably 900-1000+ T29G phones in the wild. We've been replacing them and doing new installs with the T46U, but the T29G's were still sold as new by distributors until late 2020 so it seems a little premature to sunset their support, especially since they "work fine" in a small LAN 3CX environment.

The existing already-deployed phones that were assigned to an extension will still continue to work in Local LAN provisioning environments because TLS is not used there.

And if you need to reset, you may re-assign it like usual:

 

[mcsphones]

Thanks JohnS, this is exactly what I needed to know/see. I'll update our provisioning procedures for these legacy models accordingly.

 

[rc179]

Not quite. This purely for TLS connections, which is what the phone uses for remote provisioning over HTTPS.



This is a misunderstanding. The BLFs in the Desktop client will not stop working.



There is a checkbox, it has existed since at least V15.5 in the security settings.




As simply as possible: 3CX is moving forward, and is removing the LESS secure methods of TLS because you may be vulnerable to attacks. This is something that the whole industry follows and we need to follow it too.

Phones that do not support the more secure TLS methods are now incapable of making an HTTPS connection to 3CX. This means that provisioning cannot take place, but SIP runs just fine because it does not use HTTPS.

You have the choice to reduce your own security and keep provisioning those phones:
View attachment 32130

I think you misunderstand what I was saying about the BLFs. I was referring to the programming of phone set BLFs in the web client, which is definitely a provisioning function the same as if you did it in the MC. The soft keys in the app, I would think would still work, as you say, since they have nothing to do with provisioning the phone.

The check box and being able to provision when it is unchecked, was also provided in another threat I posted in. It is definitely a good compromise. We'll be able to enable and disable provisioning of the EOL phones as needed, and as we determine is nessisary. Please, whatever you do, do not take away the ability to provision even an EOL phones till it's at least 10 years past end of sale. 2 year old phones becoming obsolete isn't going to go over well with customers, or even us lowly partners.

Thanks

 

[lvtech]

I know this thread is a few weeks old, but I do not see a full technical resolution in the reason for removing the provisioning templates these EOL phones. Based on everything I have read, it seems to me that the T46G phone does support TLS 1.2 and was even provisioned as such in the security.default_ssl_method = 5 line in the 3cX provided template. Looking at Yealink's site, it seems these phones have supported TLS 1.2 for a while. Is there maybe a cipher that 3cX is requiring now which causes this to not work? I am looking for clarity as we are well versed in cryptography and the full technical explanation would be greatly appreciated.

Finally, what is the timeline for the removal of the local lan provisioing method? I assume it is to cause all traffic to and from the server to be encrypted.

 

[mcsphones]

Finally, what is the timeline for the removal of the local lan provisioing method? I assume it is to cause all traffic to and from the server to be encrypted.

Approximately 95% of our installations are LAN-provisioned, so let's hope that capability does not evaporate!

 

[JulienI]

Hi,

I suggested using the 3CX SBC as a proxy for provisioning, but the thread was locked without reply
https://www.3cx.com/community/threads/t48g-eol-due-to-missing-tls-1-2.116717/page-2#post-541596

I still think it would be the solution to keep provisioning secure for "old" phones