Re: [rtcweb] Support DTMF "codec" or expose DTMF in signaling? (Re: DTMF usecase before DTMF API)

[Justin Uberti <[e-mail]>]

On Fri, Nov 18, 2011 at 7:05 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> 2011/11/18 Matthew Kaufman <[e-mail]>:
> > On 11/18/11 7:53 PM, Iñaki Baz Castillo wrote:
> >>
> >> So sending DTMF's over the signaling path is just better than sending
> them
> >> over the media stream, IMHO for all the possible cases.
> >
> >
> > Except for all use cases where the only way to send DTMF is over the
> media
> > path, because (for instance) there is no signaling protocol which
> supports
> > sending DTMF and/or the signaling service is no longer in-path when DTMF
> > needs to be sent.
>
> The question here is (assuming that
> draft-kaplan-dispatch-info-dtmf-package becomes a standard soon):
>
> 1) Do we want to make a solution that *just* works with existing legacy
> devices?
>
> 2) Or do we want to make a solution that *can* interoperate with other
> VoIP protocols since there are specifications for them (regardless
> some devices do not implement them "yet")?
>
> This should be clarified. But if the answer is 1), then we would also
> accept any kind of insecure communication (plain RTP, no ICE, etc etc)
> just to make happy old devices and vendors that don't want to invest
> in making their devices modern and secure.
>
> 1) or 2) ?
>
> IMHO 2).
>
>
We shouldn't use WebRTC as a lever to try to fix everything that might be
seen as suboptimal in unified communications.

To meet the requirements, we need to support DTMF, and life will be much
simpler if we support in-RTP DTMF in the API. (Applications of course are
free to communicate DTMF over signaling instead if they wish).

So I have proposed a simple API method that allows for in-RTP DTMF, in a
separate thread. If you disagree with the details of that API, please
comment in that thread.