3cx ivr choice pick problem

[Alekos]

Hello, I am new in 3cx, we trying to setup some simple ivr app using cfd and we are unable to accept choices from some telephone providers, or we do after keeping the digit pushed for several seconds. Our sip provider is not register with 3cx (its a Greek telephone provider OTE) and says that the problem is with the configuration of 3cx. The question is how can i trace the problem and find what is the problem. We've looked at the logs and we don't see anything usable.
Thanks in advance

 

[leejor]

If it requires that a button is pressed for several seconds before DTMF is recognised, then it almost sounds as if DTMF audio is being sent rather than a SIP message. You may need to make use of Wireshark to confirm.

Some general info about DTMF over VoIP...

https://www.3cx.com/blog/voip-howto/dtmf-rfc2833/
https://www.voip-info.org/sip-dtmf-signalling/

Since your provider is certain that it is your end (3CX), then they must know what type of DTMF they are sending to you. Perhaps start with that.

 

[YiannisH_3CX]

Hello @Alekos

As you mentioned OTE is not a supported Voip provider so we are not aware of the DTMF method used by them. I would recommend directing your calls to a normal Digital Receptionist and see if you can select options there. If you can then it could be a configuration issue in the CFD project.

 

[Alekos]

Yes through normal Digital Receptionist everything is ok. But the same problem happens when i use one of the demo projects provided by 3xc.

 

[YiannisH_3CX]

Can you describe what you are trying to do in CFD? An example of the call flow or a screenshot would be helpful to try to understand the issue.

 

[Alekos]

when we run the sample app PhoneSupportPortal of the cfd, we are unable to input the customer id and pin. we connect the app on the central ivr under a queue that runs it. (no agents on that queue).
But i would like to mention that it doesn't work on some of the telephone providers, in others do work,

 

[YiannisH_3CX]

This could be a case of the provider sending DTMF signals in both inband and RFC2833. This could cause issues if the signals arrive simultaneously and could explain why some providers work and some do not. The best way to identify this is to add a logger in your project which will help you troubleshoot the issue.
https://www.3cx.com/docs/manual/cfd-conditions-variables/#h.giyuwghfz906

 

[leejor]

Something to keep in mind...if you find the provider is sending both Inband (audio) and RFC2833, you may be able to block Inband by using a low rate Codec on the trunks, if supported by your provider. It might be a work-around, BUT may have other consequences too. Low Bit-rate Codecs usually have a problem passing DTMF audio.

 

[Alekos]

The provider informed us that they use RFC2833 only and they support codec G.711 A-law.

We have followed the steps from the article below
https://community.calix.com/s/article/How-to-pull-the-DTMF-tones-from-the-Wireshark-capture-1
It seems to me, that the signals are coming correctly, but the application won't understand them.
I've attached the captured pcap dump, if you need to check it.


@YiannisH_3CX
Can you give an example on how to use the "Logger" component to capture the DTMF of the "Menu" component?

 

[YiannisH_3CX]

I deleted the capture as it contains public IPs and FQDNs and you do not want to post such information in public forums for security reasons

I did have a look at the capture though and the provider does not support RFC2833 and they send only inband DTMF. As you can see from the screenshot nothing was received in RFC2833



Also the provider does not declare it in the Invite SDP of the Invite message as you can see from the screenshot below.



There is nothing wrong with supporting Inband DTMF signalling and i did proceed to export the audio stream from the provider and used an online tool (the same referenced in the guide you posted) to see what was received by the PBX.
The following are the results:


From the capture and the audio stream i can hear that your options are 0 and 1 mostly and i do not see any of these arriving.
Note: I only used the audio stream from the provider to the PBX.

 

[Alekos]

Is there something i can try from the 3CX configuration?
Do i need to talk again with the provider? And if so, what should i tell them?

 

[YiannisH_3CX]

From the provided data there is nothing to do on the 3CX side. If the provider says that they support RFC2833 DTMF perhaps it is something they need to enable on their side to get this working. Or provide them with the capture so they can check the issue with Inband. If they can enable RFC2833 however go for that as it is far more reliable.

 

[Alekos]

Hi, we just talk to the provider, they say there is a problem with ivr, how it accepts and translates inband messages. The told us that the only solution is to use a transcoder form everything to rfc2833.
Does 3cx SBC does that? 3cx supports this kind of implementation?
Thanks in advance

 

[YiannisH_3CX]

Hi, we just talk to the provider, they say there is a problem with ivr, how it accepts and translates inband messages. The told us that the only solution is to use a transcoder form everything to rfc2833.
Does 3cx SBC does that? 3cx supports this kind of implementation?
Thanks in advance

So the provider does not support RFC2833 after all. And the issue is not with the 3CX IVR as the wireshark capture is performed at the NIC level before the messages reach the IVR. It is that capture we used to see what is sent by the provider and saw the wrong digits.
To answer your question, no the SBC does not translate Inband to RFC2833 as the PBX accepts both types of DTMF if sent correctly.
I am afraid your solution at this point is to change providers.