Re: DTMF API completed

DTMF should be a specialized MediaStreamTrack object, something like 
"DTMFMediaStreamTrack". There's absolutely no reason IMHO to have the 
DTMF object have any methods in any of the core object.

> Iñaki Baz Castillo <mailto:ibc@aliax.net>
> 10 September, 2013 11:33 AM
> 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
>
>
>
> Iñaki Baz Castillo <mailto:ibc@aliax.net>
> 3 September, 2013 3:17 PM
> 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.
>
>
>
> Martin Thomson <mailto:martin.thomson@gmail.com>
> 3 September, 2013 2:58 PM
>
> 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.
>
> 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ñaki Baz Castillo <mailto:ibc@aliax.net>
> 3 September, 2013 1:00 PM
> Hi Martin,
>
>
> 2013/9/3 Martin Thomson<martin.thomson@skype.net>:
>> Unfortunately, this will be unable to produce DTMF that is compatible with any existing DTMF sender or receiver.  The problem is that the DTMFTrack is a standalone entity that does not associate with an existing audio track.
>
>
> I don't see such a problem:
>
>
> --------------------------------------------------
> getUserMedia( {audio: true} )  =>   myStream
>
> var conn = new RTCConnection( options );
>
> conn.addStream( myStream );
>
> var dtmfTrack;
>
> dtmfTrack = conn.addDtmfTrack( );
> or:
> dtmfTrack = conn.addDtmfTrack( myStream );
> or:
> dtmfTrack = conn.addDtmfTrack( myStream.getAudioTracks[0] );
>
> conn.tracks().forEach(function(track) {
>    signalToRemote(JSON.stringify({ "track": track.getDescription() }));
> });
>
> // wait for full negotiation
>
> dtmfTrack.insertDTMF("1234");
> -----------------------------------------------------
>
>
> The RTCDTMFTrack gets associated with an audio track and inherits its
> same SSRC. And it gets its own RTCTrack within the RTCConnection so
> can signal it to the remote (exactly as an audio track).
>
>
>
>
>
>> I made a proposal to the W3C working group that looks similar to this API in many respects, but the DTMFTrack was a wrapper around AudioMediaStreamTrack.  It could equally be a wrapper around RTCTrack.  Inbound audio tracks are automatically wrapped, if they contain the DTMF codec description.
>
>
> Do you mean, as an alternative approach, that DTMF feature could be
> signaled as a separate codec within an audio track description (this
> is, within the RTCTrack)?
>
> That's indeed nice, but we still need the RTCConnection.onadddtmftrack
> event and also the RTCDTMFTrack for both sending DTMFs and receiving
> them, right?
>
>
>
>> This has another properties that I believe to be important: the DTMF interfaces are completely standalone.  The rest of the API has no direct, visible knowledge of DTMF.
>
> Could you explain that a bit more? I see no problem/limitation. Why do
> you want that the rest of the API has knowledge of DTMF? we have
> provided a specifiec RTCDTMFTrack class for that.
>
>
> Regards.
>
>
>
> Martin Thomson <mailto:martin.thomson@skype.net>
> 3 September, 2013 12:34 PM
> Unfortunately, this will be unable to produce DTMF that is compatible 
> with any existing DTMF sender or receiver. The problem is that the 
> DTMFTrack is a standalone entity that does not associate with an 
> existing audio track.
>
> I made a proposal to the W3C working group that looks similar to this 
> API in many respects, but the DTMFTrack was a wrapper around 
> AudioMediaStreamTrack. It could equally be a wrapper around RTCTrack. 
> Inbound audio tracks are automatically wrapped, if they contain the 
> DTMF codec description.
>
> This has another properties that I believe to be important: the DTMF 
> interfaces are completely standalone. The rest of the API has no 
> direct, visible knowledge of DTMF.
>
>