 My name is Katerin Konstantino Shurelu, I'm a Google Summer of Code student, and I'm working on the project entitled Enabling Free Multimedia Real-Time Communication in Debian, RTC. For the beginning of my talk, I'll give a short overview of WebRTC, how it works, how it is managed. And after that, a short demonstration of the project I'm currently working on, the recon server. It's a SIP conferencing server, and possibly a replacement for Mumble, which we know had some problems in the last iteration of Debian. Okay, so what is WebRTC? Does anyone know? Okay. So, for those who don't know, basically, it's an API that enables plug-in-free communication. Basically, we have one platform for real-time communication, it's unifying, actually. WebRTC has many components, such as codecs, and the API for, I mean, for example, it doesn't have signaling. The user has to provide his own solution, but the framework provides a possibility to integrate it. Such as you can have a SIP, you can use SIP for signaling, you can use XMPP, Jabber, or something else. So it provides all the framework for real-time communication. This is a possible infrastructure. As you can see, we have soft phones, hard phones, Polycom, Cproxy, turn server, you need turn server for NetRiversal, and WebRTC actually, well, Stani is actually mandatory for WebRTC, and well, you can see it really enables everything cross-communication. Okay. The main WebRTC components are media stream. These are mainly audio, video streams, and other, like, it's not really restricted just to audio and video. You can also stream from a CD or different kinds of sensors. Okay. RTCP recognition, this actually handles the codec stuff, the security, SRTP, and DTLS. Also, it's also part of the signaling mechanism. Okay. And the RTC data channel, this is just for arbitrary data streams, anything other than audio, video, you can use it for multiplayer games or file transfer, peer-to-peer file transfer, and many more. Okay. About signaling. We need signaling for WebRTC. If you want to communicate with someone, you have to know their IP, you have to establish a connection, you need a protocol for that. You also need to know the client's audio and video capabilities, so they can communicate. And as I said, WebRTC doesn't have restriction on what protocol you can use. You can use CIP, XMPP, Java, or any other stuff. For example, XML, HTTP requests, you can use them. And, yeah, current JavaScript CIP libraries, we currently have a JS CIP, it's a very robust and simple client, we'll demo it later. CIP ML5, which is more than a CIP library, it's also a media breaker, it has many capabilities. And the Caffe CIP, this is a project on which one of my commenters works, I haven't really used it. Okay. For NetRiversal, Daniel discussed earlier, the main protocols are STUN, TURN, and, well, ICE is a framework that chooses the best way to bypass NAT and consume less resources. For example, for STUN, you just need to, you just ask the STUN server to tell you your IP address, so it knows the address on which it is listening to the client. But for certain configurations, for example, if both clients are behind NAT and the NATs are not well-behaved, you need the TURN, but TURN uses a lot of resources because you need to relay, it relays all the information from the TURN server. So ICE is the best of both worlds, chooses the best solution. Daniel presented earlier a few of the packages available on Debian, the RETURN server from Reciprocate, OpenTURN server, and RFC 5667 TURN server, okay. Now I'm going to, I want to make a short presentation of my project, the RECON server, a conversation manager. So I have a few users registered in RePro. This one should be the phone, and I also have a Lumicall client, 1015. So basically, we dial in the RECON server from both phones, for example, and if someone can speak to the phone, so I can, okay, hi, okay, I can hear you, okay, that's bad. Maybe we have some problems, but it worked earlier, yeah, okay, well, it may have some problems, but it usually works, and, yeah, I think I'm going to ask Daniel to help me a bit, also show the JSEAP client for the, let's just test directly, there may be some options that are not supported, so that's why it's not working right, okay, one-to-one, one, okay, I think I'm having some problems, okay, maybe let me try. So here you can see the browser asks for permission before it allows the web page to take control of the audio and video hardware, audio, or it's a security feature, I'm using Chrome, do you have Chromium, unstable? If you click allow, unavailable, let's just see. Yeah, okay, I don't think you're registered, could you try to register again? Okay. Yeah, I'm gonna call you. So who's got their phone on? Who is that? Oh, sorry, it's my web browser. You can see on the projector that the other user can see that the call has been answered. Yeah, can you hear me? Yes, it's coming through my speakers. Can you enable video on your side? Hello, can you hear me? Maybe not. Let's try again with the video, now you've enabled video. Okay. You've enabled video and you're going to call me again and we see if the video works. Wait, is there anybody else who has a recent Chrome or Firefox on their computer and would like to try and dial in? Sorry, you're stable, okay. So Firefox, no, it'll be a later version. Okay, so you're going to call me again. I'm going to answer the call. I have to allow the permissions. Okay, so we have video. Yes, okay. So I'm going to take this for a walk and just see how far the Wi-Fi goes. So for all those people watching remotely, yeah, welcome to Vomaku. That's the lake of New Chateau behind me. Okay. The problem there is the built-in webcam on this laptop. So, okay. So what we'll do is we'll arrange a little upgrade. That's a webcam. Okay, I'll call you again. If you try again, it's going to the wrong webcam. I don't think I have an option for that. No, I have to change something. But WebRTC is still experimental. They may not have a which webcam option at this stage. Actually, I think it may work on my laptop. It worked yesterday with a different webcam. Maybe, oh, here we go. I found it. I'm going to call you now. Okay. Allowing the webcam. And that's better. Yeah. Okay. I'm going to take this webcam for a tour of Vomaku and LeCamp. So is that any better? Yeah. Now we're going to go to the bar. Okay. Which way should I go to maintain the signal? The main talk room? Do we dare? Does anybody have any questions or would anybody else like to try it from their browser? Yes, Chromium should be supported. I do have a question. You're both running Chrome now. Yes. So I can already do that using proprietary software. So if you up get installed Firefox, would it also work? Or Ice Weasel for that matter? Not in stable. But with the new version of Firefox from back ports or unstable, it may be possible. Not yet. No. Okay. Well, have we got a volunteer who's got the free version? We have a Chromium. So the way to do this is to go to try it.jsip.net. We try one at a time. So you're going to steal my identity now. Your name is 1212. The SIP URI is just it's like this with one to SIP colon 1212 at and then that domain name. The password is and the finally the WS URI is where it says WS dot try it and delete all of that and copy in the same domain name as the SIP URI. So they did. Yes. And then colon 6060. That's the port. 6060. That's it. Yes. So now you can try dialing. I'm going to hang up. Yeah. And you can try dialing 1211. You have to allow the permissions. And that's it. Okay. So now I am calling and welcome. Oh, hi. Hi. Can you hear me? Okay. Now it works. Can you hear me? I can hear you more or less. Yeah. We don't need to participate. I hear you fantastically. And the webcam is working too, I think. Yes. Fine. Yeah. This time it was more like. Okay. So this is a completely free solution that no plugin was required. Which browser version are you using? This is Chromium. Just a moment. I tell you exactly. I am the one in unstable. But if you want the whole number is 28.0.100. 1,500.95. Baby and just a seed two, one, three, five, one, four. So this was installed from the package. It was a manual download. No, no, no, absolutely. Great. So anyone with unstable or even someone with stable can potentially take that package from back ports and try WebRTC from their website. And so, Rhonda, do you want to have a go as well? Hang down. There you are. Okay. Yep. And I'll just give you my account again. So, yes. Yeah, just close the tab. There, one, two, one, two. The SIP URI is on the little box on my screen. Yes. That's your SIP URI with the SIP prefix. I don't think we can forward. The password is in the WS URI. You just delete it. Yeah, the whole thing. WS colon slash slash, then that host name from the SIP URI colon 56, sorry, colon 60, 60, 60. Yes. Yep. Okay. So, so you can call Catalan with one, two, double one. To my script safe settings. I allowed mostly everything that popped up. But so just just try again and enable the JavaScript console and see if we get any clues of why it's blocking the call. The thing that pops up is whether I want to allow it to use my webcam. It's shortly blinks, but then says user denied media. If you enable the JavaScript console. And do you see anything when you try it? Uncalled type error. Object object has no method on ice completed. Which version of Chrome or Chromium? The one in currently in testing, that's 28.0.1500, 95. Okay. We might have to get help from the JS SIP developers. If you can, could you cut and paste the error from the JavaScript console? Sure. And we'll follow up with them. Okay. Great. Yeah. Thanks. Thanks for trying that out. And does anybody else want to have a go? Okay. Does anyone else got questions? Okay. Can we try it with other clients rather than just the WebRTC thing? Or do you want to go on to talk about? Yeah. Making my jitzy work, for example. But maybe that should come later. Emil, what did you have planned for your talk? Were you going to do a WebRTC with jitzy later? Or do you want to do that now? Do you dare? It needs, it won't work with SIP. Yes. So what I was saying is that currently jitzy does not support ice and will actually just ice with SIP. We all have public IP addresses. Doesn't matter. Chrome isn't going to establish a connection unless it has ice. We do support it with XMPP and there are people that do successful WebRTC to jitzy interoperability through XMPP. But you would have to have a gateway. And it's only a signaling gateway. It's not a media gateway, but you'd have to have it. We don't have that ready. Right. So no, I was not planning on, I was just planning on mentioning interoperability, but not. No, that's okay. Wookie, any other questions? I don't know much about this technology, how it works, but I wonder if the video traffic goes through the server or is peer-to-peer? Excuse me, I haven't heard the question. My question is if the video traffic has to go through the server or is peer-to-peer? I mean, is the traffic directly from your browser to the other browser or it has to go through your SIP server? Well, you use SIP only for signaling. So the date RTP streams are browser-to-browser, except if you need the turn server in the natural browser, it will go through the turn server. But otherwise, it browsers to browser. So even if the server is in the other side of the world, if you are communicating with somebody in your own city, it should be fast. Yeah. Okay. Thank you. Could you show us some of the Java script that's behind JSIP? Or we could start with the HTML. You probably just view the source in the browser. Okay. So I'm not sure where to... I think I'm just going to view... Yeah, that's fine. If you press control U to bring up the full screen source. Okay. And if we just scroll down just to show people the size of this telephone in HTML, that's all. 250 lines. Yes. So that's cut and paste. So to add this to a blog or to replace that old web email form on your website, you can go to this triet.jsip.net and you can cut and paste their HTML and you're halfway there. So you're going to package that. So I don't have to go and cut and paste it off a web page somewhere, which is the kind of thing that annoys me. I've already packaged CipML5, which is an alternative one. Would someone like to try installing the CipML5 package on a server? Does anyone have a server they can do that with? It'll drop a config into your ETC Apache directory and then you'll have a slash CipML5 on whatever domain you're running. Presumably it needs to be a Weezy server. Or is it... Right, yeah. My server's not running unstable, oddly enough. It may be in testing, but I don't think it's in... Yeah, it's not in Weezy. You can get jsip just using wget and copy it. Just wget from that URL that's on the projector. Copy it into a directory under var www.jsip and away you go. So this triet.jsip.net it's updated regularly. And Catalin, could you show us the custom.js file? Yeah. When we started the demo today, Catalin was already logged in. When you go to triet.jsip.net on the internet, it will ask you to fill in all the credentials to log into some Cip server. It can be your own server or you can use their test server. However, if you want to host your own version and you want it to work for people who are not going to want to log in manually, you can modify this js file and you can add in all the parameters. And then when somebody goes to the URL, it will log in automatically and they just have to click and type the number to call and click to call. And you can actually put the number in as well and then it will automatically call some number. So somebody clicking a link in an email will be taken straight into a webcam session. Is it possible to handle multiple calls simultaneously, like Google and Gaud to replace Google and Gaud? Do you have a conference? Yes, to have a conference. Yeah, it is possible. What I think you need is the sort of kind of server to do the media stuff. Yes. I'm not familiar. Yeah, the conferencing is another step. So the conferencing that Cattern started to demonstrate before is not for WebRTC. The recon server will not support WebRTC clients. It will support regular SIP phones. For WebRTC conferencing, the WebRTC browsers have different codecs. So various people have been trying to put solutions together for that. So it's not far away. We could well have remote participation in next year's debconf using this technology. Wouldn't it be most simple to just have multiple WebRTC streams between all the participants of the conference call? Or would that not be possible with browsers? Maybe they can only have one at a time. Actually, you can have multiple streams, but it would be too slow. I mean, for each user to receive multiple streams from other users? Would it? Well, the bandwidth for video is big. Are you referring to a full mesh conference? Yeah. That would probably be very unscalable, because that would require you to send the same streams to everyone in the conference, to send the same streams to everyone else in the conference. Now, currently, for example, in Europe, the most popular way of connecting to the internet is arguably ADSL. And the way ADSL is generally configured to run is with a relatively limited upstream bandwidth that could probably easily fit one upstream video stream and one audio stream as well, but it would be quite insufficient for anything more than that. And I wanted to add one more comment to this. The next talk on JTNJT Video Bridge is going to focus more on conferencing and some of the web RTC interoperability aspects. What are the bandwidth requirements for an audio-only call and for a video call? Okay, I'll start with audio. And have any minutes we got? Okay. There are a range of codecs available. Each codec offers a different style of compression, and there's a trade-off between the quality and the level of compression. And the best codecs in terms of compression will generate a bit rate of about eight kilobits a second, plus the overheads in the TCP IP, which can actually be more than eight kilobits a second. But certainly, you can get an audio session that's using less than 30 kilobits in total. And now, for reasonable quality, you'll probably have 80 kilobits or more for audio. And that will get you a G711, and sometimes you can use the G722, which is a wide band codec. And a video on top of that really varies. So the more quality and the bigger the resolution and the faster the frame weight, the more it's going to use. So even with a limited bandwidth, like with 100 kilobits, you have a very basic picture. But if you've got megabits to spare, then you'll have live sort of movement in your picture. With certainly the people with the bare bones like 128 kilobit uplink on their DSL in some of the more remote locations can get two or three concurrent audio calls over their broadband connection, or one audio and one video stream. So I just succeeded in setting this over my server. He's right. It's not very difficult. You copy the file to somewhere you can see. It doesn't look very pretty. That's Firefox not running some JavaScript, I suspect. If I try running it in the epiphany browser, it makes a crash. So that's not very good. But anyway, what do I type? Okay. So I think what we've demonstrated is we can host it on your server, even if your browser is not WebRTC ready. So the only way we're going to get past this is to upgrade the browser. But nonetheless, other people can call each other through your server now using that technology if you give them accounts. It's just you won't be able to make or receive calls with them until you update the browser. But how did you feel about the process of getting it onto the server? Like if we connect to your server from one of these laptops, it should work for us. We could try that. Okay. If you take your laptop up to Catalan and he can try that. So if you copy Wookie's URL into your browser, I think it's supposed to be Tilda in front of Wookie? Although I'm not sure why. Is everything copied? Do you do a recursive Wget? Or just... Okay. Just try a recursive Wget to borrow all the content from try.jsf.net and then it should be okay. Have we got anybody watching remotely on IRC who might want to try calling us from a remote location? Is anybody monitoring IRC? Do we have any volunteer? No. So we're now demonstrating that on Wookie's website and this is there for anybody watching remotely as well. You can all jump on Wookie's website and try to call us at the same time. So this is the sign-in form that can be automated. We'll try first with Ronda and then we'll come back to your browser. You have any luck? Okay. Network is never mind. I'll try from my browser again. So, Wookie, this is your web server. So how long did it take you to install this to your website? About five minutes. Actually, once I type the right thing in the right place, about 20 seconds. Okay. Well done. So we're really hoping that people will go away and try this. There's an article on my blog about Get Web RTC Going Fast and that will take you through the steps to do this. So people are more than welcome to come and ask questions on the mailing lists and we'll try our best to help you out. So, yeah, thanks for coming to this session and feel free to come and ask questions and let us know how you progress with it all.