We are having an issue where any key's being pressed during the listening of a Voicemail greeting is not registering. For instance as soon as you sign into your VM box with the password and start listening to the VM, you cannot press 7 or any other digits.
I've just noticed this problem on my T46S as well as T42S. Oddly, this was working before doing some minor changes to the PBX system... I just wish I knew what caused things to change!
Changing the phone setting to RFC2833+SIP INFO resolves the problem.
You can also simply remove the OPUS codec from the list of enabled codecs. Strangely, even if OPUS is at the bottom of the list of enabled codecs, the problem still appears. I'm pretty sure this is a Yealink bug. Someone on irc sent me some very useful info (agree_) about it. You can change the dtmf payload to 103, or just disable OPUS.
We recently stumbled upon this issue with 4.5.7 on Debian 9; we too have yealink phones.
We were able to resolve it by going to Advanced > Default Settings > Provision (Category) and setting the variable 'yealink_dtmf_type' to the value '3' as pictured in the attached screenshot. After quickly reprovisioning the yealink devices (In Status > Registrations, press "Provision" ), we can DTMF press away through the IVRs and Voicemail menus much more quickly and reliably.
Hope this helps someone.
I am struggling with an issue where the phones use PCMA, PCMU, G722 and G729. I've got the same codecs on my Fusion Trunk with the difference of OPUS being added as my first priority codec.
Phones are a mix of Polycom IP33X, some polycom IP650 and yealink phones (various).
Calling to an OPUS enabled system works 100% on audio but having some issues when using DTMF though. If I call from an OPUS enabled device, via fusionpbx, to a number compatible with OPUS everything works 100%.
Seems to be something wrt something happening on the backend between the phone and fusion. DTMF seems to register on fusion but not on the remote system.
One thing that I have noticed is that, at some point, the remote party sends a Re-INVITE, because PIN has been put it allowing you to call their conference bridge. DTMF seems to break after this happens. At the same time Fusionpbx sends RTP -> OPUS and right after RTP -> G722