Touch Tone Stutter

Home » Asterisk Users » Touch Tone Stutter
Asterisk Users 5 Comments

I am hoping someone else has seen this and can offer a solution or at least a direction to investigate. I am running 11.23. Most of my clients are fine but one has a strange behaviour. He has a Grandstream HT701 like most of my clients who use an ATA. He can make call and they are crystal clear. However, when he tries to use phone menus (“dial 234
for John Doe” for example) it doesn’t work. At first I thought that the tones were not being delivered but I had him play them to me and the issue is that each tone stutters. As a result, entering “234” becomes
“223344” which is not understood as a valid input.

He has a recent phone and, in fact, is almost the same model I have at home. His is a Panasonix TX-TGD220 and mine is a TX-TGD-212. The difference is mainly that his has a built in answering machine.

As I said, no one else is having the issue. One person has a horrible connection with voice drops all the time but the touch tones still work.

I have made two files available. http://darcy.vex.net/Bishop.ogg is an OGG file of the sound that it makes at the receiving end and the other at http://darcy.vex.net/Bishop.png is a picture of the wave form. I had the user think “one Mississippi” etc. and alternately press and release three different buttons. I recorded off my SIP phone which is going through the same Asterisk server as the user.

The only thing I can see in my configs that might apply is in sip.conf
“dtmfmode=rfc2833” which I don’t want to change unless I am absolutely sure. No one else is having the problem so I don’t want to risk it. Would I be safe if I set it to “auto”? Is there any chance that it would help? Is there some place else I should be looking?

Thanks in advance for any help.

5 thoughts on - Touch Tone Stutter

  • One direction that may be worth exploring further is his ATA’s config (or perhaps swapping it for a different model). Eg adjusting echo cancellation or line impedance settings.

    Is the ATA he is using the same as the ATA you use?

    Failure to correctly recognise and decode DTMF is just one of many reasons why I never use them (ATAs). Like faxing over VoIP, they’re just too much trouble 🙁

    Genuine IP phones are pretty good value these days. Could you drop one of those on-site as a temporary measure to prove that it’s phone and/or ATA related?
    
    Pete

    Ps, you might also want to consider joining VoiceOps (if you’re not already subscribed) and posting there. https://puck.nether.net/mailman/listinfo/voiceops

  • What are the problems with DTMF and VoIP?
    http://www.voipmechanic.com/dtmf-issues.htm

    In some VoIP routes a switch may be configured to detect in-band DTMF
    which is sent by the VoIP ATA, but then switches to an out of band RFC2833 DTMF required for an upstream provider. This upstream carrier then terminates the call to the PSTN, possibly to a voice mail system, which will require regeneration of the audible inband DTMF tones. The switch has to detect and remove the tone sent by the ATA from the audio stream because the upstream provider specified RFC2833 DTMF. At times the switch can’t always completely remove the in-band DTMF tone which is a problem, because by the time it has detected the DTMF tone, it has already passed a short amount of it. This small amount of in-band tone along with the RFC2833 tone sent are both received by the far end voice mail system which will then register an error (problem), possibly an invalid mailbox or invalid password.

    If this is happening You can set asterisk to use receive the tones inband which if this is occurring might help

    Trial and error probably, good luck

  • I have to be careful here as I auto-provison these devices and changes would propogate to every user. Echo cancellation is off. Do you think it should be on?

    No but it is the same as other users who do not have the problem. I use a SIP phone and a Cisco ATA.

    I understand but some use cases just need it.

    He does want to have an extension so that won’t work.

    I have subscribed. Thanks.

  • –nab3dMCF9RHGBu2IMIosbbNmBDAi6nFHL
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    Hi,

    you could try switching the DTMF mode of the ATA’s SIP peer (and also in the ATA itself) to INBAND transmission. In this mode, the ATA doesn’t need to recognise DTMF tones and your Asterisk can interpret it. For this to work, the ATA needs to use a G.711 codec. Inband DTMF needs an uncompressed codec to work properly.

    Another way is (if the ATA supports it) to switch DMTF mode to SIP INFO. In this mode, DTMF is not interpreted out of the audio stream. For external peers which are not supporting this mode Asterisk then generates the proper RTP messages or tones.

    With SIP INFO mode I made my best results with all devices, sadly it’s not very common used.

    Max

    Am 23.11.2016 um 20:02 schrieb D’Arcy Cain:

    –nab3dMCF9RHGBu2IMIosbbNmBDAi6nFHL

  • I have tried all of these ideas and it still does that stutter. Can anyone suggest any other things to try?