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

[Ted Hardie <[e-mail]>]

Howdy,
On Mon, Feb 29, 2016 at 12:10 PM, Asveren, Tolga <[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]>
> *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]>
> 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
>
>