On Fri, Jul 14, 2017 at 4:32 PM, bala murugan <fightwit...@gmail.com> wrote: > Thanks Matt , > > see response inline > > > > > On Fri, Jul 14, 2017 at 4:50 PM, Matt Fredrickson <cres...@digium.com> > wrote: >> >> On Wed, Jul 12, 2017 at 10:47 AM, bala murugan <fightwit...@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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev