 Welcome everybody. So let's just go around the room and see who's here. So I'm Daniel Pocock. I'm a developer and maintainer of some of the SIP packages. And then I helped to get the services up and running at rtc.debian.org. Okay, let me just grab a microphone to go around the room. So here we go. Do you want to run the microphone? Right, I'm Martin Berens and user interested in all RTC programming topics, but have no experience of them yet. Okay. Yeah, I'm Martin. I'm co-maintener of some XMPP related packages, mainly Gatrim and Prosperty Mjordulz. And I'm also a user of the Debian RTC services, mainly their XMPP server. And it does not work very well, so we have to do something about it. I'm Ajay. I have no real connection to the Debian project, but like this seemed like an interesting session and I run my own XMPP server. Yeah. I'm Gillem. I'm maintain a couple of packages, but nothing to do with RTC, but I do use SIP quite extensively, mostly with Linfon actually, which is a bit aging and I'm curious what you have to say here. Also, I never managed to get the Debian RTC working, so. I'm Denver, also known as OSS Guy. I developed the Sopranica family of projects, which are gateways to the telephone network for both XMPP to do text and picture messaging and for voice over SIP. And yeah, so I'm kind of interested in how that might work with what Debian is doing because I'd like to get these things into Debian eventually, but I want to see what's there already, so I'm not duplicating work. Hi, I'm Steven, a long time XMPP user. I work on Sopranica a little bit and debacle asked me to come because I also have a lot of experience making our server not get as much spam as it used to. Yeah. Hi, I'm Debian. I'm not really connected to RTC or Debian, apart from PHP Maduin package in Debian. I am here because a few of my friends from last year's Google Summer of Code worked on similar projects in RTC. They could not attend, but I am just looking out for information here. Okay. Hello, I'm Ulbika, and I worked on a Project Lumic All, so it was under free RTC and it used SIP for voice and messages. So that is why I'm interested in this talk. Okay, so we have a little bit of everything here. It sounded like there was a little bit more interest in XMPP than anything else. So does that sound fair? So if we start with the XMPP issues, so what's the biggest issue with XMPP at the moment? And just grab the microphone when, yeah, it's a spam, so spam over instant messaging. Yeah, who's got the other microphone there? Yeah, so does anyone want to talk about the problem? On the Debian RTC mailing list, users complained about getting a lot of spam. I got rid of it by getting anti-spam plug-in, but this is obviously a workaround because, yeah, fighting SPIM on the client side is not the right way to do it. We must solve this problem on our prosody server, and in theory XMPP could fight spam much better than email code, but in practice the tools are not so advanced as an email because it's a relatively new problem and affects, of course, fewer users than spam and email. So I think there are some ideas. Unfortunately, Enrico is not here, but he thought about that on the server side one couldn't compare incoming messages. If there are many identical messages going in to different users, two users that do not have them in their roster, this is clearly a sign for spam or SPIM, but there's no software as far as I know that does such a check. The server that I administer is obviously a little bit less large than the Debian server, but we've had a lot of problems with this too historically, and I think there's kind of a two-phase situation that we're in with regards to SPIM. There's like how do we solve the problem right now so that we can at least make the accounts usable for the users with the technology we have available to us, like the long-term, what more advanced things can we do? And I think there's a lot of great stuff, like the idea that you just mentioned about monitoring on a big server, a lot of incoming stuff, and there's a lot of upcoming CAPTCHA zeps that are starting to get implemented in the clients that are maybe an option, a lot of fun stuff like that. But right now, the most effective thing I've found personally on our server is just doing really simple rules-based filtering and so there's a module for prosody called ModFirewall that lets you basically write simple rules to either reject, drop, or accept incoming stanzas, and you can do just like basically rejects across. And so I do the two main things are spam trapping, so I have JIDs that look like real JIDs but that are not for real users and I publish them and the spimmers have picked up some of them and they start sending spam to these addresses and I know that 100% of all messages to these addresses is spam. And so I can log that in my log file and then I can use fail2ban to monitor the log file and do other things like adding blocks server-wide for just those JIDs that are sending that so I can say, okay, anyone who sends from this JID is a spimmer because I know that's all I'm getting from that, right? So that's the... But the really, really simplest first thing is just like words, right, blocking any messages that have certain words that aren't from a contact because we have the roster. It's very easy to say, okay, as soon as they're on the roster don't block them, I want to get all their messages and if they're not on the roster and this is a thing that's supported in ModFirewall so it's not like hypothetical, it's very easy. And as soon as they're not on the... They can be very aggressive, right, with people who aren't on your roster because they... If they get a message back that says, oh, you blocked for spam they can just rephrase to something simpler and say like, hello, I'm not a spammer, please add me or something, right? So, I mean, a lot of the spam things now say things like spam in the spam or they'll say advert or promo or the word advert in Russian. Well, saying everything in Russian is going to get us in trouble someday but I specifically have a pattern for the word advert in Russian because I see that in a lot of the Russian spam, that word and even just the names of the bot networks, XSNDR is one of the big ones, they will often put their own name of their bot network in the spam and just those like five patterns block in my experience like 70% of the spam which is not perfect, it doesn't get us where we want to be but it can often take an unusable account and make it at least usable again, right? It's a good first step, I've found, I don't know. So, I'm curious, does anyone here know what the Debian XMPP server runs? Let me clarify, like, does anyone know how it's configured? So, like, is there any anti-spam on it or like, I just want to get a sense of the problem space, right? So, am I making any sense? It's been my impression that there's basically, I mean, it depends on what you consider anti-spam tactics, so Dialback is standard on basically every XMPP server and a lot of them, I think, I don't know if Debian is requiring TLS on server to server now but probably they are, you don't know, yeah. I don't know, those are both things that help but they don't help very much anymore against the new kind of spam, right? Those are the two things that protected us for the last 20 years but the reason we have a problem now is because there's suddenly no longer sufficient. So, I've just logged into the server. It runs ProCity. Yeah, we can just read the config file right now. I guess in a sense it's a good thing that it could be interpreted as a good thing that we have a bigger spam problem now. Well, definitely, because someone is interested. Someone thinks there are enough XMPP users to bother advertising to them. I'm actually quite happy but... So that's all the modules that you have but those are all... So, blocking is enabled. So that's like the base level but that's on a per user, right? So each user has to block the spimmers one by one. It doesn't, so that's something but it doesn't... It doesn't scale at all. Although if people on your server have been... If anyone on the server has been doing that you can look in the data for what has been blocked already and maybe seed a blacklist with at least that and say, okay, these look like spammers that people have already blocked. I don't know. It's a thing you might look at. So just looking at how we get access to this who is not a Debian developer here? Yeah. So even if you're not a Debian developer you can get a guest account on Alioth. Who has a guest account on Alioth? And once you have the... And you can just register for that by yourself and it only takes a minute. Once you have that, you can then ask for permission to access this server if you want to help the RTC team to review it or extend it. We can also collaborate over the email list or IRC or maybe we can get this configuration into Git. We have to check with DSA. I think they are doing some things with Git. Is anyone familiar with that? Okay. So that could be a way to get people more involved in managing this. I was involved in setting it up but my primary activity is development so I'm not actively checking on this every day. So I would love to have some extra help to look after the XMPP side of the problem. We actually have multiple services. We have SIP. We have WebRTC which is based on SIP and we have XMPP. Another thing that could help is if someone was willing to volunteer to be a coordinator for XMPP and possibly having someone volunteering to be a coordinator for the operational side of these services so that some of us will focus on the packaging and upstream development and other people would focus on the operational issues. So these are... Just the microphone? The microphone, yeah. So I would volunteer but not alone. So there should be more people so that also in emergencies there is always someone who can help even if I'm not available. Okay. I think... Isn't Victor also involved? Yes. He's a maintainer as well. But is he involved in the administration side also? He has been. But this is something we need to explore because in any organization it's good to have one person who is the contact even if they take holidays sometimes even if they don't actually do everything themselves at least they know who to contact because for me I'm spreading myself too thin if I try to manage all these things. So it would be really good to have someone who volunteers to stay on top of prosody and that if no one else answers that person sort of jumps in and so on. I could do that. I'm personally very much interested that the service does work and runs. Okay. That would be great. And then if you could check with Victor what his role is if he's interested in the operational side or only the packaging side. So let's talk the details later then and then the RTC mailing list or RTC IRC. Yes. Just looking at the lists that we have so this is on the Wiki. So every team has a page on the Debian Wiki so the RTC team has this page and we have a lot of links. This is the WebRTC portal. This is our Alioth project. This is some documentation about how to set up different soft phones with the services with both SIP and XMPP. Anybody can add to the documentation. Here we have an FAQ which is on the Wiki as well and we have a couple of mailing lists. The Debian-RTC list is intended for the users to ask questions so other Debian developers who rely on the service and the other list the Debian RTC admin was intended for discussions between the admins of the XMPP and the SIP and so on but we can have those discussions on the Debian-RTC list as well because it's not so busy but if we're having a lot of those discussions it might be better to have that on this other list on Alioth. There's also a bug tracker for issues with the service itself. These are things we need to enable in the services both SIP and XMPP. There are a lot of different things there some of them are wish list items so anybody can volunteer to help with any of these things whether you're a developer or not in fact a lot of people get involved with things like this before they become a developer. Are any of the other developers here familiar with sponsoring someone for access to the porting machines? So there's a wiki about this that we can request accounts for people who we know who are helping to organize things so if that's necessary we can do that and the other possibility is that if we can get the configuration files into Git then people will be able to collaborate through there possibly without having machine access to see the prosody configuration. Does that sound like a reasonable way forward? Is there anything besides the prosody configuration on that machine? I would assume no, right? There is a turn server so if people want to make voice and video calls with XMPP or SIP or TTC they can all use the turn server the same credentials for all of them so that is related to it but it's not a dependency for chat it's only for voice and video. So I guess what I'm asking is like how much stuff has to be put into Git it would seem like just a readme that says install prosody install whatever turn server package we use and then copy two configuration files into such Etsy and you have a recreation of the setup is that right? The prosody configuration file itself should probably be in a repository so that when we change it we put the changes through Git That's what I was saying and then for the turn server there's a return server.config so that's another text file that could go into version control so there's not a lot there So after the spam issue are there any other issues that anyone would really like to ask about today? I have these three things on my wishlist about the XMPP so one was spam, spam and the others were that we installed Bibumi, the IRC gateway so I'm just now on the IRC using a Bibumi instance of another XMPP server and the third thing is plus the enable HTTP upload on our server, that's it So those two things could be tracked through the issue tracker so you could put those in here as wish list items and those are things I think you could probably discuss with Victor about the ongoing sort of operational support for the processes the DSA have given access for people who manage the server to modify those configuration files so they manage the system itself at a platform level but we can manage the ProCity.CFG we can restart that process ourselves we can check the log files without going to DSA so you should be able to do things like enabling modules quite easily within the team So just while you're on the topic of IRC Wookie asked me if he could join via IRC Has anyone seen him in the IRC channel? Okay Wookie says I'm interested in the possibility of using RTC for better remote conference attendance experience Okay So let's try that Let's try and get the RTC also volunteered to help with the RTC services which is great Okay So does Wookie want to try calling in? Wookie Well, you try to go in Please Yeah And if your account is not active because of your password change you can try freephonebox.net and then you can dial us anonymously So we just give him a few moments to dial to the WebRTC Yeah Did he comment? Yeah Freephonebox.net And when he gets there he can dial Pocock at Debian.org On the freephonebox.net So you were able to log in here but it's which browser I'll just wait for the microphone Okay So we have a call Hello Can you dial again with the webcam button? So that's latency from the streaming coming back through his WebRTC So on the IRC just ask him to click the webcam button when he dials So not this button but this button So this one is audio only And I will instead of this is for audio, this button and this button is for video He's clicked the right one this time Okay Can you turn off the audio from the live streaming? Wookie? Let me just check my audio Wookie? Can you hear me? Are you there? Okay, we don't hear you Can you check your if you're looking at the live stream can you check your microphone is not down here but if you can put it up here like this If you can If you can let him know on the IRC that we don't hear him Okay So we had this problem with the demo on Saturday as well So we have to check if this is a browser issue if it's my laptop if it's the other person But these are the types of little things that we have to deal with from time to time So I think he just changed something Okay, so Yeah, I can hear some feedback coming now just very gently building up so I don't know if he changed something or if it's on my end Can you hear me through your headphones? Okay Maybe we stop the call now Does someone else in the room want to try this? Okay Bye, Wookie Okay Okay This could also be the bandwidth issue here Does anyone else want to try Do you want to try calling me? Okay If you try freephonebox.net Who else has a recent Firefox or Chromium on their laptop? Using the latest version is a good idea Yes, who's that? Hello Are you on the IRC? Can you say something? Do you have the microphone there? So we try again with Do you want to try now? Pocock at No, you want to go to the freephonebox.net I'm just curious if any of the issues are bandwidth related because if it's bandwidth then this this will work through the LAN or through the Wi-Fi locally Pocock at Debian.org And the turn server is better than nothing but it's not perfect It does not get us through every NAT Okay You have to open the webcam Is it all the way? Do you see yourself? Hello So we can hear you from your desk to my desk Okay So we have one successful demonstration of the service today Thank you, Oveka Twice or more Yes So it could well be that there's a limit on the bandwidth going through the connection into the building or it could also be a NAT issue in the building but we can't be sure and it could still be that other people have different browsers Oveka has only just installed the latest update of Stretch like two days ago So everything on her laptop is the same as mine So I can't say what everyone else is running when we've done tests with them but it makes a difference having the latest browser Who has tried JitsiMeet? So the JitsiMeet is very easy to use We just go to meet.jit.si We actually create a URL So everyone who's watching can try to join this at the same time meet.jit.si slash debconf17test So if everybody goes to the same URL then we should all see each other Did you try? I'm not sure if it is case sensitive Oh no, you can Can you see me? Try changing it So it's a very good question So Wookie asked whether why would audio not work while video works if the problem is bandwidth Yes, all that as well So there might be also other problems maybe codecs or I don't know All browsers have to support the opus codec So it's not a simple question of not supporting the codec But with the video you'll notice that sometimes when it's very bad it stops and we just see it updating every second or every few seconds like the video almost freezes but with audio you just don't hear anything sometimes Audio should use less bandwidth than the video but we need to check this problem some more So we might do this after the session finishes So how many people have we got in the jitzi meet? So with the jitzi meet this is an alternative it's not hosted by Debian but the jitzi developers are very keen on Debian and I think they run Debian themselves So this is something that people can use for multi-way video calling sessions There's also some effort underway to package jitzi meet So some of the low level Java dependencies have been packaged now Ervika is working on the first package and has been studying this Pranav who was in Google Summer of Code has also been looking at some of those packages So if anyone wants to volunteer for Java packaging then jitzi meet would be a very exciting package to create So does anyone else have any final questions before we wrap up? Okay, well thanks everybody for coming and thanks for the remote participants if you can still see me So let's wrap up and go to lunch