 Welcome to the real-time communications track of DevConf this year, where we're having three talks in a row about related subjects, and the first one by Daniel Pocock here, and while we're on the subject of real-time communication, I'd just like to thank GradWorld.com, who have provided the free calls out of the conference on my desk phone, which if you haven't taken advantage of, well, you need to do that before the network goes away. Also involved in the track is Zafir Cohen, and two other people whose names I was told about 30 seconds ago, and I've now forgotten. You can do the rest. Okay. Welcome to Vomarcu in DevConf. Who's just come down for the day? Some visitors, and who's been to one of my DevConf talks before? Yeah, a couple of people. Okay. So this afternoon we've got a whole track on real-time communications, so I'm going to start with an introduction, and then Zafir is going to help with some discussion about asterisk in Debian. Catalan has been participating in the Google Summer of Code. He's going to go through some things with SIP conferencing and WebRTC, and we'll get back to what WebRTC is in a little bit. And finally, we'll finish off with Emil Ivov from Jitsi. Who's heard of Jitsi? Yeah. So free Java soft phone supports SIP and Java and other protocols. It's actually been around for many years, and he's the founder of the Jitsi project. It's one of the most heavily developed open-source soft phones. It's been very successful, so it's really good to have Emil down at DevConf today. In February, we gave a similar presentation at FOSSTEM in Brussels, and we spoke about the importance of free software for free communications. A lot of people say to me, I've got this thing called Skype, and it's free. I say, no, it's not. We have a different definition of free, and Skype doesn't quite fit that definition. And so we've had some help explaining that in the last few weeks. So the helpers come from the NSA. They've published thousands of documents revealing how they monitor solutions that are not free. And so people are more aware of this topic than at any time before. I've certainly found that they're interested in my websites, like the Lumicall website and the RTC Kickstart. They doubled overnight when the NSA started to be documented in a public domain. Just by coincidence, on the 5th of June, in the evening, I published a blog about the gold standard in free communications. I can't see if I can bring that up on the projector without losing everything else. So that was on the 5th of June. And then the next morning, we had this. All of a sudden, there's a lot of attention on this topic, and it just came out of nowhere. I knew nothing about this. It was just coincidence. But a lot of people then started saying, why have you been talking about this? Why is this important? And why has it been on your blog or at FOSSTEM? So it is an important topic at the moment. Just this week, we've seen it's not just the NSA. It's not fair to be unreasonable with our American friends. Here in London, the rubbish bins are out to get you. These rubbish bins are monitoring the MAC addresses of your Wi-Fi devices, like your mobile phone, as you walk around the street. And they have them everywhere. Except you can't find a rubbish bin on the London Underground, so you have to carry a rubbish with you if you go there. But in the streets, you'll find these everywhere. And they've been gathering everyone's movements, who you associate with or who is in the same proximity on a regular basis where you go to eat, those types of things. So these things are widespread. They happen in different technologies and in different countries. And if the opportunity is there, it seems there will be someone who will look to find a commercial possibility with that. So we've seen the statement from Google this week that the users should not expect that when they send an email to a Gmail account, they should not expect that that is a private communication. And that was in a court document that they're using in their defence. A Skype. I mean, I'm not going to say so much about it. I don't think I need to. Mobile networks around the world, we've seen similar patterns. And is there anything left that users can trust? Well, there is. It's been 20 years in the making. And a solution that had anticipated these problems from the beginning. And of course, I'm talking about Debian. I'm talking about free software. And it's not just Debian. Richard Storman's been talking about this for years, even before Debian started. And other people have been talking about the need for free software, for transparency. If your software is not free, if you don't have the source code, how can you know what's in there? How can you know that your software is not the next iteration of that London rubbish bin? That it's got something in there to monitor you. But it actually goes a step further. It's an existential issue for the free software community. The free software and free communications are linked. That as long as people have this peer pressure to use a technology that their friends are using, that they want to talk to their partner, they want to talk to their parents, they want to talk to their friends. And their friends insist on a proprietary solution. Then that's a real challenge for us. Because then they want to change their whole way of computing. They want to run a closed operating system that can run this closed communication system. And that undermines a lot of our work in other areas, whether it's free presentation software or free email software or free web browsers. All of these suffer at the hands of closed communication software that's supposedly free. The peer pressure is probably stronger with communication software than with any other type of software that I've just mentioned. Someone's not going to have pressure from their partner to change their accounting software or to change their email program. You can use any email program to communicate with anyone else. But when you want to talk to someone or to see them with the webcam, that's a personal connection that will be pressure there. And a lot of people will not argue with that. And they will try the proprietary solution. And then once they start using it, it's hard to get them away from that. Another issue is this question of why didn't people just abandon services like Gmail when all of this news came out? There's been no statistics, of course. None of these companies will want to say, oh, look, all our users are running away. But certainly, I see just as many emails from people using these services as I was saying before. So people are continuing to use them, even though they know that they've got holes in them. So people don't appreciate the individual risk. Like, if you were out in Manawa for Debcon 12, you wouldn't walk down the streets with a big expensive camera in one hand and a laptop in the other hand. Because you can appreciate the risk of doing that. And with no disrespect to the people of Nicaragua, but there were situations there where people were challenged about their security. But when it comes to email, people have no perception of any threat whatsoever. It comes to telephone calls or just maintaining a list of your friends on a social network. People have no value on that, that they just put it there and they leave it all hanging out, like a expensive camera hanging over your shoulder. But with all this attention on the subject, there's never been a better time to be promoting free software solutions. So who wants to get started to run open source communication software? So what's the strategy to do this? Obviously, if people were keen on this, they would have all done it already. Everyone would have free software. So we've got a gap there and we've got a bridge that. So I've documented a strategy here. It's fairly straightforward. One of the first things to look at is the federation. It's how we can interact between our domains, just like we do with email. SIP and JABA, the two common protocols for voice over IP and multimedia communications and they both support federation. Some versions of the software that you might have tried before did not support federation very well or very securely, but that has improved in the last 12 months. Certainly with Debian 7, with Weezy, you have federated SIP and federated JABA in the standard stable packages. The next thing is to get around NAT. Who's ever had an attempt to make a call with a soft phone and they've had audio or video in just one direction? Yeah, it's a common problem. And one of the reasons for that is the NAT, that firewalls and NAT devices are blocking something in one direction and the software doesn't know how to deal with it. There was no standard solution and for quite some time manufacturers are actually making routers and other devices that would try to help you. It's just each one would try to help in a different way and they'd end up fighting with each other and making the problem worse. Then a standard came along and that's called TURN. TURN provides a mechanism for relaying video, voice, and all other types of streams and sockets in a range of scenarios. That's going to be part of the solution. Running both SIP and JABA. Some of the people you want to speak to will be using JABA and some of them will be using SIP. We have a lot of these hardware devices out there and they're predominantly SIP devices, very few JABA devices. There are a lot of very good chat products that people have on their desktop or on their laptop or on their mobile phone and most of those are JABA based. The user identifiers which is basically like your email address can be interchangeable between SIP and JABA. The only thing that we have to keep in mind is you have to run something like a dual stack. It's like running IPv4 and IPv6 at the same time. We have to run both of them to be successful, to maximize the probability that you can get any call to anybody through either of these protocols. If the other person only has one of these but you have both then chances are your call will succeed and you'll continue using free software. The final thing is to attack from every mode of communication. We can now do this from a web browser with no plugin required. If you have a blog, if you have a small business website, where you have a contact form and you have your phone number, you can now put a JABA script control and a little bit of HTML and people can call you as long as they have the new browser. They don't need to install anything. Now let's get a little prompt to agree to let your website use their microphone and potentially their webcam. Mobile devices, the fastest growing form of internet access by far and most of them now are Android which is Linux based which is great. There's a number of options for real-time communications with CIP and JABA on Android. That's part of the picture that tapping into those options and providing Debian infrastructure and to act as a server for those apps is another way we can move forward and hard phones. Some people just feel comfortable with a physical phone. It looks like the phone that they have now that's monitoring them, but it's better. Just putting these phones into the homes of people that you communicate with that won't use a computer can be very powerful. Just looking more closely at turn from that busting, a single turn server instance will support both your CIP and your JABA users. You don't have to set up multiple turn servers. It's independent of these protocols. It supports various things like tunneling through HTTPS. If you're hoping to receive calls from people that are on corporate networks where their internet access is tightly restricted and their only access is using a proxy and they can proxy HTTPS, they can use turn. Setting up your turn server to listen for port 443 can be very powerful. It's a standard feature in the WebRTC protocol. For anyone developing any of these WebRTC solutions, whether they're doing it with CIP over WebRTC or whether it's some proprietary solution, turn is still a part of that solution. It's in the browser itself. It's not in the JAVA script. There are three turn servers in Debian. One of them, the return server in reciprocate, is in stable, in Weezy. The open turn server from Jitsi and there's the RFC 5.7.6.6 turn server project. They're both in unstable and I believe they've migrated to testing. There are three compelling solutions. If one doesn't work for you, there's a good chance that another of those solutions will work. All of the communities are very active and they're helping with bugs on those packages. You can't go wrong choosing a turn server. Setting up a CIP proxy is a first step. A lot of people have heard of asterisk or free switch and they've tried to start there. They're great products, but they have a lot of bells and whistles. Sometimes that can make the project a lot more complicated to begin with. The advice I normally give people is if you want to get federated quickly and if you just want to start trying this out, just set up a basic CIP proxy. It doesn't have voicemail. It doesn't have queues. It doesn't have all these other fancy applications. It's just a way for people to call each other, but it will support federation and you can add in PBX such as asterisk or free switch later on. They can work as an extension to your proxy. There are two popular choices. They're both packaged in Debian. One is the repro from reciprocate and the other is Camilo. Both of these solutions support TLS, which is quite important for federation now. They support WebRTC and they support the federation itself, so routing calls between domains. A lot of older solutions would just work in a local domain. They were trying to replace an office phone system. They were not meant to go out on the public internet and if they did, they would often find themselves a very big bill. These solutions hopefully won't leave you in that scenario because they're so simple. It's easier to understand what you're deploying and hopefully make it secure. The next step is the Jabba server. Once again, it's important to start with something simple. I use the eJabbaD. It's based on Erlang. It's very stable. It has a web interface where you can set up users. It can work with your LDAP if you have one to authenticate people with a single password. It's very convenient, very quick. You can often set that up in maybe an hour. Both of these solutions are packaged, so you don't have to compile anything or whatever. Taking it further. Once you've got all of those things in place, then it's a good time to look at more advanced solutions. I've listed some of them here. A soft PBX. Let's say you do want voicemail, you do want queues, you want to have a menu system where people are prompted to who they want to speak to. Then you will have to look at putting in a soft PBX. You can connect those solutions to your existing proxy. You don't have to replace the proxy, rather, you connect them together. If you want to do conferencing, you can use a soft PBX to do that, or you can use a standalone conferencing server. In Catalan, we'll talk about that in the next session. The other direction you might want to go is with Jabba, which is formerly XMPP. There are a number of solutions now to rival Facebook and Twitter for social networking features. But once again, these are a next step. After you get your basic Jabba server running, after your users have a user ID and they're able to chat, then you can look at these things coming in later. But they are there, and they're also packaged in Debian or they're open source, and you can get your hands on them and try them out. So that's all of the slides. Here are some of the packages that I've provided already for voiceover IP. There's a few others in the list as well. With Drupal, I've been working through the packaging of JavaScript so that we can make a WebRTC control that is dropped in like any other Drupal module. So then anybody running a Drupal blog, and there are millions of them out there, can just add a WebRTC calling feature on their blog just as easily as they can add a web form with email. When someone asks them, do you want to talk to me with Skype, for example, they can say no. Just come to my blog and talk to me with that. It's not only good for putting the proprietary solutions aside, but it also helps people to raise the profile of their websites, their blogs, or whatever their preferred online identity might be. So if you're running a business, you want to get people to come to your business website. You don't want them to register their details with a third party, if you can avoid it. Some of the other solutions we've got here, Reciprocate, of course. So I also work on the upstream development of Reciprocate, particularly the WebRTC code. So if anyone has any questions about that, feel free to hassle me on the Reciprocate mailing list. We've got the RFC 5766 turn server and the JIT-C turn server as well. And we've also got the Cipex Tappy. This is an alternative CIP stack, and we're using that to provide the media framework for conferencing. In the future, we might look at doing that with the WebRTC media framework, which can run standalone as well in other applications. And this provides more advanced codecs and other options for conferencing. Has anyone got any questions at this stage? I'll just wait for the microphone. Someone put a microphone. About browser compatibility with WebRTC, there is probably nothing in stable which would support WebRTC in terms of browsers. That's what Backports is for. Right. And you mentioned the possibility to use your smartphone, for example, you, well, Android is installed on most. Do they come with such a browser out of the box or would they have to install latest version of Firefox or something to use WebRTC? How widespread would it be for a smartphone user to just use WebRTC to talk to someone? For the smartphones, it's really an emerging thing. Ericsson Research released a browser which they call Bowser, which supports WebRTC. I haven't tried it extensively and I can't say if it works or not, but that is out there and that's worth a shot. The whole thing is a moving target. Smartphone users are particularly likely to be behind that as well and to have other connectivity problems. While we're still sorting out WebRTC issues just on the normal office PCs and home PCs, then some of those mobile connectivity issues will probably come last. You can see that the support for turn over TLS has only just been realized with the latest release of Chrome from Google. I haven't checked where Firefox is with that, but naturally they'll try and follow what Chrome is doing to interoperate as much as possible, but these things are still falling into place. With the original version of WebRTC in both browsers, you could only use UDP for your media streams. Now you can put your media stream in a TLS session through a proxy, which is a big step forward for connectivity with people on a restricted network. So these things, even when they're implemented in the desktop browsers, they might not follow in the mobile browsers right away. The one reality is with the mobiles, people also have to look at dedicated apps rather than waiting for the features in the browser. A lot of people have tried the non-free applications like Viber, for example. Lumicall aims to provide a similar sort of level of convenience, but with a genuinely free experience, because it's open source. People can install the app. They register their user ID as their phone number so that they can immediately call other people just by knowing someone's number. They don't need to go and say, what's your user ID on Lumicall and start making up a list of all their friends. It's automatic. It's linked to their phone number. These are the types of things that we can do to make it easier for people on mobile. That's the situation with mobile. I see that taking time to really settle down for the WebRTC in particular. Do you have other questions? What sort of resource does running Cyprocade on your server potentially take in terms of, is it tiny, enormous, might use a lot of bandwidth? This thing costs about maybe 20 francs or $20, depending where you're from, and you can run parts of Cyprocade on one of these. It's a very basic router. On a server, it's not very demanding. The Cyprocade stack actually runs on an Android device as well. You can run the return server on a device like this to provide constant and net traversal wherever you are. If you have one of these in your home running the turn server and you're out on some odd network with your laptop or your mobile phone, then you can basically use Turn to call home and to relay your media streams, which also gives you a level of privacy as well as the security that you can get through awkward network situations. It's not a very demanding stack. It's been optimized quite extensively. On the other hand, it is a very full implementation of SIP and related standards, so it's not the smallest stack by any means, but it still runs well on small devices. End up relaying, so there are considerations as to how much data you're sending through your box because the turn server ends up being intermediary if it can't make a direct connection. Is that right? Yes, and it uses access control so that only authorized users can relay. There are situations and it varies from country to country. In some countries, virtually everyone has to relay their calls because their telecoms market is very regulated and they're very much afraid of these technologies and they have to set up VPNs and relay everything. In other countries, it's just a question of what hardware people have. People with very bad routers often find that they can't make proper calls without something relaying their calls for them. So a turn server will help those users. Maybe one in ten users will need relaying in like a western country at the moment. So, more questions? So I see that it takes, we'll take a bit more time until WebRTC becomes as a big use as it would need to be to just tell somebody to go to the website. But imagine that would be the case. For me as somebody who would like to then use WebRTC, there are standalone programs who do WebRTC and for which I would then not need to use my browser, which I only want to use for browsing and not video stuff. But a standalone application which would just be like other calling applications but just would do WebRTC or multiple protocols for that matter. Okay, so what you're saying is someone wants to call you? Yes, and I don't want to use my browser but a standalone application. Does it exist? Is anyone here make soft phones? Emil? He gives a microphone too. Hey, Emil from GT. So the whole point of, I'm not sure if many of you here have tried coding with WebRTC, but basically the way it works is that you tell your browser, I imagine you've already said that, you tell your browser I want to do audio and video and then it generates a block which is an SDP, which I suppose you've already seen maybe. And the whole reason for using SDP was so that interoperability with other protocols such as SIP would be easier. So one would hope that, yes, you would be able to do that. You would be able to use a browser to connect to any SIP soft phone and receive codes without you needing to start a browser. Now, that was a plan. In reality, things got a little bit more complicated than that because as you all know, WebRTC requires a bunch of things that weren't necessarily available in regular SIP soft phones such as, for example, support for rice and not just standard vanilla ice, but trick-wise support for bundles, support for DTLS. Most of these things are currently unavailable in most soft phones today, really actually all of them. Now, what is going to happen most likely is that all of these soft phones are going to just adopt and implement the additional protocols that they need to. This is what we are currently doing in JITZ. We're implementing support for ice per SIP. We already had it for XNPP and we are also working on implementing DTLS. Today, however, there are already people who are using JITZ through XNPP, through Jingle, to make codes to a browser and receive codes from a browser. The short answer is, eventually, it would be possible today. It is a little bit of a hassle. There are some unusual side effects of trying this. Catalan, have you got the polycom phone there? Did you just pass me the polycom phone? One of the first things that I did when I try WebRTC is to make a call from the browser to one of the regular phones I had on my desk. So the SIP relayed the call from the browser to the phone and the phone crashed and rebooted itself immediately. So you have to be careful when you have to test these things before you roll them out in a commercial environment, for example. They do have this impact because the protocols are a moving target. Things are improving, but older devices will struggle with the newer protocols. I'd just like to have one comment here. The reason why some of these phones would still work today is because the WebRTC implementation in Chrome today uses SDS for key negotiation for SRDP, which is the conventional way security was being handled in SIP for quite a while. Recently, a couple of weeks ago, actually, the ITF agreed that SDS would not only be mandatory to implement, sorry, would not only not be mandatory to implement by WebRTC implementation, but it must not be used by WebRTC implementation. So all of these that actually supported SRDP on some level are going to be with their current implementation obsolete and we would have to wait for firmware updates or for new versions of soft phones. Just a simple answer to the question. GTC has only recently been introduced into unstable. Do you want to come up the front? Yeah, yeah, it's okay now. A simple answer to the question. GTC has only now been introduced into unstable and it's not even yet, it's still too young for Jesse even. There are a number of other soft phones probably of lesser quality, still already in the archive. Linphone, SFL phone, which is awkward, but has most of the features and yeah, and what, yeah, the other one. SFL phone should have it, I think. Yeah, should have it. I tried to configure it a while ago and was unsuccessful of using it, but there is a switch in the configuration panel and there's also a gate that should function as a soft phone and a bit odd and it doesn't seem to have a complete TLS support on the client side. Just to give an example, I'm not sure if I can do too much about that. Yeah. Empathy is a default soft phone in the GNOME desktop and during the testing phase of Weezy, I discovered that empathy was hard coded to relay things via Google's turn servers so that it wouldn't actually let you connect with the turn servers that are packaged in Debian. So in about March, I opened a bug just commenting that this may be against the privacy expectations of many users and I was just surprised to see this taking on a whole new meaning with the things that have happened recently, that there probably are other soft phones that have hard coded settings and this is another area where it's important to have free and open source software because then you can go in and you can discover these things and you can say, well, look, that needs to change and you can change it. So this is an opportunity to add a new configuration parameter to support any arbitrary turn server. So the current scenario, it's constantly improving but there's still little gotchas like this that you need to know about. So we've got more questions? Okay, also another basic comment. All the soft phones that we mentioned can do CIP but it's unencrypted CIP will work and will work well but I think maybe the basic assumption here for all of us is that this is not what we want, right? I'm happy with plain text CIP, making a phone call without a low rest of the world. For me, it's fine that plain CIP will be working. There's no hard demand for me to have encrypted audio streams. Any other questions? Zafrid, do you want to tell people a little bit more about the asterisk situation in Debian? A bit more about asterisk and other packages. Okay, about some packages you didn't mention. Okay, free switch, you mentioned free switch. Free switch is not yet in Debian. If you want to help packaging it, please contact me or Phil Hans should be here in the room. Okay, asterisk 11 is not yet packaged. It should hopefully be uploaded very soon. We're waiting on the PJ project package. It's now in the new queue. Asterisk 11 is the version that finally supports WebRTC and all of those things. The basic CIP TLS support is already in the existing package in Weezy. More on that, you didn't mention but there's a third alternative not widely used called Yeat. It's there. The maintainers are responsive to patches. So if you use it and have any problems, feel free to report bugs. Yeah. Okay, great. Well, our time is up. So thanks for coming along to the session. We have more questions. Feel free to comment. Afterwards, we have a free RTC mailing list. Have a look at opentelecoms.org. You can find details of some of the mailing lists for discussion of the general principles and also for specific projects. And everyone will be more than happy to help here. So thanks again for coming to Debtcon. Thank you for that.