Learn the full details of ICE, SCTP, DTLS, SRTP, and how they work together to make up the WebRTC stack.
Hear how WebRTC implementers debug issues with the tools of the trade.
Listen to interviews with the authors of foundational WebRTC tech! Hear the motivations and design details that pre-dated WebRTC by 20 years.
Explore the cutting edge of what people are building with WebRTC. Learn about interesting use cases and how real-world applications get designed, tested and implemented in production.
Written by developers who have written all of this from scratch. We learned it the hard way, now we want to share it with you!
This book is vendor agnostic and multiple Open Source projects and companies are involved. We would love to have you involved!
When talking to people I really want to emote. I am self conscious that people will think I am not interested/excited in the conversation. Through most of my life 'programming/tech' was something that I cared about. I never had any friends/family that cared though. When I became an adult and started working it felt like a re-birth of sorts :)
I just don't ever want anyone else to feel like I am not interested/excited. I will try dropping the exclamation points, and I hope that my enthusiasm still comes through.
My suggestion would be to throw in related illustrative real world anecdotes that drive a point home (personal experiences of real world impact of the tech or the architecture decisions, for example) instead of exclamation marks. That conveys the 'interested' part, and shows you can demonstrate real world connections to stuff that might otherwise be dry and academic. But it doesn't use exclamation marks! ;)
I’m glad I saw this follow-up reply before commenting, as I was about to respectfully disagree. I only saw one ! in the HN comment you replied to that I thought was superfluous. Checking your example link however, I instead feel your feedback is well warranted.
For someone like myself who knows absolutely nothing about WebRTC, it would be helpful to add an introduction with the very basics: It stands for Real Time Communications, it has to do with videoconferencing? etc.
I was fiddling with webrtc last week and I end up creating a very simplistic video chat. I was amazed on how easy it is to implement that kind of stuff. server (signaling) and client didn't took more than a few hundred lines of JS code.
I was determined to make a real app out of it, but everything I could think of, there were already other people doing similar stuff.
But its a nice piece of tech WebRTC, really impressed me.
I strongly suggest, for your next step up as a JS person, to take a peek at mediasoup.org. P2P has obvious scalability limitations. That lib not only makes server side forwarding easy (once you read example code), but it abstracts a lot of real-world needed WebRTC features such as simulcast and bandwidth estimation. You'll be making high quality Zoom-like pages in no time (beware though, the dev community ain't great for that lib because at least one of the authors comes off quite rude in the forums).
Also I'd be remiss to not point out the OP's own pion Go libs which do similar on the server side.
I suspect we will see a deluge of video chat apps in the near future. They will be similar to the wave of chat apps that appeared around 2015. I hope that the technology will mature soon. The current state of video communication seems improvable.
well, I thought about doing a video chat over some game play, so two friends could play a match of anything while having a video conversation, next day some one posted something similar here on HN.
I then thought about drawing on top of the video stream so you can use as like one os those games where you have to guess what the other people is drawing or, to coach someone one to one and being able to "comment" on their screen as they speak, but again, I'm pretty sure every video chats does that. So I left the idea on the drawer for now.
Any chance you can link the first one (video chat over gameplay)? I'm working on something similar. I've tried searching and didn't turn up all that much.
no, because not the game nor the app is ready, haha. sorry to disappoint
I was thinking something about Yahoo used to do: a chat room with several types of games and you and your friend could play one of those games while trash talk to each other on video
Sean, the author of this book, is an awesome human being. He is so passionate about helping and teaching others. He is also far too humble, he works on Amazon's C++ WebRTC implementation for AWS services, and then rewrote everything in Go to create Pion, an open source community around WebRTC. If you want to join the community, check out the #pion channel in Slack!
Thanks Ryan. I really enjoyed working together on Pion. All the relationships/experiences are what make it :) we still need to finish ffmpeg/desktop capture example.
https://pion.ly/slack if people want to join! If you are interested in RTC/VoIP/P2P it’s a great channel to be in. Lots of people working on many interesting projects in it.
I got the KVS job thanks to Pion! It was fun to have a second shot and not make the same mistakes.
For a client I created a telehealth system for mobile and desktop browsers atop Twilio Video and later OpenTok.
As an experiment in cost savings, I dove into the details and made a raw WebRTC version which worked well for a small number of users in peer to peer mode.
While I found plenty of device farms, none allowed use the device camera and mic.
How would you test a raw WebRTC video chat system short of buying a bunch of devices every generation?
I've never used or looked into WebRTC but seen it floated around and I think I heard Sean on a gotime podcast once? Not sure, but overall I have some offshoot interest as I generally like network protocols. The following is just some minor feedback after starting to go through this.
I started reading and got down to "Connecting" section in the "What, Why, and How" and realized I had no idea what it was used for still. I reread the "What is WebRTC" section, and yep:
> 'The WebRTC protocol is a set of rules for two WebRTC agents to negotiate bi-directional secure real-time communication.'
Totally missed that the first time through.
So, maybe it's just me or maybe I'm just tired, but I feel like it could be called out more what it is and what it is/can be used for. Like the first line in the "Media Communication" section:
> 'WebRTC allows you to send and receive an unlimited amount of audio and video streams.'
That was helpful. And then the "Applied WebRTC" page seems helpful as well. Maybe point these out early on in the document somewhere?
Hope this helps. I've bookmarked and looking forward to reading this more (when I'm not so tired).
I remember working on a simple peer-peer chat using WebRTC [1] and it took me a long time to actually grok what the whole protocol was and how it worked, even with off-the-shelf libraries available. This would have saved me so much time!
Maybe this is something most people already know, but I didn't. The acronym RTC was not expanded or the term WebRTC explained anywhere on the site. It seems this is for the curious who already know what it is.
I did a search and found that it means Real Time Communication. That was one of my guesses, but you might think if someone is trying to draw in and educate the curious, you would want to explain the very basics of the topic right off the bat.
I don't want to make the book (or my other projects) to be about me. Some developers use their Open Source projects to further their celebrity. Then no one else wants to contribute, why just help someones vanity project. The projects languish and die out.
So I try not to put my name on things, and license liberally. My hope is that Pion and 'WebRTC for the Curious' will generate more of a community.
Your stance is very nice and good intended, but I don't think being attributed your work should be a problem at all in forming a good community. IMHO the ingredients are not necessarily extreme humbleness and having the most liberal licensing, instead actually good contents and just basic politeness / not thinking of oneself as a superior being, should be enough.
Probably something like the GNU Free Documentation License [1] could have been also perfectly fine. It would also prevent some shark from waiting until the text is complete and polished and then take the work of authors and contributors and sell it while passing it as their own. And that's quite a nice feature in my book (pun intended)
Whatever, I like the idea of making this the best possible resource for all things WebRTC :-)
I made a live drone broadcasting platform called drohub at https://drohub.xyz based on webrtc. Webrtc is hard indeed even with the help of Janus gateway. Will definetly have a read, as I still consider myself a noob on it. Hope you get good feedback.
ICE is used to establish connectivity over UDP, TCP, TLS or DTLS. With a preference in that order. It just keeps falling back to more expensive transports if the prior ones failed.
This is great! I just spent the weekend researching WebRTC for a language learning project I'm working on. I have a few questions about SFUs. Maybe someone here can help.
1. SFUs seem to be the clear winner for multi-party calls. Do they provide any advantage for 1-on-1 calls over peer'd connections? It seems like using an SFU in this case would double the number of connections, and hence double the connection issues.
2. Do clients communicate with SFUs by establishing a normal RTCPeerConnection like they would with another peer? Or is there some other video sharing protocol for SFUs that I don't know about?
1. Not as much benefit for 1-on-1 except that you can guarantee connectivity without a STUN server, can get a bit more predictable network paths from client to server than client to client, and can abstract choosing the best simulcasted stream quality. It won't double the connection count, but it can make you upload unnecessary streams in the case of simulcast, because the client won't be the one determining which stream quality is best, it'll just send multiple.
2. Yup, SFU acts like another client. Some libs do one connection for up and one for down or other ways to handle stream multiplexing, but overall it's the same WebRTC peer connections.
Thank you! This is very helpful! We are doing mostly 1-on-1 calls, so I'm considering if peered connections would be better. They're certainly cheaper. I hadn't considering simulcasting multiple quality streams. That's something to think about.
By "doubling connection count" I mean CLIENT <-> SFU <-> CLIENT is twice as many as CLIENT <-> CLIENT.
Some do peer to peer for 1:1, then upgrade to actually using the SFU for more participants. But that's a challenge on its own, so when more than 1:1 is expected, you might just prefer to use SFU from the start, and save the hassle for when to switch between those two models
Great, this would have helped us a lot in the implementation of a remote control app we did with webrtc. In my opinion, the best available resource at the moment is https://hpbn.co/webrtc/. (Also about a lot of other protocols)
Any hints on getting the browser makers to enable us to disable it?
I gave up on Chrome because it was preventing my mac from sleeping because "webRTC has active peer connections". Before de mistifying its inner workings, you may want to address why we'd want it and why it messes with power management.
You'll never get that. You'll just have to opt out of it. i think there is an extension or two to turn it off in chrome. Maybe that will fix your problem? Also I think there is just a bool to turn off in firefox as well.
I legitimately still think pions is one of the only good webrtc libraries out there, an absolute pleasure to use. The same day I learned go in 30 minutes, I converted 4k lines to use pions and the result was fantastically stable. Keep it up!
Before I know about WebRTC I always thought you need to spent enormous amount of time and money to built a video chat system. Turns out I was able to implement my idea in less than 3 days with WebRTC.
I did some stuff with WebRTC a year ago and it was so hard to find relevant learning materials. The technology is so cool and I can't wait to dig into this book. Thank you for putting this out!
I wanted to share all my knowledge from working on these.
------
Come learn about the WebRTC specification and how all the protocols work in depth, not just a tour of the APIs. The book is completely Open Source and available at https://github.com/webrtc-for-the-curious/webrtc-for-the-cur...
Learn the full details of ICE, SCTP, DTLS, SRTP, and how they work together to make up the WebRTC stack.
Hear how WebRTC implementers debug issues with the tools of the trade.
Listen to interviews with the authors of foundational WebRTC tech! Hear the motivations and design details that pre-dated WebRTC by 20 years.
Explore the cutting edge of what people are building with WebRTC. Learn about interesting use cases and how real-world applications get designed, tested and implemented in production.
Written by developers who have written all of this from scratch. We learned it the hard way, now we want to share it with you!
This book is vendor agnostic and multiple Open Source projects and companies are involved. We would love to have you involved!
reply