Hi all,
At some point, it would be good to see fedrtc.org migrate to Fedora infrastructure and use the fedoraproject.org domain
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
- 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.
- 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.
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
1. https://fedoraproject.org/wiki/Request_For_Resources
2. https://github.com/resiprocate/resiprocate/blob/master/repro/create_postgres...
3. http://rtcquickstart.org/guide/multi/dns.html
On Tue, 19 May 2015 13:45:39 +0200 Daniel Pocock daniel@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. ;(
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?
Is this a common codebase used by the other projects that run this?
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?
* How about video/webrtc? with multiple people? or just person to person?
* What are the common use cases you have seen people use it for?
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.
kevin
-----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@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@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
Le samedi 30 mai 2015 à 16:46 +0200, Daniel Pocock a écrit :
- 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.
Could it also be used the way some use Google Hangouts: to film a talk at a conference, and live-stream it on a web page somewhere?
On 30/05/15 17:57, Mathieu Bridon wrote:
Le samedi 30 mai 2015 à 16:46 +0200, Daniel Pocock a écrit :
- 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.
Could it also be used the way some use Google Hangouts: to film a talk at a conference, and live-stream it on a web page somewhere?
Yes, you could use SIP or XMPP to get the stream to some server with bandwidth to multicast it or serve many simultaneous viewers.
For unidirectional streaming you don't necessarily need SIP or WebRTC though. WebRTC is helpful because it can get the stream through NAT and firewalls though.
It could also facilitate remote participation at events like Flock, e.g. for people watching the stream remotely to ask questions. This might require some more effort from the team managing the video, but the SIP solution will provide a foundation for them to do that when they are ready.
Regards,
Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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@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@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
_______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
_______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject....
-----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@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:
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@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
_______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
_______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject....
On Thu, 22 Oct 2015 19:47:06 +0200 Daniel Pocock daniel@pocock.pro wrote:
-----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.
ok.
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?
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 30/10/15 18:48, Kevin Fenzi wrote:
On Thu, 22 Oct 2015 19:47:06 +0200 Daniel Pocock daniel@pocock.pro wrote:
-----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.
ok.
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.
Regards,
Daniel
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.
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.
Peter
On 11 November 2015 at 16:38, Peter Robinson pbrobinson@gmail.com 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.
Peter _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
On 12/11/15 02:03, Stephen John Smoogen wrote:
On 11 November 2015 at 16:38, Peter Robinson pbrobinson@gmail.com 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:
- Who can I talk with?
- What do I need to use to talk with them?
- How do I NOT get called by people?
The infrastructure issues are:
- What are the resource needs of the service (disk, cpu, network)
- 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.
On Wed, 11 Nov 2015 22:57:48 +0100 Daniel Pocock daniel@pocock.pro wrote:
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?
Sure. works for me.
kevin
infrastructure@lists.fedoraproject.org
-
Daniel Pocock -
Kevin Fenzi -
Mathieu Bridon -
Peter Robinson -
Stephen John Smoogen