DTMF not working correctly post upgrade - 1 fails, 2 works

[rcanpolat]

I have some users reporting DTMF is not working correctly following an upgrade from V18 to V20.

DTMF works fine internally but when we a specific customers phone line and press option 1 we get a response that the entry was not recognised. I would say this is the customers phone system that has the issue but it doesn't happen when we call of regular cellular phone 4g connections to the same numbner. It happens when we use the desk phones, mobile app and PC client. Oddly enough it doesn't happen with every number either, number 1 has an issue but number 2 works fine.

Oddly enough when i call a different number, example my online banking provider then number 1 works fine for their system. When i call my mobile phone and listen to the DTMF tones they sound identical from both mobile to my 3cx and from 3cx out to my mobile. When i call the customer from another landline (non 3cx, belonging to another company, another provider) it recognises pressing number 1.

Just adding to this, my SIP provider requirments below which worked fine on V18.

DTMF rfc2833
Codec G.711
SIP port 5060 UDP

 

[OlegR_3CX]

Hi there.
Does it mean you are using the provider that is in the list here ?

 

[rcanpolat]

Correct, im using a provider not on the list.

Just reiterating that i did not have this issue wit the same provider prior to upgrading V20. What's changed that could have broken this?

 

[OlegR_3CX]

Not sure what is the cause. You should not have an issue there if you are up-to-date, however, you can compare your networking captures and see the difference between then.

 

[edossantos_sipcaller]

DTMF detection issues are most likely caused by the DTMF being send as in-band audio and not via RTP payload according to RFC2833. You can confirm this by running a Wireshark capture. Don't rely on what you hear, these tones should be sent as signals and not audio.

 

[rcanpolat]

DTMF detection issues are most likely caused by the DTMF being send as in-band audio and not via RTP payload according to RFC2833. You can confirm this by running a Wireshark capture. Don't rely on what you hear, these tones should be sent as signals and not audio.

Ok so where is the setting in 3cx V20 to change that because it worked fine on V18.

 

[edossantos_sipcaller]

Ok so where is the setting in 3cx V20 to change that because it worked fine on V18.

This is not a 3CX setting. The endpoints (phones or SIP Trunks) are the ones who send these signals as RTP payload events or audio. If this worked in v18 then maybe in v18 3CX managed to recognized these signals from the audio stream, but if this is not working now, you should not blame 3CX, because it's the endpoint who is sending this in a wrong format. Run a Wireshark capture so you can identify the responsible endpoint.

 

[rcanpolat]

Ok i need to sit in this for a while. I did submit a ticket to my trunk provider who have possibly made a change because i've just tried 2 wireshark captures and DTMF for option 1 worked on both tries