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.