SOLVED DTMF not passed to IVR?

youreontheair

New Member
Joined
Sep 16, 2013
Messages
11
Reaction score
0
Just set up incrediblepbx on a raspberry pi.
Can make outgoing calls successfully.
Can receive incoming calls successfully.

When I configure an IVR on the system (even using the nv-ivr that came with the install), I can call in from a mobile phone and hear the IVR play back, but when I press 1 for news, 2 for weather, etc... it doesn't appear the system "hears" the DTMF. The system does not respond to the DTMF.

As I'm new to this, I been reading quite a bit here, and I understand the value of having NO ports exposed on the firewall (which is how I'm currently configured)...
BUT...
when I attempt to troubleshoot, and open UDP ports 10,000 to 20,000... DTMF and the IVR appear to work correctly. When I revert back to no ports open, I re-introduce the issue.

So... is there a solution without opening the firewall ports?

Thank you!
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
Shouldn't be necessary to open ports ....

Provider? Trunk Config (sanitized)?Router type-brand, using a POTS line?

Using a registration string with your provider or not? Qualify directive in PEER trunk config?
 

youreontheair

New Member
Joined
Sep 16, 2013
Messages
11
Reaction score
0
Thanks Brian.

Provider = flowroute
Router = Arris cable modem
No POTS line.
Trunk Config (Peer Details exactly as specified by flowroute, secret and username scrubbed) :
type=friend
secret=****
username=****
host=sip.flowroute.com
dtmfmode=rfc2833
context=from-trunk
canreinvite=no
allow=ulaw&g729
insecure=port,invite
fromdomain=sip.flowroute.com

Flowroute suggests nothing in the USER details,
and then a registration string. (which works as I can send/receive calls fine.)
Registration string format username:[email protected]
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
FYI on a couple of things:

I'm assuming you have the Asterisk parameter : externip set correctly?

In Peer details for the trunk I use:
disallow=all
allow=ulaw
which really shouldn't make a difference.

Also, in The Interconnection -> Inbound routes section of the Flowroute config page I have used the host-port type setup rather than using a registration string.

You mention your cable modem but I was wondering about the router. If your using the registration string and if its working the trunk should show as registered in the Asterisk info panel. If it is that's fine BUT we are relying on the router to keep entries in its state table so that when a call comes in the proper RTP paths can be negotiated. It sounds like you only have a one way audio path which could be related to how the security and other settings on the router are configured.

On the router turn off any functions that make it SIP aware (usually called SIP ALG) as these often don't work properly. Add the line qualify=yes to your PEER section of the Flowroute trunk config. Look for any firewall settings in the router that affect Endpoint Filtering example:

http://support.dlink.com/emulators/dir655/121/Firewall.html

Trying another router is often an option....
 

youreontheair

New Member
Joined
Sep 16, 2013
Messages
11
Reaction score
0
Thanks again Brian.
Here's the summary:

Issue remains.

The only thing I could NOT test in this round was your suggestion to use a "host-port type setup rather than using a registration string."
I do not understand how to format that. Please elaborate?

All other suggestions did not lead to a solution.

Details for each suggested fix attempt follow....

-------------------------------

When I mentioned cable modem, it is a cable modem/router all-in-one as supplied by the internet provider. I suppose trying another is an option but for this round of tests, it remains as I have no other currently.

I did view all firewall settings in the modem/router, and there are no settings currently filtering anything in the firewall.

SIP ALG was enabled in the modem/router. For all the following tests, I tested with SIP ALG enabled, and then again with SIP ALG disabled. (Note: just disabling it and re-testing the existing config did not by itself remedy the issue)

For the Asterisk externip parameter, I have tried both static using my current ip, and dynamic using a dyndns account, all via the GUI. No change. Even tried coding it into sip_general_custom.conf (upon reload of the Asterisk SIP settings in the GUI, it threw an error and recommended clearing the settings from sip_general_custom.conf).
So... cleared sip_general_custom.conf back to its original state, and verified correct settings in the GUI and all good, but no fix, so moving on to the next idea.

Tried adding these to the PEER settings:
disallow=all
allow=ulaw
... no change.


Tried adding the line qualify=yes to my PEER trunk settings.
... no change.


Tried various combinations of audio codecs in the Asterisk SIP settings GUI.
... no change.

Was careful to document and return all settings to the way they were previous to testing.

Final note: I tend to think you're close with the "one-way audio" diagnosis, but if it helps at all, VOICE audio for a call works both ways for calls originated inbound or outbound. It seems it's just the DTMF audio that doesn't pass...?
 

leemason

Guru
Joined
Mar 3, 2012
Messages
207
Reaction score
24
Does this only happen if you dial in using your mobile? Have you tried dialling in using a land line phone? Does the IVR work if you use a phone connected locally to the PBX? Do you have an option with the provider to use any DTMF settings other than RFC2833?
 

youreontheair

New Member
Joined
Sep 16, 2013
Messages
11
Reaction score
0
hmm... great questions Lee. The answer is it definitely happens 100% of the time from my mobile (regardless if I'm using it through my wifi or my cell carrier). I have neither a land line phone nor a physical phone to connect locally, so I'll have to figure out a solution for those tests.

If it helps, I can add that DTMF from a softphone does work great locally on the network.
I'll ask the provider about DTMF alternates to RFC2833.
 

leemason

Guru
Joined
Mar 3, 2012
Messages
207
Reaction score
24
Let me know if you need someone to dial in and test the IVR for you. I'd be happy to do that.
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
Let's take a look at the mobile for a second.... If you call into someone else's IVR ie:bank, creditcard,store etc with your mobile does it work? Often carriers will block inband dtmf tones or at best provide a short burst so you rely on the fact that the keypress is passed along the data channel.
If you call from your mobile to a regular analog phone line can you hear the dtmf when you press the keys?

Just to verify, you are saying that when you open the RTP ports on your router the mobile phone works without issue?

If you call from a regular POTS line into your system does the IVR respond to dtmf without having to specifically open the ports?

If in fact when you open the ports, as you originally stated, everything works fine then that would imply that the dtmf is being sent INBAND which brings us back to a trunk or carrier config issue.

If you want to PM me your mobile number I will set up an inbound route that brings you to an IVR. If you press zero it will bring you to an extension. If it doesn't hear anything it will repeat 3 times and then send you to a fast busy.

DTMF keypresses can be monitored in the log and cli but that logging has to be enabled. Wireshark is another alternative
 

youreontheair

New Member
Joined
Sep 16, 2013
Messages
11
Reaction score
0
Thank you Lee and Brian

Still testing.
To confirm a couple things in the meantime:
-- when i use my mobile to call someone else's IVR, it works perfectly.
-- when i temporarily route UDP inbound ports 10,000-20,000 on the firewall/router then dtmf from my mobile to the incrediblepbx/raspberry pi box works great. As soon as I stop routing those ports, dtmf from the mobile to the PBX no longer works.
-- i tried setting dtmfmode=inband in the trunk PEER settings... no improvement.
-- haven't tested landline POTS inbound yet.
 

Hyksos

Guru
Joined
May 28, 2011
Messages
474
Reaction score
70
asterisk cli
sip set debug on
rtp set debug on

hey, i could be wrong but to me the issue is pretty clear since your first post.
one way audio. your mobile gets the audio from the pbx but the pbx doesn't get the audio from the mobile. thats it.

yes i know you said that in other circumstances, the pbx does get the audio... but in this particular scenario, since you keep not using the debug options in the cli.... you havent proven that the pbx receives the audio from the mobile. (presence of rtp packets coming in while you try to talk to the ivr or send dtmf to it.

you say the pbx does receive the audio because when you route the call differently, to an extension i guess, you can hear the audio from the mobile.

but in this scenario, the call is picked up by an ivr... so ... you dont know if the pbx receives audio from the mobile unless you check the rtp debug. why because you cant know if the ivr is hearing the audio from the mobile, you're not the ivr....

so much for debugging in the air, yoda style.... use the cli and the debug commands!

im thinking the pbx is not receiving whats coming from the mobile... at least in this scenario... i know it works in other scenario.
gee you can even compare a working debug session (with ports forwarded) with a non working one (no ports forwarded).
stop debugging in the air and check how to obtain insight into asterisk with the cli and the logs...
 

Hyksos

Guru
Joined
May 28, 2011
Messages
474
Reaction score
70
sorry if i sound harsh, not the intention, its just that i hate this kind of thing, people havent been using asterisk all those years wondering what happened to their call, its all there in logs when you learn about log levels and debug options.
you do need those skills, research that instead, it will applicable to all your problems, and you will understand... instead of blindly playing with settings until it, magically works...
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
I don't know the skill level of this particular "new member" but as I've read these threads over the years it is clear that there is a wide variation in skill set and problem solving ability among the people that join this community.

There is a natural inclination for people to take the quickest and shortest route to a problem, so often I think they post a question assuming there is a quick fix that everyone already knows about, at least that's what they are hoping.

Those of us who have been around a little while CAN often supply a quick fix if we are in a position to see, first hand, what the problem ACTUALLY is. In other cases it clearly takes a methodical approach to solve a complex problem.

Sometimes new members either don't have that problem solving skill set in anything that they do or they just don't have the technical know how in this subject area to even begin such a process.

These DTMF and trunk configuration discussions can be infuriating because people start making all kinds of wild suggestions that just contribute to the confusion and none are based in fact. There is a very finite set of reasons that some of these configurations don't act as intended but in order to "see" it you need to be able to look at the big picture.

Take for example a Router that may be involved in a particular issue, most people really don't have any idea how a Router actually works or why it should or shouldn't be configured a particular way!

There is no easy way to solve this issue because the other problem is that people don't take the time to search or to READ the material that might actually help them solve their problem! Sometimes this can require a BIG investment of time.

When all is said and done I try to remember that although I am a technical person there was a time when all this VOIP PBX stuff was very confusing to me. It's fairly easy to tell when a new member takes my suggestions and really runs with them, often making surprising progress. I'm more than happy to invest the time and energy when I know that the person is mounting a herculean effort to resolve there issue and is just looking for guidance along the way...

I do think this particular "new member" shows a pretty good level of energy on this issue while trying to learn at the same time... :)
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
Thank you Lee and Brian

Still testing.
To confirm a couple things in the meantime:
-- when i use my mobile to call someone else's IVR, it works perfectly.
-- when i temporarily route UDP inbound ports 10,000-20,000 on the firewall/router then dtmf from my mobile to the incrediblepbx/raspberry pi box works great. As soon as I stop routing those ports, dtmf from the mobile to the PBX no longer works.
-- i tried setting dtmfmode=inband in the trunk PEER settings... no improvement.
-- haven't tested landline POTS inbound yet.

So.... Maybe this will help. The rfc2833 packets (check the spec on Google) are actually sent via the RTP ports but not as Inband audio that would have to pass through the codecs. The communication is done via a special packet. Which ports it uses can vary and tend to be lower than the 10k-20k you mentioned but since those are the ones you opened it may be using those.
The question is why your router needs to have these ports specifically opened even though the call has already been established and should have RTP ports already mapped. So I think this comes down to a router or router configuration issue. For the time being I would just map those RTP ports.
 

leemason

Guru
Joined
Mar 3, 2012
Messages
207
Reaction score
24
Is there any logging that you can do on your router to see which packets it is blocking or dropping? It does seem strange that it is allowing voice packets through but possibly not allowing (or mangling) DTMF packets. What is the make and model of firewall that you are using?
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
Apparently his cable modem (Arris cable modem) is his "router" so to speak but that may in fact be the whole problem....
 

youreontheair

New Member
Joined
Sep 16, 2013
Messages
11
Reaction score
0
Hyksos I didn't think you sounded harsh. They were good suggestions.
As Brian observed correctly, I'm still new to this so some things just aren't on my radar (yet.)
Logging is great... I just didn't know how to even start with that, and, I suppose I thought this might have been a common/known issue (there are certainly a TON of posts about audio issues in this and other similar forums).
You showed me how (thank you!) and I did it (though while I feel slightly empowered, I haven't found the solution yet.)
The logs showed lots of what appear to be successful negotiation for the call... and I zeroed in on looking for anything related to DTMF (because AUDIO works two-way... I can make a two-way voice call between a softphone locally and a mobile phone... heck, even internationally to what most likely is a land line... but the DTMF tones somehow don't pass, or get 'heard')

The logs show things like:

CSeq: 20943 INVITE
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed


Found RTP audio format 0
Found RTP audio format 18
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw|g729), peer - audio=(ulaw|g729)/video=(nothing)/text=(nothing), combined - (ulaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)

A whole bunch of these:
Sent RTP packet to 4.55.17.2:11282 (type 00, seq 030323, ts 004000, len 000160)

And somewhere in the middle of the "sent RTP packet" messages ... the only thing suspicious to my currently untrained eyes...
Really destroying SIP dialog '[email protected]' Method: OPTIONS

Then a whole bunch more of these:
Sent RTP packet to 4.55.17.2:11282 (type 00, seq 030323, ts 004000, len 000160)



Of course there are at least four parts to using logs. 1) knowing of their existence. 2) knowing how to configure and execute them, 3) knowing how to correctly interpret their data, and then 4) taking the correct action as a result of # 3.

I think I'm just entering area #2....
 

youreontheair

New Member
Joined
Sep 16, 2013
Messages
11
Reaction score
0
I just noticed what is likely a crucial detail and I apologies if my not catching it has mislead efficient troubleshooting.
My (latest) lesson: if you test calls with two phones in proximity and use speakerphone, it is possible to confuse the source of the audio.
I missed a crucial detail I think (again, sorry!)

So here's what might help our troubleshooting:

If I initiate an OUTBOUND call from the softphone behind the firewall to my mobile phone: all audio (voice and dtmf) pass successfully either direction.

If I initiate an INBOUND call from the mobile to the softphone: audio is one way... all audio (voice and dtmf) pass successfully outbound from softphone to mobile, but not inbound from mobile to softphone.
 

youreontheair

New Member
Joined
Sep 16, 2013
Messages
11
Reaction score
0
finally found someone with a landline, and didn't want to trouble you folks.

exact same behavior from a landline.
calls can connect both inbound and outbound.
OUTBOUND calls all audio passes both directions successfully.
INBOUND calls audio passes outbound, but not inbound.
 

Members online

Forum statistics

Threads
25,778
Messages
167,504
Members
19,198
Latest member
serhii
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top