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:50 AM, Neil Stratford <[e-mail]>wrote:

> On Mon, Nov 14, 2011 at 10:39 AM, Justin Uberti <[e-mail]>wrote:
>
>> 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?
>>
>
> Only a SIP destination endpoint would want it in RFC 4733, a PSTN endpoint
> is going to want it in-band in the media stream, which the relaying media
> server from WebRTC to PSTN would likely do. (No SIP here.)
>

This is a RTP thing, not a SIP thing. The PSTN gateway will take RTP as
input, including RFC 4733 telephone-event.


>
>>  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.
>>
>
> How today am I notified of a quality or resolution change in the decoded
> incoming video stream? What I want to avoid is the use of an external
> signalling mechanism to tell me this, so I can avoid the glitchy
> resize-before-ready - I want to do it when the data really is at the new
> resolution.
>

Agreed. The <video/> element has videoWidth/videoHeight properties, but it
doesn't appear that a callback exists to indicate changes, so we'll
probably need to make a new API here.

Note though that no signaling is required for this case.

>
>>
> Neil