I’m so excited to show my first open-source project and first post here.
I initially started this project to learn Go language, it is an experimental project. The main goal is to track the adventure of a WebRTC stream from start to finish, by debugging the project or tracking the output at console.
By trying out this project, you will deep dive into the steps which are taken while starting up a WebRTC session, and more.
It consists of a web UI (TypeScript) and a server back-end (Golang) projects. They can run on Docker containers, in development mode or production mode, you can find details in the README file.
After some progress on the development, I decided to pivot my experimental work to a walkthrough document. Because although there are lots of resources that exist already on the Internet, they cover small chunks of WebRTC concepts or protocols atomically. And they use the standard way of inductive method which teaches in pieces then assembles them.
But my style of learning leans on the deductive method instead of others, so instead of learning atomic pieces and concepts first, going linearly from beginning to the end, and learning an atomic piece on the time when learning this piece is required.
I know it’s in a very niche technical domain, but hope you will like my project. Please check it out and I’d love to read your thoughts!
WebRTC is almost the only choice for low-latency video and audio inside a web browser. The open source libwebrtc [1] implementation that's in Chromium and Safari is now mature enough to be used in other native applications if you have a medium-sized engineering team and are comfortable with C++. (Again, WebRTC-as-a-service platforms often provide native libraries that wrap libwebrtc to give you easier to use full stack iOS, Android, (etc) SDKs.)
The three big challenges with WebRTC are that low-latency media is its own domain and the learning curve is steep, that scaling sessions to more than two or three people requires a lot of server-side packet routing code (you can't do pure peer-to-peer with lots of participants), and that there aren't yet the mature "off the shelf" cloud building blocks that exist for HTTP-ish workloads.
WebRTC data channels are the non-video/audio part of the WebRTC spec. My hot take: data channels are rarely the right solution to any problem description that doesn't start with, "well, I already have a WebRTC transport open ..."
[1] https://webrtc.googlesource.com/src
On the off chance that you're still checking this thread, would you care to elaborate? Specifically, if one isn't using WebRTC for media, is there a better off-the-shelf solution for P2P with NAT traversal in native apps?
However for that remaining 5%, I have a lot to learn. Using an abstraction is great when it works, but I'm interested in going through OP's project to get a better sense of what's happening when things go wrong.
NewTek actually uses WebRTC for NDI's remote networking, and while the NDI software itself is prone to crashing and probably not usable for production, the connection to the remote system is never an issue.
I don't find the webrtc signaling and set up particularly noteworthy, but once you try to connect nodes on different networks you're pretty much dependant on some third party.
* FaceTime @ Apple https://support.apple.com/en-us/HT212619
* KVS and Chime @ AWS https://github.com/awslabs/amazon-kinesis-video-streams-webr.... Lots of security cameras and robots use it, not public though.
* Lightstream https://golightstream.com . Cloud compositing and other magic.
I also have something I am working on now that isn't public yet that is using WebRTC. Really excited to see what people build with it/what it inspires next.
It is kind of amazing everywhere you will find WebRTC. Stadia, Boston Dynamics, Zoom, Meet, Security Systems, Drones etc... It is probable that you use WebRTC in production everyday :)
I think it is worth measuring how Google's implementation works, but it is tuned for a very specific use case by a single company.
There are some quirks in getting all the signaling working but there’s now more of a standard to do that process the right way…
Anyway since the devices are on the same network latency is nearly 0…
I do have an ack and retry process … I should add logging to see how often that happens though
Edit: that’s Web Socket Server