6 ms·

Untangling the WebRTC Flow

112 points by reimertz 9y ago

bhouston 9y 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.
- kodablah 9y ago
  While I haven't investigated deeply, it might be worth looking at https://github.com/medooze/media-server-node https://github.com/medooze/media-server-node and http://www.kurento.org/ http://www.kurento.org/.
- TD-Linux 9y 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 9y 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.
- Hydraulix989 9y 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.
shams93 9y 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 9y ago
Oh I see working with WebRTC is still difficult as hell.
- 1mike12 9y ago
  Lol, started working with it a month ago... Pretty much
kodablah 9y 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/ https://hpbn.co/webrtc/
- tostitos1979 9y 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????
  - kodablah 9y 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.
    - skykooler 9y ago
      What's a good wrapper library that makes webrtc a bit simpler?
      - gargarplex 9y ago
        I've had decent luck with Tokbox, but it's a paid SaaS rather than simply a wrapper library.
        Hydraulix989 9y ago
        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.

112 points by reimertz 9y 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.

kodablah 9y ago
While I haven't investigated deeply, it might be worth looking at https://github.com/medooze/media-server-node https://github.com/medooze/media-server-node and http://www.kurento.org/ http://www.kurento.org/.
TD-Linux 9y 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 9y 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.

Hydraulix989 9y 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.

shams93 9y 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 9y ago

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

1mike12 9y ago
Lol, started working with it a month ago... Pretty much

kodablah 9y 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/ https://hpbn.co/webrtc/

tostitos1979 9y 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????
- kodablah 9y 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.
  - skykooler 9y ago
    What's a good wrapper library that makes webrtc a bit simpler?
    - gargarplex 9y ago
      I've had decent luck with Tokbox, but it's a paid SaaS rather than simply a wrapper library.
      - Hydraulix989 9y ago
        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.