Hey, I used to work on this :).

It's complicated :).

Basically, WebRTC is a combination of a bunch of protocols: ICE, DTLS, SCTP, and RTP. You could theoretically reduce that to ICE + QUIC for p2p use cases and just QUIC for client/server use cases.

For p2p, there is RTCQuicTransport (see https://developers.google.com/web/updates/2019/01/rtcquictra...)

For client/server, there is QuicTranport (see https://web.dev/quictransport/)

Of course, you'll probably want to be able to encode and decode some audio and video as well to make that useful. For that, there is WebCodecs (see https://github.com/WICG/web-codecs or https://www.chromestatus.com/feature/5669293909868544)

For use cases like live streaming and cloud gaming, I did a presentation about the combination of WebTransport + WebCodecs: https://www.w3.org/2018/12/games-workshop/slides/21-webtrans...

And then there is the work happening in the IETF along these same lines: https://datatracker.ietf.org/wg/ript/documents/

Broadly speaking, WebRTC addresses P2P and does things like NAT traversal; HTTP/3 is "classic" server/client communications, with the server needing a publicly reachable hostname.

That being said, nothing specifically prevents a server from being one of the peers in WebRTC, but the overhead can be significant, so it's not commonly used like that.

I'm not aware of any way of doing something like WebSockets with datagram semantics (i.e. over UDP), but it seems like this is something that might be addressed once WebSockets can be used over HTTP/3.

Unrelated! (for now)

WebRTC uses decades old protocols (RTP/RTCP) for media exchange and pre-dates QUIC. There is talk of using QUIC instead, but I have no idea how that is going!

There's the Web Transport proposal. It provides client/server streams similar to what you can do with data channels (ordered, unordered, multiple streams) and it's using QUIC -

https://wicg.github.io/web-transport/