Our next talk will be about video and network.

We'll first start with a JITC presentation by Emil Evoff, who is going to talk about a video bridge and WebRTC. Let's applaud him.

A lot of people here today, I'm very happy about that, because the stuff that I'm going to talk about is really very exciting, at least we're very happy about it. It's something that we've been preparing for quite a while now, and I'm very happy that we have the chance to talk about it today.

You might know about JITC under this form. It's a relatively popular open communicator doing audio and video, high quality audio and video calls. We support codecs such as VP8, H.264. For audio we do really the state of the art ones, Opus, Silk, G722.

We have been spending the last 10 years, because it's been that long since we started, working on a number of functionalities in the client. We've been doing audio conferencing and video conferencing as well.

Just to be clear, this is stuff that we implemented within the JITC application, within the JITC rich client. That made it a very popular client. Because it's basically an open source alternative to Skype, right? We had a number of other functionalities as well, and we've had them for a while.

One of those that have been very popular, in addition to audio and video conferencing, have been our security oriented features. We encrypt everything. We have SRDP support for your media. We can negotiate SRDP key exchange with CRDP, which is really as good as it gets

in terms of security and privacy. Just as a previous speaker with Colab, we did see a big surge in JITC use last year since the Snowden revelations, so thank you prison.

We also support OTR, which allows us to encrypt your chats end to end, and DNSSEC, which is one more way to protect yourself against infrastructure attacks. In addition to that, we've really implemented a number of things that help you

integrate JITC and enterprise environments, like LDAP for example, or collaboration features such as desktop streaming, acoustic echo cancellation. We have an Android version. We run on Linux, Windows, and Mac.

We also have two very important components, which are libJITC here and JITC VideoBridge, which is really what I'm going to talk about today. A couple, two, or three years ago, WebRTC came up. How many people here are aware of what WebRTC is?

Okay, that's great. You probably must have been at least as interested as we were when WebRTC came up. The cool thing about it was really how easy it was to deploy real-time communications applications in the browser.

WebRTC also came up with this. It generated this energy in the standardization space where a bunch of things that were available for quite a while, like ICE support and DTLSSRDP, kind of became the norm. This was what you had to do in order to be WebRTC-compatible

and has to be usable and integratable with anyone. It really was about how easy it is to use. You can spin out a video call service in a day, really.

Many people also think that one of the biggest advantages of WebRTC is that it's end-to-end, peer-to-peer. Again, it's not something that WebRTC invented. It has existed for a while, but WebRTC did generate a lot of support for ICE, which is the main natural tool that we currently have out there.

The question is, since WebRTC is supposed to be a peer-to-peer thing, a one-to-one call thing, how do you implement the same kind of video conferencing that we have in Jitsi into WebRTC? How do you handle multi-party sessions?

Well, there are several ways to take on the problem. The traditional way, which you're going to throw right out of the door, is sending everything to a single server, having that server decode everything, scale it down, create composite images, re-encode it 30 times a second.

That obviously is an extremely expensive approach where you waste a lot of resources, it costs a lot of money, and it decreases quality considerably because of the double encoding that you have there. Not to mention it introduces latency and a number of things.

The cool thing about the way we were doing video conferencing in Jitsi is that you had individual sessions for every user, so you could really lay out them any way you want, you could have the active speaker in a bigger frame and everyone else smaller, etc. So a lot of people, when implementing,

when going for video conferencing with WebRTC, said, well, WebRTC is peer-to-peer, so we've established one session between Chrome and Firefox. How do you make that multi-participant? Well, you just establish sessions with everyone. Right, so this doesn't really work, and not only because I made that slide intentionally ugly,

but obviously you can't just stream to the entire internet from your home connection. Especially the way that internet is being deployed today with ADSL modems and limited upstream, you can basically do a maximum amount of 800 kilobits per second, a megabit maybe, for the most part of us.

So this doesn't work. This is where we thought, we have the Jitsi video bridge. It's this component that's based on the heart of Jitsi, on libJitsi. Why don't we make that compatible with WebRTC and make it available to all the web developers out there? So we did.

We went for it, and we added the missing parts. The video bridge, again, it's based on libJitsi, so we handled the features that Jitsi has. We explicitly added support for DTLSSRDP, ICE as well, and there it was.

So the way that the video bridge works is that you have every client participating in a conference send one stream to the bridge, and then get back the streams for everyone else. This is a very lightweight approach. There's no transcoding for video on the server.

It's just relaying. It's a really very scalable approach. Well, to be completely honest, it's exactly how Google Hangouts work. Only Google Hangouts use the VDO router from a US company called VDO, which is a proprietary product, a very expensive one. It's a good product, but still a very expensive one.

So Jitsi video bridge is pretty much the same thing, but open source. Now, just to show you how lightweight this thing is, this is a picture of our stand here in the K building. We have demos that have been running all day long, conferences with up to 10, 12 participants,

and the bridge that is supporting these conferences is right here. It's this little nook running here on a Debian, and it hosts the entire conference, and it can host three more like that.

So it's really a very enthusiastic, it's really a very cool product. Now, just to give you a little bit more detail about how you can actually use this thing. Basically, you can either just take the project and integrate it into your application

and call the existing classes, the existing API, or you could use this protocol that we came up with. It's called Colibri. It's an XMPP-based product. You can just add that to your web application. It's specified in ZEP 340.

By the way, it's a new specification, so we're looking for feedback. If anyone there is interested in checking that out, please send feedback to the Jingle mailing list on the XMPP standards foundation. The way it works is that you basically have your web application sitting somewhere,

and you add a video bridge on the same machine or a different one. Obviously, you have to put the video bridge behind an XMPP server if you're to use Colibri. Again, you can integrate that directly in the application as well. Most of the time we use Prosody, which is a very cool XMPP server, so we highly recommend that.

Your web application is going to host a conference at some point, and what it needs to do in order to host that conference is just send a message to the bridge and say, hey, could you please allocate 10 channels for me, because I'm going to have a conference with 10 people. The bridge is going to do that. It's going to allocate 10 port numbers for you,

send them back in the form of ice candidates, and then you can use that to actually invite the browser into the conference. The invitation of the browser happens through whatever signaling protocol you have. You have to understand that there's nothing protocol-specific in the GT video bridge.

It's not SIP-dependent, it's not XMPP-dependent, but of course it can work with SIP applications and XMPP applications. It just sits in the background there and relays traffic. So use your favorite signaling protocol, and SDP I put there because I don't believe that's anyone's favorite.

Once you negotiate the channels, all the participating clients start exchanging media directly with the GT video bridge and getting media directly from there. We created an application that illustrates how to do exactly this thing, which is also open source.

It was originally written by Philip Hanke, who is in here somewhere. Thanks, Philip. He contributed that to the community, so we are now working together on that application. They work very hard with Lubimir Marenov, who must be also here, one of the GT guys.

And jitmeet.org, once you deploy it, looks like this. These are real conferences, this is not a photoshopped or gimped screenshot. This is actually Philip. We're also hosting this, in case you want to try it out, in a free installation.

Oh, here you can share Prezis currently through this. We're hosting this in meet.jit.si, so you can just try it out there. The cool thing about this application, and again it's just a sample, you're not required in any way to actually go through it if you want to use it.

You just go to a URL, you just go to meetjit.si, it generates a URL for you. You take that, you put it in an email, you send it to everyone else that you want in a call. And they go to the URL, and they're in, and that's it. It's really that simple. So, we believe that this is really something revolutionary.

Obviously, it's not only our thing, we're stepping on the shoulders of giants, as they say. This uses WebRTC, which is an open standard. It uses other servers like Prosody, for example.

It uses libjit.si. It's a lot of hard work in there, a lot of it that's coming from outside of our community. But we believe that we are now getting to what really video conferencing should be like. This is the simplest video conferencing experience that you're ever going to get. Just go there, no account, take the URL, send it, and everyone's in.

Not to mention quality is great, both audio and video, so I encourage you to try it out. Well, that's it. Thank you very much. I'd be happy to answer your questions if there are any.

So, we have a question at the rear. Since you're relaying the media to multiple destinations, I assume you have to, in the case of DTLS, decrypt it and then re-encrypt it before forwarding it.

Am I correct? Yes, we do. There's actually a lot of reasons why you need to do that. You have to be able to rewrite payload types in order to support SDP. You have to be able to read RTCP packets in order to know how to handle them in optimized video quality. So, yes, we have to do that.

We would have preferred not to because it's a performance hit, and we'd really like to keep that lightweight, but we do, and it works quite well. A question here. Can you repeat the question, please? Yeah, I am. The question is, does it also work with Android?

Yes, you can use it. You can use JIT meet with Android using Chrome Beta. Soon we are going to make it also compatible with the JIT C for Android version, but currently it's just through Chrome Beta. Yes, there's a question over up there, I think.

I have a question regarding the future developments. Are you planning to include also a kind of desktop sharing, like Nicogo or Webex? Yes, we are, and there are several ways to go about that. Currently, Chrome allows desktop streaming, but it is hidden behind the user configuration flag because it is obviously a huge risk.

In the future, that flag is going to disappear, and Google have announced that they're going to make that only possible for Chrome extensions that you download from the Chrome App Store. So we might support that.

You might as well because, again, the bridge can be used in any application. It's not exclusive to JIT meet in any way. The other way that we're planning and integrating desktop streaming here is through the JIT C, a rich client. Once that is compatible, and we're really close to it, once that's compatible with JIT meet, you just capture the desktop with JIT C and stream it into there.

There's probably one last question here. Do you have ZRTP support for video conferencing, and how does that work for the keys? Is there a common key, like Wi-Fi, where you have a common key for the conference, or what's the status of it?

Right, so unfortunately, the WebRTC community hasn't gone for ZRTP, so browsers don't support ZRTP. The bridge does, or at least it could, because it's in the library, and that said, shut up, I'm done.

I'm just going to finish the sentence. That said, if you run your own JIT meet server, DDLS is just as good as ZRTP because you are the man in the middle, so you don't care about, you actually trust the server. Unfortunately, currently this is as good as it gets with WebRTC.

I think this is good enough because you have the option of downloading and installing it yourself. Thank you very much. Thank you for your time. Come see us at our stand in the K building.