Re: DTMF API completed

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

> As for Media Capture - I don't see how it perverts anything? Media Capture
> does not return that type of object and is unrelated.
>
> I don't like dtmf objects being needlessly referenced into the main object
> as it therefor cannot be ignored. It should be "yet another extension".
> This is really a specialized type of audio track in many ways.
>
> You can add a DTMF event handler even if it a separate object. You add the
> event handler to the dtmf media stream track object rather than the rtc
> connection. There's no issue or conflict.
>

If you add "DTMF capabilities" (for both sending and receiving tones) to an
audio track then you are "extending" /  "perverting" the audio MediaCapture
MediaStreamTrack, am I wrong?

An anyhow, we need that the RTCTrackDescription for the audio+DTMF track
shows the "dtmf" codec and thus, the RTCConnection needs to be told about
this desire.  I would not like a new DTMF related method/event for
MediaStreamTrack that is automatically detected by the WebRTC core stack so
it produces a RTCTrackDescription which includes the DTMF stuff.

Well, we could get rid of the RTCConnection.addDtmfHandler() method and
instead let the user creating an instance of RTCDTMFHandler class (by
passing some audio track or media stream as constructor argument). And for
the receiver side, the JS could create an instance of RTCDTMFHandler by
passing as constructor argument the RTCTrackDescription which includes both
audio and DTMF codecs. Then we would also get rid of the
RTCConnection.onadddtmfhandler event.

And we could then remove RTCDTMFHandler and instead split it into
RTCDTMFSender and RTCDTMFReceiver, which seems more appropriate with this
approach.

Thoughts?


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