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

[Neil Stratford <[e-mail]>]

On Mon, Nov 14, 2011 at 9:13 AM, Justin Uberti <[e-mail]> wrote:
>
> 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.
>

If a WebRTC capable media server is relaying media to the PSTN you may
still want to signal some kind of DTMF between the client and the media
server for onward relay. If the data channel is available, why not use it
for DTMF? Should the DTMF API only be for RFC4733 and not any other
transport?


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

I still see a benefit in exposing codec parameters, and in providing codecs
with the ability to generate events. Imagine I was building an n-way video
conference solution based on a scalable video codec, with a central point
transrating each stream based on the active speaker. Receiving codec events
in the javascript would enable me to detect rate changes and re-render the
display appropriately without requiring a full renegotiation each time.

Neil