I also decided to learn WebRTC and built a video chat app project: <a href="https://zonko.chat" rel="nofollow">https://zonko.chat</a><p>The last time I did any p2p networking was back in 2002 or something when you still had to do it all manually. We used all sorts of fun tricks like NAT hole punching, and using little script endpoints to capture and forward along port and public IP address information.<p>It was fun to see that all of this has since been formalized under the "ICE framework". I was surprised to see that the STUN spec is only 12 years old now, despite the techniques involved being used for at least 20 years, probably more like 30+.<p>So if anyone who's new to this whole p2p world feels that WebRTC and the ICE framework is confusing or onerous, I would point out that just a short while ago these were basically just a handful of heuristic techniques developed through trial and error over the years. It's really much easier nowadays! zonko.chat only took me 12 or so hours to build (and seems to be well-supported by chrome and ff, even mobile).<p>Edit: Upon reflection, I don't even remember how I learned about some of them. The concept of TURN was probably one that I, and many thousands of others, invented from scratch due to necessity (failed to punch the hole? fall back to this custom relay I wrote in perl). STUN was an easy one to figure out yourself, too. I don't remember how I learned about hole punching though. Probably a forum or a book. Or possibly just an experiment ("what if the two connections touch somewhere in the internet at the same time... hey wait, it worked?") What's interesting to me is that the core "ICE" concepts (hole punching, STUN, TURN) are still pretty simple even in their mature, formalized, scientific form. But the concept of "SIP" is <i>much</i> more sophisticated today than it was back then.
WebRTC seems easy when you're creating a proof of concept with-in your own network, once you get into complex situations behind firewalls across the internet it's a whole different story.<p>The article mentioned "This section we will just touch and go about when do you need a TURN server. It is not needed in all situations but a component needed if you have to deal with slightly less straightway use cases." a TURN server is a must in the real world...
The issue with webrtc is once you step out of the side-project domain, you have to confront the endless implementation differences between browsers, whether it's undocumented SDP behavior, different codecs, non-conformant behavior for low level calls, etc.<p>We've built a push-to-talk walkie talkie system called Squawk[0] which holds long lived webrtc connections in the background throughout the day. We use simplepeer[1] as the base to help bootstrap some of the browser shimming, but it's not perfect. So ultimately we've had to build all sorts of checks into our protocols like an audio keepalive where we send periodic frames (20ms) of silence down the media channel, and verify that we received some additional header bytes on the remote end, because otherwise webrtc would let the connections rot and you wouldn't know until you needed them which in a push-to-talk situation is too late.<p>[0] <a href="https://www.squawk.to" rel="nofollow">https://www.squawk.to</a><p>[1] <a href="https://github.com/feross/simple-peer" rel="nofollow">https://github.com/feross/simple-peer</a>
For those interested in seeing how WebRTC can really scale check out some of the media servers/SFU (Selective Forwarding Units)s that are out there:<p>- janus[0][1]<p>- mediasoup[2][3]<p>- Medoze[4][5]<p>It's never been easier to start your own video streaming platform.<p>[0]: <a href="https://janus.conf.meetecho.com/" rel="nofollow">https://janus.conf.meetecho.com/</a><p>[1]: <a href="https://www.youtube.com/watch?v=zxRwELmyWU0" rel="nofollow">https://www.youtube.com/watch?v=zxRwELmyWU0</a><p>[2]: <a href="https://mediasoup.org/" rel="nofollow">https://mediasoup.org/</a><p>[3]: <a href="https://www.youtube.com/watch?v=_GhdFOZTWTw" rel="nofollow">https://www.youtube.com/watch?v=_GhdFOZTWTw</a><p>[4]: <a href="https://github.com/medooze/media-server" rel="nofollow">https://github.com/medooze/media-server</a><p>[5]: <a href="https://www.youtube.com/watch?v=u8ymYTdA0ko" rel="nofollow">https://www.youtube.com/watch?v=u8ymYTdA0ko</a>
A 19-year-old[0] built a video call app[1] with WebRTC and open-sourced[2] it.<p>Here's a podcast interview[3] about how he did it.<p>[0]: <a href="https://github.com/ianramzy" rel="nofollow">https://github.com/ianramzy</a><p>[1]: <a href="https://zipcall.io" rel="nofollow">https://zipcall.io</a><p>[2]: <a href="https://github.com/ianramzy/decentralized-video-chat" rel="nofollow">https://github.com/ianramzy/decentralized-video-chat</a><p>[3]: <a href="https://syntax.fm/show/256/webrtc-and-peer-to-peer-video-calling-with-ian-ramzy" rel="nofollow">https://syntax.fm/show/256/webrtc-and-peer-to-peer-video-cal...</a>
IPv6 is becoming increasingly common here in Asia (I'm based in Thailand but travel a lot around Asia). For context I have used 3 different ISPs here and all have dual stack, both my cellular connections have also been dual stack.<p>This has meant NAT is less of an issue for native IPv6 endpoints, including P2P.<p>Hopefully when IPv6 is finally widespread in US/Europe we will see stuff taking more advantage of this fact.
I'm eager to create a higher quality video broadcasting (not web meeting, one way only) app for some local yoga studios I help out with and am hoping this article gives me a push in the right direction.<p>The audio quality on zoom is just terrible no matter if you disable DSP or not.<p>So many yoga classes require high quality music.<p>It's frustrating that chaturbate provides top notch video and audio quality for free essentially, while paying $20/mo for zoom gives you what looks like 380p video quality and audio quality I have yet to find a poor comparison for...<p>Does anyone know how one could emulate what chaturbate does?<p>Any good articles outlining how they do what they do?<p>Ideally, the teacher would just plop their phone down in front of them, hit broadcast, and a few seconds of buffering later 1080p video and quality audio would be visible through a browser.<p>Why is that so tough to do??? I haven't been able to find a single article that simplifies or distills it at all.
I've been looking into webrtc and used the "webrtc samples" which are good in many ways. It is fairly easy to get something up and running, but I found several areas that were difficult.<p>* debugging. One users sound just doesn't work while it works perfectly for me with different machines. I am clueless as to how to debug it.<p>* ice. while it works, I had a hard time understanding, tracking and debugging what was going on.<p>* closing and restarting connections<p>* multiple clients in one room?<p>* echo cancellation. This was frustrating for users.<p>* Turn. Is there a tool or way to know which clients need a turn server? Are using a turn server?<p>I ended up guessing that getting it to be a product would actually be fairly time consuming
<a href="https://brie.fi/ng" rel="nofollow">https://brie.fi/ng</a> - a modern pure open source WebRTC implementation. It can even blur peoples background for visual privacy. Sources at <a href="https://github.com/holtwick/briefing/" rel="nofollow">https://github.com/holtwick/briefing/</a>
Twilio costs but not a bad idea. I created Remotehour(<a href="https://remotehour.com" rel="nofollow">https://remotehour.com</a>) which allows you to have an 'open-door' policy video call easily. It works with Twilo :)
This reminds me of Icecomm[0] from a few years back.
Unfortunately, it didn't stick around for too long. It was pretty easy to use, as well, and a lot of people here ended up in a video chat together[1]. LOL!<p>[0]: <a href="https://news.ycombinator.com/item?id=8952880" rel="nofollow">https://news.ycombinator.com/item?id=8952880</a><p>[1]: <a href="https://medium.com/@icecomm/how-launching-icecomm-on-hacker-news-created-the-most-curious-chat-roulette-ever-731fb22dc072" rel="nofollow">https://medium.com/@icecomm/how-launching-icecomm-on-hacker-...</a>
I have some experience in this from developing <a href="https://p2p.chat" rel="nofollow">https://p2p.chat</a> a while back.<p>As others have mentioned, building a simple project is fairly simple. The difficulty comes when you want to scale to more than ~4 users without the app becoming unusable. Adjusting audio/video constraints to ensure that you get optimal media streams is quite difficult, also. Nevermind dynamically tweaking them!
In real life, the STUN server rarely works, and thus, the myth of this peer to peer utopia was never realised, and why webrtc did not receive any attention
A small group of friends and I are working on a virtual karaoke club using WebRTC and Go, <a href="https://github.com/ryanrolds/club" rel="nofollow">https://github.com/ryanrolds/club</a>. 100% agree with the WebRTC being easy to create proof-of-concepts, but there are a lot of edge cases and browsers differences that have to be worked through.
I really learnt so so much from the entire thread discussion here today! WebRTC I've gathered is oftentimes easy to create, but the real challenge is in the scalability. From the way it seems, scalability is only possible with the forwarding architecture with the use of the Selective Forwarding Unit or of like.<p>I always wonder if there is a way to think outside of this 'box'.
One thing I've wanted to make is something like gather.town where I can remix the audio and video so that different users sounded louder or quieter. But, I never figured out where in the WebRTC API that is done. It seems like I need to set up my own SFU and put the necessary logic over there.
Pretty cool!<p>Check out<p><a href="https://github.com/meething/meething" rel="nofollow">https://github.com/meething/meething</a><p>dWebRTC Video Meetings MESH/SFU hybrid using GunDB, MediaSoup and Beyond!<p>This seems to be one of the most promising projects in the WebRTC space with support from Mozilla Builders.
sadly webrtc p2p does not scale. Sadly current HTML-based solutions for media servers are slow and highly CPU intensive. Even more sadly, adobe flash has solved the problem of multi video chat decades ago, but we have decided to deprecate without alternative
This article is a strange one. They mention WhatsApp and some other mobile products but then proceed to frame everything into the context of a browser.<p>WebRTC works without a browser too FYI
It's interesting the raise again for unified communications. All this technology specifically WebRTC is being around for few years now. The Innovation is minimum, why? Most do the problems are solved. When a technology is mature most of the focus is on security or applying other technologies to improve it such as Machine Learning. In the case of VoIP and Video apps, is very mature since the inception of H323, SIP, SCCP, RTP, sRTP, most recently JS and WebRTC.