Re: DTMF again

On Thu, Dec 15, 2011 at 11:57 AM, Timothy B. Terriberry <
tterriberry@mozilla.com> 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.
>

Yeah, this is definitely a pathological case, because there isn't a clear
good way to handle this (AFAICT). Depending on what kind of processing the
ProcessedMediaStream is doing, you may or may not want DTMF tones to pass
through.

My suggestion would be to fail insertDTMF() if the relevant stream isn't
directly connected to an audio renderer or a PeerConnection. Certainly open
to other proposals though.