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

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

I am not sure whether 40ms should be absolute minimum for all codecs. Even for 6000ms, who am I to argue that somebody can’t come up with a use case/application, which requires something longer. So, overall, enforcing does not seem to be the right thing IMGO (default value is fine as already indicated) (and I don’t fully agree with your statement that “the point of min/max is promoting sane values” as the model you are describing is  “enforcing” a range rather than a default value in browser/recommendation in the specification).

Thanks,
Tolga

From: Ted Hardie [mailto:[e-mail]]
Sent: Monday, February 29, 2016 1:36 PM
To: Asveren, Tolga <[e-mail]>
Cc: Harald Alvestrand <[e-mail]>; 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

On Mon, Feb 29, 2016 at 10:29 AM, Asveren, Tolga <[e-mail]<mailto:[e-mail]>> wrote:
There obviously are some values which are unreasonable but using sane values should be driven by the application

Okay, but the point of the max (6000ms) and min (40ms) is exactly that--to make a common statement about what range is sane in this context.  Without that, there would have to be API surface for discovering what was considered sane; as Harald pointed out, that's going to get little use for the complication it adds.
Do you disagree that these are sane values for a bound to the range?
regards,
Ted


. Browsers still can support some default values –to be used if application does not supply any value-, better based on the negotiated codec, for application developers, who are not savvy enough to pick a value. OTOH, what I am arguing against is browsers *enforcing* certain limits and rtcweb-audio specification mandating limits.

Thanks,
Tolga

From: Ted Hardie [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Monday, February 29, 2016 12:22 PM
To: Asveren, Tolga <[e-mail]<mailto:[e-mail]>>
Cc: Harald Alvestrand <[e-mail]<mailto:[e-mail]>>; Roman Shpount <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

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

On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga <[e-mail]<mailto:[e-mail]>> wrote:
I don’t think browsers should be enforcing *any* limitations. It should be up to the application developer to decide what values to use.

So a tone of 2 hours duration is okay?  That seems pretty likely to trigger the "multiple digits" issue that Roman pointed out for SBCs, for one thing.

Harald's point is that there are some clearly silly possibilities out there, so some limitation will be there (1 hour, 3 minutes, 6000ms) and that probing for what an implementation has chosen is much more complicated here than makes sense.

This would solve the problem and is the right approach anyhow IMHO.
 Without any hats on, I think this is pretty unlikely work out well.
Ted
Thanks,
Tolga

> -----Original Message-----
> From: Harald Alvestrand [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Saturday, February 27, 2016 8:11 AM
> To: Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; Roman Shpount
> <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt>
> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
>
> Den 27. feb. 2016 11:45, skrev Asveren, Tolga:
> > If I don’t mis/over-interpret Roman’s answer, it seems like at least
> > some people who really care/have practical experience about this
> > issue, e.g. Roman and myself, are in favor of not mandating any values
> > and suggesting that w3org specification is updated accordingly. I
> > personally would prefer nothing more than a (or two) sentence as a
> > warning without using any keywords in rtcweb-audio. Does this sound a
> > reasonable choice to other folks?
>
> At the WEBRTC API, this *will* lead to noninteroperable implementations,
> since some browsers will enforce different limits from other browsers.
>
> It's all coming back now - we decided to go with fixed limits in the spec
> because it was inconcievable that implementations wouldn't impose
> *some* limits, and the idea of adding API surface for probing what the limits
> were was just too gross for such a low-value (relatively
> speaking) feature.
>
>
> >
> >
> >
> > Thanks,
> >
> > Tolga
> >
> >
> >
> > *From:*Roman Shpount [mailto:[e-mail]<mailto:[e-mail]>]
> > *Sent:* Friday, February 26, 2016 4:56 PM
> > *To:* Asveren, Tolga <[e-mail]<mailto:[e-mail]>>
> > *Cc:* Harald Alvestrand <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> > *Subject:* Re: [rtcweb] Fwd: Last Call:
> > <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing
> > Requirements) to Proposed Standard
> >
> >
> >
> > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <[e-mail]<mailto:[e-mail]>
> > <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
> >
> >     i- I think w3org should have followed the lead of IETF in this issue
> >     rather than the other way around, i.e. the values recommended by the
> >     IETF specification should have been cited in the w3org document IMHO.
> >
> >
> >
> > I agree completely. I am not aware of any IETF document that defines
> > DTMF or RFC 4733 tone duration limits, so I proposed to add these
> > limits to draft-ietf-rtcweb-audio. Most importantly I wanted the text
> > from W3C reviewed in IETF since it was clearly a network related.
> > Furthermore, anybody implementing WebRTC compatible RTP audio
> > interface should not need to read the API document to find the network
> specific limits.
> >
> >
> >
> >     ii- The reasonable value range could depend on the negotiated codec
> >     and that would be known at the time of interesting the digits; so
> >     anything with MUST strength is too restrictive IMHO.
> >
> >
> >
> > We know that RFC 4733 would be used to transmit DTMF tones from
> WebRTC
> > endpoints. RFC 4733 has no upper or lower limits on tone duration, so
> > technically these can be set to anything or not set at all. Some
> > people argue that we should limit number of foot guns for future API
> > users, so they wanted to have reasonable tone duration limits.
> >
> >
> >
> >     iii- The presence of transcoding/interworking (between different
> >     forms of digit transfer) devices (they will be there, whether we
> >     like it or not, for certain scenarios) makes it even less desirable
> >     to have MUST strength mandates.
> >
> >
> >
> > Unfortunately I spend a significant amount of my time dealing with
> > transcoding elements (SBCs) dealing with RFC 4733 tones. Sending tones
> > which are too short or sent at high rates make such transcoding
> > elements generate unexpected or broken DTMF sequences. Reordered or
> > interleaved tones are commonly generated in response to such
> > sequences. Extremely long duration DTMF digits typically break into
> > several digits. There is danger in not having reasonable limits. The
> > decision if API users should be protected from this danger is up to this
> group.
> >
> >
> >
> >     iv- I think adding some text regarding gap/duration of digit packets
> >     could be fine but I rather would prefer it with “recommend” (even
> >     not RECOMMEND) (and providing some values only as examples).
> >
> >
> >
> > I agree that having reasonable recommended values should be sufficient
> > for most cases. The group has to decide if it wants to protect the
> > developers from themselves and set MUST level limits on tone and gap
> > duration.
> >
> > _____________
> > Roman Shpount
> >
> >
> >
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb