W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2014

Re: Proposal: Fire a toneDiscarded event while discarding the invalid DTMF values.

From: tim panton <thp@westhawk.co.uk>
Date: Fri, 13 Jun 2014 15:31:33 +0100
Cc: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Justin Uberti <juberti@google.com>, Kiran Kumar Guduru <kiran.guduru@samsung.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <DA91BC44-CF43-4C0B-A593-8112F1E0AEB1@westhawk.co.uk>
To: Harald Alvestrand <harald@alvestrand.no>

On 13 Jun 2014, at 15:18, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 06/13/2014 03:54 PM, tim panton wrote:
>> On 13 Jun 2014, at 14:35, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
>>> So, I am sorry, but the argument of "Javascript can do it, so browser should not" does not sound like a good argument to me.
>> That is exactly my argument. (better expressed than I’ve managed so far ;-) )
>> If it can be implemented by the average javascript developer in 10 lines or can be neatly put into a simple library we shouldn’t
>> put it in the browser.
>> Every thing we add at this stage (and I’ve been saying this for 9 months) delays the standard, and complicates testing. 
>> You have to be _very_ sure your favourite feature is worth the delay.
> Tim, DTMF was added in order to have a surface to command the browser to
> send RFC 4733 telephone-events, because people said that was required to
> implement use case #3.4.2 ("Fedex Call").
> Telephone-events can't be generated using WebAudio.

Yes, I know I lost that argument. (Someone pointed me to a
commonly used device that supports 4733 but not tone-detect, unless you pay extra).

> The interface we have in the spec now was finished a year or so ago. It
> was thought at the time to be an interface that solved the problem, and
> had as few bells and whistles above that as we could get away with.


> To my mind, every message we spend on revisiting this inteface is a
> waste of time. We satisfied our use case, we should go on.


> Some people are saying we should change the text.
> They need to show that the changed text fits better with satisfying use
> case #3.4.2, OR that it makes life significantly easier for either
> browser developers or Javascript developers.
> If not, I see no point in changing it.
> Given that -use-cases is not changing, I don't see ANY justification for
> revisiting the issue of whether we have this API or not.

Agreed, my original point was that the additional features of filtering the invalid symbols
could be done in 1 or 2 lines of javascript and so did not belong in the browser.


> -- 
> Surveillance is pervasive. Go Dark.

Received on Friday, 13 June 2014 14:32:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:59 UTC