W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

Re: [Bug 18485] Change DTMF API to be on PeerConnection

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 10 Aug 2012 16:51:10 -0700
Message-ID: <CABkgnnU3zJ1KeyfoL0E6xaUL066E1ww=YN8aYvKsJxp+cYgVXg@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Cc: public-webrtc@w3.org
On 10 August 2012 09:03, Randell Jesup <randell-ietf@jesup.org> wrote:
> The incoming track would be for local echo.  Using an audio element in the
> app for local echo invites the possibility of the local tone not being
> echo-cancelled and leaking into the outbound stream (especially if the
> developer guesses wrong at the length/start-time of the outgoing 'tone'),
> causing possible double-detection in an IVR. Everyone I've seen who puts a
> number pad in a phone or softphone does something in audio when you hit one
> (generic beep or DTMF tone normally), so one would expect anyone building an
> app which expects to access PSTN gateways to include that.  This makes it
> easier for them to not shoot themselves in the foot.   It's not mandatory,
> but likely would be a source of frustration and odd hard-to-reproduce bugs
> and possibly works-in-one-browser but fails 1-in-20-times in another
> browser.

OK, I see where you are coming from.  This is not how I imagined echo
cancellation being built in a browser.  Relying entirely on feedback
loops within the browser is insufficient - you have to use the whole
of the audio that goes to the speaker.

For that reason, echo cancellation is a browser capability.  I don't
necessarily want an application getting access to what music I'm
listening to.

--Martin
Received on Friday, 10 August 2012 23:51:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 10 August 2012 23:51:41 GMT