Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

[Justin Uberti <[e-mail]>]

On Mon, Nov 14, 2011 at 3:39 AM, Neil Stratford <[e-mail]>wrote:

> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti <[e-mail]> wrote:
>
>>
>> As a non-"telco" participant in this WG, I strongly agree with this. DTMF
>> has a clear upside (support for PSTN) and no downside other than the need
>> for a new API method.
>>
>
> This is my concern, that we are proposing a codec specific API method when
> we have ruled out exposing APIs for other codecs.
>
> If two peers have negotiated a data channel between them it doesn't make a
> lot of sense to send DTMF over RTP, it should be carried over the reliable
> data channel. So if we do expose an API for sending tones, can it be done
> in such a way that it can be carried using whatever the most appropriate
> transport is? (obviously without requiring any javascript changes - because
> we can't expect javascript developers to upgrade)
>
>
If two peers have negotiated a data channel, it doesn't make sense to use
DTMF at all. I can see the converse argument to make the DataStream API use
DTMF if it is the only thing available, in order to avoid adding a
DTMF-specific API, but I think the semantics are different enough that the
DTMF API is a better approach.

Regarding whether this API should be extended to be a generic codec API, I
think it should be obvious that the ability to send one of 12 well-defined
signals in a standardized manner is orders of magnitude simpler than the
configuration options available for modern video codecs.