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

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

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 13 Aug 2012 11:45:03 +0200
Message-ID: <5028CC9F.4090502@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Adam Bergkvist <adam.bergkvist@ericsson.com>, Justin Uberti <juberti@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 08/10/2012 05:49 PM, Martin Thomson wrote:
> On 10 August 2012 05:49, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:
>> I don't see any reason why the DtmfAudioStreamTrack needs to be a
>> MediaStreamTrack. We could simply have an object that's used as a remote to
>> insert and receive DTMF on associated MediaStreamTrack objects.
>> [Constructor(MediaStreamTrack outgoingAudioTrack,
>>      optional MediaStreamTrack incomingAudioTrack)]
>> interface DtmfTransceiver : EventTarget {
>>      void playTones (DOMString tones,
>>              optional unsigned long duration = 100);
>>      void startTone (DOMString tone);
>>      void endTone ();
>>      attribute Function? ontone;
>> };
> This also works.  The complication here is for the browser
> implementation: audio tracks will all need to know about DTMF so that
> they can carry it.  There would be browser-private interfaces for
> sending and receiving tones that are only exposed once the descriptor
> is added.  Sure, this would be hidden from users, but the core audio
> track implementation would carry the burden of DTMF support.  That
> negates the benefits of isolation for the browser implementation.

It would be interesting to know how severe this issue is. The 
DtmfTransceiver seems to me like an OK API, but if it makes the 
implementation difficult that is not a good thing.
Received on Monday, 13 August 2012 09:46:14 UTC

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