Re: Min DTMF Gap

OK - Here is my proposed 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 40 ms. The default duration is 100 ms
          for each tone.

          The interToneGap parameter indicates the gap between tones. It
          MUST be at least 30 ms. The default value is 70 ms.
          
          The browser MAY increase the duration and interToneGap times to
          cause the times that DTMF start and stop to align with the boundaries
          of RTP packets but it MUST not increase either of them by more than
          the duration of a single RTP audio packet. 

That close enough for now? 

Barry, don’t worry, it will be awhile before this spec is done and in a month or so if we find out this has a problem, we can still fix it. 


On Jan 20, 2014, at 4:17 AM, Barry Dingle <btdingle@gmail.com> wrote:

> 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 Wednesday, 22 January 2014 15:51:23 UTC