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

[Stefan Håkansson LK <[e-mail]>]

On 01/03/16 12:27, Asveren, Tolga wrote:
> There are obviously different levels of flexibility. I am not arguing
> for changing the "level of abstraction" for the API. I just argue
> that enforcing limits *in the browser* is not a good idea.

I think differently. Having limits (based on real world 
experience/implementations and that allow agreed use cases to be 
supported) makes life easier for the app developer, the browser 
implementer and everyone involved in testing.

>
> When it comes to use cases setting limits based our
> imagination/agenda does not seem right to me. I think the high level
> principle should be the opposite: Do not add restrictions until
> absolutely necessary. One could have an application where pushing a
> digit for 10seconds triggers some special service/treatment. And 40ms
> is definitely too low of a value, I am aware of VoIP systems where
> lower values are used (but I definitely think that no enforced limit
> is the right thing to do rather than merely decreasing min).
>
> Thanks, Tolga
>
>> -----Original Message----- From: Stefan Håkansson LK
>> [mailto:[e-mail]] Sent: Tuesday, March 01,
>> 2016 6:18 AM To: Asveren, Tolga <[e-mail]>; Harald
>> Alvestrand <[e-mail]>; Ted Hardie <[e-mail]>
>> Cc: [e-mail] Subject: Re: [rtcweb] Fwd: Last Call:
>> <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing
>> Requirements) to Proposed Standard
>>
>> On 01/03/16 11:18, Asveren, Tolga wrote:
>>> Well, in your case, it is obviously app. developers fault to
>>> supply duration/interval without knowing what they mean/what he
>>> is doing (assuming those values are breaking something for
>>> whatever reason for that particular deployment). This would be a
>>> bug on the application/unintelligent behavior by the app.
>>> developer. I am for convenience and accommodating people who are
>>> not savvy about DMTF aspects but enforcing limits to guard
>>> against stupidity would sacrifice flexibility, which IMHO is
>>> another important aspect. And enforcing min/max would do exactly
>>> that, limiting flexibility.
>>
>> I don't think increasing flexibility is a good reason per se. If
>> that was the guiding principle all browser APIs would be on a very
>> low level.
>>
>> Is there a use case that can't be supported with the current spec?
>>
>> Stefan
>>
>>>
>>> Thanks, Tolga
>>>
>>>> -----Original Message----- From: Harald Alvestrand
>>>> [mailto:[e-mail]] Sent: Tuesday, March 01, 2016
>>>> 4:25 AM To: Asveren, Tolga <[e-mail]>; Ted Hardie
>>>> <[e-mail]> Cc: Roman Shpount <[e-mail]>;
>>>> [e-mail] Subject: Re: [rtcweb] Fwd: Last Call:
>>>> <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and
>>>> Processing Requirements) to Proposed Standard
>>>>
>>>> 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?
>>> _______________________________________________ rtcweb
>> mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>
>