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

[Roman Shpount <[e-mail]>]

On Fri, Nov 18, 2011 at 3:56 PM, Roman Shpount <[e-mail]> wrote:

>
>
> On Fri, Nov 18, 2011 at 3:02 PM, Justin Uberti <[e-mail]> wrote:
>
>> Can you make a proposal for what you'd like to see here? My view is that
>> DTMF is a special case already, so the most pragmatic approach is a special
>> case DTMF API.
>>
>
> DTMF is somewhat a special case due to fast payload switching. So, it
> might need its own specific API.
>
> What I was thinking is something a long the line of
> sendCodecCommand(payloadType, JSONObject). In case of DTMF the JSON object
> should have digitString and digitDuration parameters (maybe more, but this
> is up for the group to decide if we want to specify pause duration and
> volume). Having a CODEC specific command is helpful, since this will allow
> control of codec specific options that can be changed without offer/answer,
> such as encoder complexity or enabling decoder post processing filters,
> without polluting the API.
>

Since my proposal caused some confusion I wanted to clarify it a bit. I do
want WebRTC to support RFC 4733. What I meant in the previous email was
that it might be be better to implement payload specific type features
through some sort of generic codec control API. So, instead of using
sendDTMF command on peer connection, we could do
sendCodecCommand('telephone-event', 'digitstring: "1234"') to implement the
same thing. This will also be useful for other codecs like
sendCodecCommand('ilbc', 'enhancer: true') or sendCodecCommand('silk',
'red: true, redPercent:10') without defining a new ilbc or silk specific
API.
_____________
Roman Shpount