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
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? Or is this a bug in the BLF version incrementing?
I’ve got a phone, not a Yealink. It sends a SUBSCRIBE for a URI - 114. Asterisk sends an OK. Asterisk sends a NOTIFY with version set to 0. 114 makes a call. Asterisk sends a NOTIFY with version 1. 114 hangs up. Asterisk sends a NOTIFY with version 2. The phone unsubscribes by sending a SUBSCRIBE with an Expires of 0. Asterisk sends an OK, then sends a NOTIFY terminated. The phone later decides to reSUBSCRIBE. The version starts over a 0, and seems to increment correctly.
I’m using Asterisk 15 out of branch; it shouldn’t be particularly different from 13.22. I’m using chan_pjsip.
Under what sequence of events can someone cause Asterisk to not increment the version on the dialog? How does one reproduce this?
This seems like the same issue we have noticed in 15.x. From what we have deduced, there is a bug in Asterisk where the version number in the NOTIFY payload is reset to 0 at restart. Since the phone isn’t aware of this, it still expects the version number to be increasing and many phone models ignore the NOTIFY messages assuming they are old. Not sure if that’s exactly your issue, but if you are restarting Asterisk I’d assume it’s related. You could test by capturing SIP packets before and after a restart to verify what version Asterisk is sending in the payload.
At this point I am still trying to figure out how to actively reproduce this. It’s happening for around 70 phones on one server and it seems to either affect 1 phone at a time or an entire sites phones all at once. It gets fixed upon rebooting the phone.
A phone on a different server, same asterisk version, had it’s BLF lights stuck yesterday and now today the BLF lights are working normally without rebooting that phone?
phlobot over at the freepbx forums said some newer grandstreams were having the same thing.
P.S. I also have some old grandstream 2124’s doing a similar thing with the same reboot resolution.
Edit: Not sure if its related to that. I will have to pay attention and see if I can find out more. We do restart one server’s asterisk often but the main one I am referring to we do it less often.
I think this may be it based on how this played out.
Two weeks ago I updated the firmware on my Yealinks.
The old firmware 81.0.X did not keep track of the notify counter. The New firmware 83.0.X keeps track of the notify counter and discards old ones. As per Yealink.
Went on vacation last week.
Server was not restarted during that time and everything worked great.
Restarted asterisk this Monday.
Next day/s a shit storm of people saying their BLF’s are not updating.
Restarted most of their phones and they have been working since
Have not restarted asterisk since
No new instances of this problem on that server.
So all Yealink phones with newer firmware may have this issue on asterisk… Shit.
Our workaround was to disable subscription persistence so that Asterisk forgets them on startup and requires the phone to re-request them. We did this by modifying our sorcery.conf file with the following:
Again, this is 15.x and we are not using FreePBX. I believe the setting should still apply but I’m not familiar with 13.x and don’t know how easy it is to get to the Asterisk configs with FreePBX. It’s something to try if you get a chance, though.
Interesting thanks! I will have to try this. The main server we are having the problem is 100% PJSIP so I should be able to try it.
I’ve not modified sorcery but in general its not bad. Edit the things in the CLI or they even have a GUI config editor now. Typically have to edit the _custom file it generates.
Asterisk is an open source project, so there’s no guarantee on when anything will be resolved. What people work on varies between what they are personally interested in or what their own company requires.
