-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 reSIProcate 1.10.0 was finally released and the packages have now arrived in EPEL7, that means everything needed for this is now in EPEL or RHEL itself. I've been thinking about the domain and I really feel that users will have to use their full fedoraproject.org addresses rather than fedrtc.org addresses. The reason for this is that people will be able to "Dial" in reply to an email or use addresses that they have already saved in their contact list. 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? On 21/09/15 20:37, Daniel Pocock wrote: > > > > Just following up on this - given everybody is talking about the > Skype outage (if they are able to talk to anybody that is), it > seems like an opportune time to mention that FedRTC.org running on > (RHEL|CentOS)+EPEL7 is just fine. > > The reSIProcate 1.10.0~beta2 from Friday will probably be released > this week and I will make it available in both F23 and EPEL7. If > there is anything else we can do upstream to make this more > attractive/supportable for Fedora infrastructure then please let me > know. > > Regards, > > Daniel > > > On 30/05/15 16:46, Daniel Pocock wrote: > > >> On 22/05/15 16:21, Kevin Fenzi wrote: >>> On Tue, 19 May 2015 13:45:39 +0200 Daniel Pocock >>> <daniel@xxxxxxxxxx> 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@xxxxxxxxxx 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 > >> _______________________________________________ infrastructure >> mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/infrastructure > > _______________________________________________ infrastructure > mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/postorius/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWKSEaAAoJEOm1uwJp1aqDACcP/1lrdoXlpIhZmNoByO355Er8 L9XKhFVN16uga8hFreDQBD6zBsZlZeorfRVc4htTm2ZyI5JKTrsSTq5yii3fdHW/ 9IBBQelU6muhrKSMraVXgF8dggrn3bN67s2CLzo8K+ugDvqzVAf03zhKEizmmxYc wWLXczcdSjRQcq4yOVsGiDMXjCdl+mt7TCIGYworXiZc76CbmSVewbtCDVT8oCC7 l1ltNs6rTsOjLM+Hc3RRcn9c2MqJCeaYzZGXZ13nlCCZ5zhijvdEnYnBBzM2TSUu QEzTJcoFooBdc6snidwElT+gCUpM7JvN67qKpGFFUK1OtjKgXBjWOm2elFJyBu8S gNrr2UkW+4A7VoIIu+RDIgkaCZngbQdwDPmz3m4BD7CRGsxlJ5jCDPFDz2VJVOaT 6XGT0bkTLP5S0HQdxLz0Sy6WDefH6yxSEqCnCil+MJDlY1js36W3fe2j6GNzNAff AUjO+W7QHi5eEp+bP6q7iITgMrY0cfMjfYFtxhECd60tmWs/lRml12Fh+oqRpfAf aEC2gUxbUd6zW6lxFMtaYQ2+lVw8pESNRoEtISEh6kpI6XifriLQthU9XWveYUpW QZ1DIBAJZb4pzx5KC3jFA+F5qhLakAOPN/mql60YzTz7iCzGe6hcn72g+irncT2/ rHR5rVnTxi8hvQ+FlQlG =/FdB -----END PGP SIGNATURE----- _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
