W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2011

Re: DTMF again

From: Timothy B. Terriberry <tterriberry@mozilla.com>
Date: Thu, 15 Dec 2011 08:57:41 -0800
Message-ID: <4EEA2705.8030603@mozilla.com>
CC: public-webrtc@w3.org
> 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.
Received on Thursday, 15 December 2011 16:58:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 15 December 2011 16:58:11 GMT