Re: Min DTMF Gap

On Fri, Jan 17, 2014 at 6:01 PM, Gunnar Hellstrom <
gunnar.hellstrom@omnitor.se> wrote:

>  On 2014-01-17 22:55, Roman Shpount wrote:
>
>  I would recommend to keep default tone length at least at 70 ms.
> Justification is that it should be long enough to loose a packet of G.711
> audio (which normally is no more then 30 ms long) and still be long enough
> to be recognized.
>
> The transmission must be RFC 4733 coded, that provides good protection
> against packet loss. The tones are sent as RFC 4733 coded event codes, with
> an increasing total duration for each new event code as long as the tone
> lasts. End of tone has a special flag and the end event is sent three times
> for robustness. Gaps by packet loss during the sequence of event codes will
> not generate tone gap and not shortened tone.
>

I think you are forgetting that we are not dealing with an end-to-end VoIP
environment. A phone call generated from WebRTC browser can switch between
VoIP and PSTN several times and can be transmitted using G.711 with no RFC
4733. So, the minimal length of 70 ms is required for DTMF tone to
successfully traverse the PSTN network.


> But you are right anyway that 70 ms tone is a good choice.
> There is an ETSI standard in force for DTMF transmission ES 210 235-2
>
> http://www.etsi.org/deliver/etsi_es/201200_201299/20123502/01.02.01_50/es_20123502v010201m.pdf
>
> And it requires transmission of tones 65-75 ms and gap 65-75 ms.
> Even the upper limit is said to be needed for some equipment to not
> malfunction.
>
> This requirement seems to give us values that are within all previously
> discussed limits.
> Since the detection limit according to Q.24 is 40 ms, it does not make
> sense to allow transmission of as short tones as 40 ms.
>

It still does. In end-to-end VoIP systems (ie in cases where the operator
controls both end of the call), RFC 4733 tones can be reliably transmitted
and recognized for anything longer then 40 ms. There might be interop
requirements to keep the tones as short as possible.

I now suggest that we follow the ETSI standard and set 70 tone 70 gap fixed
> with no adjustment possibility.
>
>
This will be extremely undesirable. First of all, you do need to generate
long DTMF tones (there are IVR features that are activated by DTMF tone of
half a second or longer). Second, and this was the original reason for my
request to Cullen to change these parameters, there are a lot of legacy
interop scenarios with opposite requirements (some need long tones, some
need short tones, some need gaps of the right minimal length). Let the
defaults be safe for typical DTMF use case, but let the application
developer be able to generate any legal DTMF tone if it is needed. If app
developer decides to change these optional settings, it is his
responsibility to make sure that they will work for his use case. There is
no point to reinvent DTMF standards here -- let's set the minimums to
currently accepted minimums.