> Step 9 · failure. Just log the error to console and call it a day.
There is not a single WebRTC guide that says anything else on the matter of error handling. There is zero guidance on how to handle fail over, what parts are recoverable, how to sequence multiple users joining a session at the same time, what to do if the signal process hangs--basically anything other the default one-to-one successful scenario. All we ever get is the same rehashing of the signalling process, for the last 5 years now. It's ridiculously bad.
I think once you understand the handshake, it make a lot of sense. But the success case is just one. And we don't need 20 guides on it with 0 on any error cases.
I've probably read 90% of the available literature, including several full length books. They pad their length with code listings, like people copy code out of books anymore. You are on your own if you are trying to develop a good app using WebRTC.
The best way to deal with this in my experience is by drawing out finite state machines that cover all possibilities and ensure that every path through the state machine ends up making forward progress towards a graceful error recovery.
I've found this[0] chapter has a great overview of WebRTC communication. I do wish the transports were a bit more pluggable so I could use, say, an onion service to bust NAT for me.
In general I believe WebRTC, as a set of multiple protocols, has too few full implementations (i.e. w/ the stun/turn/ice server AND client sides, media extensions, etc). I think with more implementations, WebRTC will become a decent p2p standard even without the browser. I personally am starting to toy w/ a Rust impl of some of the RFCs.
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.
One thing I could use is a Node.JS library for streaming MP4s and other vidoe streams to WebRTC directly. Basically use WebRTC as a low latency streaming video means.
This is a great article, if you look at webrtc support once Apple is out of the yellow zone with safari we have across the board support for webrtc in all browsers. Its still not a settled api so its pretty hair raising. My first webrtc startup failed but now I'm working on replacing a legacy flash system with webrtc, in this case with flash being phased out webrtc is the only choice. This article is really well done this is going to help me give something my cto can read and quickly understand so he fully "groks" what my team is doing.
There is not a single WebRTC guide that says anything else on the matter of error handling. There is zero guidance on how to handle fail over, what parts are recoverable, how to sequence multiple users joining a session at the same time, what to do if the signal process hangs--basically anything other the default one-to-one successful scenario. All we ever get is the same rehashing of the signalling process, for the last 5 years now. It's ridiculously bad.
I think once you understand the handshake, it make a lot of sense. But the success case is just one. And we don't need 20 guides on it with 0 on any error cases.
I've probably read 90% of the available literature, including several full length books. They pad their length with code listings, like people copy code out of books anymore. You are on your own if you are trying to develop a good app using WebRTC.