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

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

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?

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