Originally published at: https://www.freepbx.org/yealink-endpoints-now-certified-for-freepbx/ As part of our ongoing efforts to expand the FreePBX EcoSystem we are happy to announce that Yealink has completed the Certification process to become a Certified Hardware Partner and included in the FreePBX EcoSystem Program.
Certification means that Yealink and The FreePBX Project engineering and development team now have a direct relationship and are work together to ensure that our shared end users and partners that wish to utilize Yealink devices when building their communications platforms have assurances that Yealink endpoints have been tested and provide great functionality and usability within the FreePBX Platform.
Certification also means that Yealink phones that have been submitted for Interoperability Testing are now officially supported within the FreePBX EndPoint Manager. EndPoint Manager support allows easy provisioning and management of supported endpoints directly from within the FreePBX Administrative GUI. In addition many Yealink phones also are now listed as a supported devices for running the popular FreePBX Phone Apps. Phone Apps integrate FreePBX features and calling functions directly within the supported phones interface. This integration allows enhanced usability and functionality for end users deploying FreePBX Communications Systems.
“With FreePBX, the world’s most popular open source PBX, Sangoma delivers a platform that allows organizations to build communications solutions to fit their needs,” said Preston McNair, Vice President of Sales at Sangoma. “By extending our relationship with Yealink, we are building on a collaborative alliance of Certified Hardware and Software Partners, that have been instrumental in the adoption of FreePBX worldwide and have delivered on the promise of an open standards-based UC solution for businesses of all sizes.”
“We at Yealink are pleased to see deepened cooperation with FreePBX through our expanded FreePBX-supported phone array,” said Stone Lu, Vice President of Yealink. “Our relationship with FreePBX reflects our consistent pursuit of the broadest possible compatibility and reliable yet flexible VoIP solutions,” he added. “We look forward to future cooperation with FreePBX as we jointly promote our solutions worldwide.”
As a user of both Yealink phones, Restful phone apps and commercial EPM, I think Schmooze and Yealink should look into fixing the the broken record function on Yealink phones.
The SIP Notify of ‘Record: on’, that is sent when a user presses a “record” softkey on a Yealink phone requires that the feature code is called ‘automon’, but FreePBX no longer uses that, which breaks the recording feature. issues.freepbx
Also, I would be happy if you built a feature into the UCP for EPM module, that allows the user to set time zone on an individual bases for a particular phone. I have many remote phones in different time zones, but don’t want to have to build EPM templates for each of them.
Yealink phones have no way of pulling time zone automatically from DHCP.
Just to make sure effort isn’t focused in the wrong place, but I believe this appears to be more of a Yealink issue than anything else. In the forum discussion that @Marbled referenced, if you start reading from this post forward - g722 Codec Problem - it appears that Yealink and Grandstream, perhaps others, do not negotiate the codec priorities properly.
I say this only because it probably is not an Asterisk issue. The problem most likely lies with the phone manufacturers and their firmware. Therefore, since some effort has been put in place by both the FreePBX team and Yealink to certify Yealink Endpoints, it would be in the best interests of Yealink and the FreePBX team to sort out the issue (regardless of whose fault it is), so that customers who purchase Yealink Endpoints based on the fact they are Certified for FreePBX are not disappointed, frustrated, or worse, when they encounter the problem. The issue has been reported on the Yealink forums, you can find it here: Bug involving codec G722. It has been reported by 2 users in that thread, with absolutely no resonse from Yealink. Likely, the FreePBX team could more easily get the attention of Yealink engineers to point out the bug in the firmware and motivate them to work on a fix.
It is nice to see FreePBX establishing these relationships with hardware manufacturers. It will no doubt continue to make the FreePBX Distro an outstanding product.
Quite likely (though it could also be a Yealink problem because not all phone manufacturers have this problem) but I agree with what Bullfrog said and I think the same…
People expect (and rightfully so) something which is certified to perform admirably with the product it is certified to work with and currently something in the FreePBX/Asterisk/YeaLink solution makes this very far from the truth…
And the FreePBX distro is a FreePBX/Sangoma product isn`t it not? It is affected by this problem and I don’t think that someone who would invest a lot of money in that solution thinking that is is certified to work would be very happy with being told that his certified product doesn’t perform correctly, that it is a known problem and that it is assumed that the problem is in another product made by another company but which is bundled with the FreePBX distro…
(A product that is a vital part of that solution…)
It’s not important to know whose fault it is, your clients don’t care, they just want something that works and certification is supposed to give that assurance…
While there may or may not be a fixable bug in asterisk/FreepBX/yealink firmware, out of the hundreds of yealink endpoints I have deployed, which cover at least five different models, I have never, ever, been able to reproduce this issue (if I am reading the thread correctly). I have only ever seen where a call won’t set up at all if there is a codec mismatch, I have never seen the call set up successfully and then not work due to incorrectly negotiated codecs and this goes back to asterisk 1.2 and trixbox and up to asterisk and fpbx 13. I have also been using g.722 as a primary codec on the pbx side for as long as I can remember with the exception of certain polycom endpoints which had issues with it. What are the codec priorites on the SIP settings, extension settings and endpoint for someone that has had this issue?
Its FreePBX that Yealink is certified with. FreePBX Distro has nothing to do with their Certification. FreePBX manages Asterisk configs so if something is broke between Yealink and Asterisk that would need to be sorted out between those 2 entities. I know at one point Yealink was Asterisk Certified. Not sure if they are anymore.
The only direct interaction I can think of between the phones and non-distro FreePBX is the Endpoint manager (or related phone apps).
If that’s the case then shouldn’t they be the ones certifying you as being compliant, etc… and not the reverse?
You might want to tell that to the guys who wrote those press releases and documents because by itself something which manages Asterisk configs is not a PBX by itself and is only one part of an “ecosystem”, not the whole ecosystem by itself. Part of that “ecosystem” are FreePBX appliances for people are most likely entirely dependent upon you to fix any issues these might have.
Both products are now part of that ecosystem and directly affect your products performance.
If someone buys one of your appliances and Yealink phones and encounters this problem even though both are now part of the “FreePBX® Certified EcoSystem Product Program” I am not sure they will be very happy to know that FreePBX/Sangoma is unwilling to do anything to get the problem fixed and the problem has been known for a while.
Yes, you are right that FreePBX is very likely not to blame in any way in this but you now have a direct relationship with Yealink and could let them know about the problem, you would be able to report to them an “upstream bug” which is a very normal thing to do for any open source project even though they are not to blame either…
Someone as just suggested today a possible cause of this problem in the thread I mention earlier by the way…
Please report the problem to them, everybody will win including you…
@Marbled I have pinged @Yealink_James and @Yealink they can assist with taking a look at issues you may be encountering, if you note in the various threads on this, some people seem to have an issue, others can’t replicate, it’s tough to make a bug a priority if it can’t be replicated reliably by development and engineering staff or other users.
Hopefully Yealink having access to their phone firmware source code will be able to identify its possible issues and edge case (and replicate them) more easily than any of us and someone has recently suggested a possible reason for this problem.
Thank you very much for doing this, everybody will win from having that problem corrected…