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

[Justin Uberti <[e-mail]>]

On Nov 14, 2011 7:48 PM, "Neil Stratford" <[e-mail]> wrote:
>
> On Mon, Nov 14, 2011 at 11:07 AM, Justin Uberti <[e-mail]>
wrote:
>>>>>>
>>>>>>
>>>>>> 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.
>
>
> In my example the terminating WebRTC media server *is* the PSTN gateway.
There is no RTP beyond the gateway, just ISDN etc. In this case to get the
most reliable DTMF transport from the client to the PSTN I'd have to roll
my own DTMF transport over a DataStream, carry if over the signalling
channel, or accept the lossy RTP DTMF channel. In many cases this DTMF RTP
will be the only RTP sent in that direction - I'm often asked for the
ability to send DTMF without requesting microphone access permission for
information only IVR use cases.
>
> I'd prefer we didn't have a DTMF API and instead leave it up to the
developer to send over the signalling channel (the usual sync arguments
don't apply here if you are sending from an API), but if we do have an API
it makes sense to use the most reliable transport available to carry it.
>
>>> 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.
>
>
> I agree that no signalling is required, but I'm not sure that a simple
callback with width/height is enough to enable notification of quality
changes etc. I still think that to build telepresence/broadcast quality
systems we will need closer access to both codec parameters and codec state
changes.

I'm sure we will need to expose more info, but I think that should be
driven by specific requirements, like what you mention above.
>
> Neil