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 thought I answered that aspect but here it goes again with an example:

App Developer, who knows what he is doing:
API call:
Send_DTMF_Digit(“5”, duration=2000ms, interval=60ms)
Browser uses the values supplied in the API call. It does not enforce any checks.
App. Developer may use different values based on the negotiated codec.

App Developer, who is not savvy about DTMF digits:
API call:
Send_DTMF_Digit(“5”)
Browser uses its default values for duration and interval.
Browser default values may be different based on the negotiated codec.
Different browsers may use different default values but this does not cause any problem from App. Dev. perspective.

Overall, browser never enforces a range. IT either uses what has been supplied by the API call directly or its default values.

ii- I think any enforced range is always guesswork and we may be limiting some use cases (people can be imaginative ;-) ). Especially a min of 40ms is too high IMHO. But as said, I don’t see a reason for the browser enforcing a range anyhow.

Thanks,
Tolga

From: Ted Hardie [mailto:[e-mail]]
Sent: Monday, February 29, 2016 3:53 PM
To: Asveren, Tolga <[e-mail]>
Cc: Roman Shpount <[e-mail]>; 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

Howdy,
On Mon, Feb 29, 2016 at 12:10 PM, Asveren, Tolga <[e-mail]<mailto:[e-mail]>> wrote:
- App developer knows what he is doing

You still have not answered the question of how the application discerns what the bounds are for a browser, if they are not specified.
Also, assuming either 40/6000 (or even 40/8000, to follow Roman's recent suggestion) are used in conformance with PSTN requirements, what is the likelihood that the developer who knows what she's doing is going to select something outside that range?
regards,
Ted


Thanks,

Tolga

________________________________
From: Roman Shpount <[e-mail]<mailto:[e-mail]>>
Sent: Monday, February 29, 2016 2:30 PM
To: Asveren, Tolga
Cc: Ted Hardie; Harald Alvestrand; [e-mail]<mailto:[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