I am so happy that WebRTC has so many implementations. Every developer thinks differently, it's good to have a implementation that matches your mindset.

* https://github.com/shinyoshiaki/werift-webrtc (Typescript)

* https://github.com/pion/webrtc (Golang)

* https://github.com/webrtc-rs/webrtc (Rust)

* https://github.com/algesten/str0m (Rust)

* hhttps://github.com/sepfy/libpeer (C/Embedded)

* https://webrtc.googlesource.com/src/ (C++)

* https://github.com/sipsorcery-org/sipsorcery (C#)

* https://github.com/paullouisageneau/libdatachannel (C++)

* https://github.com/elixir-webrtc (Elixir)

* https://github.com/aiortc/aiortc (Python)

* GStreamer’s webrtcbin (C)

See https://github.com/sipsorcery/webrtc-echoes for examples of some running against each other.

> I still don’t fully understand why more people don’t use them over something like QUIC

Dealing with NAT traversal especially with full-cone NATs is difficult and expensive - you have to maintain dedicated infrastructure of TURN servers for NAT and you have to proxy all your traffic through that, it's quite the overhead, especially since IPv4 addresses and bandwidth on AWS don't come cheap.

The horrible boilerplate and complexity is why people don't use it. Getting even simple usage examples seems to be a tall order for some use cases and LLMs are hopeless in trying to help with it.

P2P connections are also often blocked by ISPs for whatever reason, making it impossible to use without a fallback TURN server which defeats the entire purpose of the thing if you wanted to do scalable multiplayer without the server infrastructure. You're left sending over the whole stream with double the latency and have to eat all the bandwidth.

> I still don’t fully understand why more people don’t use them over something like QUIC.

> the ecosystem around there is super underdeveloped compared to the ecosystem around QUIC/quinn

> There is a LOT of boilerplate involved that feels unnecessary

I think you just answered your own question and even gave the answers I would've given.

Im excited for WebTransport for similar reasons. Being peer to peer is really cool though

I have been working on a quic/webrtc application for a while, webrtc capabilities are severely underrated since everything pairs it with TCP signaling defeating the power of webrtc

I have no knowledge of any of these but do you think webRTC might be superior to websockets for a multiplayer game at this point?

My experience is WebRTC has an on-ramp problem, which this is partly to address, but it is significantly helped if you are thrown in the deep end to work on it with someone that knows the quirks already. The big thing I got from that process was to stop being afraid of reading the SDP, because a huge amount of the problems you will run into are really the result of SDP oddities. It is credit to people like the libwebrtc maintainers that the complex morass of MediaStreamTrack processing is as solid and performant as it is these days. (And extendable).

I share the view that it should form the basis of real time communication, humans involved or not, and a/v media involved or not. There seems to be some progress on applying absolute timestamps to frames, for example, however, at some point if we want to have rocket ships using it (and I do too) we will eventually need to have some way to reconcile divergent clocks used at different sources!

Sean is modestly not mentioning Pion here, which is the lower level library many golang people reach to for webrtc components, and deservedly so.

WebRTC is amazing! I think it might be helpful for some younger folks if you talked about UDP, I realize it's maybe a bit "weird" - however coming from the UDP world helped me think about all the ways WebRTC can be used. I think it's one of the most underrated and underutilized technologies.

I cannot thank you enough for writing this; the very first page with the "What, Why and How" is precisely what I wish were written for every "thing" I have ever worked with. It's so clear, and contextualizes so much so quickly, I'm frankly in awe. Thank you for your contributions!

Thanks so much for the book! Its lovely

I’m glad you had fun with WebRTC. It’s super cool tech.

If you are ever back in WebRTC land would loved to help https://pion.ly/discord

The book is vendor agnostic. I wanted it to be timeless and vendor agnostic.

The lack of code made all publishers I approached reject it :( I would love to see a hard copy someday.

I had hoped if I put no code in it the WebRTC community would feel more comfortable with it. If I made it Pion specific, would greatly reduce its reach.

The “for Dummies” branding is a trademark of the publishing company Wiley, so you need a contract with them to use it.

Yep! ICE lets you try a bunch of different ports and protocols.

So you can have a remote peer and try to contact it via UDP/TCP/TLS. You can even attempt via multiple interfaces (Wifi and 5G).

You can then measure the packet loss/latency across these different paths and figure out which one is best.

Likely yes, via TURN servers.

No. It doesn't allow anything that can't be done by a browser behind a firewall connecting to a regular web server outside the firewall.