Re: DTMF again

On 12/15/2011 05:57 PM, Timothy B. Terriberry wrote:
>> DTMF or not. So it is best to have the API there always.
> Some more thinking through why this could be a problem:
> What happens if I have a MediaStream that's fed into a
> ProcessedMediaStream to do some mixing, and I call sendDTMF on the
> _input_ to that ProcessedMediaStream, rather than the output? If the API
> is always there, this is something that's easy to do (even if just by
> mistake), but the result I would expect from a real implementation is
> that the DTMF tones are inserted as actual audio into the MediaStream
> being fed into the ProcessedMediaStream (because it isn't directly
> connected to any PeerConnection), rather than as RFC 2833/etc. packets,
> which is clearly a bad thing. Now you need to hope the far end has a
> DTMF decoder, and that it works, and that your ProcessedMediaStream
> didn't distort the audio so much that it breaks it. Whereas if you'd
> called sendDTMF on the output of the ProcessedMediaStream, you could use
> negotiated support for a direct encoding of the data.
> I consider this a clear failure of the "hard-to-misuse" API design
> principle.

A philosophical follow up question: how easy to use, and fool-proof, do 
we need to make the DTMF API?

I'm asking, since to me DTMF is a very special feature that is there for 
legacy interop, not for the main (browser-to-browser) case. It would 
also require that you employ some kind of GW towards the legacy system 
(terminating the PeerConnection-connection so to say). So it would not 
be something the ordinary webrtc developer would ever consider.

To me it would be OK to make DTMF a bit more cumbersome to use (e.g. 
there would be certain cases where it would not work even though there 
is always a DTMF API available on AudioTracks) than the browser to 
browser functionality.


Received on Saturday, 17 December 2011 14:14:51 UTC