I'm working on a project that requires consuming a UDP video stream from the browser. Because of the near real time latency requirements, I think a WebRTC is the correct solution, but every time I start reading about it, I get overwhelmed by all these acronyms like STUN, TURN, ICE, etc.
Does anyone have suggestions for good learning paths for WebRTC?
quick summary of the acronyms... STUN/TURN/ICE are all related to NAT traversal (ie. when you are behind a router or firewall of some kind and your computer's IP is different from your public IP). The reason you need this is because UDP is not connection-based like TCP. So STUN is a service that helps your computer find its public IP. ICE is a protocol for finding and reporting peer candidates (after they've learned their public IPs via STUN) so they can establish a peer-to-peer connection. TURN is when you reflect the connection off a public server instead of establishing a peer-to-peer connection.
SDP is session description...basically information on what media formats and other things each client will accept.
RTP is how the media (or other data) packets are framed
RTCP is out of band reporting for things like packet loss and other info so that each side can adjust media properties
The nice thing about WebRTC is it takes care most of this stuff for you. If you're always connecting to a server with a public IP you'll just need a few things:
1) WebRTC server that can accept media data (like janus or aiortc)
2) Some signalling mechanism, Websockets work well for this
3) you _may_ need a STUN server, google has stun servers available but you could also use coturn for this.
The rest you shouldn't need to worry as much about because webrtc handles it all under the hood
"ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device's operating system and network card; if that fails (which it will for devices behind NATs) ICE obtains an external address using a STUN server, and if that fails, traffic is routed via a TURN relay server." (1)
Turn just proxies all the data instead of being p2p. p2p has to overcome NAT, which is why ice and stun exists. If it can't be p2p it'll be turn.
"STUN servers live on the public internet and have one simple task: check the IP:port address of an incoming request (from an application running behind a NAT) and send that address back as a response. In other words, the application uses a STUN server to discover its IP:port from a public perspective." (1)
It also took me several years to get up the gumption to actually learn WebRTC after having previously used wrapper libraries...
And it is annoying, but you can get the stab of it within a week or two. The most confusing thing is figuring out setRemoteDescription vs setLocalDescription - that took a bunch of playing around to finally get it to work.
All said and done, we were able to write a WebRTC adapter in less than 100LOC[1], and it is capable of doing inter-network signaling once peers have established connections. And the "signaling servers" that bootstrap non-WebRTC peers, those servers themselves can be decentralized as well.
If you don't want to deal with the fuss of it all, I highly recommend using EasyRTC, and/or studying their code to learn more:
I felt similarly when I’ve looked into it in the past. My suggestion is to just take a day or two and do a deep dive, use tutorials and it will all get better. Maybe not what I would have wanted to hear but after crossing the chasm to where I understand those things now it doesn’t seem like it was too much. It was just more than I expected from what I saw as a simple browser feature. The thing is that there is a lot to p2p communication when you consider local networks sharing the same up address, firewalls etc... Not just that but how to fallback when someone is behind a network that essentially blocks p2p. WebRTC is somewhat of a low level API that lets you navigate these waters but it expects you to do more work than I initially expected.
If you are more interested in a plug and play solution I’ve heard good things about https://tokbox.com/
As for Toolbox, unfortunately there isn't any good competition in the market. Tokbox is "the best" (though I wouldn't say "great").
Their pricing model is better than most. It's not the cheapest, but it's worth the service quality. The low intro price seems deceiving, but I think it's pretty good because a lot of really basic, proof of concept apps can work on that range and not break the bank. You won't find anything much cheaper for the whole kit and caboodle.
Does anyone have suggestions for good learning paths for WebRTC?