 There was this small French young guy sitting in a booth in another building talking about some open source software called the SIP communicator. Now it's not that small anymore, Emilie Bob started with SIP communicator that grew into Jitsi and headed off into Vidio, created a real cool Vidio server I think you're going to speak about. Our friend Sal, joined Emilie and has a new t-shirt. Tell us, what's the state of Jitsi? Thanks, Owen. Well, hi everyone. Just before we start a quick show, hands, who knows what Jitsi is or stands for? Wow, okay. Well, then I can skip real quick for the few of you who don't know. It's a collection of software, of open source software that allows us to have scalable and secure multi-party video conferences. So the hallmark of this collection of projects is called Jitsi Meet. And this is how it looks like. This is our weekly, our daily stand up, sorry, where we all, everyone in the team connects and shares what the hell we're doing. So as you can imagine, connecting like 12 video streams all together has a certain degree of difficulty. And the idea is that we take care of that for you so you don't have to worry about it. And today I'm going to let you know how we achieved this and we're going to see how you can also do it for yourself without having to do everything from scratch. One important thing that happened is my t-shirt, which is Jitsi joined Atlassian roughly two years ago in 2015. And it got integrated into some of their proprietary products, our proprietary products now. So one of which, for example, is HipChat, which is a proprietary group chat application, but the video part is done via the same way we do our video conferencing, so via Jitsi Meet. We also have a company-wide all-hands meeting where all the offices connect together, the founders give some updates, some presentations are shared, so on and so forth. So this integration of Jitsi into Atlassian actually empowered us to basically go a little bit further, scale up better and basically build these things that maybe before we either didn't have the idea to do or necessarily all the tools. Now we have these resources, these needs, and we can do that. And we can do that actually while being a fully open source project, which is a nice thing to keep. Everything is available as open source in the Jitsi.org website. We host a bi-weekly community conference call where we share like what's the plan, what we're working on, and actually I'm here today to basically tell you a little bit more about this, but actually it doesn't stop there. So there are other companies, both for-profit and not for-profit, that are using our tools to build the products. One such company is Hi5. They sell these hardware and software-based video conferencing solution and they use one of our pieces of software at a Jitsi video bridge. The video bridge is the entity responsible for routing the video to all participants and being the smart guy in the room which knows what kind of video has to be routed to what person depending on its bandwidth needs and so on. Another sort of instance of this is Meet Jitsi is our publicly available instance. So this one you can use to host your meetings, share your desktop. It's fully functional. You can use it. It's hosted by us. And more than that it has an external API which can be used to embed Meet Jitsi into your own applications without necessarily needing to host the instance yourself if you don't want to do that. One such case is Rocket Chat which is an open source group chat application which added video support by embedding Jitsi Meet. So we have this high-level API, we call the iFrame API, which allows you to customize how you want to actually see this multi-party video conferencing, you know, the view, the experience. You can change things around maybe the kind of application you have in mind. Doesn't necessarily need a large view here and you want to go with just the thumbnails or the film strip as we call it. So you can customize this when you use this embedding API to make your application be, you know, multi-party video conferencing enabled. So what is sort of everything that this thing does? Which you may be aware of some of the things and not some others. So we can of course do video, but that video can be your desktop. So we can do desktop sharing. Your conferences can be recorded or streamed to YouTube. For instance, this is how we do the company-wide all-hands. We stream it to YouTube. So that way you can imagine that maybe in a different scenario you're like, okay, I need a million people to join the room. Well, that might be a bit hard on your Chrome instance. So how about you stream it to YouTube and then you can have as many viewers as you want if they don't need to participate, for instance. Or you can watch the recording later as well. It's fully anonymous as well if you want to. So you don't need to basically sign up or put any data out. You just go for it, use it, and that's it. There's an integrated chat in it. We can do collaborative document editing with Etherpad. There's a calendar invitations plug-in which I'm going to show you. This basically allows you if you're using Google Calendar, for instance. You can schedule a meeting and really quickly create a DC meeting room so that that's where the meeting would kind of virtually take place. We can invite other participants by just sharing the URL so you can share it via email or whatever other means. And I left the kind of two, well, two important ones for last, let's say. So simulcast is the ability to forward just the specifically relevant video to each participant. So in the image we saw before with 12 people, you can imagine that we cannot handle like, well, not cannot, but your bandwidth cannot handle 12 to 15, let's say, full HD video streams. So what do we do? Well, it turns out that each participant will send three or two or three different resolutions and we'll just pick the appropriate one to forward to you. So if you are on the large view, then of course we're wondering full HD. But if you're in a thumbnail, we can do fine with a much smaller resolution which takes a lot less CPU, less bandwidth, and so on. So we use a combination of techniques here. Simulcast, a little bit of SVC also to cut down on the frame rates in some cases and also what we call last end, which means you don't necessarily need to receive all the participants' information because maybe they are not active in the conference so you can basically skip the non-active participants and only get the last end active participants. And this way you also save again bandwidth CPU. And mobile apps. So that's actually one of the things actively working on right now. We haven't announced them yet, but they are in the Apple Store and the Play Store. You just have to put the right name in, GCMeet, and you will get the thing. That way you can just enter the conference room name here. If you have your own deployment, you can enter a full URL and it will also work. And you just join the conference and participate via your mobile application. Now mobile applications are also open source, turns out, just like the other things. So you can go ahead on GitHub, actually, that's where we do all our work in the open for request reviews and so on. And you can either build them yourself if you want to get them from the store. Code is up there. Now you're probably thinking, well, cool story, but I want to host it myself. So how do I? So the plan for now is I'm going to start with my destroyed development virtual machine and build it up again so that we have it running and hopefully some of you guys can join the meeting. So this whole thing requires a number of moving parts, a number of components to have our GCMeet infrastructure. You need a web server, you need an XMPP server. Did I say anything about XMPP? Well, not really, but it turns out it's used internally. So we need a setup there. But the idea is that we should do this with as little configuration as possible. So it's more approachable for everyone. So hopefully that's what I'm going to show you with any luck. So. Dangerous. Dangerous. Let's see. So let's do mirroring. And the first thing we need is double check that the thing doesn't work. So all I have on my server is NGINX and some SSL certificates in a folder. This is my server. There are many, but this one is mine. So I can just stop the install GCMeet and all the dependencies and stuff. This is an Ubuntu system. So we have packages for Debian and Ubuntu. So we have to enter some information like on what domain we're hosting this. This will create the necessary configuration. So it is reachable via NGINX. We can opt to create a self-signed certificate. But then it gives us the annoying warning in Chrome. So let's do that. I have my insert. So let's do that instead. I'm just going to ask for it right now. So because I did that, I have the key and the cert on the same place. So we install it. And now we should be off to the races. Well, turns out we are. So let's join the room. Let's call it FOSDAM. Can anyone in the room with a laptop join me here? Ulan, Iñaki, Jose, hello. Something went wrong. But they are trying to fix it. So it's okay. Whoever they are. What the hell? Okay. So we got another fellow Jits here here which joined. And I don't know, another guy doesn't want to show their face. So this is the main GCMeet interface. Okay. Now we're going overboard here. Let's see how the Wi-Fi holds. So what can we do from here? Well, so if you're collaborating with multiple people, you may want to take turns and raise your hand and stuff when you want to do something. Here we can share it to YouTube if we have an API key. We have an embedded chat. We can choose a nickname here. And say boo. And then we can have a chat real quick here. So it's 12 participants here. All right. So this is basically all happening on a server in Ireland. It's the forwarding happening. And here for each participant we have some information which we can hover on. So we're not receiving him. You see how we're just receiving a tiny little thumbnail. 180p. Nothing really. So this is happening all in the WebRTC domain. But sometimes you just got to go for the PSTN, good old line lines and stuff. So we also have a gateway in the past. It's called Gase. It stands for DC Gateway Percept. And that way we can actually join via SEP. So we need to configure a SIP address. That is the one which is going to receive incoming calls. So I have a SIP address from a French operator, offer one. And let's see. There's a default room configured. So I'm going to exit this FOSDEM thing. And I'm going to enter my SIP test room. So my microphone is back. Why? Can you please not enter this one? Because I'm going to enter with a phone. So in this room, I can just take out my mobile here and use the phone application, which is usually hidden somewhere because you don't need it and stuff. And with any luck, there we go. Boom. So we are in via the mobile phone in this WebRTC multi-party conference. If somebody joins, their audio is also rich. So everybody basically, what you guys will do is receive all the audio for every participant, mix it in so we have it in here. So this way we can really easily branch out to either old legacy SIP devices, even the PSTN, whatever. And you can use it. Like that old IBM ad said, it connects anything to everything. So that worked. That's cool. So what's next then? What are we working on? We're working on the PERC with the PERC IETF working group to have fully end-to-end encrypted conference calls. So this is quite tricky. It requires that you use SRTP twice, and so far nobody has it. As in we are working with someone which is doing a modified version of Chrome, and hopefully this makes it once the standard is stabilized so we can use it. We're also working on simulcasts at activity. So basically trying to better adapt to changing network conditions to dynamically change these number of participants you get or different resolutions, try to be smarter in this department. We're also working on an optimization when you're calling one-on-one. So when you're just two participants, we'll try to bypass the bridge and basically have a direct connection between us if we can do that without any turn service. If you heard the first talk about Merquist, you'll see that, well, that's not always possible, but if it's possible, we'll go one-on-one. But then, when a third person joins, we'll go to the bridge so that we'll work together. And then we're also doing some work in ICE mobility. Basically, if connection changes, we need to survive and continue our call without being disrupted by these connection changes. And of course, our mobile applications efforts are also in full swing. So that's all I got. Got any questions? I'm here now and tomorrow. And that's the Twitter thing. As I said, it's already there. It's already there. You go to the GC Meet repository. And the code is there because the website and the applications share a lot of the code. So just as a fun trivia fact, the web application is now gearing towards rewrite in React. And the mobile is built with React Native. So we're unifying all in a single direction. And there is also a document on how to build them if you want to do it yourself. Thank you. Thank you. There, bye. Hello. Happy question. The GC Meet. Yeah. And it has three components. I installed many of them. And the thing is, it's quite hard to upgrade. So if you have used it for... Oh, sorry. Okay, I'll repeat the question, which is if we're doing releases because updating manually can be painful, you don't know what to expect. So I don't disagree with you. Right now, the thing is all of these projects, they are somewhat intertwined together as in if you want to implement something, it's possible that it touches multiple projects and you need them to work in tandem. So we have Jenkins test everything together and tag each repo. So if you use the same tag across all the repos, that's the working set. Now, that said, if you have followed along GC Meet for a while, you probably know that it pretty much didn't change all that much in how it looks. It basically keeps on improving. So that is the idea. It's a little bit of a rolling kind of thing. So if we think about doing stable releases, well, what does a stable mean? Because we have to change things all the time because Chrome changes things all the time and Firefox changes things all the time. They are moving targets, so we try to adjust and it's a little bit hard to set the point where this thing is ready now because the thing is ready right now. But if we look tomorrow, it may not be because some things have changed. So it's like with this perk thing, it's happening right now and it's probably going to evolve a little bit more before it gets there. So if you look at, for instance, browser releases and this has to be very close to browsers because those are the main endpoints here. They move so damn fast that they don't make releases more like if you're using five-folder versions of Chrome, it's like what are you in prehistoric times. So it's a little bit, I understand your pain point. That's why we have these packages that basically do it for you. You have to do it by source. All I can tell you at the moment because I don't have a better answer is that you have to see all the tags together. We have regression tests and everything runs on Jenkins. But Marquise said actually testing is not built into WebRTC but you can do it and we do it. So we don't release something that is broken. Like if it's not green on our screen that are hanging from the office, it doesn't go out. Now of course there's always things that are unexpected and we can't test for the unexpected. We're not perfect yet. Yes, we do and it should be coming up soon so I haven't personally worked a little bit on that on one part of this. I'm hoping to give a talk on these things later in the year once it's a little bit more ready. But we do have a plan and a working prototype on how to do this for legacy C10 points that can only do a one-to-one video call to have everybody join the conference. We do. Okay.