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

Re: Min DTMF Gap

From: Gavin Llewellyn <gavin.llewellyn@crocodilertc.net>
Date: Fri, 17 Jan 2014 11:47:24 +0000
Message-ID: <CAJJRMDuU9+vrk70RcsSKmBskUUM6BsD5QJxPc79O-Kv6iO_yAg@mail.gmail.com>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I'm not convinced that the timing figures in the ITU specifications
are relevant here.  In that case, DTMF is being used for call setup -
can you really imagine a WebRTC use case where you connect to a
gateway that gives you a dial tone, and then have to provide the
destination number over DTMF?  If you are connecting through a gateway
to a legacy PSTN destination, it's far more likely that you have
already provided the destination number in the signalling layer, but
end up connected to a DTMF-driven menu system.  I don't think these
would be required to meet the same timing guidelines.

Having said that, as long as the defaults are set sensibly (and the
current values look fine to me), I think giving the developer more
flexibility is a good idea.  It should be down to them to ensure the
timing is appropriate in their use case, not the WebRTC specification.
--
Principal Design Engineer
Crocodile RCS Ltd
GPG key: 0xF8F6FFF2


On 17 January 2014 07:11, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
> On 2014-01-17 01:43, 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.
>
> The same table in Q.24 has a value for signal velocity, that is the minimal
> sum of a tone and a gap. Figures are between 93 and 125 ms, with 93 for USA,
> 100 ms for Europe, 120 for Japan and Brazil and 125 for Australia.
> That would require for example 50 tone and 50 pause to cover USA and Europe,
> and 50 tone and 75 pause to cover all.
>
> Since RFC 4733 should be used for the transmission and detection of DTMF,
> one could expect to rely on RFC 4733 for the timing. In section 3.1 it
> refers to Q.24 and points out 40/40 but a limit of 8 to 10 digits per
> second.  That would be accomplished for example by 50 tone and 70 pause.
>
> It would be interesting to know if there are any international experience
> from setting parameters for RFC 4733 usage that we could use.
>
> We should also remember that Q.24 is talking about timing for detection at
> the receiving end. So, some tolerance should be given at the generating end.
>
> So, it seems that 50 tone and 50 pause would be good timing for transmission
> except for Australia, Brazil and Japan ( if the Q.24 limits are still valid
> in these countries ).
>
> Gunnar
>
>
>
>
> _____________
> Roman Shpount
>
>
> On Thu, Jan 16, 2014 at 7:19 PM, Cullen Jennings (fluffy) <fluffy@cisco.com>
> wrote:
>>
>>
>> This has been sitting on the editors todo list for a long time and I
>> wanted to try and sort it out 
>>
>> The gap between DTMF digits is currently specified at 50ms. Long ago
>> someone requested we change this to 40 ms.
>>
>> Does anyone remember why people wanted to make this change? Thought on if
>> it should be 40 or 50?
>>
>> Thanks, Cullen
>>
>>
>>
>
>
Received on Friday, 17 January 2014 11:47:52 UTC

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