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 don’t think browsers should be enforcing *any* limitations. It should be up to the application developer to decide what values to use. This would solve the problem and is the right approach anyhow IMHO.

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