The point of editing the base file is you only do it once for every phone that uses that base file.
I have done some further testing on this and if you downgrade a T46S to the original supported firmware in EPM 1.17 Yealink version 66.81.0.70 this error goes away. So this seems to be an issue with the new EPM 1.18 Yealink version 66.84.0.15 firmware and how it handles speed dial keys. I have also tested newer non supported firmware and the issues is still present. Has anyone heard back from yealink yet on this issue?
Not going to see an update soon. Not really any different than all but nothing getting don in the US around Christmas. Also, I have no idea what part of China. or if they are being impacted by the virus outbreak.
Just out of curiosity @sorvani, did you ever hear more detail back from Yealink on this?
Their ticket has not been updated since January. I thought yealink had posted something about extended closures do to COVID-19, but I cannot find it now.
So I was not really expecting much.
The current status of the ticket:
That said, EPM still needs to not populate that field as it does.
Just to chime in on this issue, as I have a ticket opened with Sangoma and Yealink. I noticed this starting in V84, while V81 firmware is fine, just as stated above. Right now, Sangoma says it is a Yealink issue and Yealink is going to fix it. While Yealink says it is a Sangoma issue and Sangoma has to fix it.
Yealink Ticket - 101856
Sangoma Ticket - 948114
I’ll update both tickets and reference this thread, as this is the exact issue I’m having as well. Thanks Jared for opening a ticket back in December. Hopefully this will be fixed faster than the BLF issue that is also in V84.
Chris
1 Like
@jsmith because the Sangoma ticket is not public for EPM, What is the status of fixing EPM to not populate when it should not be.
This thing that prompted this entire conversation and the finding of the bug in the firmware (Yealink issue) is something that should never have been populated in the first place (Sangoma issue).
Here is the reference from earlier in this thread.
It is simply lazy programming that puts the ** on every button even when it is not set to the correct type that would actually use it.
I’m trying to keep that EPM issue moving along internally, but I wanted to make sure my understanding of the situation aligned with what others are seeing, so that we can get to a resolution sooner rather than later.
The EPM issue and the Firmware issue are technically unrelated.
The EPM putting the ** in a field that it does not belong simply led to the discovery of the firmware bug.
Researching/testing the firmware bug is what led me to RTFM in more detail and thus realize that EPM was populating the wrong thing.
Just to give an update to the community, Sangoma has given me a beta update to test and see if it resolves the issue. I’ll send an update after I test it on our Yealink T41S here.
Chris
1 Like
Good news!
I tested this and it is now resolving the issue. The config file now has %EMPTY% instead of the ** for the pickup_value. When the phone applies the config, it is now leaving out the **.
Example section from my phone config:
linekey.8.label = TestSpeedDial
linekey.8.type = 13
linekey.8.value = 2000
Same example section from Endpoint Manager Config:
linekey.8.line = 1
linekey.8.value = 2000
linekey.8.pickup_value = %EMPTY%
linekey.8.type = 13
linekey.8.label = TestSpeedDial
At this point, I would say this resolves the issue. I’ll see about applying it to other phones and see if I encounter other issues.
Thanks Sangoma for getting a fix out there!
Chris
2 Likes
The test file that i was given to try did not resolve the issue for me.
Edit: correction, it resolved type 13 (speeddial) only. other key types still have a pickup value of **.
Shouldn’t the other’s have the ** for the pickup_value? The BLF keys would need it, for it to pass it onto Asterisk. Looks like you’re meaning to limit this so it is only used for Type = 16? The XML (Type 27) also has it as well, and it is working fine.
Chris
No. This field should basically not be used for anything.
If you go back up to my post from December 19th, when I linked the admin guide, it basically tells you that.
linekey.X.pickup_value should not be used in the first place for this. it should be using the linekey.X.extension field for linekey types 14 (Intercom), 16 (BLF), 24 (Paging), or 39 (BLF List)
Ok, then that makes sense. Just to have it cleanup the config, it would make sense to take that out. At least right now, my phone are back to normal for the speed dials at least. Hopefully Sangoma can make that one additional change, and it isn’t causing any problems.
Chris
Right. Speed dials are fixed. But as this thread ended up proving, there is a bug in the Yealink firmware also. So why cause the bug to trigger when it should not even be populated in the first place?
But assuming this was a simple enough change, I think that it needs to go to QA and be released without waiting on the rest of the changes. because Speed dials is the thing most often used other than line keys and BLF keys.
Hi @sorvani yes as speed dial was most common issue so tried to fix that first and released edge release of EPM also for FreePBx-14 and FreePBX-15 to give try.
I’ll be looking further on your suggestions to improve configuration.
Thanks
Kapil
1 Like
Thank you all for getting this released, as I was anticipating this taking a while. I’ll update this thread if I do run into any other issues with the phones. I know there is another thread discussing the BLF keys, and I will be monitoring that as well.
Currently, Yealink gave me an support firmware release of 66.84.0.111 that I’m testing as well.
Thanks again for all of your help!
Chris
Yes, just for clarification – the updated in “edge” only fixes the “**” issue for speed dials – it hasn’t yet done anything with other types such as BLF keys. Stay tuned for more updates around those.
Did they say what this was for? because my ticket has not been updated at all.