- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Mon, 13 Aug 2012 11:45:03 +0200
- 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