Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

[Harald Alvestrand <[e-mail]>]

Den 01. mars 2016 09:04, skrev Asveren, Tolga:
> i- I thought I answered that aspect but here it goes again with an example:
> 
>  
> 
> App Developer, who knows what he is doing:
> 
> API call:
> 
> Send_DTMF_Digit(“5”, duration=2000ms, interval=60ms)
> 
> Browser uses the values supplied in the API call. It does not enforce
> any checks.
> 
> App. Developer may use different values based on the negotiated codec.
> 
>  
> 
> App Developer, who is not savvy about DTMF digits:
> 
> API call:
> 
> Send_DTMF_Digit(“5”)
> 
> Browser uses its default values for duration and interval.
> 
> Browser default values may be different based on the negotiated codec.
> 
> Different browsers may use different default values but this does not
> cause any problem from App. Dev. perspective.
> 

The other way to look at it:

App developer who doesn't know what he's doing:

Send_Dtmf_Digit("5", duration=10)

Runs on Chrome. It works on his test system. Deploys to a thousand users.

Someone runs it on Firefox.

"Illegal value".

Files a bug against Firefox. Wastes a lot of people's time.
In the meantime, the Chrome users discover that the DTMF-sending app
only works part of the time, and files bugs against Chrome for not
sending reliable DTMF.

Lots of time wasted for all. People's distrust of DTMF ever working
reliably goes up.

What's the benefit of NOT having a hard limit?