W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: Min DTMF Gap

From: Roman Shpount <roman@telurix.com>
Date: Fri, 17 Jan 2014 12:43:34 -0500
Message-ID: <CAD5OKxuxNNc-78u7KsxO6BsjiQkXf7GHvLB-VS6UaoV6SnfE7A@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Jan 17, 2014 at 1:42 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 01/17/2014 01:43 AM, Roman Shpount wrote:
>
> I was the person who asked for this change.
>
>  Based on http://www.itu.int/rec/T-REC-Q.24-198811-I/en Annex A, valid
> tone duration is 40 ms and up. Valid gap duration is 30 ms (minimal for
> Japan) and up to 70 ms minimum in Australia. So, my suggestion was to keep
> defaults at their current values but allow to set minimal values to minimal
> possible legal values (40 ms tone and 30 ms gap). My justification is that
> DTMF is a legacy interop feature and it should be able reproduce any legal
> DTMF string which can occur in the wild by modifying the JavaScript
> parameters.
>
> Current text:
>
> The duration parameter indicates the duration in ms to use for each
> character passed in the tones parameters. The duration cannot be more than
> 6000 ms or less than 70 ms. The default duration is 100 ms for each tone.
>
> The interToneGap parameter indicates the gap between tones. It *must* be
> at least 50 ms. The default value is 50 ms.
>
> So you're suggesting that 70 ms change to 40 ms, and "at least 50 ms"
> change to "at least 30 ms"?
>
This is exactly what I am suggesting.


>  I don't have a problem with that - I think it's risky for an app to use
> bursts so short that they are not required to be detected in some
> jurisdictions .... but that's the app's problem, not mine.
>
I agree completely. Most of the people should leave the configuration
settings at their default values. If they are changing this, they should
know what they are doing.
_____________
Roman Shpount
Received on Friday, 17 January 2014 17:44:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC