WebRTC might be our best bet to establish P2P connectivity between all languages/platforms. Would love to get rid of the single point of falure in Pub/Sub systems. WebRTC also feels like a great path towards easy cloud-agnostic code. You can use lots of different languages, and not dependent on SDKs/Servers.
* https://github.com/aiortc/aiortc (Python)
* GStreamer’s webrtcbin (C)
* https://github.com/shinyoshiaki/werift-webrtc (Typescript)
* https://github.com/pion/webrtc (Golang)
* https://github.com/webrtc-rs/webrtc (Rust)
* https://github.com/awslabs/amazon-kinesis-video-streams-webr... (C/Embedded)
* https://webrtc.googlesource.com/src/ (C++)
* https://github.com/rawrtc/rawrtc (C++)
Then you have a couple that aren't Open Source. But proves it is possible for these platforms also.
* Shiguredo (Erlang)
* |pipe| (Java)
If you are new to WebRTC I have been working on making it more accessible https://webrtcforthecurious.com. I am currently pretty tied up with Pion so haven't been able to make much progress lately.
> 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
* 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.
Until/unless we've all moved to IPv6 without any NAT, we'll be stuck needing STUN and TURN to make it work.
TURN is of course an entirely different beast because it's proxying all the data between clients. It's also where some more complex video stuff happens potentially. The good news is that there are solid, open source TURN servers available to run on your own hardware. The downside is that running those servers for non-trivial amounts of clients gets pretty resource intensive pretty quick.
It's typically when ICE can't determine the first few steps (eg your public address) that you need STUN to help you out.
TURN tends to be needed in hostile networking situations like double NAT'd networks or very restricted networks like hospitals.
 - https://webrtcglossary.com/ice/
And the problem isn’t with WebRTC, it’s with the current infrastructure of the net that prevents some clients from just communicating directly without some element of centralization. And some of it’s our own fault.
A cynical way of looking at it might be that WebRTC is being allowed because it helps scale the web while still being dependent on a central weak link of control.
But it is what it is.
For peer to peer, you'd have a tough time avoiding STUN/TURN anyhow.
hell will freeze before that happens.
This is the bread and butter of ISP. Without NAT they lose too many revenue sources.
They will hold to their NATs forever, claiming something like user security. While pushing for IPv6 to reduce their operating costs (those IPv4 costs add up)
This in turn means that symmetric NAT will be considered sort of broken, which it should be as it is horrible for anything P2P or any novel protocol for that matter. Of course IPv6 is the ultimate long term solution.
I feel like this is similar to
"We'll have nuclear fusion in the next 30 years."
However if you look at the graph from google - https://www.google.com/intl/en/ipv6/statistics.html
maybe it'll be here sooner than we think...
 - https://www.cidr-report.org/v6/as2.0/#Aggs
This student didn't understand that it was possible for one device to talk to another device directly.
ITER is huge and fabulously expensive, but it's intended to be more of an experiment/testbed that happens to maybe generate some power. It's not intended to be a practical reactor.
To move to true P2P for WebRTC seems impossible, as even if 80% of web users were on IPv6 without NAT (and even 80% seems a bit hopeless at this point considering we've been transitioning to IPv6 for 20 years now), you'd still need a fallback configuration for the 20% that don't. There doesn't seem to be a feasible gradual transition strategy.
This is not really my area of expertise, so I'd love to be proven wrong.
Many providers choose to use SFU's even when not needed because they have features like recording that require it. I've gotten much better quality and latency on normal webrtc than I have over slack, teams, hangouts, even over bad mobile networks.
Comment below talks about some ideas that are new to me about how to navigate around nAT
STUN servers are cheap to run (they require very little processing and bandwidth as opposed to TURN), and setting up a few on each public cloud should be easy for anyone using ICE seriously. There are also public STUN servers still available, although I would not rely on them personally.
But still I think at least how I read single point of failure: it's reliant on a 3rd party. even if multiple 3rd party it's not realistically trustable in the way 'owning' the full stack would be. Though host your own as someone else points out below.
In the LAN I am excited about this thread https://discourse.wicg.io/t/idea-local-devices-api-lan-servi...
I'd love to see a pool of STUN servers available for this, with some randomization.
Still will need hole punching but no “IP discovery”.
mediasoup is moving towards dropping Google's implementation https://github.com/versatica/mediasoup/issues/344 excited to see congestion controllers that are easily usable by others!
There is some documentation here https://testrtc.com/webrtc-internals-documentation/ and while trying to remember that link I just came across https://chrome.google.com/webstore/detail/analyzertc-visuali... which looks promising to make the internals data more usable.
The gap between webm and zoom proprietary scalable codec still makes or breaks a call.
I've seen news of av1 working in real time up to 720p but I haven't tried it myself yet.
That could make a difference for the open web.
Disclosure: I edited the web.dev announcement
Hopefully over time it will become more accessible.
It is meant to be relatively low level. It's like WebGL, in order to draw a simple square on the canvas it takes likes 50 lines of code just to bind attributes to buffers and stuff, link, compile your shaders and execute the program on the GPU. It takes 3 lines with Three.js. You are probably not meant to use it directly if you don't know the domain, but use a library.
So I'd argue that if every single WebAPI was like that, the web would have been a failure.
At the same time, it's also a great playground if you INTEND to learn some things that can be useful OUTSIDE the browser. For instance, WebGL knowledge can be directly transferred to any OPENGL application, because the API is similar to C or C++ version of it.
Partly because it's intended to be a really, really flexible API, the abstractions are pretty leaky. You end up learning a lot about video codecs, UDP and RTP networking, and browser implementation details as you build out WebRTC applications!
(I'm the cofounder Daily.co of a YC company that tries to make WebRTC "just a few lines of code" for common use cases, and to be the best possible application-level APIs and global infrastructure for advanced developers.)
Though some people here seem to complain about no audio or no video...I have to say once we got it working it kept working. Sometimes the websocket we used for signalling dropped it's connection but the video call kept on trucking on some really bad WiFi!
Having said that, it's an absolute nightmare of an API that should probably be re-done from scratch.
Multiple independent protocol implementations exist (and the protocol part was handled at IETF, through their processes), so interoperability on protocol level has been shown even if browsers happened to pick the same one.
The W3C spec describes the wrapping JS APIs, sufficiency of that spec has been shown by the browsers independently building those layers around a WebRTC library. Especially given the working real-world use WebRTC already has it those two layers combined are a good argument that the spec is suitable.
Is it possible to avoid the signal server in some way? So we can have true p2p network inside a browser directly.
Specifically, you need to construct an object that kind of looks like an SDP message and pass it into the API; the demo applications generally get this from a signalling server, but you can make it based on whatever input you want.
Is there a way to further strip down the long-ass sha-256 fingerprint? A 6 digit pin should be sufficient for communications inside a LAN.
It is a trade off as this would also prevent applications like snapdrop.net working in the local network.
I understand that backwards compatibility is very important, but this adds to technical debt.
As often happens with wars, though, the outcome in 2014 wasn't enough to permanently settle the matter, and there was a further outbreak of fighting later between VP9 and HEVC. More recently, some are saying that the Codec Wars are back, with the arrival of AV1 as a contender.
For beefier machines VP8 works great, and you don't need to worry about cost. For IoT/Embedded space you usually just get H264 (from a hardware encoder). If we didn't have both I think it would shut out a lot of interesting use cases.