- From: Barry Dingle <btdingle@gmail.com>
- Date: Mon, 20 Jan 2014 22:17:14 +1100
- To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
- Cc: Roman Shpount <roman@telurix.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Mike Johns <m.johns@commsalliance.com.au>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAN=GVAvRhjW9UEKxCMi8o+YhRLTYZ4mKC0TnitVPT_TKD27auQ@mail.gmail.com>
Gunnar, I agree with you and Roman. What you suggest appears to cover the Australian DTMF case. My only hesitation is that I cannot reply on behalf of Australian Industry. (Everyone 'in authority' is on Summer Leave at the moment !!) Cheers, /Barry Dingle "Australia" Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote: > On 2014-01-19 20:06, Roman Shpount wrote: > > On Fri, Jan 17, 2014 at 12:44 PM, Roman Shpount <roman@telurix.com>wrote: > >> On Fri, Jan 17, 2014 at 12:35 PM, Cullen Jennings (fluffy) < >> fluffy@cisco.com> wrote: >> >>> >>> I’m fine with lower limits allowing people to shoot themselves in the >>> feet but I want the defaults to be safe for most cases. >>> >>> So the way I think we should set this is to set the default to be "safe" >>> for all major deployments world wide. And have the minimum values allow >>> you set it to be as low as is usable in any any major deployment world >>> wide. With that strategy, and the information folks provided in this email >>> thread, I think we get to the following. >>> >>> How about this for a proposed change: >>> >>> We change the min tone time to 40 ms. >>> >>> We change the min gap time to 30 ms. >>> >>> We change the default gap to 70 ms (this meets Australia AS/CA S0020) >>> >>> We leave the default tone duration at 100 ms. >>> >>> Does that change look OK to folks? >>> >>> >> This looks perfect to me. >> >> > After I thought about this a little bit more I would suggest that tone > and gap generation should take the packet ptime into account. The reason is > that WebRTC will switch between RFC 4733 tone and audio codec during the > pause. This means for 70 ms pauses and most common ptime of 20 ms we will > end up with a 10 ms audio packet. Packets of duration other then ptime have > a tendency to cause interop issues. In our implementations of similar DTMF > generation code we would round up gap and tone duration to the next ptime > interval, so that with 20 ms ptime you can set the gap to 40, 60, 80, 100 > ms (etc) and tone duration to 40, 60, 80, 100 ms (etc). With 30 ms ptime it > would be 30, 60, 90 ms (etc) for the gap and 60, 90, 120 ms (etc) for the > tone. > > Yes, this seems right. > The WebRTC API spec should then just mention the rounding of the durations > and alignment with the ptime, and the IETF RTCWEB audio spec should be > specific about how to do the interleaving and relative timing of audio and > DTMF. > > So, for the API spec: > Default duration is 100 ms and default gap is 70 ms. The transmission > timing and duration used will be aligned by extension if needed to use the > same packet transmission time and interval as the audio stream. > > And the details in an RTCWEB spec. > > /Gunnar > > _____________ > Roman Shpount > > >
Received on Monday, 20 January 2014 11:18:04 UTC