webrtc-nuts-and-bolts VS rtp-over-quic-draft

I recommend WebRTC For The Curious too, as another comment. Personally, I didn't use WebRTC in C#, but the WebRTC concepts are nearly the same in every different language/platform. Also, you can check out my project and documentation on internals of WebRTC, written in Go and JavaScript: https://github.com/adalkiran/webrtc-nuts-and-bolts . It's not related directly, but another example of usage at my other project, written in Go, Python, and JavaScript: https://github.com/adalkiran/distributed-inference .

I am heavily biased toward WebRTC. Here is my take on it though!

> It's incredibly complex as a specification

What is complex about it? I can go and read the IETF drafts, webrtcforthecurious.com, https://github.com/adalkiran/webrtc-nuts-and-bolts and multiple implementations.

QUIC/WebTransport seems simple because it doesn't address all the things WebRTC does.

> has limitations and numerous issues that set limits in how scalable it can be

https://phenixrts.com/en-us/ does 500k viewers. I don't think anything about WebRTC makes it unscalable.

-----

IMO the future is WebRTC.

* Diverse users makes the ecosystem rich. WebRTC supports Conferencing, embedded, P2P/NAT Traversal, remote control... Every group of users has the made the ecosystem a little better.

* Client code is minimal. For most users they just need to exchange Session Descriptions and they are done. You then additional APIs if you need to change behaviors.

* Lots of implementations. C, C++, Python, Go, Typescript

Show HN: WebRTC Nuts and Bolts, A holistic way of understanding how WebRTC runs\ (0 comments)

You can find it at: https://github.com/adalkiran/webrtc-nuts-and-bolts

I agree that RTP over QUIC [1] is closer to what we'd build today if we were starting from scratch than WebRTC is. (Partly benefiting from the lessons learned getting to WebRTC 1.0, of course.)

It's worth noting that QUIC is also a very complex specification and is only going to get more complex as it continues through the standardization process. In parallel, there's ongoing work on the next generation of the WebRTC spec. [2] (WebRTC-NV also adds complexity. Nothing ever gets simpler.)

My guess is that we're at least three years away from being able to use anything other than HLS and WebRTC in production. And -- pessimistically because I've worked on video for a long time and seen over and over that new stuff always take _forever_ to bake and get adoption, maybe that's going to be more like 10 years.

[1] https://github.com/mengelbart/rtp-over-quic-draft