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

[Justin Uberti <[e-mail]>]

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

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

Why represent the DTMF in an alternate format, when the only thing that
cares about it wants it in RFC 4733?


>  Should the DTMF API only be for RFC4733 and not any other transport?
>

That's my thinking.

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

It's not hard for me to imagine that scenario, but I don't understand how a
codec API is needed to allow UI relayout on stream resolution change.

>
> Neil
>