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

[Iñaki Baz Castillo <[e-mail]>]

2011/11/18 Hadriel Kaplan <[e-mail]>:
> 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)

Opss... then, why do we need the "SIP INFO Method and Package
Framework"? just for having a generic "framework"? for nothing?
It's hard to believe :(



> 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

But what is the real DTMF alternative in the signaling plane? using
INFO as so many devices do? such usage has drawbacks, those DTMF's are
not negotiated and so.

Or do you mean SIP KPML (the most exotic and complex mechanism for
sending simple DTMF's)? I'm pretty sure that 99% of existing SIP
devices do not implement KPML (does it really mean that a PSTN GW
should subscribe to any peer fom which it receives an INVITE?? it
sounds really annoying IMHO.


> 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.

I'm not 100% opposed to implementing RFC 4733 in WebRTC. But AFAIK,
instead of creating a cool API, the only worry is about implementing
all the requirements of SIP protocol (and others).

-- 
Iñaki Baz Castillo
<[e-mail]>