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

Re: DTMF again

From: Justin Uberti <juberti@google.com>
Date: Tue, 20 Dec 2011 22:24:17 -0500
Message-ID: <CAOJ7v-0fW_fwxM2Z1_fFo9gnhcR13ZSB=Rr1ueJzyWDmpxoh8A@mail.gmail.com>
To: "Timothy B. Terriberry" <tterriberry@mozilla.com>
Cc: public-webrtc@w3.org
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

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.
Received on Wednesday, 21 December 2011 03:25:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC