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 feel some "unfriendliness" in the reply I received but that is probably just my misinterpretation ;-) )

i- I understand very well what is defined by W3C and what by IETF RTCWEB WG. The point I am trying to make is that in this issue, the order of events seem to be upside-down to me as what is specified in the rtcweb-audio is not only applicable for browsers. And, what prevents W3C to enforce limits in the API even if such limits are not cited in rtcweb-audio?

ii- As far as use cases are concerned, your point seems to be "If it is not done until done, it does not need to be covered". I disagree but will leave this one here as well as I don’t have anything to add.

iii- Just so that they are not lost; would appreciate answers about systems detecting digits with <40ms duration and about the gap between the final packet retransmissions.

Thanks,
Tolga

> -----Original Message-----
> From: Harald Alvestrand [mailto:[e-mail]]
> Sent: Friday, March 04, 2016 5:47 AM
> To: Asveren, Tolga <[e-mail]>; Roman Shpount
> <[e-mail]>
> Cc: 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 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.