Untangling the WebRTC Flow

https://www.pkcsecurity.com/untangling-webrtc-flow.html

by reimertz • 9 years ago

112 25 9 years ago

kodablah4• 9 years ago

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.

0 - https://hpbn.co/webrtc/

tostitos19792• 9 years ago

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????

kodablah4• 9 years ago

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.

mtgx• 9 years ago

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?

https://www.infoq.com/news/2014/08/ortc-webrtc

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.

api• 9 years ago

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.

shams932• 9 years ago

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.

bhouston• 9 years ago

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.

kodablah4• 9 years ago

While I haven't investigated deeply, it might be worth looking at https://github.com/medooze/media-server-node and http://www.kurento.org/.

TD-Linux• 9 years ago

You can use Janus for this - it's a server daemon that you can blast plain RTP to, and it will relay it to all connected WebRTC clients.

moron4hire• 9 years ago

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.

Hydraulix9892• 9 years ago

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.

shams932• 9 years ago

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.

cooervo• 9 years ago

Oh I see working with WebRTC is still difficult as hell.

1mike122• 9 years ago

Lol, started working with it a month ago... Pretty much

Untangling the WebRTC Flow

Related Stories