I've looked at WebRTC as well, and it is a mess. Consider websockets as a protocol. So much cleaner and clearer. With WebRTC, you gotta know/implement SIP, RTP, RTSP, RTCP????
WebSockets are a completely different use case (i.e. client-server vs client-client among other things).
Also, you don't need to know/implement those protocols, library abstraction should help you avoid it. The low-level implementers do. That's like saying you have to know the WebSocket protocol/upgrade details to use it.
I'm a low-level systems person (writes the libraries you speak of). Just complaining that it is a pain to get all the details. This also hinders optimization/scalability analysis.
I feel that it looks messy because people are doing it all in userspace. The main justification for this seems to be that you need to encapsulate SCTP in UDP to get it through firewalls, but only FreeBSD looks to have this capability in the kernel network stack.
(author here) I've used SimpleWebRTC[0] in the past with success. It was helpful once I needed to start dealing with the annoyances of cross browser compatibility, multiparty calls, etc. You can also fork their code on github[1], which is what I ended up doing.
Thanks for the nice writeup. You mentioned Javascript in the article. Is webrtc tied to browsers and JS? Or can it be used by other clients too .. like mobile apps or wearables?
Can you clarify the use case? For client side use, PeerJS [0] (a bit old though), simple-peer [1], and SimpleWebRTC.js [2] are friendly abstractions (and you'd use publicly-provided stun/turn servers). If you need to do more advanced stuff instead of client-to-client, there are a couple server-side impls, but it's not a common use case.
Although this doesn't quite answer your question, I had a lot of fun playing with TogetherJS a few years ago; it made taking advantage of webrtc for a collaborative web game/tool pretty straightforward.
I tried Tokbox and vanilla WebRTC (using SimpleWebRTC), and I'm still not convinced there are any benefits to the paid services (oh, they provide out of the box signalling? that's nice, that's a one-time cost, along with setting up your own STUN/TURN servers). It's like using Red Hat Linux enterprise edition instead of the free Ubuntu (or should I say, CentOS?).
The thing is, these SaaS companies that simply wrap WebRTC up and sell it don't take you very seriously if you are not a big client. It's pretty frustrating when your customers have issues, and your only interface with a black box is through T1 support who is just asking you to do stuff you already know to do because it's on their script ("have them refresh their page") rather than actually fixing the problem.
With SimpleWebRTC, it's a bit more work, but I'm able to actually dig into issues myself and fix them whenever my customers have problems. Tokbox is more for someone who doesn't want to take time to grok the contents of the linked article and who has a large enough budget to pay for their enterprise support.
I've designed several p2p protocols. WebRTC is at least two orders of magnitude more complex than necessary. The same is true of all its component protocols.
It's typical of modern network protocols. They must be designed by committee. Web sockets is for a different use case but it's full of cruft as well. Why couldn't it just drop to TCP? But no there's cruft in there for SOAP for some insane reason. I guess someone from MS was on the committee.
Of course a lot of modern software is over-engineered so maybe it's just a general cancer.
Wasn't WebRTC 1.1/ORTC supposed to fix the mess by 1) modernizing the API by making it object-oriented and 2) separating the new stuff from the legacy cruft? Whatever happened to that?
I'm surprised it's not ready yet. I wonder if they are just waiting for AV1/NETVC specs to be finalized.
I wish we got a webtorrent spec, too, but with the MPAA now on the W3C board and the majority of the W3C board seemingly being in league with the MPAA now, it doesn't seem likely anytime soon.
Microsoft Edge implements ORTC. The problem is, the IETF RTCWEB working group was/is dominated by players from the SIP world who wanted to re-use their existing code. The argument was that WEBRTC devs would never need to touch the SDP, and all specification work done for SDP would have to be repeated for any other approach.
Of course, today's WEBRTC SDP, RTP, and RTCP is quite incompatible to existing SIP platforms (which usually dont support trickle ICE, RTP/RTCP bundling etc).
You don't write code to do the srtp that's handled by the browser, you actually often use websockets to signal, but basically you could write a socket.io node or golang server then use one of google's free stun services and do realtime video chat with just that without the need for a specialized webrtc server. If you're building a robust product you would want to add in coturn to authenticate the media layer rather than using google's free stun server.
