 Hello, guys. I'm Tarashish. I'm an undergrad student from India, and I'm sort of new to web development, but I was an GSOC intern for the OpenHatch project last year. So I'm going to talk about WebRTC and how you can easily build real-time web apps with WebRTC and Python. So first, let me tell you what this talk is about and what it's not about. It's kind of an high-level overview of what WebRTC is, what it can do, and what APIs it has. And then there is this overview about the signaling system. We'll get to what signaling system is and how it works and all that and how exactly do you implement it. Next, what it's not about. It's not really a deep guide about what WebRTC can do, how the things work inside WebRTC. Because let me tell you, I'm not that experienced to actually tell that to you, and it's not really in-depth talk about signaling because actually it depends on your particular use guess. So let's start with WebRTC 101. First question, what exactly is WebRTC? So WebRTC is this new technology. It was developed at Google first and then they open-sourced it. Actually, let's your browser or any client, for that matter, to talk to another client, its peers in real-time. Before WebRTC, browsers didn't really have the capability to get the media sources like access to your webcam or your microphone directly. We should use some kind of native plugins and download and install them to let our browsers access the media sources. But now WebRTC actually provides you some JavaScript APIs so you can actually access media directly from your browser and then communicate that media or even arbitrary data like it can be textual data or binary data to peers directly. It's sort of a peer-to-peer network. So as I told you, WebRTC mainly has three functions. First thing, sorry. Oops. Oops. Oh, sorry. OK, yes, three functions. First is to access and acquire the video and audio streams from your webcam or your microphones. Second is to establish connections with your peers and actually transmit that data, that video or audio data that you acquired to other peers. Then the third thing is you can communicate arbitrary data. Suppose you are building a game, you can just communicate JSON or something or files or whatever you want. So for these three functions, WebRTC provides three JavaScript APIs. First one is get user media. It lets you pull out all those video and audio streams. Second is RTC peer connection. It's here the magic really happens. You communicate with your peers and all that. Third is RTC data channel. Data channel lets you communicate arbitrary data that is not the audio video only. First, get user media, acquiring audio and video. So it really has a simple API. Navigator is the global object. And navigator, get user media, gets you all the audio, video tracks. You pass in some constraint object into it and specify all resolution. And do you want audio or video or both? It provides you tracks, video track, and audio track. And you get channels, like let channel for your audio, write channel for audio. It's what the code looks like. This is the constraint object. And you can pass video, true, audio, true, or both. False, I don't know. Then the resolution of the video you want and all that. Then you pass in the success callback. So if you get the stream and whatever you want to do with it, you can do it inside the success callback and then the error callback or whatever happened. Then it's the RTC peer connection object. It really does all the heavy lifting. It does noise cancellation, echo cancellation, codec handling, peer-to-peer communication security, and all that bandwidth management. It sort of figures out what the bandwidth is for the clients and then what resolution should you transmit and all that. It's built in, so we don't have to worry about that. It does all this automatically. Is there some way to influence the bandwidth management from the JavaScript side? No, I didn't think so. It automatically does that. So this is what the code looks like. You get a peer connection object. Then there are these event handlers. So what you want to do when you get a remote video stream attached, or first you actually create an offer. You send that offer to your peer. Then they send you back an answer. So then the communication actually begins. And then you can have a bunch of these event handlers. What do you want to do after you got the offer? What do you want to do after you got the remote video stream or something? Then the RTC data channel, the API is mostly web sockets. But with web sockets, you actually send the data over to the server and then back to another client. But in case of RTC data channel, it's client to client. So the latency is pretty low. And you can choose between UDP or TCP. So it depends on what your data is. If you want a reliable connection, a reliable transport, or a fast transport, so you can choose. And it's secure by DTLS. And then so in sort and summary, before web RTC, client used to send data to the server. And then the server pushed it back to another client. But now it's client to client. Everything's fast and secure. And now when I say snooping in between. The question is, how exactly do the peers find each other? Because if you want to communicate with someone, you just can't go into the internet and shout that, hey, I want to talk to you, talk to me, talk to me, connect to me. So you first need to figure out a way that you find your peer on the internet. But actually the web RTC standards don't actually mention or there is no standard for finding your peer. It's up to us to implement that in whichever way we want. So this thing is actually called signaling. So signaling is sort of the process where you find your peer and then communicate the essential data that is needed for to establish the initial connection to start transferring the actual data. So I told that web RTC actually peer to peer. But we still need servers to actually build the connection. So one example is what signaling does is peers connect to a certain server. Then the server tells, hey, this is A, this is B. And then you can talk all you want without saying anything to the server. So before the actual call begins, the actual data begins to transfer between the clients, you need to sort of pass these metadata to the other peers. You need to pass what codecs do you support, how is your bandwidth and stuff, and then what exactly is your public phasing IP so that the connection can be made and all that. And it's all taken care by the signaling mechanism. So this is what it looks like. The apps communicate by signaling at first to exchange the session description. Once you get the session description from your other peer, you pass it on to the browser. And then the media actually flows from browser to browser. You don't need a server then. So let's talk about how you can actually implement signaling. So signaling is just another messaging service. So you just need some way to where there is bi-directional flow of data from one client to the other. It can be via a server, or you can even send your session description via email or some kind of messaging service, or even a messenger piece if you want. Doesn't matter. If you just need some kind of messaging service, and it has to be bi-directional. So for that, you have WebSocket. It's kind of the newest technology for signaling. And you don't actually need to worry about browser support per WebSocket because all the browsers that support WebRTC support WebSockets too. And then there is XMPP Jingle. That is, I don't know what that is, but it's used for all those VOIP things. And then there are GammaCell platforms like Pusser and PubSub that you do the message processing. And then Google App Engine has this messaging channel API that lets you pass messages from one client to the other. Then there is RTC Data Channel API of WebRTC itself. So it's not actually self-sufficient because you still need to get the connection going. But it's sort of its lower latency than WebSocket. So you can just do the first connection via WebSocket and then switch to RTC Data Channel. And the signaling will be much faster and much more secure. So it's what it looks like. And the client sends the data signaling data to the server. And then the server sends it back to the other client. And then it just happens. So let's see the code. I actually implemented it in TANADO. So I have these rooms that are like channels. And they have clients connected to it. And the track which clients are connected to each room. And then this room handler just serving a static page. And this main handler just redirecting people to a certain room. This is where the signaling actually happens. It's just WebSocket handler that when it receives a message, it just broadcasts it to other clients in the room. And that's it. That's all you need to implement the signaling system. So the code is actually, and the full code is actually in GitHub. I have the link to us. And then I just state the server. And it's all done. And then in the client side, I have this init function that gets the video and audio data and all that. And it has all the pure connection stuff that we talked about. And it's really just that simple. But there's a catch. The thing is this is kind of, it was really small in scale. When you actually build bigger stuff with sort of like a clustered environment, it doesn't work if you just have a sort of a global dict of rooms with all the clients connected and all that. You sort of need something better, a better messaging system. And I think it can be implemented easily by using something like zero MQ. Actually, the people at Talkbox, Talkbox is this platform that provides you web RTC infrastructure to build your apps on. They actually build this messaging system. And their entire web RTC signaling system with zero MQ, it's called Reumer, I think. I don't know if it's open source or not. And so you can always do that aside the web socket infrastructure. So the code is on GitHub. Sorry, I should have actually put the link there. Sorry. It's the link, but I don't know. The text should have no shit. The text should have said the link, actually. Maybe tell your GitHub user's name. It's right there. Sunoo on GitHub. And that's the end of our session. Great. Thank you. Any questions? I think you have time for a few questions, yes. OK. No questions? Thank you again. Actually, I have a demo. One question. I played a bit with web RTC, and there are quite some services on the internet where you can test video and audio conferencing with a small group of people. But what was rather open the problem that with two people, it works quite OK. If you try it with four people, it's somehow stuttering and having issues. And people get lost somehow or don't get in. Is there some trick to tune it a bit somehow? It depends on the bandwidth, because with four or five people communicating with each other at once, you send each stream separately to each client. So the trick would be to set up something on the server and then use web RTC infrastructure on the server and then send the stream to the server only and then send that to each client. So you have to upload your video stream only to one client instead of all the five separately. Any more questions? Dougal, I think you can set up now. Well, thank you for that. Oh, one more. It's not traversal in any way addressed in web RTC. Yeah, there are some protocols called stern. And stern actually lets the clients know the public ID of the client. So first, you need to try stern. But if it's still the business work, then you can try stern. That actually sends the data through a turn server to the client to address the matter. Thanks. Thank you. I know Tarashees was worried. This was his first time speaking at EuroPython. Very well done and very interesting.