BLF's not working right with Yealink 83.0.X firmware. Response from Yealink

Distro Discussion & Help
1

We are having a problem with BLF lights freezing when using Yealink’s 83.0.X firmware. We caught it acting up and sent Yealink a bug report. Their response is that the BLF’s need to use a different RFC standard.

Dear Customer,

This is East from Yealink Technical Support team, nice to meet you.

Thank you for the detailed information.

After I checked the syslog that you provided, I can confirm the reason. Please see the detail bellow:

When the monitored status change, the server will send NOTIFY to the phone, there is a BLF version on the NOTIFY.

In our V81 version, the phone will not check the BLF version in the NOTIFY. But in the V83 (actually updated in V82), the phone will check the BLF version.

We modified it because it is compliant with standard RFC4235, it is a better update. Please see description of BLF version below:

Version: This attribute allows the recipient of dialog information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber . Versions are scoped within a subscription. Versions MUST be representable using a non-negative 32 bit integer.

But according to the syslog, after received NOTIFY from server, the phone found that the version is smaller than the previous one, it is a substandard parameter. So the phone will not update the status of the BLF, and prompt error like: BLF bad version param. Cur ver=71, new ver=26

1534391779427098351
15343917794270983511086×408 115 KB

As our phones refer to the standard RFC4235, please contact your service provider to modify the NOTIFY message, and let it also refer to the standard. Then it will work well in BLF.

Where can I set the blf’s to use RFC4235 as they suggest?

Freepbx 14 asterisk 13.22

Asterisk Forum post: BLF’s not working right with Yealink 83.0.X firmware. Response from Yealink - Asterisk SIP - Asterisk Community

1 Like
2

While a feature request is premature at this time - I’d probably start writing one up so that’s it’s ready to send.

This wasn’t a problem until very recently, but is probably going to only get worse over time.

3

At this point I am not sure if it is a feature request, or a freepbx vs asterisk bug report.

If things are already using RFC4235 then its probably a bug report but if not then its a feature request.

4

I’ve seen newer grandstreams having similar issues, maybe it’s the same problem… interesting

1 Like
5

Like I said, it’s probably premature. Having the request ready to go either way would still be a safe course of action, and you’re “it” now.

6

If there is an issue, it’s related to Asterisk. BLF subscriptions and hints at the level discussed here are controlled by Asterisk. The same post made over in the Asterisk forum would probably net you better info with regard to which RFCs are supported.

3 Likes
7

What asterisk version were they using? Actually I have some old grandstreams doing this same problem myself. I thought it was just the phones because they get fixed upon restart too but maybe not…?

If anyone else has noticed this with other phones post in here. I want to get this fixed its becoming a problem.

@lgaetz Ok so its probably an asterisk problem. Thanks!

1 Like
8

I would approach this as a Yealink problem, inasmuch as hints are working fine for everyone else.

9

… Unless it’s the same problem the Grandstreams are having.

Haven’t done the research, but it might be a good discussion to start on the Asterisk side. Having said that, though, that puts implementation out a solid six months…

10

The problem is in this bug report (Vote for it plz): https://issues.asterisk.org/jira/browse/ASTERISK-27759

The problem is that as BLF’s change their BLF “version” counter increases on both the server and the phone. Some phones and firmwares correctly impliment the RFC Yealink was referring to and reject version counters below their current counter.

Yealink’s new firmware follows that standard and so if the version is at BLF notify #123 it will reject any numbers below #123.

When asterisk restarts it sets that counter to 0 and does not inform the phone. So the next BLF update sends a notify #1 and the phone rejects it because it is below #123.

So yeah this could span across many different brands but only affects the ones that use BLF keys heavily and that properly implement that RFC standard. As I see it the only options are to:

  1. downgrade yealinks to the 81.0.X firmware that are not reliant on this
  2. Do not restart asterisk
2 Likes
11

But when asterisk restarts it has no info anymore as that is all in memory. The biggest issue is yealink forcing you to adopt a new standard. The need to let you pick. I doing you will see a change like this in asterisk anytime soon and if we do it will be ok PJSIP only not chan sip.

2 Likes
12

Good point. I let Yealink know it would be a wise decision to have their yealinks be able to change its behavior between the old and new behavior because otherwise they will be broke on all non up to date asterisk versions along with todays version.

2 Likes
13

This is completely not a Yealink problem. It is an Asterisk problem. That said, Yealink should never have implemented this without a way to make the BLF use old behaviour until Asterisk also supported the RFC.

Using standards is a good thing .

2 Likes
14

I’ve talked with Yealink and it sounds like company policy to adhere strictly to the RFC standard.

Personally, I think the suggestion is good.
But for the whole company, we will not consider this new feature, unless a new project MUST need that. Because we have followed the RFC standard, that may be not a best option, but that is not wrong.

table-flip
table-flip600×547 67.3 KB

1 Like
15

But they use to handle asterisk BLF fine. Guess that is their loss.

16

Yeah they adhered to the standards in firmware V82. Before that they didn’t enforce it. Now BLF’s are broken upon asterisk restart in V82+, unless you reboot the phones after restarting asterisk.

Maybe if more people bug them they will change the policy? Really sucks since they fix some backup server issues in V83.

1 Like
17

I recently updated some yealinks T-48S’s to 66.84.0.10 from 66.81.0.70 because I wanted to use Opus. But now I seem to have the same problem as described in this post. Even with subscription period set relatively low, this still seems to happen. Are there plans to resolve this problem?

1 Like
18

Yealink needs to change their behavior. All worked fine until you updated firmware on the phones. They need to work with how asterisk does things like they use to and decided to change that behavior with new firmware.

19

There is an active bug ticket for asterisk to fix this, yealink says asterisk isn’t following a standard, here: ASTERISK-27759: res_pjsip_pubsub: Subscription persistence does not preserve XML <dialog-info> version number

Only solution to this that I have found is Move back to firmware 81.X or never reboot asterisk without rebooting all phones to go along with it.

Yealink is saying they are following the RFC standard and that asterisk needs to update to match it.

They claim asterisk isn’t following RFC4235. I’ve noticed similar behavior on grandstreams as well. I just blamed it on grandstream but now other brands are exhibiting the same behavior with updated firmware. It might be a good idea to double check that RFC since this problem is happening on new Grandstreams and Yealinks.

1 Like
20

Come to think of it. I think I’ve also recently seen this behavior exhibited on Grandstreams with new firmware too. Which would seem to indicate that this is more than a “yealink is wrong” problem.

1 Like