W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2013

Minimum InterToneGap for DTMF (Re: New version of Peer Connection draft)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 03 Apr 2013 11:29:13 +0200
Message-ID: <515BF669.4000306@alvestrand.no>
To: public-webrtc@w3.org
On 04/02/2013 12:58 AM, Roman Shpount wrote:
> Did I send it in the right thread or should this be addressed 
> somewhere else?

It is on the right mailing list, but with the wrong subject. I've 
changed the subject.
> _____________
> Roman Shpount
> On Wed, Mar 27, 2013 at 4:15 PM, Roman Shpount <roman@telurix.com 
> <mailto:roman@telurix.com>> wrote:
>     Few comments about section 6.2.2:
>     1. It specifies that:
>     /
>     /
>     /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./
>     I this should be adjusted to allow at least 40 ms minimum
>     duration, since tone duration of more then 40 ms is technically
>     legal. Also, inter tone gaps of up to 20 ms are also technically
>     legal, so the minimum inter tone gap should be 20 ms.

I can't parse the logic of your sentence here - are you arguing that we 
should allow shorter inter tone gaps than what is currently allowed? 
Longer inter tone gaps are certainly allowed.

The issue is that shorter inter tone gaps are non-compliant in *some* 
jurisdictions. Longer inter tone gaps are always OK. So by reducing the 
minimum, we're allowing Javascript that creates non-conformant tone 
sequences in some jurisdictions. What's the use case where this is a 
Good Thing?

>     Also, should we allow to modify the duration of delay associated
>     with ',' character? It is currently hard coded to 2 seconds, but
>     it might be useful to control this value via one more optional
>     parameter for insertDTMF.

What's the use case that justifies this additional complexity? It seems 
to me that it takes less Javascript to schedule the sending of the next 
tone 1.5 seconds later than to add yet another optional argument to 

DTMF is a very marginal feature, in my opinion. Adding more complexity 
needs justification.
Received on Wednesday, 3 April 2013 09:29:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:42 UTC