Re: DTMF API completed

2013/9/3 Martin Thomson <martin.thomson@gmail.com>:
> To be perfectly clear, DTMF is like forking.  You want to be able to
> ignore it.  With a method on the RTCConnection class, you force users
> to read, understand and then dismiss the feature.

Martin, I would strongly appreciate specific technical issues with the
proposed DTMF API, as from your comment I just understand you would
prefer not to have it. If we hide it, it is not in the API, if we show
it, it must be somehow in the API.

BTW, the user can perfectly ignore the RTCConnection.onadddtmftrack
event (who in a browser is interested in receiving DTMFs?).

Is it just that you don't like the RTCConnection.addDtmfTrack() method
and RTCConnection.onadddtmftrack event? what else?


> If the intent is to make this a usable API, DTMF is not a feature you
> want to shove in the faces of your users.  Turns out, the web already
> has better methods for doing that sort of stuff.

I do know, and personally I hate DTMF into WebRTC, but it seems a "requirement".

I would like to understand what you propose then. From your previous
mail I understood you prefer that RTCDTMFTrack (or any other name)
directly operates on top of an existing audio MediaStreamTrack by
extending its codec list in its associated RTCTrack instance (which is
signaled to the remote so it knows that it will receive DTMF tones
over the same RTP track) but I'm lost with your last mail.


Thanks a lot.



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

Received on Tuesday, 3 September 2013 19:17:55 UTC