Re: DTMF API completed

2013/9/11 Robin Raymond <robin@hookflash.com>

> DTMF should be a specialized MediaStreamTrack object, something like
> "DTMFMediaStreamTrack".


I like more the vision of Martin, in which DTMF is just an adicional codec
over an existing audio track (see mails below). Having a
specialized MediaStreamTrack was the previous attempt (before last commit)
in which we had RTCDTMFTrack.

Now let's assume such an approach based on RTCDTMFTrack which is a kind of
MediaStreamTrack. This is problematic as we do not want to pervert the
MediaCapture MediaStreamTrack, do we? Do we want
MediaStream.getDtmfTracks() method?

In our previous approach (before last commit) RTCDTMFTrack was not a kind
of MediaStreamTrack at all, but a class totally separated from MediaCapture
(this is, you cannot add a RTCDTMFTrack into a MediaStream and so on).

I strongly like the current approach in which DTMF is just a separate codec
within an audio track ("dtmf" codec) which means that the
RTCTrackDescription of an audio track includes an additional "dtmf" codec
(along with a "opus" or "g711" codec).


> There's absolutely no reason IMHO to have the DTMF object have any
methods in any of the core object.

We need a way to add a DTMF hander. We can add a method to RTCConnection
(as we do now) or we can pervert the MediaCapture MediaStream /
MediaStreamTrack with this legacy and artificial stuff.

We also need a way to receive DTMF. Yes, we could get rid of the
RTCConnection.onadddtmfhandler event, and instead force the user to inspect
the received RTCTrackDescription and, in case it is an audio track with
"dtmf" codec, then create a RTCDTMFHandler instance by itself. I don't see
too much benefit on that.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>