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

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 .


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.

1 Like

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

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

I recently updated some yealinks T-48S’s to from 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

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.

There is an active bug ticket for asterisk to fix this, yealink says asterisk isn’t following a standard, here: Issue Navigator - Digium/Asterisk JIRA

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

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

Guys it may very well be asterisk is not following the RFC the way they want it but asterisk is a huge project and my point is both Yealink and GS both worked fine for 10 plus years with BLFs and magically they both update their firmware and it breaks BLFs with asterisk. I think it’s on them to also take ownership in this. We can’t just go changing BLFs in asterisk because of changes they made and risk breaking things for other manufactuers that work just fine.

Same problem happening to Polycom VVX410.

1 Like

What software is the Polycom VV410 running? Ive told you before I’m 90% Polycom / 10% Yealink when it comes to deploying phones. I have yet to see these Polycom issues you keep referring to.

I can’t 100% speak on Yealink, as I haven’t moved them to the latest firmware yet.

When I did a brief test with Yealink 84 firmware, I experienced the same issue described above. If you reload asterisk, the BLF keys did stop working until you restarted the phone.

In regards to Polycom, just searching for RFC4235 on Polycoms site yields a reference in Firmware 6.3.0:

“To notify the call states of a monitored extension, your phone expects the NOTIFY message body to include
a dialog-info XML (Content-Type: dialog-info+xml) that is compatible with RFC4235.”

Maybe a lot more of the phone manufacturers are beginning to force that standard?

I agree with Tony’s statement that manufacturers shouldn’t just go changing basic functionality without giving some type of notice. On the same token, if there is a defined standard, I would assume everyone, over time would move to that standard for compatibility. The question is why was there no notification about changing that standard?

Seems like the next step would be for Asterisk to look at the RFC4235 standard. Or work through the manufacturer channels and notify them of the issue and work together toward a resolution.

Any chance someone from the Asterisk team could chime in on their thoughts on the issue?

On a side-note, I do appreciate the Sangoma team at least responding to the issue and commenting on the forums. This reflects the fact that the company is taking time to listen to the community. Thank you for any help!

1 Like

This is for the Obihai phones. Remember, Polycom bought them. I’m referring to the Polycom UC software that runs the VVX series phones, 301, 401/411, 501/511, 601/611. That is on 5.8 right now.

Two different phone lines, two different firmware releases, one company (now).

PolycomVVX-VVX_410-UA/ was installed via EPM.

I think it was set as a standard in 2005:

I wonder how many manufacturers are following that standard and how many other PBX systems follow it? Is it that manufacturers are adopting it too quickly or that asterisk is slow at adopting it?

It is nice to see Sangoma participating in the forums often. One of the great things about them.


Yeah, in my reply in the PJSIP thread was that Polycom UC pre-5.6ish had a BLF bug that caused issues. Updating the phones to UC 5.7 or higher (5.8.x is the current) will fix this bug.

The problem with relying on the EPM for your firmware updates is that the firmware packs are never “up to date” as far as current releases. They need to be tested, verified and made sure the changes/fixes/updates don’t break how the EPM templates configure the phones. When someone like Polycom isn’t a “certified partner” with Sangoma this makes it even harder.

UC 5.5 is like 2+ years old and has bugs, like this, that have been resolved in current firmware.

OK, so testing the updated firmware on Yealink was on my to-do list before the end of the month but now I’m very curious about this. So I’m going to be moving that up to this weekend/early next week.

My question to everyone is this, how did you configure your Yealinks on firmware 82.0.x or higher? Are both the firmware and the configs handled by the EPM module?

Currently, you have to do a custom firmware. I did this for the 84 firmware.

The only caution is make sure you run chown to asterisk:asterisk when you upload via SCP to the folder.

It is interesting that they haven’t released any newer firmware than V81 for Endpoint manager. I do know there are tickets open for the newer firmware.

Let me clarify why I asked that question. I do not use the EPM, myself, anymore. I have my own provisioning server and my own templates. I will be testing this using my templates and even directly configuring this in the phone.

I asked because if everyone says “Yeah, we do” and then I cant replicate the issue then my next test would be via the EPM. If the issue can be replicated after that then it does narrow down the field.

Let’s put this another way.
RFC2435 is from 2005. So why has Asterisk never supported it?

@tonyclewis You are getting very defensive for no reason. No one is claiming that Sangoma failed to do something here.

But what is being pointed out is that Asterisk needs to be updated to follow standards. This is why standards exist. Will it happen during the life of Asterisk 16? 17? /shrug No idea. But it should happen.

I also said in my earlier post that I feel Yealink’s actions were also overboard. Making a change that affects things at this scale, obviously without any testing of the change, is bad.

Edit: Yes, I know that a RFC is not a Standard, and RFC 4235 was never made a standard. It was also updated by RFC 7463 in 2015. I am also not someone that is so deep into the Protocol, that I know if Yealink actually followed this correctly or not.

1 Like

Have you tried the newest release? 84 is out and it has a bunch of both “new” and “improved” featurea for BLF functions. Nothong listed as a big fix but almost a 12 new/improved features.