Re: WebRTC NV Use Cases

On Thu, May 24, 2018 at 4:52 PM youenn fablet <yfablet@apple.com> wrote:

>
>
> > On May 23, 2018, at 9:06 AM, Bernard Aboba <Bernard.Aboba@microsoft.com>
> wrote:
> >
> > Youenn said:
> >
> > "It would also be interesting in a world where we would use the QUIC API
> on the web page server QUIC connection."
> >
> > [BA] By "QUIC API" do you mean the WebRTC-QUIC API?
> > https://w3c.github.io/webrtc-quic/
> >
> > That API is for peer-to-peer use (e.g. the QuicTransport constructor
> requires an IceTransport)
>
> How is it different though? They are all a QUIC connection on which we
> might want to send either structured data or media data.
> I agree that the security model is different, but let’s say we restrict
> this API to same-origin contexts only (plus maybe an opt-in by the server).
> Then, doesn’t it makes sense to allow using the QUIC server connection in
> the same way you would do for peer-to-peer?
>

I agree that the QuicTransport could be used client-to-server without ICE.
It's pretty easy for a server to also terminate ICE (ICE lite is easy), but
I think we could get the consent/security things right to allow for
QuicTransport without ICE.


>
> FWIW, if we define such an API, we should make it as good as possible, and
> not care about RTP too much, if not at all.
> RTP is the protocol in use for WebRTC currently, maybe it should also have
> its own API.
> It is then up to the other APIs (encoder/decoder) that could be used in
> conjunction with either QUIC or RTP to be designed adequately.
>

That's exactly what I think we should have: media in one corner
(tracks/encoders/decoders) and transports in another (RTP/QUIC/SCTP) and
let anyone stick whatever audio/video/data over whatever transport they
want.


>
>         Y
>
>
>