Issue with DTMF Signaling

mnewdigate · March 20, 2018, 7:03pm

Hello,
I have had DTMF issues with only certain people since the system was installed over a year ago. When some people call in they press the desired extension or IVR choice and the system seems to not read it correctly. For example this person tried to call Ext. 3309, but the system seemed to read it as Ext 30 then replied invalid, then read the 9 to send them to the directory. This is seemingly random, but some people always seem to have the same issue. Is this a timing issue perhaps?

[2018-03-20 14:47:00] NOTICE[2312] pbx_spool.c: Call completed to Local/s@tc-maint
[2018-03-20 14:47:02] DTMF[2309][C-000008ff] channel.c: DTMF begin ‘3’ received on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:02] DTMF[2309][C-000008ff] channel.c: DTMF begin ignored ‘3’ on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:02] DTMF[2309][C-000008ff] channel.c: DTMF end ‘3’ received on DAHDI/i1/814XXXXXX-138, duration 25 ms
[2018-03-20 14:47:02] DTMF[2309][C-000008ff] channel.c: DTMF end passthrough ‘3’ on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [proxy@dpma_message_context:1] Set(“Message/ast_msg_queue”, “MESSAGE(custom_data)=mark_all_outbound”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [proxy@dpma_message_context:2] Set(“Message/ast_msg_queue”, “MESSAGE_DATA(X-Digium-AppServer-Response-URI)=sip:10.5.X.XXX:5060”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [proxy@dpma_message_context:3] Set(“Message/ast_msg_queue”, “MESSAGE_DATA(X-Digium-AppServer-Response-FullContact)=sip:10.5.X.XXX:5060;ob”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [proxy@dpma_message_context:4] MessageSend(“Message/ast_msg_queue”, “digium_phone:blah”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [proxy@dpma_message_context:5] Hangup(“Message/ast_msg_queue”, “”) in new stack
[2018-03-20 14:47:03] WARNING[2362][C-00000001] channel.c: Unable to write to alert pipe on Message/ast_msg_queue (qlen = 0): Resource temporarily unavailable!
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Spawn extension (dpma_message_context, proxy, 5) exited non-zero on ‘Message/ast_msg_queue’
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [digium_phone_module@dpma_message_context:1] Set(“Message/ast_msg_queue”, “MESSAGE(custom_data)=mark_all_outbound”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [digium_phone_module@dpma_message_context:2] Set(“Message/ast_msg_queue”, “TMP_RESPONSE_URI=sip:10.5.X.XXX:5060”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [digium_phone_module@dpma_message_context:3] Set(“Message/ast_msg_queue”, “MESSAGE_DATA(Request-URI)=sip:10.5.X.XXX:5060;ob”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [digium_phone_module@dpma_message_context:4] Set(“Message/ast_msg_queue”, “MESSAGE_DATA(X-Digium-AppServer-Response-URI)=”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [digium_phone_module@dpma_message_context:5] Set(“Message/ast_msg_queue”, “MESSAGE_DATA(X-Digium-AppServer-Response-FullContact)=”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [digium_phone_module@dpma_message_context:6] MessageSend(“Message/ast_msg_queue”, “sip:10.5.X.XXX:5060,proxy”) in new stack
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Executing [digium_phone_module@dpma_message_context:7] Hangup(“Message/ast_msg_queue”, “”) in new stack
[2018-03-20 14:47:03] WARNING[2362][C-00000001] channel.c: Unable to write to alert pipe on Message/ast_msg_queue (qlen = 0): Resource temporarily unavailable!
[2018-03-20 14:47:03] VERBOSE[2362][C-00000001] pbx.c: Spawn extension (dpma_message_context, digium_phone_module, 7) exited non-zero on ‘Message/ast_msg_queue’
[2018-03-20 14:47:03] DTMF[2309][C-000008ff] channel.c: DTMF begin ‘0’ received on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:03] DTMF[2309][C-000008ff] channel.c: DTMF begin ignored ‘0’ on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:03] DTMF[2309][C-000008ff] channel.c: DTMF end ‘0’ received on DAHDI/i1/814XXXXXX-138, duration 89 ms
[2018-03-20 14:47:03] DTMF[2309][C-000008ff] channel.c: DTMF end passthrough ‘0’ on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx.c: Invalid extension ‘30’ in context ‘ivr-1’ on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx.c: Executing [i@ivr-1:1] Set(“DAHDI/i1/814XXXXXX-138”, “INVALID_LOOPCOUNT=1”) in new stack
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx.c: Executing [i@ivr-1:2] GotoIf(“DAHDI/i1/814XXXXXX-138”, “0?final”) in new stack
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx.c: Executing [i@ivr-1:3] Set(“DAHDI/i1/814XXXXXX-138”, “IVR_MSG=no-valid-responce-pls-try-again&custom/ovscdayrevised11172016”) in new stack
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx.c: Executing [i@ivr-1:4] Goto(“DAHDI/i1/814XXXXXX-138”, “s,start”) in new stack
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx_builtins.c: Goto (ivr-1,s,9)
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx.c: Executing [s@ivr-1:9] Set(“DAHDI/i1/814XXXXXX-138”, “TIMEOUT(digit)=3”) in new stack
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] func_timeout.c: Digit timeout set to 3.000
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx.c: Executing [s@ivr-1:10] ExecIf(“DAHDI/i1/814XXXXXX-138”, “1?Background(no-valid-responce-pls-try-again&custom/ovscdayrevised11172016)”) in new stack
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] file.c: <DAHDI/i1/814XXXXXX-138> Playing ‘no-valid-responce-pls-try-again.slin’ (language ‘en’)
[2018-03-20 14:47:03] DTMF[2309][C-000008ff] channel.c: DTMF begin ‘9’ received on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:03] DTMF[2309][C-000008ff] channel.c: DTMF begin ignored ‘9’ on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:03] DTMF[2309][C-000008ff] channel.c: DTMF end ‘9’ received on DAHDI/i1/814XXXXXX-138, duration 89 ms
[2018-03-20 14:47:03] DTMF[2309][C-000008ff] channel.c: DTMF end passthrough ‘9’ on DAHDI/i1/814XXXXXX-138
[2018-03-20 14:47:03] VERBOSE[2309][C-000008ff] pbx.c: Executing [9@ivr-1:1] Goto(“DAHDI/i1/814XXXXXX-138”, “directory,1,1”) in new stack

PitzKey · March 22, 2018, 12:41am

What Asterisk version are you on? What version of FreePBX, modules?

mnewdigate · March 22, 2018, 10:30am

Sorry should have specified this first.
Asterisk: 13.9.1
FreePBX: 12.0.76.4

There are a bunch of modules so not sure how to list each one and the version.

PitzKey · March 22, 2018, 10:48am

What distro (version) are you on? I meant to ask if you’d modules are up to date?

mnewdigate · March 22, 2018, 11:11am

Oh sorry not sure where to find the version. These are the modules that have updates available.
cxpanel 4.1.19 (current: 4.1.18)
digiumaddoninstaller 2.11.0.14 (current: 2.11.0.12)
endpoint 12.0.20 (current: 12.0.19)
pbdirectory 2.11.0.6 (current: 2.11.0.5)

This was an issue when it was first installed and always has been when everything was up to date. The issue used to be worse and the vendor changed the DTMF setting to Relaxed which helped, but I still have some people that can’t seem to dial extensions. This seems to only be an issue with extensions that start with 3, where the ones that start with 6 are fine.

arielgrin · March 22, 2018, 12:26pm

Are you setting the dtmf mode of the trunk to the value specified by your trunk’s provider?

mnewdigate · March 22, 2018, 12:37pm

It is supposed to be set, but hard to really get a solid answer out of them (Time Warner) on what we should be using. We are using a PRI over a fiber line. I can try to reach out again.

arielgrin · March 22, 2018, 1:37pm

At this point we would need a little more information about your specific configuration, specially PRI card make and model, whether it has hardware echo cancelling, dahdi config for the span, at least.

mnewdigate · March 22, 2018, 4:30pm

I think this is what you are looking for. pbxcard2

arielgrin · March 22, 2018, 4:43pm

If your card has hardware echocancelling, verify if you have enabled DTMF detection directly from the card.
If indeed you have DTMF detection enabled for the card, try disabling it, as Asterisk is already doing the detection.

system · March 22, 2019, 4:43pm

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.