Web Client (and browser extension) DTMF not registering

Status
Not open for further replies.

ckobayashi

Free User
Joined
Jan 12, 2021
Messages
34
Reaction score
8
We are using the web client in our organization and several users have reported external IVRs not registering touch tone input, meaning they are unable to dial extensions or navigate IVRs at other companies.

I have attached a recording of a call I made from my web client to my mobile phone. The recording was made by my mobile phone. In the recording I can hear two very brief DTMF tones for each key I press in the web client. It seems these tones are not enough to be registered by external IVRs.

What settings should we evaluate in our 3CX server configuration? I don't see any readily apparent settings for this in the server application or the web client. Our server version is 16.0.9.

Thanks in advance,
 

Attachments

This is usually a problem with the SIP Trunk you are using to make calls.
There is no easy way of checking this that I can think of, you need to make a packet capture to capture a whole call you make to the IVR of an external company, then check if the provider supports "telephone-event" or not, then see what 3CX is sending.

Are you using a supported provider?
https://www.3cx.com/partners/sip-trunks/

If yes, tell me which one, and then in a PM send me the number you are dialing and will try and check.
 
I have faced the same problem, but a realized that this problem occurs only in chrome / edge with or without extension, if I use in a mozilla firefox, for exemple, it's works fine.

Any ideias ?
 
For me I was having this issue with the windows softphone and then tried the edge extension and it worked fine. I was calling the comcast 1800 number. I then tried the windows softphone and it still wasn't working. I validated that RFC2833 is set on the windows softphone.

I use telnyx and have my codecs set as G722 then G711. I found this from Telnyx on there codec info page -

Note on DTMF:
The tones for DTMF are not transported reliably in G.729 and cannot be expected to work under any conditions. They're also not expected to work reliably with G.722, but may do so. DTMF should always work perfectly in any G.711 stream. DTMF tone frequencies were chosen to work with the PSTN, so must work reliably when encoded with G.711, which is the only codec in which we should expect no problems.

So I set the softphone to be G711 and retried calling comcast and it worked great, with not as nice sound quality but it worked. So I set it back to G722 and it's been working fine in the windows softphone since on G722. Super weird...
 
It is true that In-Band DTMF tones were designed to work with G711A/U codecs (PSTN Network).
However with the introduction of VoIP, DTMF tones can also be sent over and out-of-band method, commonly called RFC2833 DTMF. RFC2833 does not rely on the actual codec the audio is being transmitted over, these DTMF 'tones' are separate packets.

So, 2 types of DTMF transmission available, keep that.

Provider now have 2 ways of negotiating which DTMF transmission method will be used.

Some providers will 'upscale' or 'downscale' In-Band to RFC2833. What this means is, if you are calling from a modern PBX like 3CX that supports RFC2833, to a legacy analog PBX that supports In-Band, the provider will 'translate' RFC2833 to In-Band, and vice versa.

Other provider take a different approach, they are 'transparent'. This means that when you make a call from your modern PBX, depending on what the other side supports, the provider will just pass along the message, so in the same example is above, even if your PBX supports RFC2833, if you are calling someone that has an old PBX that only supports In-Band, you will have to send In-Band, not RFC2833.

3CX does both and can send In-Band DTMFs over any codec, but it comes down to how the 'far end' reads those codecs. If you are facing such issues, in your SIP Trunk settings in 3CX set the first 2 codecs to the G711A and G711U (PCMA and PCMU).

This, until hopefully the world is rid of PBXs that don't support RFC2833 DTMFs!!!

(sorry for the long reply)
 
It is true that In-Band DTMF tones were designed to work with G711A/U codecs (PSTN Network).
However with the introduction of VoIP, DTMF tones can also be sent over and out-of-band method, commonly called RFC2833 DTMF. RFC2833 does not rely on the actual codec the audio is being transmitted over, these DTMF 'tones' are separate packets.

So, 2 types of DTMF transmission available, keep that.

Provider now have 2 ways of negotiating which DTMF transmission method will be used.

Some providers will 'upscale' or 'downscale' In-Band to RFC2833. What this means is, if you are calling from a modern PBX like 3CX that supports RFC2833, to a legacy analog PBX that supports In-Band, the provider will 'translate' RFC2833 to In-Band, ad vice versa.

Other provider take a different approach, they are 'transparent'. This means that When you make a call from your modern PBX, depending on what the other side supports, the provider will just pass along the message, so in the same example is above, even if your PBX supports RFC2833, if you are calling someone that has an old PBX that only supports In-Band, you will have to send In-Band, not RFC2833.

3CX does both and can send In-Band DTMFs over any codec, but it comes down to how the 'far end' reads those codecs. If you are facing such issues, in your SIP Trunk settings in 3CX set the first 2 codecs to the G711A and G711U (PCMA and PCMU).

This, until hopefully the world is rid of PBXs that don't support RFC2833 DTMFs!!!

(sorry for the long reply)
Don't be sorry for the long reply. That was very informational and it explains a bit. Thanks Nick.
 
I raised the issue with our SIP provider (@NickD_3CX unfortunately we are not using an supported provider) and they just provided this feedback:

From what we can tell with the provided examples, the PBX seems to be duplicating the tones and should be investigated locally.

Their recommendation is perform a packet capture at the PBX to see what it's sending. Is this something that can be performed if we open a support ticket?
 
Since an unsupported SIP Provider is in use, 3CX Support may be able to check the 3CX PBX side and confirm whether the data sent by 3CX is what is expected to be sent.

Do consider contacting a 3CX Partner to get help on this matter. If necessary they can then contact 3CX Support on your behalf.
 
Status
Not open for further replies.

Forum statistics

Threads
112,349
Messages
592,026
Members
165,512
Latest member
gmacinit