Re: Minimum InterToneGap for DTMF (Re: New version of Peer Connection draft)

On Wed, Apr 3, 2013 at 5:29 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On Wed, Mar 27, 2013 at 4:15 PM, Roman Shpount <roman@telurix.com> wrote:
>
>> Few comments about section 6.2.2:
>>
>>  1. It specifies that:
>> *
>> *
>> *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 70 ms. The default duration is 100 ms for each tone.
>>
>> The interToneGap parameter indicates the gap between tones. It must be at
>> least 50 ms. The default value is 50 ms.*
>>
>>  I this should be adjusted to allow at least 40 ms minimum duration,
>> since tone duration of more then 40 ms is technically legal. Also, inter
>> tone gaps of up to 20 ms are also technically legal, so the minimum inter
>> tone gap should be 20 ms.
>>
>
> I can't parse the logic of your sentence here - are you arguing that we
> should allow shorter inter tone gaps than what is currently allowed? Longer
> inter tone gaps are certainly allowed.
>
> The issue is that shorter inter tone gaps are non-compliant in *some*
> jurisdictions. Longer inter tone gaps are always OK. So by reducing the
> minimum, we're allowing Javascript that creates non-conformant tone
> sequences in some jurisdictions. What's the use case where this is a Good
> Thing?
>

My argument is that this API should be allowed to generate any legal DTMF
tone sequence even if it is legal only in some jurisdictions. My assumption
is that most developers would not change default duration parameters. The
ones who will change them would do so for a reason and should be assumed to
know what they are doing. I would even argue that API should allow to
generate any reasonable DTMF tone sequence even if it is illegal, ie tone
gaps of 0 and more and tone duration of greater then 0. If developer is
going to change default tone or gap duration, we should let them set it to
anything they want.

  Also, should we allow to modify the duration of delay associated with ','
>> character? It is currently hard coded to 2 seconds, but it might be useful
>> to control this value via one more optional parameter for insertDTMF.
>>
>
> What's the use case that justifies this additional complexity? It seems to
> me that it takes less Javascript to schedule the sending of the next tone
> 1.5 seconds later than to add yet another optional argument to insertDTMF.
>
> DTMF is a very marginal feature, in my opinion. Adding more complexity
> needs justification.
>

First of all there is consensus that DTMF is required. I, personally, would
consider it very important feature until last PBX or IVR dies a slow
painful death at some point within the next 100 years.

Second, support for comma based pause in DTMF API was not something that
was discussed on either list. Duration of the pause associated with pause
was not discussed either. It is a nice convenience feature, but as
you correctly pointed out can be coded around. So, what I am trying to say
is either:

a. In order to keep API as simple as possible drop support for comma based
pause

b. If comma based pause is left, make it usable by making pause duration
configurable. Use case for comma based pause is typically to auto-navigate
IVR menus (ie go through a menu like "Press 1 if you know your party
extension", then wait, then enter extension). Doing so you need a more
precise pause control, so you often need to reduce comma pause duration to
half a second or something similar. Two seconds is a very long duration in
IVR. From personal experience, if you expose comma based pause in the API,
you typically get request to control pause duration almost immediately
after someone tries to use it.
_____________
Roman Shpount