Re: Min DTMF Gap

On Sat, Jan 18, 2014 at 5:45 PM, Gunnar Hellstrom <
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.
>
>
>  (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.

/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> 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> 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> 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 Saturday, 18 January 2014 09:42:30 UTC