 Thanks, Sayi. As Sayi mentioned in his chat heart, about three years ago, I started up a blog largely to help me make some notes and meet some of the other technical people inside WebRTC called WebRTC Hacks, and that's really got me much, much more into the industry. Today I'm going to talk about servers for WebRTC. So, Herman touched on that. Part of that in the previous presentation, there was a lot of questions here that were very server specific. I hope I'll answer some of them, probably not all of them, but certainly some. So, as Herman started out, usually when you see WebRTC you hear about, it's all, it's peer to peer, right, and you can send VoIP peer to peer, and there's a lot of focus on the browser and the browser and a browser and a mobile app, and then you usually see some sort of diagram like this that shows just the signaling stuff down there. And I always, like, starting out, I was always very, you know, kind of scared of, like, what's going on here? I, you know, I knew how to program, I was, you know, in the browser and do JavaScript, but, you know, the server-sized stuff was hard. So, I can say the server-sized stuff, it doesn't have to be that hard. It can be in some situations, but definitely getting going, it shouldn't scare you off. And I'm going to walk through some of those aspects during this talk here. So, if you go into more detail, and this is actually from the W3C WebRTC spec, there's actually a lot of elements here. It's not just two little browsers, right? And a bunch of these are the actual servers here, right? And I'm going to explain what these things are. There's four main types of servers in WebRTC, right? There's signaling, which basically you always need. There's NAT traversal, and I'll spend some time on this. This is really important, especially for production environments. You mean, realistically, you probably should have this in your application development environment, but there's different levels you can do. Media servers and gateways, they're really application-dependent, depending on what you want to do. And we'll discuss some of those applications in a moment. So, let's start out right away from signaling. And I think, as you've discovered now, WebRTC is not just peer-to-peer. You need to have this signaling server, right? WebRTC is peer-to-peer for media, right? But WebRTC is not peer-to-peer for signaling. And why do you need signaling? We just talked a moment about this thing called Session Description Protocol. I can say I spent many, many hours with help from experts trying to build an STP guide here. It is a very, very complex thing. But it's important because you need STP basically defines the capabilities and permissions of what one browser can handle, and it needs to share that and negotiate that information with the other browser, right? So all that information is encapsulated inside STP, right? And while it's possible to manipulate STP, and there's a lot of actually use cases where you might want to do that today, most of those are more advanced use cases. And certainly, if you're just starting out, you really don't need to worry about STP and the contents of STP. What you do need to worry about though is how do you get STP from one browser to another browser, or from one of your clients to another client. And that's what signaling is all about. It's about transferring that STP from one browser to the other browser, right? So one of my favorite ways to illustrate this is actually using one of the official GitHub, one of the official Google sources on GitHub. Here, I'll just load up my browser, right? And I like this because it walks through the process that you saw Hermann present just previously, right? Step by step. So we start by getting the media, right? That's our get user media, see our screen here, right? We create a peer connection, right? And this next step is really where the signaling part comes in, right? We're going to create an offer, right? And you can actually see that actual offer down here. Again, this is just for illustrator purposes. If you're doing more advanced situations, you can actually go in and edit this and change this. If you want to prioritize certain codecs or capabilities or remove certain types of network connections, you can do all that. There's other ways to do it too, but that's available to you, right? So then we're going to set our offer, right? Then we're going to go to the other side. We're going to create an answer, right? We're going to set our answer, right? And now we're connected, right? So it seems like there's a lot to the process when you see it at first, but really, if you just go through some of these samples, you can see there's, in reality, there's not as much going on as you might think, right? There's a lot of things that go on that are automated and taken care of for you as part of the APIs. So the next step is, okay, you need to send this SDP from one browser to another browser. How do you do that, right? You need to have some sort of server, right? You need to have something that transfers that. And the reality is, like, the server could really almost be everything, right? There's actually a spec written that says that's sending WebRTC via avian carrier, right? Which means a bird, right? A pigeon, a passenger pigeon, right? Because in theory, it doesn't actually work with most browsers, but you could actually send this SDP, you know, stick it on a carrier pigeon, send them off, and then take that SDP and interpret it. People like FIPO have gone so far as to, you know, reduce that SDP down so you can send it with a tweet or close to it, right? But to create, you know, a signaling server, it does not have to be very complex. You just need something that will pass that SDP from one side to the other side. Last week, we had a great session in San Francisco focused on mobile, but it actually has just a kind of, you know, an introduction in one of the slides from one of our sponsors, Talkbox there. Cesar Garano put together just a really simple 32-line signaling server here, right? And as you can see on the screen, this is actually all you need for a lot of applications here. And all this is doing is just taking, you can see a message from one client, takes it and broadcasts it and sends it out to all the other clients, right? So not the glance over signaling, it can get pretty complex, but actually most of the issues with signaling don't really have to do with WebRTC. Most of the other issues are general elements that you need to deal with with your application in the first place, right? So you need to find, you know, who can actually create a session, right? Who's allowed to use the system, right? And that's, you get a user authentication, right? To what level, what degrees were they allowed to do, you know, what controls they have. There's, you know, security and access controls, right? If you're dealing with mobile environments and you don't want to kill your battery and you don't want your signaling to be too chatty and keeping your phone on, you know, keeping the network awake the whole time, you need to think about things like push notification services. One aspect that I will say can get very difficult, especially as you get into large-scale production dealing with millions, tens of millions, hundreds of millions, is scale. Daniel Pearson later on today has a really great presentation that I'll talk through a lot of the aspects of scaling out of service, right? So he'll spend a lot more time on that topic. And in general, there's a lot of other things that your application is doing that you need to consider. And if you have a more robust advanced application, odds are you already have some sort of signaling mechanism of some aspects there. So the real, then the challenge comes into how do you map some of those existing application capabilities into what you need and what you want to do with WebRTC. And so how do you get or use a signaling server? One approach to getting started with WebRTC is actually just go to, you know, communications platform as a service provider. Like we have some, you know, our sponsors Twilio and Talkbox are two examples of those. Since signaling is basically a mandatory part of WebRTC, every CPAS provider has some sort of signaling built in to their framework, right? But if you don't want to do that, as I showed, it can be actually really simple to run your own, right? And there's several, you know, frameworks out there. Some of them I've listed here that can help you get going really quickly or help give you some basic signaling. At the end of the day, if you search on GitHub, you'll find dozens or hundreds of potential signaling options in different ways to do this. Beyond that, there's a lot of other, you know, more generally more specific signaling and messaging type services that are designed specifically for sending messages between elements, right, or mediating those sorts of things. And you can see some of those here, like Firebase, PubNub, you know, even Google Cloud Messenger, which Daniel will talk about a little bit later. All right, so that's signaling. The next segment here we're going to go into is NAT traversal firewalls, right? And these are devices that are part of the network. And one of the challenges with WebRTC versus, say, existing, you know, telecom systems is when there's no connection, you can't just go tell your user, oh, I'm sorry, you have to go change your network, right? No one's going to go and tweak their firewall, their router, just so they can make a call with you, right? So a lot of the work that's been put into WebRTC and the standards are about getting around that sort of process. So you as a user and your users, you know, at home or at work, can just have a very quick, simple call with WebRTC without having to worry about the network or making any changes, right? So to start out, I'd like to talk about the NAT problem, right? And NAT stands for network address translation, right? And in traditional web systems, you have a web server here, right? And they're really set up for you, you know, your users at home or at work for talking to those web servers, right? And this system works pretty well, you know, systems are to do this. All the, you know, the network configuration for doing this is pretty well established, right? If there's something out on the World Wide Web, generally, you're allowed to go get it as long as it's over HTTP and, you know, follow as usual parameters. WebRTC breaks this, right? Because now we're talking about doing peer-to-peer media, right? We're not just going from a server, from your client to the server. We're actually going from client to client, right? And we're just sending things direct, right? It's peer-to-peer. And that's really where a lot of the issues start to come into play, right? So most networks are behind these NAT devices, right? And NAT devices exist for a lot of reasons, but, you know, fundamentally, before IPv6, there wasn't enough address space out there. And for management purposes, your ISP or your IT manager generally put in some sort of NAT device. And you had a local address, right? And so a couple of examples of local addresses here, right? And these addresses are used, you know, within the local LAN, the local environment behind the NAT. And what's exposed externally is a different address, right? And the problem with WebRTC is I need to have this client talk to that client. So how do I know it's a dress, right? The only way, the way these clients look to the outside world, it actually shows the external IP address, right? But to really reach this client, I need to know how to get through that external one and also find the local internal address, right? And be able to differentiate that between, you know, one of thousands, hundreds, thousands, tens of thousands of potential clients within that local area network. And so that's problem number one. Problem number two is there's different types of traffic, right? There's TCP, and there's UDP, which is more beneficial for VoIP, because TCP has reliable connections that will retransmit. But in most cases, for VoIP, there's no time for that retransmission, right? If that packet or that message doesn't get through, it's too late. You're better off just throwing it away and not bogging down the network, right? And TCP and UDP, they follow certain port ranges, particularly UDP. And a common practice for security reasons for firewall is basically just to block anything that doesn't look like it should be there, or that you don't want to have access. So to prevent external hackers from penetrating your network or finding some service and exploiting it, right? So firewalls very typically block certain ports, or they block UDP altogether. And so just to recap, some of the problems and some of the addressing scheme that you should keep in mind with using WebRHC, there's three main aspects to addresses that you need to remember. One is the IP address, right? And I showed all IPv4 addresses, but this could also be IPv6, right? There's ports that you need to deal with. There's common ports like 80 and 443, but then there's a whole big range of UDP ports out there. And then there's the protocol that we talked about, UDP or TCP. And one of the great things that's built into WebRHC, and that's been standardized, to help get around some of these firewall and NAT problems is called Interactive Connectivity Establishment, or ICE, right? And as you see here, basically ICE is a protocol for allowing a client behind a NAT or firewall device to talk to another one that may or may not also be behind a NAT or firewall device. And there's two types of servers that handle ICE transactions. And I'll go through it in more detail what these things are, right? But the first is a stun server, right? Sessions for versatile utilities for NAT. They're pretty archaic names, right? But the second one is a turn server. And I'll show what these are. So the first one is the sun server, right? And we talked about the problem here. I need to know as a user what is my, you know, basically what does my external address look like so I can include that addressing information externally, right? And the easiest way to do that, just like you can usually, you know, on, you know, some web pages, websites offer this is, let's just go out to a server and ask it, what is my IP address, right? So it goes out, stun server basically is you do a request and ask, what is my IP address? And it returns, not the internal one, it turns the external address that it sees here, right? The second type here is a essentially acts like a relay server, right? And this is turn. So when you can't make a connection via stun for whatever reason, turn servers generally have a well-known public IP address, right? That both clients can reach just like your web server. And the media ends up being relayed through that media server or through that turn server, right? So comparing these two items, important things to remember, your one is stun, one is relay, right? When it comes to cost, right, stun is very scalable because it doesn't have to do much, right? You're just basically asking for an IP address, it sends back that information. Turn, on the other hand, is very much more intensive, right? Because it's relaying all your media, right? And someone has to pay for that bandwidth and that server at the end of the day, right? So turn ends up being a lot more expensive. Another challenge with turn, if you don't architect your network right or have enough, you can actually introduce delays and latencies which can hurt quality, right? So how often are these different types of relays and turn servers needed here? So generally, stun is almost always needed. I asked for a run, he'll be giving a calculator on to maybe pull some stats from his call stats IO database to see, you know, what's the latest on, you know, number of users that need to have a relay to be able to use a turn server. It's around 24%, right? And Talkbox, another sponsor that's here with us today, this date is a few months old now, but for them, you can see it ranges quite a bit from day to day or from month to month, but on average, it's somewhere around, you know, 10% or so of turn server, of all WebRTC calls require this turn server. So you can see, you know, even though a turn is expensive, if you're running a production network, is it okay for 10% of your users not to be able to connect or make a call? In most cases, I'm guessing it's no. So this is why it's really important to include a turn server, right? And using these turn servers is actually, is relatively simple, actually, making use of a turn server. And I'll show you quickly how to do this here. So the first thing you want to do with a turn server is actually just get a nice server's object, right? Go here, a load of my terminal. Briefly, let me just clear, right? And you'll see here in this case, I'm going to use a turn server for one of our sponsors, Twilio. This is a very simple REST API call. Most of the vendors, people who offer turn servers have, you know, libraries you can iterate in to make this. And so I'm just going to do this very simple REST API call to the turn server, essentially asking it for an ice server's object, right? And I'll walk through what that looks like in a moment. And then I'm just going to pipe this to a simple Python command just to format it and make it look nice. Right? So you can see here what this returns is a list of different ice servers, right? And I'll walk through, I'll show it a moment. Let me walk through here what some of these things are. And you can see the first one is a stun server, right? You can see this other one here is a turn server. And there's a few different varieties. You can see they use different protocols here, TCP and UDP, right? And ideally, your turn server is going to give you a bunch of different options for connecting, right? So in case you come across some firewall that for whatever reason blocks, you know, TCP or blocks certain ports on TCP or blocks UDP, you have many different options for getting through and connecting, right? And as you can see here, just the recap, same thing, shows the different objects. I think I touched on most of this. The key thing with turn servers, I'd say almost 100% of the time, they're going to have some sort of username and password, right? Because it's using some sort of network asset and you don't want someone else just hijacking and relaying media through your server and running up your bandwidth bill, right? So there's always some sort of credentials. And generally, there's a time to live element with all the turn servers too, right? And this lets you know how long those credentials or those actually turn servers are valid for, right? So I showed a couple different types of ICE candidates and protocols, right? So, you know, the turn server you go out and you ask it for different options. So some of the options we've talked about a little bit, UDP, again, this is really what's best for VoIP. This provides the lowest latency and overall the best performance, right? But sometimes it's blocked. You know, the next alternative is TCP, right? And if TCP doesn't work for some reason, if there's some, you know, packet inspection going on that might be blocking it, the last option is actually doing TLS over TCP encrypting the traffic. Now, TLS over TCP in some ways is not great because you're actually encrypting the traffic twice. You know, WebRTC's traffic by default is encrypted and you're encrypting it again. It's not really providing any security benefit on top of it. You're just doing this to hopefully allow, you know, so that the firewall permits the traffic to go through, right? And you'll see turns S candidates, right, for this. As you see in this example I have here the last one is turn S, right? That lets you know it's TLS over TCP, right? And if we look, you know, different types of, you know, turn, what kind of turns types, most of them in general allow, you know, turn over TCP, you know, followed by, you know, I'm sorry, most allow turn over UDP. That's the biggest chunk, this blue one here. Again, thank you, Varun, for sharing some of this recent data, right? Turn TCP is a smaller. And generally, you know, the, you know, the turn TLS element is the smallest portion that's required or used in that work. And most turn servers actually, as I showed in the two examples before, they're going to try all these, right? And hopefully your connection will be made in priority of what provides the best performance or the best capabilities, right? So just to recap some other terminology you saw there, there's a couple of different ICE candidate types, right? A host candidate is when you can use a local address. So probably what happened when we tried doing the jitsi meet call that Hermann used to open the session. Most of us, since we're all in the same network, were probably able to use a local address and connect that way, right? That's known as a, as a host candidate. You might hear another term called your reflexive or server reflexive candidate, right? That's an address that's returned from a stun server, right? It's reflexive, basically get reflected back, unless you know what your address is. And the last one is relay, right? A relay candidate. And that's coming from a turn server, right? And we can actually some other great tools on webrosee.github.io. There's a lot of tools you can use to test your ICE connection, right? This is really helpful when you're trying to diagnose or make sure your turn server is working, right? It's really good to be able to go and use some third-party code to do this. You see here, I've already pre-populated from the, from the ICE servers object, you know, the servers I had here. But essentially, you know, all you do is you put in the address that gives you, you put in the username and the password, right? You'll see typically stun servers oftentimes don't require a username or password because people aren't as concerned about using those. You can add additional if you want. And you basically go and you gather candidates. And you can see here, this will vary. You can try this on your mobile phone. You can get a different set of candidates than you would, you know, here in office at Google, I got a completely different set of candidates inside my hotel room. You can filter this if you want to just look at relay candidates. I'll just look at all of them here quickly, right? And you see a bunch of different options, including UDP, UDP over IPv6, UDP over IPv4, right? So this shows you all the different, basically, ways or methods that are being tried to connect your one peer to another peer, right? Again, this all happens as part of the ICE process behind the scenes. So in most cases, you don't need to worry about this unless you're doing some more advanced, you know, troubleshooting and diagnostics. The key is really to emphasize that this is all stuff that is happening as part of the ICE process. And you're going to get these relay candidates and reflexive candidates when you use a stun and a turn server, right? Included a couple other links here. We'll show later on another great tool from the official Google WebRTC source, you know, testweberc.org, you know, there's some capabilities to test there. I just showed you the, you know, some of the other trickle ICE testing, a sample there too. So when you go from, you want to actually use or deploy your own turn server, or when you're considering using a turn service, there are a couple things that keep in mind. Just probably one of the highest level, the simplest ones to start out with is you really want to have some level of redundancy and ideally geographic distribution, right? Because especially if you have users that are distributed throughout the world, right, the turn server relays media, right? So you want to consider the latency that happens between the user and that turn server and turn server on the other side. If the turn server I'm trying to call, you know, from here in Brazil, and my turn server is up in my home in Boston, and for someone else down here in Brazil, right, that's going to be a really long loop and delay. It's not going to lead to very good voice quality. It's much better if my audience is in Brazil to have a turn server that's in Brazil, or one that has a very low latency or close connection. And so just to conclude on the turn server section here, you know, what are some of the ways to get a turn server? Well, most of the CPAS providers include some sort of turn option. Again, this is something that everyone should have in production. If you want to run your own, there are several options out there. My personal favorite is the co-turn server, which is widely used, but there are others as well. And there are several dedicated turn services, right, where perhaps you don't want to use a larger kind of communications platform as a service, you know, API set. You just care about having access to that turn server and doing some of the things I showed you earlier where you just basically go and get the ice servers and add that ice servers object into your peer connection. There's a bunch of services that allow you just to do that, right? And they generally charge you, you know, based on bandwidth, for the amount of bandwidth you use. All right, so next I'd like to talk about media servers, right? And there's a few reasons why you might need a media server. Hermann talked earlier about doing multi-party calls, right? This is where you have multiple users calling in the same line, similar to what we showed early on with, you know, the GSC video meet. Recording is another of actually very common popular applications for making advantage of media servers. Anytime you want to do any sort of media manipulation, this is another aspect, right? Perhaps you want to do some image processing on the stream that's, you know, too processor intensive to do locally or you want to take advantage of some cloud algorithms to do that, right? So media manipulation is another one. And live broadcasting is another emerging application for using media servers. First, I'd like to start and talk about the multi-party scenario, right? And WebRTC is a, you know, peer-to-peer technology when it comes to media, right? So the simplest approach to start out with doing a multi-party call is to just connect up multiple peers and add them all together. And this is a perfectly valid, you know, technical possible, technically possible thing you can do. But you'll see, you know, doing, you know, adding a third party is not really that big a deal, right? You don't have that many different streams to deal with, right? But as you start adding more and more parties, you can see that there's this exponential effect in terms of the number of streams that each client needs to deal with, and also for your overall network, the number of amount of bandwidth that's required to send all this information around. And the challenge here is, especially if you're dealing with mobile devices or anything on a battery, the more streams you have, the more decoding it requires, it's going to chew up your battery and probably not lead to a great experience. So the traditional way of solving this product, this problem is through an approach called an MCU, a multi-point control unit, right? And this essentially just takes all the streams and you send your stream to a centralized media server, that centralized media server mixes it together and sends it back out to all the clients, right? And this is actually pretty, from a client perspective, this is a pretty simple approach, right? You don't have to deal with connections and connectivity to potentially dozens or however it may be of other clients. You're only dealing with connection to one other element, right? And dealing with that connection, right? And that other element takes care of everything for you. Now, the downsides of this is this approach is actually very processor intensive on the server side, right? So this requires a lot of capacity. And as I'll show here in a moment, part of the challenge with the MCU is it doesn't actually give you a whole lot of layout options because the MCU is taking in all those streams, you know, mixing them together into a single stream and sending that back. And generally, when that mixing happens, it's down sampling or downsizing the image. It's, you know, resizing things. So the people on the other end aren't getting the same images that are being sent out. And, you know, as using these services, generally, you need to define or decide exactly how do you want to have that screen be laid out. Oftentimes, to save on processing capacity, the MCU will actually include a view of yourself, right? Which is, you know, might be a little bit weird to see yourself with a little bit of delay there in an unmeared fashion. So some of the downsides of the MCU beyond just general cost, right? Because they're very CPU intensive, tend to be that they're limited in layout options and they don't give the client really any ability to control or limited abilities to control what the layout would look like. So another approach emerged called a selective forwarding unit in SFU. And this essentially acts like a video, you know, a media stream router. And I should add in here, the primary use cases for all these tend to be video. But there's no reason audio wouldn't work with any of these scenarios. The advantage of audio is generally a lot less bandwidth. So you can actually get away with the SFU or with the peer-to-peer approach a lot more. But, you know, as I illustrate in the slide, it doesn't make the problem go away. It just lets you add more clients than you could potentially otherwise. Right? So transitioning back to, you know, the SFU, this is a much more flexible approach, all right, where instead of relying on the central media server to do all this processing and mix things, the client basically sends up one stream. And in a very lightweight process, the SFU sends back this basically copies that stream and sends it back to everyone else. And this is much more lightweight because the SFU only needs to do decryption to pass it along. Right? And this ends up being, in a lot of cases, a lot more scalable, a lot more cost-effective. You're basically passing on some of the cost burden of the media server, you know, from the media server to the clients, which lowers your price and helps increase scale. But as you can see, some of the downside here is this can end up using a lot of bandwidth, you know, both in your network and potentially on the receive side in your clients. So a newer, more advanced method for dealing with that bandwidth issue is known as simulcast, right? And unlike before where basically the SFU was, you know, just passing along generally a high bit rate stream or single type of stream, simulcast is basically each client, you know, simultaneously sends more than one media stream. Generally one is a high bit rate HD type stream. And generally the other one is a lower bit rate type thumbnail, right? And so both of these streams get sent to the SFU, right? And the SFUs generally have enough logic and intelligence to say, you know, not everyone out there needs to see, you know, 10 or in this case, five different HD video streams at a time. Usually the way these calls are set up is you have one active talker that gets the most real estate, whoever's presenting or speaking, and everyone else gets a smaller thumbnail, right? And this allows you to scale up a lot higher because now instead of sending back all those HD video streams, you know, down to every client, you're just sending, you know, a series, a few smaller thumbnail, you know, low bit rate video streams, right? And as a client, in this case I'm showing an example from the Jitsi video bridge that we showed earlier, but Google Hangouts works the same way. As a client you have the ability to select, actually I want to look at this person or this screen, right? And the SFU can then has the logic to send each individual client whatever streams they request, right? So there's a lot more flexibility, a lot more control, and ultimately this ends up to much better user interfaces and user experiences on the application side, right? So this is really the state of the art of, you know, media servers where people are going today. Now, there are additional and more advanced techniques coming. I don't have time to cover that today, but in general, in most applications you can do pretty well with an SFU or a simulcast application today. So, you know, how do you get, you know, how do you use a media server? Well, many of the CPAS providers, you know, generally have something or they're adding something here so you can always go there. There are a number of open source products out there that you can go and take advantage of. Their capabilities and use cases vary quite a bit. You know, some of these are SFUs, some of these are MCUs, some of them let you do either one, and there are, you know, use cases where you want to do an MCU or might, you know, where, or others where an MCU doesn't make sense and you just need the SFU, right? And then there is an industry of commercial vendors who sell software-based systems or hardware-based systems that do media servers, too, right? So, again, this is for applications that require larger-scale multi-party video, right? There are a number of tricks and hacks you can do that try to increase the number of users you can get inside a multi-party situation without using a media server, but generally there's always some limits or some other limitations that, if you go big enough, you want to have a media server. All right. The last topic I won't spend a lot of time on, but I did want to introduce is gateways, and this was talked about in some of the Q&A previously, right? Gateways are for when you're not just talking browser to browser, right? Sandra Webber sees good for that. But what if you want to go and make a call from a browser to the telephone network, right? To somebody's mobile phone, you know, through the native dialer app or to someone at home, right? There are gateway products, right? The core part of gateways basically need to do two things, right? There's some signaling aspect, and there's some media aspect, right? The media aspect at least is a little more standardized, right? Because it's standardized by WebRTC. So you need to convert that media from SRTP, DTLS inside WebRTC to something else. And generally that's just plain RTP without encryption, but it might be. And oftentimes there's a codec conversion, or there might be a conversion of codecs from the opus codec, which is most commonly used to more, you know, in this case, a telecom-oriented codec. The signaling side can be a little more complex, right? Because WebRTC doesn't define exactly how you need to do the signaling. It just tells you you need to figure out a way to pass STP from one side to another through that offer answer mechanism, right? You need a way then to convert whatever signaling mechanism you have to the standardized signaling mechanisms that are out there in the existing telecom telephony world with protocols like SIP, right? So just to conclude here, right? You can't completely ignore servers, right? In a lot of cases you don't need to have all these servers, right? But at a minimum you have to have a signaling server, right? And you really should probably have a STUN intern server. Oftentimes, STUN intern, they're the same in one server. If you don't want to actually pay for a STUN server, a lot of people use the Google one, which they leave open and allow you to use, right? So just to conclude with some considerations on the signaling side, if you can leverage the existing application infrastructure and the existing signaling mechanisms that you have already in your application, that will make things a lot easier, right? If that's not possible or if you don't have that or it's not practical, at least getting started, signaling can be, you know, pretty easy and you don't actually need to have a lot of code or you can take advantage of open source or other, you know, commercial products out there. Natural versus side, again, just reinforce probably the biggest problem that comes into play with people that are new to WebRTC when they start to deploy it is some portion of their calls don't work because they never deploy to turn server, right? You have to deploy this. Media servers, important for multi-party recording, you know, very specific situations. These come into play, you know, it only matters if your application needs one of these things, right? If your application doesn't, then you don't necessarily need to worry about media servers. If you are dealing with multi-party video, the state of the art is, you know, is an SFU with Somicast. And lastly, if you do want to connect to some other network, most typically, it's just, you know, a SIP network that's out there in existing corporate environments, you're going to need to have a gateway to do that. And there's a number of products and techniques. That, we can take some questions.