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 <tasveren@sonusnet.com>
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:ted.ietf@gmail.com]
> *Sent:* Monday, February 29, 2016 12:22 PM
> *To:* Asveren, Tolga <tasveren@sonusnet.com>
> *Cc:* Harald Alvestrand <harald@alvestrand.no>; Roman Shpount <
> roman@telurix.com>; rtcweb@ietf.org
>
> *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 <tasveren@sonusnet.com>
> 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:harald@alvestrand.no]
>
> > Sent: Saturday, February 27, 2016 8:11 AM
> > To: Asveren, Tolga <tasveren@sonusnet.com>; Roman Shpount
> > <roman@telurix.com>
> > Cc: rtcweb@ietf.org
> > 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:roman@telurix.com]
> > > *Sent:* Friday, February 26, 2016 4:56 PM
> > > *To:* Asveren, Tolga <tasveren@sonusnet.com>
> > > *Cc:* Harald Alvestrand <harald@alvestrand.no>; rtcweb@ietf.org
> > > *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 <tasveren@sonusnet.com
> > > <mailto:tasveren@sonusnet.com>> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>