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
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)
[1] https://www.html5rocks.com/en/tutorials/webrtc/infrastructur...
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:
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.