Strange (double) DTMF problem

We have problems with DTMF detection. In 95% of cases digits are doubled.

Call flow is following:
Phone -> E1 -> TE411P -> Asterisk -> via SIP -> Intel HMP

We tried many things (changing DTMF mode, echocancelation, RX/TXGain, tweaks in zapata)

New asterisk box is tested with other asterisk box, several sip providers, phones but everything works great without double DTMFs.

Also, Intel HMP works perfect with old CentOS based Asterisk@Home server.

Gateway configuration TE411P ISDN board, Asterisk 1.2.4 and RedHat ES4

We suspect that problem maybe is in: network card/driver, some RedHat network setting or Intel HMP

Any idea or same problem?


Problem could be in your provider.

With one of our VoIP providers we had same problem. Some of DTMFs were multiplied, some missing. After provider did his job (they spent months) then problem disapeard.

Problem occurs in our internal network in comunication between Asterisk and HMP via SIP protocol.

First we tought it might be problem in compability with DELL 2850 and E1000 network card as mentioned here ( Today we tested with some plain PCI network card but problem is still there.

Not sure is maybe HMP a problem or not.

Good day.
I am the colleague of the topic starter, we are working on the setup together.

Let me elaborate on the setup first.
We have

  • several Primay ISDN lines (european),
  • 2 asterisk boxes,
  • one seperate machine running Intel HMP software (VBVoice)
  • the machines are talking SIP with eachother over a LAN.

-> the first asterisk server is a test box:
– slow pentium3
– CentOS
– Digium Wildcard TE110P T1/E1 Card
– Asterisk@Home

-> the second asterisk server is meant to become the production server:
– blazing fast DELL 2850 dual xeon
– RHEL 4
– Digium Wildcard TE411P Card
– Asterisk 1.2.4

-> the VBVoice machine doesnt stand out
– blazing fast DELL 2850 dual xeon
– windows server 2003
– Intel HMP & VBVoice

Now, all calls that are made to the testbox are handled perfectly. All the calls that are passed to the VBVoice machine are good, DTMF is passed perfectly. Its just not suited for production due to its lack of power.

All calls that are made to the big asterisk server however behave just a tad bit different.

  • If the call is handeled on the asterisk machine itself there is no problem, sound quality is good, DTMF tones are recognized good.
  • If it connects over SIP to the VBVoice machine however: Sound is good, but DTMF tones are replicated about 1 out of every 3 times.
    Debugging shows that if i press some number, say “5” that it sees it just as that, a single character “5”, and passes it on. The VBVoice machine gets “55” and reads that back (in some tiny test app).
    “Huh?” you would say… indeed, a big “Huh?” is in order here.

As mentioned above, DELL 1850 used to have a problem with the network card in combination with the TE411P card. However, this is a 2850. I disabled the onboard ethernet controllers anyway and chucked in a cheap realtek card. It the network card worked, but the effect on the problem was 0.0

We tried different versions of asterisk, gain settings (should not be needed on primary ISDN!) and even echo cancelation.
But that is not the problem, as the asterisk server DOES recognizes the DTMF tones just perfectly.

Then we did something interesting:
We put a litle dialplan on the testbox so that if you dialed one extension it would connect (dial) to the production box over SIP, wich would in turn dail to the VBVoice machine.
Lo and behold, DTMF tones where doubling again!

Then we did it the other way around.
We put a litle dialplan on the productionbox so that if you dialed one extension it would connect (dial) to the test box over SIP, wich would in turn dail to the VBVoice machine.
Lo and behold, all DTMF tones fine!

So no matter how the call was made (with a phone or over SIP) the production box would double the DTMF tones (about 1 out of 3) when talking to the VBVoice machine.

We did a network capture of the production machine.
For every DTMF tone made it sent out 6 packets, exactly as it should.

Still there possibly is a problem in the communication between the production asterisk server and the VBVoice server, perhaps both interpreting the rfc2833 in a different way?

We are running out of options here.
Q: is there a difference in wich Asterisk@home and the normal version sends out DTMF over SIP?
Q: Could it be a hardware problem? (i hardly believe it, but we have to try everything) We will swap the Digium cards at the next oportunity.
Q: Could using H323 instead of SIP to talk to the VBVoice machine be a solution? (and is there anyone who got that to work?)
Q: Did anyone ever have this problem, and if so, was it solved? how?

Well, this concludes a very frustrating week. I realy hope anyone has some ideas how to solve this, as i currently dont.

Ellert van Koperen.

A friend suggested that it could be that the Production box is not muting the sound very well when sending the DTMF data packets.
That could mean that the DTMF data is sent to the HMP machine in 2 ways: as datapackets (the 6 packets we saw when capturing the network traffic) AND ALSO through the sound channel.
I am not sure that the HMP machine can, but if it can detect the DTMF sounds seperately from the DTMF datapackets, that that could be the source of all trouble.

But isnt asterisk supposed to mute the voice channel when detecting DTMF ?

It was a problem in the hardware echo-cancelation module.
When we unplugged it the DTMF problem was history.
Very very odd.

In case your problem crops up again, I was going to suggest it may be related with the following bugs - so something to keep in mind if it starts acting up:


We got tip from Digium technical support to disable DTMF hardware support in wct4xxp.c file