[SOLVED] IVR stops recognizing DTMF after 15 minutes

I’ve tried the following to fix the problem:
Set both trunks to dtmfmode=rfc2833 (switched to the other two modes when this failed. No success.)
I have one trunk coming in from Suddenlink and one from Callcentric.
All endpoints are set to use rfc2833.
I can get it to recognize DTMF again if i hit the apply settings button in either the IVR itself or the Callcentric trunk.
It will stop recognizing DTMF again after 15 minutes.
IVR is set as the destination for the Callcentric trunk
Deleted and recreated the IVR.
Called from a mobile number to try to rule out a misconfiguration with the clients
Looked at the logfiles to see if dtmf is being received. (Yes)
Noted that the IVR is the only thing not responding to DTMF. e.g. Voicemail is responding fine from all endpoints
Searched this forum for a post with a similar problem. Nothing has turned up a solution for me.

Freepbx version is: 6.12.65-24

If anyone has any further suggestions I would be very grateful.

See if the hover-over help for “signal ringing” on your inbound route is applicable.

Unfortunately this does not apply. I forgot to mention that the call connects and the IVR does play back the greeting. It just doesn’t respond to DTMF. It will work correctly for about 15 minutes and then stop responding to DTMF.

Are you sure that is not just “early media” you are hearing, no DTMF can happen until connected, did you try it?

Ok. I think I understand what you’re saying. Went back and tried it and it stopped working at about the 30 minute mark this time.

Sorry, I have never seen that behavior, for starters I would turn on DTMF logging in you console and watch a failed call.

I do receive the DTMF. Logging shows up DTMF and the number I pressed.
BTW thanks for the suggestions. I’m still not giving up. I’m going to try to turn off fax detection and move the IVR over to the new trunk. If you come up with something else, let me know.

random changes based on guessed analysis only works with your “luck factor” being at 100% . I suggest against that direction :slight_smile:

You do have a point. I’m not sure exactly where to look at the moment, though. Nothing in the log looks out of place to me, but I’m not very experienced at recognizing problems with the DTMF. I do know the PBX is recognizing the numbers as they are dialed. I see them in the logs. Why the IVR is ignoring them is beyond me. What drives me nuts right now is the fact that I did move the IVR to the other trunk (Suddenlink) and it has been working fine for the last hour and a half!
I’ve opened a support ticket with Callcentric to see if there were changes on their end. I can’t see how that would be if I’m seeing the DTMF coming through in my logs, though.

Basic deduction, if it works with provider B but not Provider A, then maybe provider A is effing with you :wink: Call them to see what they actualluy support . . .

Ok. While I’m waiting on an answer from them, I moved the IVR back. Definitely has to be between Callcentric and my IVR.
That leaves Callcentric, my trunk settings, my inbound route settings, and my IVR. Everything else seems to work. Right now, given that the IVR works with Suddenlink, I"m thinking I can safely eliminate that for the time being.

Just a followup on this thread for anyone who runs across this problem.

In Settings>Asterisk Sip Settings>Audio Codecs I had several codecs checked. I was under the impression that the server would select the first codec that both server and client supported. Unfortunately this did interfere with IVR functionality. I unchecked everything except ulaw and now my IVR works properly.

You can only reasonably use open source or licensed and paid for non free codecs, does that not make sense?

If you had g729 checked then asterisk will pass it through, and your phones might well have paid the stipend and accept the call, but the IVR (your asterisk server) will need that license also (non free), it’s all explained in the WIKI