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

[Roman Shpount <[e-mail]>]

On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <[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