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- I don't know why we are trying to restrict the solution to PSTN/ITU recommendations. t certainly is possible that interworking is to be done to some other form of VoIP network.


ii- I think the core requirement is that we don't want application developers to use "wrong" values. There are two possibilities here:

- App developer knows what he is doing

In this scenario, he can supply the values to be used.

- App developer does not know much about DTMF digits

In this scenario, browser default values can be used. An application written by such a person still would run on all browsers as long as browsers supports *some* default value -not necessarily the same-.


IMHO, recommending some guidelines for app.developers and default values to be used by browsers (without any keywords) would provide a satisfactory solution for both scenarios.



Thanks,

Tolga


________________________________
From: Roman Shpount <[e-mail]>
Sent: Monday, February 29, 2016 2:30 PM
To: Asveren, Tolga
Cc: Ted Hardie; Harald Alvestrand; [e-mail]
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

On Mon, Feb 29, 2016 at 1:42 PM, Asveren, Tolga <[e-mail]<mailto:[e-mail]>> wrote:
I am not sure whether 40ms should be absolute minimum for all codecs. Even for 6000ms, who am I to argue that somebody can't come up with a use case/application, which requires something longer. So, overall, enforcing does not seem to be the right thing IMGO (default value is fine as already indicated) (and I don't fully agree with your statement that "the point of min/max is promoting sane values" as the model you are describing is  "enforcing" a range rather than a default value in browser/recommendation in the specification).


Hi All,

Just to be absolutely clear, there are no interconnected PSTN systems which accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC 4733 does not impose the minimum DTMF tone duration limit, so VoIP only systems will take shorter tones. We routinely test SBCs and provider gateways on how they handle extremely short DTMF tones. Quite a few of them break, since tones and gaps need to be extended to generate valid PCMU/PCMA audio.

RFC 2833 had a maximum DTMF tone duration of 8191 ms after which the tone duration counter overflowed (unsigned short int used to measure duration in RTP units with 8 KHz clock). I am not aware of anyone who run into this limit for any practical application.

So, as far as I can see we have two options for min duration:

a. Set the min tone duration limit to 40 ms and min gap limit to 30 ms. These are minimum values accepted by national phone networks according to ITU
b. Set the min tone duration and min gap to 0. These are the minimum values possible with RFC 4733

I would prefer option b here, but this is mostly for testing. I would understand if no one else would want this and go with PSTN based limits (option a).

And we have two options for max duration:

a. Set max tone duration to 8000 ms (I would increase it from 6000ms to at least have some reason for it).
b. Make max tone duration unlimited.

I would go with option a. No one needs tones longer then 8 s even for testing.

I assume no one is against the default values of 100 ms tone and 70 ms gap. I believe these values to be safe and reasonable.
>From interop experience I would also enforce starting and ending the tone on the non tone packet boundary, but this can be an implementation specific.

This was all discussed to death in the webrtc group. Unfortunately it was the wrong group to discuss this topic.

Regards,
_____________
Roman Shpount