Re: Min DTMF Gap

On 2014-01-18 10:41, Barry Dingle wrote:
>
>
> On Sat, Jan 18, 2014 at 5:45 PM, Gunnar Hellstrom 
> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>
>     On 2014-01-18 01:53, Barry Dingle wrote:
>>     I have attached the Australian S002 Standard for reference.
>     Good,
>
>>
>>     In summary, Section 5.5.1.9 (e) states:
>>
>>     (i) *minimum duration* of DTMF burst (i.e. transmission)  shall
>>     be *50 ms*.
>     And ETSI ES 201 235-2 section 4.2.4 requires 65 to75 ms.
>
And the maximum limit was for use during supplementary services.
>
>
>>
>>     (ii) *minimum interval* between the transmission of digits shall
>>     be *70 ms*.
>     And ETSI ES 201 235-2 section 4.2.4 requires at least 65 ms and a
>     note requiring not more than 75 ms.
>
>>
>>     A Note says post answering DTMF signalling, digit duration should
>>     be minimum 100 ms.
>     How do you interpret this. Is it tone duration that should be 100
>     ms or tone + gap that should be 100 ms?
>
>     I guess that all our use of DTMF will be "post answering".
>
>
> I took that to mean duration of tone Burst (i.e. NOT including the gap 
> between tone bursts.
>
Yes, that sounds to be the most likely interpretation.

So, then we have guidance to the default values:

The default tone duration should be 70 ms to follow ETSI or 100 ms to 
follow Australia. ( because the usage will be "post answering" )
( the 70 ms figure appears n many other sources as a suitable value. I 
suggest that that is selected if Australia can confirm that it can be 
used. )


The default gap should be 70 ms  ( for both ETSI and Australia )

/Gunnar





> /Barry
>
>
>     /Gunnar
>
>>
>>     I _cannot_ find a reference to a minimum 125 ms tone + gap time
>>     Or to a maximum 'signalling rate' of 8 digits per sec (that
>>     equals 125 ms).
>>
>>
>>     Cheers,
>>     /Barry
>>
>>     Barry Dingle
>>     "Australia"
>>
>>     On Sat, Jan 18, 2014 at 8:39 AM, Gunnar Hellstrom
>>     <gunnar.hellstrom@omnitor.se
>>     <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>>
>>         On 2014-01-17 18:35, Cullen Jennings (fluffy) 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.
>>
>>         Why this long tone? All columns show minimum 40 ms for duration.
>>
>>         If you want to guarantee the minimum total length of tone +
>>         gap to be 125 ms as required by Australia, it would make more
>>         sense to set the default tone to 55 ms.
>>         Then default tone + default gap is 125 ms, and this is also
>>         very close to the maximum rate set by Japan and Brazil.
>>
>>         Regarding all problems with misbehaving echo cancellers in
>>         VoIP gateways, I think it is good to not push these figures
>>         to its extremes.
>>
>>         So, my proposals for default figures are 55 ms tone and 70 ms
>>         gap.
>>
>>         And minimums as Cullen's proposal.
>>
>>         /Gunnar
>>
>>
>>             Does that change look OK to folks?
>>
>>
>>
>>
>>             On Jan 17, 2014, at 6:26 AM, Barry Dingle
>>             <btdingle@gmail.com <mailto:btdingle@gmail.com>> wrote:
>>
>>                 Thanks for helpful reply Gunnar.
>>
>>                 The Australian DTMF specification in included in
>>                 AS/CA S002. The current version of S002 'still'
>>                 states that DTMF tones should have a minimum 70 ms
>>                 gap. The min DTMF Gap value has not changed because
>>                 of PSTN network equipment and some older Customer
>>                 Equipment including IVR.
>>
>>                 I have informed the organisation (Communications
>>                 Alliance) that reviews S002 of the WebRTC interest in
>>                 setting consistent DTMF tone and gap durations and
>>                 that it might impact operation involving Australian
>>                 approved equipment.
>>
>>                 Barry Dingle
>>                 "Australia"
>>
>>
>>                 On Fri, Jan 17, 2014 at 6:11 PM, Gunnar Hellstrom
>>                 <gunnar.hellstrom@omnitor.se
>>                 <mailto: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
>>                     <mailto: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 Saturday, 18 January 2014 21:35:42 UTC