Huh? Webtransport isn’t trying to compete with webrtc. It’s a server/client protocol not a p2p protocol. And it’s not designed with video conferencing in mind like webrtc is. Webtransport is trying to be a better alternative for websockets with support for h2/h3 and unreliable delivery.
> WebTransport assume a 100% browser world.
Webtransport should work anywhere that http is available. There’s nothing browser specific about it.
WebTransport (QuicTransport) was cited to be an alternative by one of the RFCs authors [0] he gives his reasoning in the thread.
I consider WebRTC Agnostic because you just need to exchange the Offer/Answer. With something like https://tools.ietf.org/html/draft-murillo-whip-00 it means I can upload video without running any kind of SDK/blobs locally. With WebTransport we are going to have no interop between services/clients. There will be need to be code to signal with each.
I am not sure I follow this. WebTransport defines a way to transfer arbitrary data over HTTP/3, it's not a media protocol. I expect that a well-defined media transfer protocol will eventually emerge for media over WebTransport, and it will make its way to IETF.
(FWIW, you can send RTP over WebTransport datagrams, instead of using SRTP and ICE-lite)
> a well-defined media transfer protocol will eventually emerge
Until then interacting with a 'WebTransport Media API' involves me running code distributed by the person running the API. With WebRTC I can exchange a Offer/Answer and then have a bi-directional media session. I appreciate that these lower level APIs help companies that need the flexibility. I worry that the complexity will lock out Open Source and smaller companies. Smaller companies are going to have to figure out things took years to solve with WebRTC. Stuff like
* Congestion Control/Error Correction trade-offs and Latency
* Simulcast
* Re-negotation
* Rollbacks
* Capability Negotation
I was always a big fan of ORTC. Give flexibility to the power users, but give an even playing field to small players.
> RTP over WebTransport datagrams
I don't feel strongly about QUIC vs S(RTP). WebTransport doesn't force RTP, so it doesn't help unless I control everything. Bridging will get a lot harder. Right now it is nice that Reports/NACKs/etc.. can cross protocols.
> WebTransport assume a 100% browser world.
Webtransport should work anywhere that http is available. There’s nothing browser specific about it.