[asterisk-users] Touch tone stutter

[Duncan]

On 23/11/16 13:49, Pete Mundy wrote:
> 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
>
>
>> On 23/11/2016, at 12:16 pm, D'Arcy Cain <darcy at vex.net> wrote:
>>
>> 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.


      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

>>
>> 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.
>>
>> -- 
>> D'Arcy J.M. Cain
>> System Administrator, Vex.Net
>> http://www.Vex.Net/ IM:darcy at Vex.Net
>> VoIP: sip:darcy at Vex.Net
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20161123/8f955000/attachment.html>