Re: DTMF API completed

Hi Martin,

I've modified the API to include your proposal of DTMF as a separate
audio codec (rather than a separate track). Hope you like it:

https://github.com/openpeer/ortc/commit/fb467a7f6a54f7948f38c54e8e32f93a3439015a

Specially:

https://github.com/openpeer/ortc/commit/fb467a7f6a54f7948f38c54e8e32f93a3439015a#L0R707

2013/9/3 Iñaki Baz Castillo <ibc@aliax.net>:
> 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>



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

Received on Tuesday, 10 September 2013 15:33:58 UTC