- From: Gavin Llewellyn <gavin.llewellyn@crocodilertc.net>
- Date: Fri, 17 Jan 2014 11:47:24 +0000
- 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