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

[Hadriel Kaplan <[e-mail]>]

On Nov 18, 2011, at 7:05 AM, Iñaki Baz Castillo wrote:

> The question here is (assuming that
> draft-kaplan-dispatch-info-dtmf-package becomes a standard soon):


Unfortunately draft-kaplan-dispatch-info-dtmf-package will never become a standard.  I presented it a couple IETF meetings ago, and was basically told to go away and never bring it back to the IETF.  (despite the fact it was the main use-case and motivation for creating INFO packages to begin with)


> 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")?

I'm not sure I understand #2 - we have "a solution that can interoperate with other devices and is a standard": RFC 4733.  It also works with legacy devices.

If you mean #2 is signaling-plane DTMF (a la SIP KPML), then your choices are false - it's not a choice between #1 or #2, because it's impossible *not* to have #2.  We can't choose whether to support DTMF in signaling or not, because it's possible to do it even right now today on any browser, without any changes whatsoever.  So we've already got #2.  Any javascript developer in the Web can do #2 already, today.  The question for RTCWEB is whether to also support RFC 4733 or not.  

So if it's not too hard to add, it would be great to support RFC 4733 as well, so we can let the web-app provider work with even more non-WebRTC devices.  And we've been told it shouldn't be too hard to add, so why do you care?  If you don't want to use it in your web-app, don't.

-hadriel