Re: DTMF v4

On Fri, Dec 14, 2012 at 5:30 PM, Gunnar Hellström <
gunnar.hellstrom@omnitor.se> wrote:

>  On 2012-12-14 22:10, Roman Shpount wrote:
>
> WebRTC-SIP Interworking Requirements Draft states that:
>
> A3-4 WebRTC MUST provide a means for the Javascript application to invoke
> [RFC4733] DTMF events to be generated, and their duration, with a default
> duration of 100ms.
>
> A3-6 WebRTC MUST NOT generate [RFC4733] events closer than 50ms
> back-to-back.  In other words, even if                      the Javascript
> calls the API repeatedly or provides a string of digits to send, the
> browser must enforce a minimum of 50ms inter-event gap.
>
> There are several fairly old recommendations, such as ITU-T V.18, on which
> these values are based, but the bottom line that these values are usually
> considered safe.
>
>   ITU-T Recommendation Q.24 is the origin of the timing of DTMF.
> http://www.itu.int/rec/T-REC-Q.24-198811-I/en
> A table is given in Annex A for some countries.
>
>
> It seems that a minimum 40 ms signal and minimum 30-70 ms gap are common
> requirements.
> ( the 70 ms gap is Australia. I suggest that you check if they still
> require that value. )
>
> So 50  ms signal and 50 ms gap sound good for real produced values except
> for what is said for Australia in Q.24.
> But some countries seemed to require a sum of signal + gap to be more than
> 120 or 125 ms, while more common seems to be 100 ms.
>
> I assume that the duration mentioned in A3-4 is meant to be signal time
> plus silence time. Right?
> This is
>

I am not sure this is right, I think this actually means 100 ms of tone and
50 ms of silence.

Normally requirements for recognition and detection are different. It is
recommended to generate at least 70 ms of tone with at least 50 ms gaps.
Tones of at least 40 ms in duration with 40 ms pauses should be recognized.
Part of the reasoning is that loosing a single audio packet (typically 20
ms) would still allow DTMF tones and gaps between them to be correctly
recognized.
_____________
Roman Shpount

Received on Friday, 14 December 2012 22:52:16 UTC