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

[Harald Alvestrand <[e-mail]>]

Den 04. mars 2016 11:34, skrev Asveren, Tolga:
> i- I don't think satisfactory technical explanation is provided why "enforcing a range" is superior to a "default range". I will leave this here and obviously this is just my personal -but honest- opinion.

I interpret this as "the explanations that have been given do not
convince me".
Sorry about that.

> ii- I got confused about what WEBRTC WG refers to, maybe to W3C? If so, is rtcweb-audio specification only about browsers?

Again, for the umpteenth time:
The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG
(which is a WG of the W3C, not the IETF) API specification.

> I wouldn’t think so. There are other types of entities playing in the RTCWeb domain, e.g. gateways. The limits we are talking about, are they applicable only for digits sent by browsers? What about digits emitted by a native application or a gateway? Will a browser be able to accept them if they are out of the range (assuming that the final outcome is to use enforced ranges)?


If you don't understand which parts of the spec are done by the IETF and
which by the W3C, some more reading might be in order.
And if you don't have any experience in designing Javascript APIs, you
might want to talk to someone who has that experience.

> 
> iii- Just as an example, I am aware of systems, which can detect digits <40ms.
> 
> iv- What about the gap between the final packet (with E-bit set) retransmissions? 
> 
> v- As use cases for the need for longer duration (all these are based on the same deployment model: A "legacy" application controlled by phone needs to be extended so that it can be accessed by Internet connected devices, e.g. a web-book. DataChannel is not used, e.g. not supported by gateway, by application etc..., hence digits are used for control.
> 
> - TV gaming show
> User registers for the game and is selected for that day's show.
> The user sees what is happening on the game on his TV and controls it by digits
> The game (balloon escape) requires that at the beginning the user pumps air into the balloon. This is done by continuously pressing "5"


Reference? To a game that actually works on current (mobile) phones?

> 
> - Remote valve/door/lock control
> Authorized person makes a call and then continuously presses "6" to keep the valve/door/lock open for that period.
> 
> - Panic button
> An application for women who are mistreated by their husbands. Police/Social service workers rush to the registered address if she presses "7" continuously for longer than 10 seconds.
> 
> I am just trying to show that there are many different/imaginative ways using the "digit UI".

If you want to assert an use case, please assert one that is seen in the
real world.

The whole DTMF stuff is a wart that was added to the specification to
address use cases with real, existing, deployed hardware. It was not a
goal to stimulate people to imagine new ways in which DTMF could be used.

It remains a wart. It's a design goal to keep the cost of supporting the
wart low.
Removing the limits in the API would raise the support cost.

> 
> 
> Thanks,
> Tolga
> 
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:[e-mail]]
>> Sent: Thursday, March 03, 2016 11:46 AM
>> To: Roman Shpount <[e-mail]>
>> Cc: Asveren, Tolga <[e-mail]>; Ted Hardie
>> <[e-mail]>; Stefan Håkansson LK
>> <[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
>>
>> Den 03. mars 2016 17:06, skrev Roman Shpount:
>>> On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>     You've made this argument before. I cannot see that anything new has
>>>     been brought to the table that is likely to alter the WEBRTC WG
>>>     consensus to have these enforced limits.
>>>
>>>
>>> Am I correct to understand that WEBRTC WG decided that there should be
>>> limits on DTMF tone generation and it is up to this group (IETF
>>> rtcweb) to decide the exact values of these limits?
>>
>> Formally, the RTCWEB group can advise the WEBRTC group about appropriate
>> values, but in practice, the result is indistinguishable from your formulation :-
>> )
>>
>>> In this case, as I have stated before, the maximum tone duration
>>> should be 8000 ms to match possible tone duration for RFC 2833 DTMF
>>> tone. RFC
>>> 2833 was in use for the past 15 years and no one reported any issues
>>> with this limit.
>>>
>>> Minimum tone duration of 40 ms and minimum gap duration of 30 ms are
>>> minimum physically required to transmit DTMF tone as 8 KHz audio
>>> signal and still satisfy the talk-off specifications. These
>>> limitations have not caused any practical issues for the past 50
>>> years. I would like to mention that shorter tones are used during call
>>> setup since it can be guaranteed that no audio signal is present and
>>> talk-off requirements are relaxed. Furthermore VoIP only networks,
>>> which use RFC 2833/RFC 4733 tones, can support tones and gaps of
>>> anything from 0 ms and up. This is why I initially advocated for 0 ms
>>> min duration. On the other hand if the group decides that removing one
>>> more potential foot gun is more important, I will not be too upset.
>>>
>>> If anybody can come up with the practical example where tones longer
>>> then 8 sec or shorter then 40 ms with less then 30 ms gaps are used,
>>> please report them to the list. Otherwise, let's document what is in
>>> W3C TR and move on.
>>
>> Sounds good.