On 12/11/15 02:03, Stephen John Smoogen wrote: > On 11 November 2015 at 16:38, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >>>>> What is the best way to proceed from here? Would anybody like to >>>>> have an IRC meeting to discuss it perhaps, or to have it on the >>>>> agenda at one of the weekly infrastructure meetings? Is there >>>>> anybody from the infrastructure team who would like to login to >>>>> the lab server where it runs now to get a feel for what is >>>>> running there? >>>> >>>> I think it would be great to discuss at a weekly meeting. >>>> >>>> Are you able to make those? >>> >>> >>> I was traveling last week, for the next couple of weeks I should be >>> able to join, but not tomorrow. I am on UTC+1 (Central Europe) so >>> attending earlier in the meeting is easier for me. >>> >>> Would you like to make this an agenda item for 19 November? >>> >>> We also went live with debian.org XMPP on Saturday, using Prosody. So >>> far it has been successful so we could also look at how to replicate >>> that on fedoraproject.org. Looks like Prosody is already in EPEL7: >>> https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/prosody.html >>> I've CC'd Robert (the package maintainer) and Matthew (Prosody project >>> leader). >>> >>> The TURN server (part of the existing fedrtc.org trial) can be shared >>> by XMPP users as well as serving SIP and WebRTC. >> >> >> I don't want to interject here but I've got some queries, well >> actually one query, which leads on to a bunch of questions. >> >> What's the current usage against fedrtc.org? >> >> I remember when we had "Fedora Talk", yes I am that old!, and it was >> never really used and was eventually shut down because the calls a >> week were in the single digits. As a contributor I don't really care >> for that sort of service, and since Fedora Talk I think the demand has >> declined, because I can use any number of other services for voice >> communication with other Fedora people, and I so use many different >> ones to communicate with various contributors all over the world >> dependent on location/ISP/timezone etc. >> > > Actually the calls were in single digits per month with a couple of > them just being test calls people would do to see if the service still > worked. Then we had a spammer connect to it and people getting > 'called' by it. That was pretty much the end of the call system. > > The usual questions with a 'phone' system is: > > 1) Who can I talk with? > 2) What do I need to use to talk with them? > 3) How do I NOT get called by people? > > The infrastructure issues are: > 1) What are the resource needs of the service (disk, cpu, network) > 2) What the authentication/authorization methods of the service (the > asterisk used plain text passwords and while people were not supposed > to use their fedoraproject one most did) > > If the fedrtc.org system only connects Fedora people to Fedora people > it may not be too useful... if it would be more useful to consolidate > it with the Debian one as that would allow multiple floss to work with > each other. [And sorry if this is something that is obvious.. the > fedrtc.org timed out when I tried to get to it the first time and the > second time it kind of gave me some of the page.] > >> The concern I have, as an onlooker, that knows the load of the infra >> team because of the services they provide they're already snowed under >> but there's all sorts of implications, from resilience to security to >> maintenance, that a service such at this demands of the infra team, >> but I've seen no actual hard statistics for the actual usage that >> fedrtc.org gets to justify such an investment. I personally think >> that's needed and it can be presented on list if you can't make a >> meeting, might even be better for you to outline >> statistics/demands/requirements here first to save time. >> This is all valuable feedback but there are some big differences with Fedora Talk. Also, many of the concerns raised have been considered in the design. Fedora Talk was based on Asterisk. https://fedoraproject.org/wiki/Infrastructure/Asterisk Asterisk has lots of great features (voicemail, queues, etc) but it is mainly for voice, it emphasizes SIP and at the time it was also quite bad with IPv6, TLS and NAT. FedRTC.org is based on a SIP proxy, not Asterisk. SIP proxies (and XMPP servers) tend to have a much bigger emphasis on connectivity and they also tend to have less features, so they are easier to support. The repro SIP proxy has exceptionally good TLS and IPv6 support. Asterisk is not really optimized for federation but federation is quite easy with a SIP proxy because of the emphasis on connectivity. FedRTC.org also has a TURN server, this boosts success for people behind NAT. Times have changed too: - WebRTC is here, millions of users have WebRTC capable browsers. It is not just voice, it lets you do voice and video with just a little HTML. Have a look at the page source behind fedrtc.org to see what I mean. The only server-side scripting is the PHP for password creation. - Google is deprecating their standards-based XMPP. People wanting to continue talking to friends who use real XMPP are looking for alternatives. - Mobile: apps for mobile VoIP, video and messaging are everywhere. Open source apps like Lumicall (for SIP) and Conversations (for XMPP) are trivial to install. I recently submitted a patch to K-9 Mail on Android so people can reply to any email with a SIP or XMPP call https://github.com/k9mail/k-9/pull/866 Android devices are, by their nature, optimized for making calls, so these apps tend to work a lot more intuitively than first generation desktop softphones. The service itself is not just for usage by developers, there are two other purposes it serves: - it gives people a stable point of reference for testing any softphones or chat applications packaged in Fedora. - it it useful for demonstrations. I demonstrated federated calling between FedRTC.org and rtc.debian.org in several talks, including the Debian and Ubuntu Community Conference (DUCC) in Milan earlier this year. Actual stats: 26 people have tried the service so far. In Debian, we have had over 200 people (about 25% of developers). FedRTC.org has not been promoted as an official service so I think it is reasonable to suggest usage will increase if it becomes officially supported and if XMPP is part of it too. The query about passwords: making it an official service, we could probably find some way to validate the passwords people choose to make sure it doesn't match their normal FAS password. SIP also supports certificates, I documented it for Jitsi: http://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi Interaction with other communities is another big drawcard. There are various others doing it: Debian (both SIP and XMPP), GNOME (XMPP) and FSFE (XMPP). The Lumicall app allows anybody to create a SIP account based on their phone number and FedRTC.org users can call Lumicall users and vice-versa. Both the SIP and XMPP services have been built for secure federation. Some developers already run their own private XMPP servers and will be happy to talk to people who have a fedoraproject.org XMPP address. I understand the concern about this potentially creating extra work for the infrastructure team. In Debian, we didn't want the service to become a burden on the DSA team and so we created a dedicated RTC team to handle issues specific to the services. https://wiki.debian.org/Teams/RTC The DSA team only have to worry about keeping the machines running, backups, package updates and dumping some data from LDAP into the files we need. The RTC team test and propose changes to the configuration files and engage in discussion with users. The lightweight nature of the services (a SIP proxy rather than a full Asterisk server) also reduces the support burden. It is worth considering some of the other benefits too: - developers and other community members who decide to use a fedoraproject.org SIP and XMPP address will start building buddy lists using those accounts and this becomes another facet of the community experience, strengthening the sense of belonging that people have. - the fact that open solutions like SIP and XMPP are not as universal as things like email right now means it is a space for leadership. Linux distributions, like Fedora and Debian, have traditionally been leaders in the IT industry and this is a great way to show the reliable and flexible communications solutions can be built with open source and open standards. _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
