 All right, so allow me to give Giovanni here the first one from the Italian Void map, yeah? And the first one to fall back to a map when he's ending because Linux always works, right? Always. I'll try to be very, very fast and to leave some space for some question and answer because we'll cover a lot of ground here because real-time communication is getting complex and complex. We have multiple protocol, multiple transport and so if you want to build something that is really scalable in this real world where you have so many paths and so many different clients, you really need to put some total need, some real engineering and trade also some real-world experience to check out what works and what not. High availability as the first things, the most important part in high availability is you really need to have it all double, at least double. So before thinking of complex things like software or things like that, you first have to have double power supply, double different circuit for your power and double switches. For example, you can put so much total into having your double networks and things like that and then your switch burns and doesn't work anything. So as a first thing you double it all, then you come out with the simplest high availability architecture that is an active passive. So you will end up with one machine that is staying idle on the side of an active machine and that works very, very well and this may be the most important architecture for critical systems. So you actually have a spare machine that is just on the side doing nothing but it doesn't scale, it doesn't scale at all. So you can use this architecture just to protect something that is a critical service but is absolutely nothing that you can scale and that you can absorb millions and millions of user packets or whatever you want. So you need something that is high available and scalable and so in this architecture this doesn't scale at all because you have one that is completely idle and you have only one to absorb all your clients. Then you start thinking at load balancing. So you end up having many machines and something in the front that just distributes the calls, distributes the pockets on all those machines and obviously you try to combine the two architecture. So you have high availability here on the front end. So you have two distributes or two point of entrants where one is active and one is passive. So those two are machines that are able to sustain the entirety of your traffic but that doesn't need to be enormous machine because they just switches around and route pockets. And then you have on the back your farm with all the machines that you need to offer service to unlimited number of users. I mean as users grow so you just keep adding machines and then you have the back end your database fundamentally that is also in high availability. So it's in also in that case it is a duplicated or it can be a cluster. So both with MySQL and with Postgres you can have a cluster architectures that scales very well. You have a difference between how you can scale with different protocols because for example the protocols that is in this moment the most scalable is definitely SIP because SIP has let's say at least 20 years of experience in being hyper scalable and fundamentally running the whole telecommunication world in whole of the world. And so you really can do scaling with SIP and we will see that it's kind of different when you approach that through WebRTC and virtual that is protocol that is specific of free switch in this moment. And another need that you need to take care about is NAT because as you know all of our clients will be behind NAT on that home, on that office behind routers that apply NAT. And we had before all the presentation that was all about not having no more NATs but I mean for some year we still have to do to deal with NAT. And also in this case we will use the front end to manage the NAT particularly we will use SIP proxies that Tatar or Daniel Camilo or leave you open SIPS or there are also other software that can do SIP proxies. And then we have the how to put where to put the SIP register. The registration is a high frequency transaction that is doing a lot of packets moving back and forth and when you have millions of customer or clients you then have to really think where you put the register. You can put it on the back end or you can put it on the front end. Definitely it's better to put it on the front end because as this morning Matt was making clear in the scaling as to his presentation that SIP proxy is designed to deal with so many transactions. Then the same proxy will do dispatcher and load balancer and we arrive at this kind of initial architect where we have the media that is flowing through a media proxy and this media proxy that is managed by the SIP proxy. We'll take care about the NAT part of the media because it's the media the problem normally you always are able to establish a session between your server and your end user but maybe this session will have no audio or audio in only one direction. Those are the typical NAT problems that with this kind of architecture having the proxy managing through a media proxy the media path will we will solve. And this is the typical algorithm that you use to distribute registrations and call to back end made by multiple machines. Then we will see that with virtual protocol that is an alternative more geared through web developer to javascript developer etc. To integrate real time communication into web services with virtual we don't take this problem about the NAT and media path because the virtual and user directly I see for distributing media. And it's much more simple to use when you are dealing with when you are dealing with web pages and web developer. So the problem in this case is that virtual being a younger protocol has not yet all the infrastructure like registrars and proxies to keep him growing. So we we use IP tables to distribute on the back end and to choose a basis of an algorithm where to route the single call. And in this case we arrive at having the same kind of architecture that is bought for both for CIP and for virtual. One important role is made by the keep alive the software that is the software that manage the high availability between two machines. So from one side that you distribute using the proxy or IP tables and from the other side you use the RRP with keep alive to have one only machine active on each moment. And so you have the active passive architecture and then you have on the back all the farm and this farm need to access some shared file system. And in this case what is the most easy to use this cluster FS when you can have just a small cluster of machine that exports a break. And the important thing is keep your mind that don't use shared file systems for something that is very fast moving or for very small transactions. That is a no go. But for all media files configuration files etc. Shared file system are okay. The same thing is important to have some form of indirection when you access your database. So each machine need to have its own proxy for the database so you don't clog your database with hundreds of connections. And this is about load balancing into scaling. But we have a lot of special cases as also that was talking this morning that you need not to blindly distribute your incoming call. But you need a call to land on a specific machine because it needs to be joined at the audio level with some other call. And in this case the answer is you need to partition. Partition means you distribute the calls not in base of the load but in base of some more intelligence in practice of what domain that call belongs to. So this is in a distributed architecture when you need to use specific services. For example a conference services for one big domain. So you just destinate one specific machine or more than one machine to this service. But you have another situation that is also very common and that has its own specific need that is multi tenancy. So you may have just the opposite. Not one big domain with millions of users but many thousands of domains each one with maybe 100 users. So what you do in this case is that you distribute and hash on the domain. So each call that pertains to a domain goes to a specific machine. And in that case you have another set of keep alive where you have let's say one spare machine for each four machine. And that machine is ready to take the place of the machine that failed. And this is the last slide. So I was able to stay in the time. So those are books just. Questions. Yeah, couple of. And probably there will be another one for August. And so if there is no questions, I invite you all to come in Chicago for crew con. And that it will be like the queen, the spiritual continuation of this conference. Questions. Maybe I've not understood the question. Yeah, that will be a fully functional server. That I mean, you keep a virtual IP addresses on those on those machines. So if one of those machines goes down, this one will take its its address and just will work as it was that machine. And that's it. You just restart the services and give it the new IP address. Yeah, skip a lot. And obviously, if you have 100 production machines, you may be better to keep like five spare or things like that. In case we need the spare, do we keep the current calls up or those calls will go? That's definitely depend. Almost all WebRTC calls will be able to just continue yet. For the voice call or let's say for the SIP call, it depends. Friswitch has a mechanism to migrate that I will not put so much into that. First, because I mean, you're supposed not to have a machine that continues failing. Second, I mean, we are always used that that call can go down and you just call back. And it's not, I mean, someone that is on surgery or something. I mean, it's not live at risk. So it's doable. We demonstrated it. I'm not sure that it works, that it is worth for the investment and the attention that it keeps. Definitely, I will do that for a 9-11 or some emergency call or for, I mean, where it works, but not for a normal service. Second, do you need RTP proxy? We couldn't resolve everything on Friswitch without RTP proxy, right? RTP proxy is good to have because in this way you don't expose your farm on the public internet. You have all behind. And so this is from one thing is security. From another thing, many times you are required by law to have a single point where you can do access to it, et cetera. Also, there is a lot of reasons, both operative of business and law for law, that you better keep like that. Okay, thank you.