Re: [rtcweb] The DTMF API [Was: Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)]

[Randell Jesup <[e-mail]>]

On 11/16/2011 1:38 AM, Hadriel Kaplan wrote:
> On Nov 16, 2011, at 1:13 AM, Justin Uberti wrote:
>
>> [Local]MediaStreamTrack.sendDTMF(in DOMString tones, in optional long duration)
>>
>> ex:
>> sendDTMF("1")  // plays tone 1 for 50 ms
>> sendDTMF("2", 200)  // plays tone 2 for 200 ms
>> sendDTMF("123")  // plays tones 1, 2, 3 in succession, each for 50 ms
>> sendDTMF("456", 200)  // plays tones 4, 5, 6 in succession, each for 200 ms
> Sounds good to me, but supporting a multi-digit-string as you did above reminds me that I'll have to check with some experts if this is ok - it reminded me there have been issues with DTMFs being too close to each other in time, but I am not an expert in that and it may not be an issue at all.  (there were issues in PSTN when multiple DTMFs were generated back-to-back from a saved address-book contact-entry type thing, but it may have only been a problem for using in-band DTMF which won't be an issue here)

Typically you need an on-time and an off-time when sending a stream.  I 
think typical minimums are around 70ms on, 40ms off, but that's 
off-the-cuff from old neurons.  I think the minimum is around 45ms on, 
but that will see problems with decoders.

http://nemesis.lonestar.org/reference/telecom/signaling/dtmf.html
indicates 50ms min on, 45ms min off, 100ms min cycle duration. I 
wouldn't want to run too close to those numbers, though.

"It should be mentioned that Radio Shack, one of the worlds largest 
retailers of consumer telephone equipment, requires that all telephone 
devices it sells generate DTMF tones of no less than 70 msec of 
duration. Radio Shack developed this number based on real-life use of 
their equipment on telephone networks throughout North America and the 
finding that shorter tones are more likely to cause dialing troubles."

-- 
Randell Jesup
[e-mail]