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

["Asveren, Tolga" <[e-mail]>]

>And, what prevents W3C to enforce
> limits in the API even if such limits are not cited in rtcweb-audio?
> 
> Nothing. I thought your argument was against there being limits at all.
Yes, I was advocating not to enforce any limits on the browser (but won’t harp on it anymore, nothing to add). OTOH, enforcing limits in the browser v.s. in the rtcweb-audio specification are not exactly the same thing AFAICS. Would leaving RFC4733 -indirectly- untouched cause any problems? If what W3C needs is a recommendation from RTCWeb WG, can’t this be conveyed just by other means (and those limits can be imposed by the browser vendors as they see fit). Limits in rtcweb-audio will open the door for the need for yet another type of interworking (to make sure that RTCWeb leg complies with the limits) and wouldn’t it be preferable to eliminate such a need unless doing otherwise is absolutely needed?

Thanks,
Tolga

> -----Original Message-----
> From: Harald Alvestrand [mailto:[e-mail]]
> Sent: Friday, March 04, 2016 7:08 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 12:22, skrev Asveren, Tolga:
> > (I feel some "unfriendliness" in the reply I received but that is
> > probably just my misinterpretation ;-) )
> 
> I see why it could be interpreted as such.
> I will endeavor to maintain a neutral tone.
> 
> 
> 
> > i- I understand very well what is defined by W3C and what by IETF RTCWEB
> WG.
> 
> Thank you. I was a bit confused about your knowledge given that you said "I
> got confused about what WEBRTC WG refers to, maybe to W3C?"
> 
> > 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?
> 
> Nothing. I thought your argument was against there being limits at all.
> 
> >
> > 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.
> 
> If it's not done until now, there's a chance that there are genuine problems
> with doing it at all. We're not here to solve those problems; not part of our
> requirement set.
> 
> >
> > 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.
> 
> I will leave that argument to others.
> 
> >
> > 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.