- From: Timothy B. Terriberry <tterriberry@mozilla.com>
- Date: Thu, 15 Dec 2011 08:57:41 -0800
- 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 UTC