fedrtc.org -> infrastructure?

[Daniel Pocock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 22/05/15 16:21, Kevin Fenzi wrote:
> On Tue, 19 May 2015 13:45:39 +0200 Daniel Pocock
> <daniel at pocock.pro> wrote:
> 
>> 
>> 
>> Hi all,
>> 
>> At some point, it would be good to see fedrtc.org migrate to
>> Fedora infrastructure and use the fedoraproject.org domain
> 
> Possibly. ;)
> 
> Do you have any stats on usage since you announced it? I worry that
> we would get it all up and running and no one would use it. ;(
> 

After the recent blog, about 12 people linked their FAS user IDs.  I
don't have any other stats on how many minutes of calls they make.  It
has only been promoted in one blog so far, I could probably do more to
promote it.  Maybe if there was some announcement email calling it an
official trial more people may sign up, even though there should not
be any risk, people may even be reluctant to use the OpenID thing
knowing that it is not on official infrastructure.


>> I'd be happy to submit the full request for resources[1] but I
>> just want to see if there is any initial comment on it.  Here is
>> a list of what is involved:
>> 
>> - it uses a PostgreSQL database schema[2]
>> 
>> - it requires some DNS entries (SRV and NAPTR), examples[3]
>> 
>> - it needs a TLS cert for fedoraproject.org on the host(s) where
>> it runs
> 
> Those are all easy. ;)
> 
>> - it has static HTTP content and PHP that is currently hosted
>> with all but one problem[4] on a RHEL7 httpd.  Content is in
>> Github[5], it could be presented as an RPM if necessary.
> 
> I'm not too crazy about PHP. Would it be hard/possible to re-write 
> things in something else? say flask?
> 

I've been doing stuff with flask recently, I have no objections to
that.  The main features of the code are the FAS OpenID integration,
running a PostgreSQL query and doing some HMAC stuff.  All of those
things can be done in Python.

Do you have any example of how you implement flask applications (or
any other frameworks you support) for your hosting environment?  I
have only ever used flask for trivial stuff running in my dev
environment, e.g.

https://github.com/dpocock/github-icalendar
https://github.com/dpocock/nagios-icalendar

> Is this a common codebase used by the other projects that run
> this?
> 


It is basically the php-OpenID sample code with a PostgreSQL INSERT
after the user logs in.

We could probably find a Python OpenID sample, import psycopg2 and get
the same result.


>> - all packages are in EPEL7, except: cajun-json in EPEL6, in
>> testing for EPEL7 resiprocate in Fedora, builds from SRPM on
>> RHEL7
>> 
>> - the SIP proxy is a single daemon, managed by systemctl.  All 
>> settings in a single file, /etc/repro/repro.config
>> 
>> - the TURN server process is also a single daemon, managed by 
>> systemctl. All settings in a single file,
>> /etc/reTurn/reTurnServer.config
>> 
>> Just to clarify the scope of this: it is not a full telephony
>> service like Asterisk, just a SIP proxy and TURN server.  There
>> is no persistent state information (as there would be for
>> voicemail, email service, etc) and no customized routing.
> 
> Yeah, thats nice. ;)
> 
> Some really dumb questions:
> 
> * This does jabber/XMPP?

The TURN server can be used by XMPP clients to do voice and video
through NAT.  Running a reTurn instance kills three birds with one
stone: SIP, XMPP and WebRTC

Currently, fedrtc.org has a SIP proxy but no XMPP server.

Running an XMPP server would be an extra step.  The Prosody project
leader, Matthew Wild (on CC), has been very supportive of deployments
for free software communities, e.g. he wrote this module explicitly to
help us use a common user database for SIP, TURN and XMPP on
rtc.debian.org:

https://code.google.com/p/prosody-modules/wiki/mod_auth_ha1

and it is just as valid for a Fedora deployment.  It is not hard to
get Prosody running.

There is one catch: if we run XMPP on fedrtc.org, even temporarily,
then people will have to go through the pain of migrating buddy lists
to the fedoraproject.org domain.  Maybe it is better to just run that
on fedoraproject.org from the beginning, whenever you are happy to run it.


> 
> * How about video/webrtc? with multiple people? or just person to 
> person?
> 

Yes, it supports video.  As it is a SIP proxy, it doesn't actually
know about what is inside the streams or message bodies (voice, video,
text messaging).  SIP proxies just provide a way to relay things
between endpoints.  The SIP proxy also doesn't care about things like
codecs and transcoding, that makes the proxy easier to administer and
scale, but it means that the clients have to have common capabilities.

Multi-party communication is also supported by the endpoints or by
running a conference server.  E.g. somebody can run a private Asterisk
instance on their user at fedrtc.org address and other people call them
and join their personal conference.  The SIP proxy doesn't know or
care, it just connects callers to the address they specify.

In a later stage, Fedora could choose to run a dedicated conference
server, that would be something else to administer though.  My
recommendation is just start with the lightweight SIP proxy for some
months and see if people volunteer to run services like conferencing
on their own infrastructure.

> * What are the common use cases you have seen people use it for?
> 

Some Debian Developers have tried interviewing GSoC students using
WebRTC.  It is important to show the students, from their very first
contact with our projects, that we don't depend on any proprietary
stuff like Skype or WhatsApp.

Another use case is testing the various SIP packages (GNOME Empathy,
Linphone, etc).  If we want people to take these things seriously we
have to be able to show that we can run them in our own communities,
even if IRC and mailing lists are the preferred means of communication.

Another use case is demonstrating federation.  There was a demo at a
conference recently, a debian.org user calling a fedrtc.org user with
WebRTC.


>> Ongoing maintenance requirements: - TLS certificate renewals -
>> monitoring the ports - package updates from time to time
>> 
>> It currently runs on a lab machine, I'd be happy to arrange SSH
>> access to the Fedora Infrastructure team to see exactly what is
>> involved and verify that it is manageable.
>> 
>> Regards,
>> 
>> Daniel
> 
> Thanks for working on this. I find it definitely interesting... i
> just want to make sure we have enough use cases and people who
> would use it before we commit to running it.
> 


Understood - I'm happy for it to continue on my server for now, but if
you email me your ssh key in a GPG signed email I'll let you log in
and look over it.

Regards,

Daniel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVac1TAAoJEOm1uwJp1aqDMuUP/i1ks4nNGYXRTfrBv60MfzDe
FOJL/Nu9bUqTHz9qSpZsbQYufso44BHT9E+Niazo4212G7Gq7eEaSHDjwoIOjBR3
HCcNaQdawPiphyF8HGbTd2KzL5DVFdlk6aZ1ce3+k49wE7KUL/V6oNCIlFulCMAL
G6HNDczFc+gwPFJtWFmObIzyB3aWfPiJt0irt3PauJAfEJpSAfxRW/uPGP5I9jiR
zjQY/Ik26JLGWzharrbTMm61Op0HeRYvFodtAJWlbsBvkuhDrTZkmi8YEh4OzGIu
Ue0Tfe+LnBtCPOvHUfJErWbo6LYJlNE0uJrzIeyeoDJGQpr6anDbvoeRZC/uagTk
pIZY27bFQuG3MxielyQJ/rogsanvJrdASxcKvR4kb9hCg4z5hqI3se6D8y5oR/Tg
Hp5G9kIR/T0vEVvrXU/jxvbZy9WJRG8h9yPbe77Y/4ODisxblVaNuhuBKu0mqRHy
NrJfXPX+xE91E4G++w9aDkOFkb3jb+gM0Qv+w5u+8LCi/ptJllixMTHaFzgq0rjN
grnqpFQlMJfz7VWSxaGLdpOYtMfdmXAkg0ArAK5WYDBo0P+y04amY27ZEyCr6Bk4
nfxZ4VvhyfV9JuHPfo2YJD7PaLQ5FWaGuqLyvtKCnGoeWK45ks0Oef2hlHhj8qYe
2qaj1x6pOBnfwb1PHz6T
=1hu4
-----END PGP SIGNATURE-----