Re: Min DTMF Gap

Thanks Cullen.

I will wake our Regulatory people up to this issue when they return from
their Summer Holiday slumbers and try to get them to respond.

Cheers,
/Barry

Barry Dingle
Fixed - +61(0)3-9725-3937    Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Electrical and Electronic Eng.,
Australia
> Linux + Android + Apple + Open Source software


On Thu, Jan 23, 2014 at 2:50 AM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
>
> 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
> >>
> >
> >
>
>