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

[Matthew Kaufman <[e-mail]>]

On 11/18/11 3:29 PM, Harald Alvestrand wrote:
> On 11/18/2011 11:02 AM, Hadriel Kaplan wrote:
>> On Nov 17, 2011, at 9:46 PM, Harald Alvestrand wrote:
>>>>   AFAIK, DTMF is not directly going to useful in browser-browser 
>>>> scenario and it is possible to pass DTMF in the signaling layer for 
>>>> H.323, SIP in the standard manner.
>>> What do you mean by "the standard manner"?
>> H.323 and SIP both offer a signaling-plane means of indicating DTMF, 
>> other than RFC 2833/4733.  For H.323 it's H.245 User Input 
>> Indications (UII) messages.  For SIP it's officially KPML (RFC 4730), 
>> but in practice it's not popular.  Two vendors I know of support it, 
>> but it's a drop in the bucket compared to rfc2833 or SIP INFO.
> OK, thanks.
>
> So the discussion that is really part of the IETF's task here is to 
> pick one (and preferably one) way that WebRTC applications are 
> recommended to do DTMF.

I think it is simpler than that. The IETF's task here is to note that 
in-media-plane DTMF signaling is required to meet the IETF's use cases, 
and that RFC 4733 tells how to send that over the wire. Whether or not 
there are additional non-media-plane ways of doing DTMF signaling turns 
out to be irrelevant, unless we go down the road of defining the entire 
JavaScript-to-Web Server signaling protocol, which I hope we can agree 
to not do.

>
> If we accept draft-cbran's codec recommendation, it follows that an 
> API must be standardized in the W3C, and discussion of the form of 
> that API should go to the W3C list.

Agree with this. It follows that if we agree that RFC 4733 messages are 
to be sent in the media plane directly from the browser, W3C must 
provide an API by which JavaScript may insert those messages.

Matthew Kaufman