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

[Harald Alvestrand <[e-mail]>]

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