> WebTransport assume a 100% browser world.
Webtransport should work anywhere that http is available. There’s nothing browser specific about it.
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.
(FWIW, you can send RTP over WebTransport datagrams, instead of using SRTP and ICE-lite)
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.
Until then just use webrtc for client/server video. P2p protocols work just fine in centralised contexts.