Solved PBX no longer sends DTMF codes in call after upgrade to 16.0.3.676

[Felicia King]

I installed the latest release candidate after having read the release notes for it. Now if I call anything where a DTMF code needs to be sent over an existing call, no DTMF code is sent.
So imagine you are calling someone else's phone system. You get into their autoattendant and no DTMF codes are sent, so you can't even select any menu options.
I have tried this from the web client, the soft phone, and the mobile app. It all behaves the same, so this is a problem with the PBX and has nothing to do with a particular physical desk phone.
I have tried from different phone extensions. All same behavior.
I have clients that have not been upgraded yet. Their phone system works fine. They are running 16.0.2.910.
Nothing was mentioned in the release notes for 3CX update that it was going to break DTMF capability in the phone system. What is going on?

 

[cobaltit]

So 16.0.3.676 is the final, not a RC. And if it was a 3CX issue, I'm sure you'd be seeing a LOT more complaints about it since it was released yesterday. It sounds like an issue with your trunking provider. Are you using a 3CX certified SIP trunking provider?

 

[AWS2P]

All our pbxs are updated to latest v16 sp3 and we have no problems with DTMF

 

[Felicia King]

Thanks guys,
Using SIPTrunk and everything worked perfectly prior to the upgrade to 16.0.3.676 on the same trunk. I looked up https://www.3cx.com/blog/voip-howto/dtmf-rfc2833/ and it is recommended to use inband DTMF delivery. I have not made any changes to DTMF defaults in the PBX. The clients that are working fine are also on SIPTrunk. Inbound calls to our PBX in the IVR from an external cell phone register correctly. Also I made a call from a client PBX on 16.0.2.910 into our PBX and was able to interact with the IVR properly. So the issue appears to be that our extensions are no longer sending DTMF when in call. Any ideas?
I can call the number for our IVR in-house and the DTMF codes work properly there to make the selections.
Do you still think it is a trunk issue?

 

[leejor]

So you are using Inband DTMF, correct? That being that case, it might be a Codec issue. Inband DTMF requires you use G711a or u, or the DTMF will not be reliable. Check to see which Codec are set, and being used on the trunk to your provider. you may also want to consider (test) using a different DTMF method, as set on the phones.

See... https://www.voip-info.org/sip-dtmf-signalling/

 

[leejor]

There was a post a while back, about DTMF issues, after upgrading to version 16. I seem to recall that a re-boot cleared that.

 

[Felicia King]

Update for you guys with a solution. I contacted SipTrunk about the issue. Their support is excellent as always. Apparently the issue was very isolated and difficult. They did a trace through a media server to provide better visibility to what was going on. At my suggestion, I made them an extension on my PBX temporarily so they could test at will and watch the traffic.
With that, they were able to determine that the issue only occurred when calls were coming from my PBX to a client PBX. They described it as calls from my numbers were being treated differently than from other calls. So they changed the path to get to my client phone numbers from my phone numbers which got DTMF working.

 

[leejor]

Was this an issue to only one other destination, or any call to an IVR on another PBX? The explanation given to you by your provider doesn't really make clear what the issue/solution was.

 

[Felicia King]

One other tidbit of useful troubleshooting.
If you call 631-791-8378, there is a DTMF testing option. This could help identify if the problem is all outbound DTMF on the trunk or just a single path to a number.

 

[Felicia King]

Hi Leejor, the problem was a path from my numbers to the numbers of my client's PBX. So it was a SIP routing issue. It only affected the numbers associated with my client's service.