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

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 UTC