Grandstream FXO gateway bad DTMF on outgoing

Asterisk Asterisk Support
1

At the start of the year we moved from dedicated hardware for our phone system to running the phone system as a VM. This was done for failover and redundancy.

Our four PSTN lines had been connected using a Digium 4 FXO port card - which of course won’t work when Asterisk is running as a VM. We purchased a couple of Grandstream GXW4104 FXO gateways. A few problems surfaced - but all except one were resolved with firmware updates or configuration changes.

But one is really killing us. When dialing out quite often when the connection is answered we get one to several unrequested DTMF/touch tones generated coming from the GXW4104 - i.e. not keys on the phone touchpad were pressed at all.

BTW[ol][li]I originally posted this on the FreePBX forum (community.freepbx.org/t/extra-to … ialing-out) - some good debugging tips have come from this, but no solution yet. Now I’m trying to reach out to a broader audience and hopefully get some new ideas.[/li][li]Also we’ve had a case open with Grandstream since Jan 23rd - with very little support effort shown.[/li][li]The reseller we bought the equipment from, Telephony Depot, is at least trying to put together a configuration in the lab to duplicate the problem - but no luck yet.[/li][/ol]

With webinar and other conferencing systems, like GoToMeeting, it really screws things up. Sometimes if you are careful you can recover and re-enter the id, but other times you end up having to hang up and try again - sometimes multiple times.

We have a Vitelity SIP trunk for additional capacity when our PSTN lines are all busy - outgoing calls on this trunk are clean, no extra DTMF tones when the call is answered.

The time lost has convinced our customer that we might as well just switch to pure VOIP - and we’re about to concede on this. But the current arrangement gave them a much more resilient system - letting them keep working if either the PSTN lines for the Internet was down (but not both). Our main incoming DID rolls over to our SIP trunk.

System info: Asterisk 11.10.2 running under FreePBX distro 5.211.65-14.

I’m including a snip from the Asterisk log of one of these calls. The first three “7” DTMF tones are coming from one of the four GXW4104 trunks we have setup - “SIP/PSTN3_4809615164-00000048”. The following DTMF tones “32781496#” come from the handset/extension “SIP/1051-00000047”.

[2015-03-24 11:33:45] VERBOSE[65141][C-000003f6] netsock2.c: == Using SIP RTP TOS bits 184 [2015-03-24 11:33:45] VERBOSE[65141][C-000003f6] netsock2.c: == Using SIP RTP TOS bits 184 [2015-03-24 11:33:45] VERBOSE[65141][C-000003f6] netsock2.c: == Using SIP RTP CoS mark 5 [2015-03-24 11:33:45] VERBOSE[65141][C-000003f6] netsock2.c: == Using SIP RTP CoS mark 5 [2015-03-24 11:33:45] VERBOSE[65141][C-000003f6] app_dial.c: -- Called SIP/PSTN3_4809615164/18773092073 [2015-03-24 11:33:45] VERBOSE[65141][C-000003f6] app_dial.c: -- Called SIP/PSTN3_4809615164/18773092073 [2015-03-24 11:33:48] VERBOSE[65141][C-000003f6] app_dial.c: -- SIP/PSTN3_4809615164-00000048 is ringing [2015-03-24 11:33:48] VERBOSE[65141][C-000003f6] app_dial.c: -- SIP/PSTN3_4809615164-00000048 is ringing [2015-03-24 11:33:53] VERBOSE[65141][C-000003f6] app_dial.c: -- SIP/PSTN3_4809615164-00000048 answered SIP/1051-00000047 [2015-03-24 11:33:53] VERBOSE[65141][C-000003f6] app_dial.c: -- SIP/PSTN3_4809615164-00000048 answered SIP/1051-00000047 [2015-03-24 11:33:53] DTMF[65141][C-000003f6] channel.c: DTMF begin '7' received on SIP/PSTN3_4809615164-00000048 [2015-03-24 11:33:53] DTMF[65141][C-000003f6] channel.c: DTMF begin ignored '7' on SIP/PSTN3_4809615164-00000048 [2015-03-24 11:33:53] DTMF[65141][C-000003f6] channel.c: DTMF end '7' received on SIP/PSTN3_4809615164-00000048, duration 100 ms [2015-03-24 11:33:53] DTMF[65141][C-000003f6] channel.c: DTMF end passthrough '7' on SIP/PSTN3_4809615164-00000048 [2015-03-24 11:33:53] DTMF[2070][C-000003f6] channel.c: DTMF end '7' received on SIP/PSTN3_4809615164-00000048, duration 800 ms [2015-03-24 11:33:53] DTMF[2070][C-000003f6] channel.c: DTMF end passthrough '7' on SIP/PSTN3_4809615164-00000048 [2015-03-24 11:33:57] DTMF[65141][C-000003f6] channel.c: DTMF end '3' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:33:57] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '3' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:33:57] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '3' queued on SIP/1051-00000047 [2015-03-24 11:33:57] DTMF[65141][C-000003f6] channel.c: DTMF end '2' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:33:57] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '2' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:33:57] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '2' queued on SIP/1051-00000047 [2015-03-24 11:33:58] DTMF[65141][C-000003f6] channel.c: DTMF end '7' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:33:58] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '7' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:33:58] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '7' queued on SIP/1051-00000047 [2015-03-24 11:33:59] DTMF[65141][C-000003f6] channel.c: DTMF end '8' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:33:59] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '8' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:33:59] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '8' queued on SIP/1051-00000047 [2015-03-24 11:34:00] DTMF[65141][C-000003f6] channel.c: DTMF end '1' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:34:00] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '1' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:34:00] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '1' queued on SIP/1051-00000047 [2015-03-24 11:34:01] DTMF[65141][C-000003f6] channel.c: DTMF end '4' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:34:01] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '4' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:34:01] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '4' queued on SIP/1051-00000047 [2015-03-24 11:34:01] DTMF[65141][C-000003f6] channel.c: DTMF end '9' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:34:01] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '9' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:34:02] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '9' queued on SIP/1051-00000047 [2015-03-24 11:34:02] DTMF[65141][C-000003f6] channel.c: DTMF end '6' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:34:02] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '6' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:34:02] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '6' queued on SIP/1051-00000047 [2015-03-24 11:34:04] DTMF[65141][C-000003f6] channel.c: DTMF end '#' received on SIP/1051-00000047, duration 250 ms [2015-03-24 11:34:04] DTMF[65141][C-000003f6] channel.c: DTMF begin emulation of '#' with duration 250 queued on SIP/1051-00000047 [2015-03-24 11:34:05] DTMF[65141][C-000003f6] channel.c: DTMF end emulation of '#' queued on SIP/1051-00000047 [2015-03-24 11:34:06] VERBOSE[65141][C-000003f6] pbx.c: -- Executing [h@macro-dialout-trunk:1] Macro("SIP/1051-00000047", "hangupcall,") in new stack [2015-03-24 11:34:06] VERBOSE[65141][C-000003f6] pbx.c: -- Executing [h@macro-dialout-trunk:1] Macro("SIP/1051-00000047", "hangupcall,") in new stack

Any ideas are appreciated or suggestions are really appreciated.

Thanks in advance! - R

2

This is called “talk-off” and it is a potential problem with any inband signalling system.

My guess is that the Grandstream is prepared to detect shorter tones than the Digium card/Asterisk.

If you can configure them for inband signalling doing so will push the problem onto Asteisk, which might be more configurable, even if the card was doing the actual detection, before.

3

Not sure I’m following you completely as I don’t think we are using “In band” DTMF signalling.

But I realize I did not include the details of DTMF settings between Asterisk and the Grandstream either. They GXW4104 has been set to RFC2833 and the Asterisk trunk definitions have also been set this way - dtmfmode=RFC2833.

Coincidentally, our Telephony Depot suggested we change the Grandstream to use either RFC2833 OR SIP INFO this morning - but so far it does not appear to have improved things.

All of the GXW4104 configuration guides I’ve found (both from Grandstream and the community) say you need to use RFC2833 for DTMF. But if you think it might make a difference, I can try that.

Thank you much for the response and suggestions.

4

There will be no difference between RFC 2833 and INFO as to how the Grandstream tries to avoid talk-off. They only way you will make a difference is if you stop it trying to decode the DTMF at all, i.e set it to what Asterisk would call “inband”. (The codec must also, be suitable, that generally means mu-law or A-law depending on where the world you connect to the PSTN.)

I’m not sure whether Asterisk of the card itself does DTMF detection with your dahdi hardware, but if the former, inband DTMF ought to have the same talk-off tolerance (and conversely, tendency to fail to detect valid tones) as your dahdi configuration (except that the increased jitter from using VM may make false negatives more likely).

5

David,

Thanks for the additional info. I just want to clarify one thing. You wrote “I’m not sure whether Asterisk of the card itself does DTMF detection with your dahdi hardware…”. The Grandstream GXW4104 is not a PCI card - it’s a separate gateway box that the 4 PSTN lines connect to and then it connects over the network to Asterisk.

If you were just using the term “card” loosely, my apologies - just don’t want to go down the wrong path. Also both Grandstream and the other howtos I’d found all say to use RFC2833 - but then they aren’t having the issues we are having.

So then after hours I’ll:
[ol][li]Change both the GXW4104 and the Asterisk trunk definitions to use “in band”;[/li][li]The code is already set to ulaw in the trunk definition and and the GXW4104 has the first codec set to PCMU so I think we are good there;[/li][li]Give it a whirl.[/li][/ol]

Thank you - Richard

6

As I understand it, you didn’t have this problem when you used a PCI card. It is that card that I am referring to. If that card did its own DTMF detection, going inband may not help, but if Asterisk did it for it, then by going inband you will have the DTMF detection being done in the same place.

If I misunderstood, and you never had this working with a PCI card, your problem may be more fundamental; your system design may not have made proper allowance for talk-off.

7

Hello,

We currently have this exact setup, GXW4104 with FreePBX. this problem still exists. We are able to “hide” the DTMF with Aastra 68xx phones by changing the option (we added it in the Template): suppress incoming dtmf playback: 1

But with Yealink t46g or other brands, this option doesn’t exist.

Did someone find a correction?

8

Hi,

We have the same problem: on outgoing calls, we hear a few dtmf tones.
Has anyone been successful fixing this issue ? It’s really annoying and I can’t find a way to fix it.
I’ve followed the setup instructions on this page to configure the trunks: http://community.freepbx.org/t/how-to-grandstream-gxw-4104-setup/13727/5