- From: Barry Dingle <btdingle@gmail.com>
- Date: Sat, 18 Jan 2014 20:41:42 +1100
- To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAN=GVAskEDSHExtsLvtPaNKo85fukoakYFsdJzn3Oqki_cOVQQ@mail.gmail.com>
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