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

["Asveren, Tolga" <[e-mail]>]

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.

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
> >