The debian.org SIP service has been active for over a year and the fedrtc.org service for Fedora is actively being evaluated[1] and will hopefully be adopted as official Fedora infrastructure.
Can anybody think of other communities that would run this solution? Would FSF Europe like to play an active role in engaging other communities to try this now that we have a way forward to replace Skype?
RTC Quick Start guide[2] documents everything that has been done in the debian.org and fedrtc.org sites and is a blueprint for anybody who wants to replicate this.
Two common points of concern when I discuss it with system administrators: a) they don't want to run an Asterisk instance because they tried it once already and realized they don't have time to learn and support a whole PBX b) softphones on Linux frequently have NAT problems and one-way-audio problems and this makes many complaints and time wasted and a bad impression of the service
The solution chosen for debian.org and fedrtc.org is not a full Asterisk, it is just a SIP proxy, so that resolves the first problem. WebRTC and TURN have advanced NAT traversal capabilities and all the logic is in the browser, the server (and administrator) are not responsible for troubleshooting a million complaints about NAT, that resolves the second problem.
1. https://lists.fedoraproject.org/pipermail/infrastructure/2015-May/016245.htm...
Don't forget the TOX project (no servers, all encrypted data, audio&video, chat, chatroom multi-audio, many plateforms, ...) : http://tox.im
Tested with qTox interface and uTox interface. QTox is very recommended by me for the moment (more stable with video flux).
Librement
Le 31/05/2015 10:21, Daniel Pocock a écrit :
The debian.org SIP service has been active for over a year and the fedrtc.org service for Fedora is actively being evaluated[1] and will hopefully be adopted as official Fedora infrastructure.
Can anybody think of other communities that would run this solution? Would FSF Europe like to play an active role in engaging other communities to try this now that we have a way forward to replace Skype?
RTC Quick Start guide[2] documents everything that has been done in the debian.org and fedrtc.org sites and is a blueprint for anybody who wants to replicate this.
Two common points of concern when I discuss it with system administrators: a) they don't want to run an Asterisk instance because they tried it once already and realized they don't have time to learn and support a whole PBX b) softphones on Linux frequently have NAT problems and one-way-audio problems and this makes many complaints and time wasted and a bad impression of the service
The solution chosen for debian.org and fedrtc.org is not a full Asterisk, it is just a SIP proxy, so that resolves the first problem. WebRTC and TURN have advanced NAT traversal capabilities and all the logic is in the browser, the server (and administrator) are not responsible for troubleshooting a million complaints about NAT, that resolves the second problem.
https://lists.fedoraproject.org/pipermail/infrastructure/2015-May/016245.htm...
Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
On 31/05/15 12:12, cyberesprit wrote:
Don't forget the TOX project (no servers, all encrypted data,
"no servers" is not accurate. The DHT Nodes are effectively like servers in SIP or XMPP networks:
audio&video, chat, chatroom multi-audio, many plateforms, ...) : http://tox.im
Tested with qTox interface and uTox interface. QTox is very recommended by me for the moment (more stable with video flux).
While there are several interesting solutions like this (TextSecure was another example) they are not getting traction in organizations like large companies, universities or public bodies. SIP and XMPP may well be the only open solutions having the right profile to serve institutional needs.
There are also proprietary solutions trying to service those institutions: Microsoft Lync, Google Hangouts, vendors like Avaya offering products that claim to do SIP but only work with other products from their approved partners.
Sooner or later, I can imagine Facebook, LinkedIn and Salesforce all offering their users WebRTC too.
Just as Google dropped XMPP support, I doubt any of those vendors will be keen to enable federation or interact with open source clients if they can avoid it. The only thing that will make them consider remaining open is if some large organizations or public bodies do actually deploy standards-based SIP and XMPP.