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/5.5.1.15880 was installed via EPM.
I think it was set as a standard in 2005: RFC 4235 - An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
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.
2 Likes
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.
https://wiki.freepbx.org/display/FPG/EPM-Admin+User+Guide#EPM-AdminUserGuide-InstallingCustomFirmware
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.
Yes the 84 firmware is no different
2 Likes
Asterisk doesn’t implement every voip RFC that exists. It would be silly to think they should.
This affects us too. Yealink T46S phones, 66.82.0.31 firmware. I was hoping to update to v84 firmware, but according to everyone’s comments here, I actually need to downgrade to v81.
+1 vote for fixing this in Asterisk soon. I like standards. Though I agree that the phone manufacturers should have synchronized this fix with Asterisk so they would all remain compatible with each other.
3 Likes
I see that Sangoma has released V84 into Endpoint Manager. Curious if anything was done in regards to this issue, as this would cause support calls when the BLF keys stop working on an asterisk restart.
I’m still running V81 and will have to test again with V84. I don’t believe they have a cfg guide yet, to see if there is anything that may help with this issue.
Did anyone post or speak with Yealink about an option to allow a toggle?
I’m seeing the issue on v84 with FreePBX 14/Asterisk 16 on T46G and T46S phones. I haven’t seen any action anywhere to suggest a real fix is close to coming forth. FWIW, since its been verified as an issue with multiple vendors (Yealink/Grandstream/Obi to name a few), I think the onus is on Asterisk to fix.
2 Likes
The Asterisk Community post has not been updated for a year now. Last update was from @jcolp.
There is also an Asterisk bug report. It has also not been updated in a year.
A question of clarification on this topic:
BLF breaks on Yealink V82 or greater when Asterisk is restarted or also when reloaded?
Now if that happens and the phone gets rebooted, the BLF counter on the phone gets reset and BLF starts working again?