We ported in a number for a client with a NEC DSX 80, they have it setup with an auto attendant, calls get delivered fine from our cloud freepbx to the on-premise grandstream ht818 ata, but when auto attendant options are pressed, nothing occurrs.
I have checked the following:…the extension on freepbx has dtmf signaling set to RFC2833
the ht818 profile 1: dtmf payload type: 101, preferred dtmf method: rfc2833
Not sure if there’s anything else I should check. Any ideas?
Enable dtmf debug on Asterisk so you can see in the log if the digits are reaching Asterisk or not.
It’s possible that the Grandstream is capturing and interpreting the digit presses for you, which isn’t what you want. Turning on the DTMF debugging will tell you if the digits are even making it to the PBX. If they are not, either the ATA or the DSX is snagging the audio.
I want the DSX to snag the audio, but that’s not what’s happening, but that’s an interesting idea, maybe I’ll try turning off DTMF on the Grandstream.
It looks like the pbx is getting them: I pressed 2, 3, 3. I see those characters in the log. Perhaps the Grandstream is taking those presses and not passing them thru to the NEC DSX?
Here’s a copy of the log:
[2019-05-28 16:32:24] Asterisk 13.23.1 built by mockbuild @ jenkins2.schmoozecom.net on a x86_64 running Linux on 2018-10-03 21:46:52 UTC
[2019-05-28 16:32:38] DTMF[12483][C-0000a393] channel.c: DTMF begin ‘9’ received on SIP/1168-00016e1e
[2019-05-28 16:32:38] DTMF[12483][C-0000a393] channel.c: DTMF begin passthrough ‘9’ on SIP/1168-00016e1e
[2019-05-28 16:32:38] DTMF[12483][C-0000a393] channel.c: DTMF end ‘9’ received on SIP/1168-00016e1e, duration 160 ms
[2019-05-28 16:32:38] DTMF[12483][C-0000a393] channel.c: DTMF end accepted with begin ‘9’ on SIP/1168-00016e1e
[2019-05-28 16:32:38] DTMF[12483][C-0000a393] channel.c: DTMF end passthrough ‘9’ on SIP/1168-00016e1e
[2019-05-28 16:33:33] DTMF[13757][C-0000a3b3] channel.c: DTMF begin ‘2’ received on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:33] DTMF[13757][C-0000a3b3] channel.c: DTMF begin passthrough ‘2’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:33] DTMF[13757][C-0000a3b3] channel.c: DTMF end ‘2’ received on SIP/my-sip-provider–ob-trunk-1-00016e70, duration 395 ms
[2019-05-28 16:33:33] DTMF[13757][C-0000a3b3] channel.c: DTMF end accepted with begin ‘2’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:33] DTMF[13757][C-0000a3b3] channel.c: DTMF end passthrough ‘2’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:33] DTMF[13757][C-0000a3b3] channel.c: DTMF begin ‘3’ received on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:33] DTMF[13757][C-0000a3b3] channel.c: DTMF begin passthrough ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:34] DTMF[13757][C-0000a3b3] channel.c: DTMF end ‘3’ received on SIP/my-sip-provider–ob-trunk-1-00016e70, duration 395 ms
[2019-05-28 16:33:34] DTMF[13757][C-0000a3b3] channel.c: DTMF end accepted with begin ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:34] DTMF[13757][C-0000a3b3] channel.c: DTMF end passthrough ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:34] DTMF[13757][C-0000a3b3] channel.c: DTMF begin ‘3’ received on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:34] DTMF[13757][C-0000a3b3] channel.c: DTMF begin passthrough ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:34] DTMF[13757][C-0000a3b3] channel.c: DTMF end ‘3’ received on SIP/my-sip-provider–ob-trunk-1-00016e70, duration 415 ms
[2019-05-28 16:33:34] DTMF[13757][C-0000a3b3] channel.c: DTMF end accepted with begin ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:34] DTMF[13757][C-0000a3b3] channel.c: DTMF end passthrough ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e70
[2019-05-28 16:33:52] DTMF[13791][C-0000a3b4] channel.c: DTMF begin ‘0’ received on SIP/my-sip-provider–ob-trunk-1-00016e72
[2019-05-28 16:33:52] DTMF[13791][C-0000a3b4] channel.c: DTMF begin passthrough ‘0’ on SIP/my-sip-provider–ob-trunk-1-00016e72
[2019-05-28 16:33:52] DTMF[13791][C-0000a3b4] channel.c: DTMF end ‘0’ received on SIP/my-sip-provider–ob-trunk-1-00016e72, duration 75 ms
[2019-05-28 16:33:52] DTMF[13791][C-0000a3b4] channel.c: DTMF end accepted with begin ‘0’ on SIP/my-sip-provider–ob-trunk-1-00016e72
[2019-05-28 16:33:52] DTMF[13791][C-0000a3b4] channel.c: DTMF end ‘0’ detected to have actual duration 60 on the wire, emulation will be triggered on SIP/my-sip-provider–ob-trunk-1-00016e72
[2019-05-28 16:33:52] DTMF[13791][C-0000a3b4] channel.c: DTMF end ‘0’ has duration 60 but want minimum 80, emulating on SIP/my-sip-provider–ob-trunk-1-00016e72
[2019-05-28 16:33:52] DTMF[13791][C-0000a3b4] channel.c: DTMF end emulation of ‘0’ queued on SIP/my-sip-provider–ob-trunk-1-00016e72
[2019-05-28 16:33:55] DTMF[13858][C-0000a3b6] channel.c: DTMF begin ‘3’ received on SIP/my-sip-provider–ob-trunk-1-00016e75
[2019-05-28 16:33:55] DTMF[13858][C-0000a3b6] channel.c: DTMF begin passthrough ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e75
[2019-05-28 16:33:55] DTMF[13858][C-0000a3b6] channel.c: DTMF end ‘3’ received on SIP/my-sip-provider–ob-trunk-1-00016e75, duration 275 ms
[2019-05-28 16:33:55] DTMF[13858][C-0000a3b6] channel.c: DTMF end accepted with begin ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e75
[2019-05-28 16:33:55] DTMF[13858][C-0000a3b6] channel.c: DTMF end passthrough ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e75
[2019-05-28 16:34:02] DTMF[13858][C-0000a3b6] channel.c: DTMF begin ‘3’ received on SIP/my-sip-provider–ob-trunk-1-00016e75
[2019-05-28 16:34:02] DTMF[13858][C-0000a3b6] channel.c: DTMF begin passthrough ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e75
[2019-05-28 16:34:02] DTMF[13858][C-0000a3b6] channel.c: DTMF end ‘3’ received on SIP/my-sip-provider–ob-trunk-1-00016e75, duration 275 ms
[2019-05-28 16:34:02] DTMF[13858][C-0000a3b6] channel.c: DTMF end accepted with begin ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e75
[2019-05-28 16:34:02] DTMF[13858][C-0000a3b6] channel.c: DTMF end passthrough ‘3’ on SIP/my-sip-provider–ob-trunk-1-00016e75
This should not be hard to troubleshoot. To start, temporarily disconnect one port from the NEC and connect the HT port to an analog phone. Call in, answer the analog phone, confirm that you have clean audio in both directions, then press keys on the calling phone and confirm that you hear clean DTMF tones on the analog set. If not, debugging tools include packet capture on the PBX (look at RTP being sent to the HT) and syslog on the HT.
If the DTMF sounds good, reconnect to the NEC and monitor a call with a butt set. If you hear nothing wrong and still have trouble, one possibility is high frequency noise messing with the NEC – try a DSL filter between them (try it both ways). If no luck, perhaps changing the FXS Tx gain will help.
well I posted my dtmf log from freepbx above, I’m no log expert, but from what I can tell, it looks like freepbx is doing its part. I spoke with the carrier & they said they should be using rfc2833 and payload 101, which is inline with what i’ve got on my equipment. No dsl filters in the way, as the client has a 100mb fiber connection with static ip. Stewart, I will try your idea with a butt set.
I just figured it out!!! It was simply that I was using a really old firmware on the Grandstream HT818. I updated to the latest firmware & boom, problem solved…It’s always the simplest of things we over look (DOH!!!)
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.