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

[Neil Stratford <[e-mail]>]

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


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

>
>
Neil