3CX dtmf issue during IVR

[jayfromit]

sip provider: ATT FLEX
3cx version: 15
server: 2012 R2

We just upgraded to 3cx v15 and during test/deployment it worked fine, however in the middle of the following day the dtmf stopped working. So callers would call in, but could not connect to their ext or press anything because the dtmf would not accept the user input. At first I just rebooted the 2012 R2 server and it started to work again but then about within 2-3 hours the dtmf stopped working again. Luckily at that time it was end of business day and I didn't have to the reboot it so I can gather more information.

When I had time messing around with the system while it was broken, I learned
This would not affect our backup line. so when callers called in using call centric the dtmf worked when our ATT flex line didn't work.
Then I figured out that stopping the service "3CX PhoneSystem Media Server" and restarting it would fix the problem.

So currently everything is working but i'm concerned this will happen again and trying to get to the bottom of this so i can fix the root issue.

Does anyone have an idea how to fix this issue?

 

[leejor]

I'm not familiar with AT&T Flex. is this a VoIP service, or do they supply a box that in turn connects to a gateway?

In either case, since your other provider seems to be working through all of this, I'm going to suggest that it may be a Codec issue with the AT&T trunks. If a lower bit rate Codec has been chosen, then, in many cases, audio DTMF can have issues. (I have to assume that SIP messaging is not being used to pass on the DTMF information) To better understand what 3CX is actually "hearing", the next time this happens, call in, answer on an extension, then have the caller send some DTMF tones, what do they sound like? Distorted, Very short?

 

[jayfromit]

Leejor!

ATT supplies us a box which connects to a gateway.

I totally forgot, I noticed that call centric codec was little different order then the ATT Flex line so I did change the order the codec was in to match centric codec. But after i submitted the change, and called in it still kept ignoring the dtmf signals. Maybe it takes a while to take effect? Anyways since I reboot the media server services last night, about 20 hours ago, I have been constantly monitoring the phone lines and calling in so far no issue.

Anyways next time it does it I will do that.

 

[leejor]

Since you have confirmed that you are using a gateway, you might want to confirm that the preferred Codec order puts the (usually g711a/u) Codecs as first choice, and perhaps going as far as removing the others from the list altogether. On an internal LAN there is no need to have to try to save bandwidth.

With a gateway, the ideal operation would be where the gateway detects the tone, then passes them onto 3CX as a message, rather than audio. I'm not certain as to what is actually happening in your case. the fact that it works, then doesn't, would suggest to me that the Codec (or something) is changing perhaps upon re-registration, at times.

 

[Anonymous]

We had a DTMFproblem with a version 12.5 system last year. In our case there was enough packets out of order on the wan link that 3CX refused to identify some of the DTMF . We had no problems with voice quality, bandwidth or internet - only dtmf and it had to do with Out of order packets. We ended up reworking the Digital receptionist, so that invalid input redirected to the reception to redirect manually.

We did wireshark traces and played back the rtm audio and dtmf sounded perfectly fine. It seems that the 3CX dtmf recognition can be overly sensitive. We had opened a ticket with 3CX support but as the WAN or ITSP were not "certified", they told us it was out of scope.

As a WAN issue, the ISP traffic eventually stabilised and the problem went away.

 

[andreaschr]

Hi jayfromit,

What codecs are you using for the provider ? and what order ?

 

[jayfromit]

I'm not familiar with AT&T Flex. is this a VoIP service, or do they supply a box that in turn connects to a gateway?

In either case, since your other provider seems to be working through all of this, I'm going to suggest that it may be a Codec issue with the AT&T trunks. If a lower bit rate Codec has been chosen, then, in many cases, audio DTMF can have issues. (I have to assume that SIP messaging is not being used to pass on the DTMF information) To better understand what 3CX is actually "hearing", the next time this happens, call in, answer on an extension, then have the caller send some DTMF tones, what do they sound like? Distorted, Very short?

Leejor! you are a genius! Long story short, I still have a problem but I feel it gets us closer to the resolution.
Anyways, I did what you asked me to do, have the call route straight to my EXT. I did answer the call and noticed I can not hear anything on the receiver side. However the caller can hear everything. I guess, this doesn't fix my issue but at least we are getting somewhere.

EDIT: I can confirm when I call out on that sip it doesn't work.

Also this test was was done with the recommendation you remove all other codecs other then u/a law.

I route all incoming calls to our backup line so I have plenty of DID and time to trouble shoot this. Your guidance would be appreciated!

 

[leejor]

The next step would be to plug a set directly into one (the first?) of the lines coming from the AT&T "box", answer an incoming call, and do the DTMF test again. This would confirm that your provider is passing the tones on correctly to your gateway. It could be that they are too short, or too low of a level. In an ideal situation, if the caller hold down a button (on a set that does this), the tone will continue until they release the key. On newer electronic sets, as well as mobiles, DTMF is almost always sent as a pre-timed burst, no matter how long you press.

I haven't used that particular gateway, so I'm not sure if there are settings that will affect the incoming DTMF audio. On outgoing, there is usually a selection of DTMF methods that have to match up with the set that is placing an outgoing call.

I suspect , in your case, it is a matter of getting the DTMF audio, to pass through.

 

[jayfromit]

I think i'm getting closer to figuring out the issue,
from port 9100-9255 our palo alto is denying those ports. I'll unblock those ports and see what happens.

 

[jayfromit]

The next step would be to plug a set directly into one (the first?) of the lines coming from the AT&T "box", answer an incoming call, and do the DTMF test again. This would confirm that your provider is passing the tones on correctly to your gateway. It could be that they are too short, or too low of a level. In an ideal situation, if the caller hold down a button (on a set that does this), the tone will continue until they release the key. On newer electronic sets, as well as mobiles, DTMF is almost always sent as a pre-timed burst, no matter how long you press.

I haven't used that particular gateway, so I'm not sure if there are settings that will affect the incoming DTMF audio. On outgoing, there is usually a selection of DTMF methods that have to match up with the set that is placing an outgoing call.

I suspect , in your case, it is a matter of getting the DTMF audio, to pass through.

Leejor, when I said i could not hear anything, i meant I could not hear any audio period. It's no longer a dtmf issue it's an audio issue. I swear when I called out, last week I was able to hear people but now when I do it, I can't hear audio on one side.

 

[jayfromit]

Thanks everyone! it was our Palo Alto blocking it!

 

[leejor]

Great, glad you solved it. I had incorrectly assumed that it was simply a DTMF issue and not a complete lack of audio.