FedRTC.org SIP and XMPP service - help needed

Daniel Pocock daniel at pocock.pro
Fri Nov 13 08:19:19 UTC 2015



On 13/11/15 00:00, Jared K. Smith wrote:
> 
> On Thu, Nov 12, 2015 at 2:36 PM, Daniel Pocock <daniel at pocock.pro
> <mailto:daniel at pocock.pro>> wrote:
> 
>     I've been looking at ways to expand on the fedrtc.org
>     <http://fedrtc.org> service and would
>     like to start creating a team around the service just as we did in
>     Debian[1].
> 
> 
> 
> Ordinarily I'd probably be the first to encourage this, but having done
> a lot of the work to setup Fedora Talk many years ago, I'm not sure this
> is a good fit for Fedora Infrastructure.  Why?  Because with Fedora
> Talk, we saw that the service wasn't used very much, and while the
> maintenance burden on the Infra team wasn't big, it was still one more
> thing they had to worry about, and something that the didn't feed 100%
> confident in administering.  Do you have any statistics on how much the
> service is being used by Fedora contributors?
> 


I replied to those same queries on the infrastructure mailing list[1]
and I've largely copied the reply.

Some key things to remember when comparing statistics for debian.org and
fedrtc.org:
a) debian.org also has XMPP, this engages more people.  I didn't offer
XMPP on fedrtc.org because it will be inconvenient for people to move
their buddy lists to fedoraproject.org
b) debian.org runs it as an official service, it has been announced in
the newsletter and debian-devel-announce mailing list and other places
over a period of almost 2 years now.

I've also started a separate thread on the infrastructure list with an
alternative hosting solution[2]

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.

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.

- it improves our posture when talking to people outside the community.
 For example, several GSoC mentors used rtc.debian.org for interviewing
students.  It shows the students (and anybody else we come into contact
with) that we are serious about using free software to build free
software and that we aren't at the mercy of Skype or Google Hangouts.


1.
https://lists.fedoraproject.org/archives/list/infrastructure%40lists.fedoraproject.org/message/PJNH4JME7MNBXMZHGZS4SGTOEFFKWE4K/

2.
https://lists.fedoraproject.org/archives/list/infrastructure%40lists.fedoraproject.org/thread/BJQ4U27FTZ52D6WFP555L5ROEZCTE5GJ/


More information about the devel mailing list