- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 13 Aug 2012 11:51:26 +0200
- To: public-webrtc@w3.org
On 08/13/2012 11:45 AM, Stefan Hakansson LK wrote:
> 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.
>
>
>
The immediate trigger for the current proposal to move the interface to
the PeerConnection was Tommy's realization that it significantly messed
up the MediaStream implementation.
Received on Monday, 13 August 2012 09:51:56 UTC