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

[Ted Hardie <[e-mail]>]

On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga <[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]]
> > Sent: Saturday, February 27, 2016 8:11 AM
> > To: Asveren, Tolga <[e-mail]>; Roman Shpount
> > <[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
> >
> > 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]]
> > > *Sent:* Friday, February 26, 2016 4:56 PM
> > > *To:* Asveren, Tolga <[e-mail]>
> > > *Cc:* Harald Alvestrand <[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 Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <[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]
> https://www.ietf.org/mailman/listinfo/rtcweb
>