W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2018

Re: WebRTC NV Use Cases

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 11 Jun 2018 11:23:14 -0700
Message-ID: <CAJrXDUEyco_CCXm0HHtMUdagHeWj21xC1-fvtrw_jaLi3a6_jg@mail.gmail.com>
To: youenn fablet <yfablet@apple.com>
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, WebRTC WG <public-webrtc@w3.org>
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

>         Y
Received on Monday, 11 June 2018 18:37:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC