Yeah we use libdatachannel. tbh we didnt see much (if any) network improvement using WebRTC over WebSockets, but our testing/analysis is pretty shallow (3 person company - whos got time for that, lets make products)
This is much better then the status quo today. Even if things are E2E encrypted it is so wasteful that 'HTTP Tunnels' route through jump servers.
Cool thing about WebRTC is you can put this in a lot more places if you want.
Don't have anything constructive to add, but will share this on Pion Twitter/LinkedIn later. This has been on my short list of 'I really wish someone would build this' for a long time.
What makes something a 'blessed way'? Are you looking for community support, large corporate users etc..? Not being snarky, curious about how people see the space. Lots of implementations exist and I have used most of them for different projects, not all these projects went to production though.
> Are you looking for community support, large corporate users etc..?
Lots of documentation and demonstrations. And honestly, probably a bit better SEO or maybe searching on my part. For some reason GStreamer's webrtcbin totally flew under my radar.
Also not trying to be snarky/negative about WebRTC. I think it's fantastic at what it does. But as a tinkerer, I want something with more tinkering surface area. Not to detract from the great work on WebRTC and how accessible it's made low-latency streaming.
WebRTC actually feels exceptionally tinkerable to me, with human(-ish) readable SDP offers, public RFCs, various implementations, and importantly it being accessible from JavaScript playgrounds right within the browser!
I've learned a lot about it over the years by following https://webrtchacks.com/, which does just that, i.e. taking apart various open and closed VoIP implementations (WebRTC or otherwise) and seeing how they work.
libdatachannel[0] is exciting me the most for 'low footprint'. str0m[1] is especially exciting, but you have to be in a device/ecosystem that allows rust.
> only if you use the same kind of software and codecs
With WebRTC I can connect clients with varying support of H264, VP8, VP9, AV1, Opus, ulaw and alaw. WebRTC has plenty of flaws, but 'lack of negotiation' is one of them.
Edit: Woah, I somehow completely missed that Pion does WebRTC media too (I've only seen it in a data channel project I've toyed around with in the past). Definitely add that to my list above, and I can somewhat vouch for it, it's cool!
The book 'Show Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft' is a really great read on Dave Cutler.
I would love more 'tech origin stories'. Next I am planning to read 'Soul of a new machine'. Another one I enjoyed was 'Open: How Compaq Ended IBM's PC Domination and Helped Invent Modern Computing'
To me it was that all tutorials are very outdated, using deprecated browser APIs, and/or using packages and services that abstract away WebRTC (SimpleWebRTC deprecated package and service, PeerJS, etc...), and none of them using TypeScript.
So I wrote my own WebRTC app that solves all of those issues [0].
I really liked your book, but there's no code in it at all, and I'm a person that learns more by following examples and applying them.
I honestly found it a bit weird that a book about WebRTC has no code at all.
Thanks for your contribution and maintaining the pion library(I am a user). The thing is that WebRTC usually isn't a complete solution, many don't want to have p2p but a p2s2p(which usually means distributed computing/SFU) solution, which makes developing an application way too complex.
Thanks for your work -- I've used pion before myself.
Then you know the answer to that question. I imagine on a thread like this that would only tread the surface of the complexity, the first question will always be "What the hell even is STUN, TURN, ICE, SCTP, DTLS, SRTP?"
And thats the beginning of the complexity. But it's also a naturally complex problem. So, I thought it was a joke.
Cloudflare has been doing some amazing stuff with live video.
I am so glad they did WHIP/WHEP[0] support. That lets me push video from my browser and pull via GStreamer. Or I can push via OBS and watch in browser with 300ms of latency! When developers start to see what’s possible I expect to see another wave of WebRTC innovation :)
300ms is the same interval originally used in iOS to distinguish between a tap event and a double-tap. IOW, while not "realtime", its's pretty damn fast. I wonder what the theoretical lower limit is for your use case?
Go isn't the problem. The issues I have seen is that you are I/O bound by the kernel.
One company did Pion WebRTC + https://www.dpdk.org/ and is now doing 4x throughput. They tried switching to Rust (and still doing userspace networking) and it didn't make a big difference.
Which is why last-mile solutions often rely on userspace networking, for which low overhead FFI and tight control with unsafe primitives is required (you are unlikely to need the latter with Rust, as long as the data access patterns play nicely with static load partitioning and context switch minimization).
Really great writeup. Stuff like this dispels the FUD that 'You can not scale WebRTC'. It for sure is harder to scale then static/loss-less content like HTTP. But I have never found it intrinsically harder then other media.
I am heavily biased, but it really feels like an inflection point with WebRTC recently. Seeing Cloudflare put up this post, this morning I talked with a camera vendor about having WHIP support in firmware etc... exciting times for sure!
