[asterisk-dev] ASTERISK - DTMF Inband Handling

[Matt Fredrickson]

On Fri, Jul 14, 2017 at 4:32 PM, bala murugan <fightwithme at gmail.com> wrote:
> Thanks Matt ,
>
> see response inline
>
>
>
>
> On Fri, Jul 14, 2017 at 4:50 PM, Matt Fredrickson <creslin at digium.com>
> wrote:
>>
>> On Wed, Jul 12, 2017 at 10:47 AM, bala murugan <fightwithme at gmail.com>
>> wrote:
>> > Hi ,
>> >
>> >  can anyone provide answers or comments on the below
>> >
>> >  1.   What is the expected minimum and maximum silence duration between
>> > the
>> > dtmf tones.
>>
>> I think that depends on how you're playing DTMF tones within Asterisk.
>> For tones utilized in the case of sending call address data to setup
>> the call, the answer is dependent on the channel driver.  For tones
>> that are bridged between calls that are already up and active, you can
>> potentially have variable length tones, depending on where the DTMFs
>> are coming from.  If you're using an application in Asterisk to play
>> tones depending on the underlying API the answer might be different as
>> well.  Which case are you concerned about?
>
>
>>
>> [Bala] This is expected through an External IVR Application that talks
>> through Asterisk AGI Interface which plays prompt and expects DTMF on agi
>> response .
>> This is not a bridged call . Asterisk is only the receiver of Inband DTMF
>> on G711 ulaw and send the same to the external IVR application via AGI
>> using chan_sip Driver
>
>      Need to know if there is any expected  fixed silence (max or min)
> duration between each tones required for reliable processing of the tone
> that comes from  gateway/switch(which is a source sending inband dtmf
> tones).

Not that I know of - but it could be that you're finding out something
new.  One thing to consider, particularly if you're using inband DTMF
- packet loss can kill detection.  So verify that you don't have
packet loss causing you detection issues as well.

>> > 2. mindtmfduration = 80msec in /etc/asterisk/asterisk.conf what is the
>> > significance of this parameter ? .  Is there any maxdtmfduration or
>> > highwatermark configuration or limitation in handling the DTMF tone's
>>
>> If a passed through DTMF event on a bridged call that's already up
>> receives a dtmf indication that is shorter than the mindtmfduration,
>> Asterisk will extend the length of the tone to be at least
>> mindtmfduration milliseconds long.
>> [Bala] Can this be explained more on how the behavior would be for IVR
>> kind of application that's implemented using AGI.

It would appear that mindtmfduration behavior would be triggered when
you have two channels bridged together and one tries to send a DTMF
tone that's shorter than mindtmfduration.  So unless your AGI has two
channels bridged together (with a Dial application or something of
that nature) my guess is that you would not run into scenarios where
it would be utilized.

>> > 3. can it handle the DTMF tones  ranging in the 180-210 ms duration .
>> > The
>> > reason is we are experiencing DTMF issue and all the tones that sent to
>> > asterisk are in this range.
>>
>> I can't think of a reason why that would be an issue.
>
>    [Bala] We see the tones are missed if there is a delay of 400msec between
> tones with the tones duration ranging  180-210ms.
>
>    so looking for defined or asterisk expected standard length/duration and
> delay/silence duration between each tones Inband DTMF benchmark for reliable
> DTMF processing .

Perhaps check into the packet loss theory - that's where my thoughts
go first.  This is a probably a better question to ask on the -users
list.  Typically, the -dev list is for C-level source code discussion.
Regardless of that, I wish you the best in your mystery.  Perhaps
there is a bug that you are dealing with, but the DTMF code in
Asterisk is quite old and quite mature - I'm guessing it's something
related to the transport or the way you're using it in your scenario.

-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA