It has been some time. I come back from the shadows to announce the release of Ring-KDE 3.0.0, A GNU Ring.cx client. GNU Ring is a secure and distributed communication platform based on open standards. It weaves industry standard technologies to work together and provides audio calls, video conferences, chat, screen sharing and peer to peer file transfer between you and your friends. Additionally, its use of open standards allows to bridge to various other systems like the main phone network or SIP compatible devices.

When joining the GNU Ring, no servers or centralized accounts are needed. Beside an optional blockchain-based way to reserve your username against takeover, nothing leaves your device. All your data is kept under your control. Ring-KDE provides a simple wizard to help you create credentials or import your personal information from other devices.

This release is a full rewrite of the application to use more modern technologies such as touch support, QtQuick2 and KDE Kirigami adaptive widget framework. The old Ring-KDE was a fork of an older KDE application called SFLPhone. At the time, it was focused on being a office phone replacement for your KDE desktop instead of being a more generic multimedia communication software.

The screenshots below show the old SFLPhone/Ring-KDE 2.x versus Ring-KDE 3.0.0:

This blog entry wont try to list every single change from the 2.x series because
that’s too much amazement for a single post. A more useful introduction is how to use it.

Ring 2.x and the older SFLPhone versions used mostly the history and address book to select who to call. This made sense for a phone, but the newly expanded scope changes this. While they are both still available, from now on, the user interface is based on the timeline concept:

Version 3.x also has better support for video, screen sharing and file streaming.

Most relevant audio call features have been ported to the new application including multi-call support, hold, recording and notifications:

The basic chat support has been replaced with an integrated timeline that contains all the calls, chat messages, video capture, recordings and eventually file transfer and images.

Navigation has been revamped and is now using a search box as the primary way of finding your friends. It uses locally stored data to avoid uploading too much potentially private information to the cloud. Only looking for registered user names normally uses the internet. It is optionally possible to download this information locally, but it uses more disk, CPU and network resources to keep up-to-date.

In the immediate future, the next few versions will try to fix bug, improve performance and catch up with recent improvements to Kirigami2, KDE own touch-friendly set of widgets and application design guidelines. Since beginning to work on Ring-KDE 3, Kirigami has made great progress, but Ring-KDE 3.0 still mostly reflects the state of the art from a year ago.

Download:

Ring-KDE can be built from source if the ring-daemon is also built from source. The source code for Ring-KDE 3.0.0 can be downloaded here.

To use the AppImage, download it, right click, choose Properties -> Permissions and check “is executable”, Then open the file. When using the AppImage, no other dependencies are required. If you also have another GNU Ring.cx like the Gnome client, please close it and run “killall dring” before executing the AppImage to avoid conflicts between the two versions.

This post is about how Ring ( http://www.ring.cx ) and its KDE client ( named, umm, Ring-KDE, formally known as SFLPhone-KDE ) work. Ring is a communication platform built on open standards aiming for maximum compatibility with the existing software and hardware infrastructure while providing a secure and distributed architecture. First of all, a little bit of background information and terminology:

* Centralized service: A service where all request pass through a single entity. Such services include Skype, Facebook and Google Hangout. While it is possible to implement client to client encryption with Diffie-Hellman on top of the service, the vast majority don’t and use term of services to notify the user about how they decide to use your personal information.

* Federated service: A service where different provider can setup their own node and communicate with each other. This include DNS, HTTP, Jabber/XMPP, Diaspora and emails. Their still require some “fix” components and infrastructure to locate and communicate with each others. All the data is often seen unencrypted by all the nodes involved if no additional security layer is implemented of top of the base protocol. You have to trust all nodes involved, something that is, in practice, impossible given the potentially infinite number of nodes.

* Decentralized: Each client is part of a cloud of “equal” clients. No centralized node is required. Order can be created momentarily out of the relative chaos and each clients are responsible to be “good citizen”. The most common “protocol” for this is called DHT (distributed hash table) The most well known example of this are recent Bittorrent clients, many scientific cluster software and some malwares. Privacy and security is left in the hand of each client and handled locally. Correctly implemented, only basic network metadata is being “leaked”. Even then, it is only available to your ISP.

Ring is able to work in all 3 of these modes. It’s predecessor, SFLphone, could only work on a centralized SIP and IAX2 server, multiple of them using built-in media mixing or direct IP to IP mode that required open ports on each side. Ring add a new type of account implementing secure SIP top of a DHT cloud. Given the project early state, there is little information about how everything works together and how Ring is different for emerging alternatives such as Tox or Bittorrent-Blink.

SIP (Session Initiation Protocol, RFC3261) was created in the 90’s by the IETF, the same comity responsible for most Internet standards. It share a lot of similarities with HTTP and emails. It is less or more the stateful equivalent of HTTP. SIP is a very large specification comprised on a master RFC (request for comments, the name used by the IETF for their standards) and multiple sub RFC to address individual use cases, such as file transfer (RFC5547), text messaging (RFC3428) or security. It also integrate with other IETF specifications such as TLS (RFC5646), ICE (RFC5245), UPnP (RFC6970), MIME (RFC2045), STUN (RFC5389), TURN (RFC5766), RTP (RFC3550), SDES (RFC4568) and many more. These day, even if the trend of using gigantic and complex protocols for stateful data synchronization faded (SOAP, UML, CORBA anyone?), SIP survived. It is the industry standard and is used by most VoIP product shipped today. It is also used in niche industrial use case to synchronize/negotiate streams and in some distributed networking products (like Ring-DHT!).

What is also notable is the sheer number of hardware that can interact with SIP. Any landline phone can be bridged to work with SIP using a cheap adepter of an online service. Most office hardware phones with ans RJ45 or Wifi equipped networking actually use SIP, so Ring can be a drop in replacement for these device while being integrated into your desktop and existing applications. For example, it can pause your music in Amarok when an incoming call arrive or you can click on phone numbers in KAddressBook or Firefox to place a call. With a good headphone with integrated microphone, you don’t even have to move to handles phone calls. But, there is more, remote communication is not all about phone calls anymore. Skype anyone? SFLphone was all about voice (and a little about video), Ring is all about communication, the media(s) are up to you!

But this introduce a new kind of issues: how do you connect all users? Historically, SIP was mostly used in client/server scenarios. While the protocol is very generic and very vast (for the better and worst), this was by far the most common mechanism. For one thing, this is how the Internet/Web usually work, and the landline phone/telegraph network before it. Then, for most “large” use cases, such as corporation and business VoIP, it make sense. The large and mighty IT departments of the pre BYOD movement also wanted a lot of control when it came to VoIP. While those case are still supported, Ring want something else: connecting people together.

While it can be done using a centralized server, like most competing product do, we also want it to be secure and distributed. This is why we are working on our layer under SIP to find and connect people. For this, we use the Distributed Hash Table (DHT) theory. You might not hard heard about it, but you may already use it. This is what power the Bitorrent MagnetLink technology and help finding peers. The “protocol” is quite simple. You first have to find a bootstrap node. This can come from an hardcoded list, a cache from previous sessions, a web server, tor are from your local network using MDNS or UPnP discovery. For now, Ring use a cache and an hardcoded DNS entry. An UPnP discoverability feature is partially implemented. You can then get a value out of the table. For this, you query the bootstrap node, that query more nodes, and so on until the value is found or a timeout is reached. You can put a value, where you send it to 8 nodes. You can also listen to specific key insertions and be notified asynchronously. The implementation is still a work in progress, but is already quite mature and has been proven reliable in medium sized deployments.

On top of the DHT layer, we add a security layer. This layer add public key infrastructure signing using TLS (eventually with TLS 1.3, this will provide forward secrecy too). Each “account” are in fact a pair of public/private keys created locally by the user, just like the keys you use to authenticate yourself when doing a git push. This is used to ensure that a client read a value that really come from the right source, not just someone hijacking the DHT key. To know if the source is right, Ring use a mix of public key infrastructure (signed certificate), certificate pinning (avoiding man in the middle a attack in subsequent communications with a self signed peer certificate) and other means of distribution, like inserting the certificate key in contact backends such as Akonadi[1], GMail, Evolution Data Server, a vCard folder, Apple Contact or Windows contacts.

When a user turn Ring on (with a DHT account enabled), it will start to listen to key inserted that correspond to its certificate public key. When it receive such information, it will match it to a know (or new) certificate. Depending on settings, it can tell the peer its IP address and start a peer to peer socket negotiation using ICE and UPnP. Obviously, this is like telling the world your IP address and opening ports: Not the best idea. To solve the “potential” security and privacy issues, Ring can be used in private mode. In this mode, it will only automatically answer requests from known/allowed certificates. For new person/certificates to be able to call you, they first have to perform a “trust request”. The same as you have with other products where someone has to ask first yo be in your friend list. This trust request come with a vCard containing the person profile. This can be used to insert this person into your contact backend such as Akonadi. This vCard can also be signed using a certificate authority to validate it. Currently, while in alpha, Ring is not using the private mode by default, but it can be enabled. We first want to test the DHT calling ability before enabling the full security stack. There is also some missing elements in the pipeline making it impractical for day to day usage for now.

Once you called someone or multiple people, you can create conferences, including between participants from landland phone, Ring-DHT users or a centralized SIP server. This works because the mixing is done client side. It is using your local CPU power instead of sending all the confidential information to a third party service. While not the most energy or bandwidth efficient way, this prevent your data from being sent in a black box. This is in line with the new User Data Manifesto 2.0 recently created with KDE as a founding signing organization.

Other interesting architectural information is that Ring is a collection of multiple projects. The most low level is the Ring daemon, a dbus service manage communications and connections. On top of that is LibRingClient, a Qt library I originally wrote for the KDE client and now shared by all Ring clients. It has all the analytic and notion of “people” added on top of the daemon. The daemon itself have no notion of person or people, it only handle the protocols and hardware. LibRingClient has recently moved from KDE infrastructure to the Ring one to reflect this change and avoid arising conflict of interest/cultural shock of the new contributors coming from non-KDE background. On top of that are native “thin” clients for Gnome, OS X, KDE and a Qt based client for Windows. The Gnome and OS X clients are binding less or more directly to QObject, QAbstractItemModel, signals and slots and so on. The very interesting fact about this is that it actually work and didn’t required a large effort to implement. Because of the new Qt5 C++11 features, Qt is now mostly compatible with these alien GUI toolkits! The reasons different clients are used is also for much deeper platform integration, such as the native contact abstraction, global keyboard shortcuts, accessibility and so on. While requiring a much larger effort to implement, they also provide a better user experience.

Ring is currently still in alpha stage. Before the first official stable release, the DHT negotiation protocol might still break in incompatible ways, bugs will be fixed and incomplete features, including security ones, will be completed. I hope this blog post help you understand what Ring is about and why you (hopefully) should use it.

One last note. Starting tomorrow, many KDE developers will join force in Randa, Switzerland to work toward a touch friendly future. While there is already many touch friendly Free Software, I don’t think there is anything as well integrated as what you can find in native desktop platforms such as KDE. This is true when it come to organization. The major mobile platforms lack major community working on a greater scope than a single or couple of applications. What made and make KDE different in the past, present and future is that we are one community working toward the creation of a complete and coherent software suite. Moving to mobile devices is, in my opinion, crucial to the fulfilment of a flly Free Software based phone ecosystem. Please consider to donate by clicking the banner below to make coding sprint like this one possible.

[1] Akonadi support has only recently been introduced to KF5, I have yet to re-enable it in Ring, I will as soon as some major distros actually ship with it. A vCard bridge is used to synchronize with KDE4 based KAddressBook for now.

]]>https://elv13.wordpress.com/2015/09/05/what-is-ring-and-how-it-works/feed/12Announcing Ring, a distributed and secure multimedia communication platformhttps://elv13.wordpress.com/2015/05/07/announcing-ring-a-distributed-and-secure-multimedia-communication-platform/
https://elv13.wordpress.com/2015/05/07/announcing-ring-a-distributed-and-secure-multimedia-communication-platform/#commentsThu, 07 May 2015 18:59:06 +0000http://elv13.wordpress.com/?p=85Savoir-faire Linux inc. and the SFLphone Development Team are very excited to announce the first public alpha release of a new voice, video and chat communication platform that requires no centralized server and leave the power of privacy in the hands of the user.
By adopting the same technology that is used by popular Torrent networks – Distributed Hash Tables (DHT) – this platform creates its own secure network over the Internet by which it can distribute directory functions, authentication and encryption across all systems connected to it – that’s why we call it Ring: http://ring.cx.

Just as SFLphone, Ring is also fully standard compliant and inter-operable with existing communication infrastructure such as most enterprise SIP phones and accounts. Some features that were part of SFLPhone-KDE are currently not available in Ring-KDE:

Akonadi integration is on hold until a KF5 enabled Akonadi version is released. As a workaround, using a shared vCard directory between Ring-KDE and the KDE4 version of Akonadi is possible.

The IAX2 protocol is not supported

The ZRTP encryption mechanism is no longer supported (please use TLS+SRTP)

Conferences, transfer and holding are known to be broken.

Translations are not fully re-integrated yet, this will be addressed soon

The KDE client is based upon SFLPhone-KDE and is now a KF5 application. The client now support the Ring-DHT distributed SIP communication cloud.

The client is now fully KF5 based

The Ring-DHT distributed communication cloud is now supported.

Better asset security awareness from top to bottom

The SIP negotiation code has been reworked for better standard compliance

Multiple dependencies including commoncpp/ucommon, ccrtp and zrtp have been replaced by LibAV

OpenSSL has been replaced by GnuTLS

The Ring daemon and LibRingClient have been ported to Windows and Mac OS X

An Evolution data server and a Mac OS X AddressBook contact backends has been developed for the Gnome and OS X clients respectively

If you wish to try this alpha version, to migrate from SFLPhone-KDE to Ring-KDE, it is recommended to re-configure each account manually. However, if you are adventurous, you can attempt to use the old configuration files directly:

To share vCards between Akonadi and Ring-KDE, please do:
(1) Open KAddressBook and File->New->Add Address Book
(2) Select “vCard directory”
(3) Select the “/home/your_user_name/.local/share/ring-kde/vCard” folder
(4) Press OK
It will now be possible to access and edit your contacts from KAddressBook. Again, this is a temporary workaround until a KF5 version of Akonadi is available (be it Akonadi-NG or a KD5 of Akonadi 1).

]]>https://elv13.wordpress.com/2015/05/07/announcing-ring-a-distributed-and-secure-multimedia-communication-platform/feed/9SFLPhone-KDE 1.4.0 released!https://elv13.wordpress.com/2014/07/18/sflphone-kde-1-4-0-released/
https://elv13.wordpress.com/2014/07/18/sflphone-kde-1-4-0-released/#commentsFri, 18 Jul 2014 22:24:55 +0000http://elv13.wordpress.com/?p=66Savoir-faire Linux is proud to announce the immediate availability of SFLPhone 1.4.0. This release finally enables video by default. We have refactored the video implementation to be much more robust against a variety of conditions and made the configuration more flexible. It is also now possible to stream a variety of file types and even share your screen. Other interesting features include support for the JACK audio system used by audio industry professionals and hobbyists. Thanks to improvements in audio buffering, latency and resampling, audio quality is noticeably better. The KDE client now has much better Akonadi support. It can now act as a KAddressBook replacement for most phone related scenarios. There will probably be one final KDE4 release before officially making the switch to KF5. The SFLPhone-KDE logic backend, libqtsflphone, has been compatible with Qt5 for over a year, some of the UI dialogs have yet to be ported. As for SFLPhone in general, we plan to merge work that has been done in parallel for a while now to make the daemon more modular, easier to build, more secure and more portable to other operating systems.

Please update or comment on this ticket to add user noticeable changes and new features

After almost a year of work, a new version of SFLPhone-KDE and SFLphone daemon are available. This version is a major rewrite intended to support Qt5 and QML technologies. This release also introduce some new features and improved usability and KDE integration. It doesn’t use KF5 yet, SFLPhone-KDE 1.3.0 is still a KDE4 application.

The next release should improve security configuration, further KF5 support. Windows / OSX support are also a possibility. Hopefully we will release on a more regular basis. Thanks to all beta testers for their feedback. Special thanks to Ákos, Martin, Tristan, Alex, Laurent, Emmanuel, Andrew and all translators. Without your contributions, this project would be a lot less stable. Please test, there is a lot of new code / features, feedback are needed.

SFLPhone-KDE 1.2.3 have been released today as a bug fix release 6 months after 1.2.2. This version is (hopefully) the last in the 1.2.* serie. The next generation (1.3) is under heavy development since the last release. According to git diff –stat, 1.3 branch have a massive 16000 lines of changes. It is also 10x faster, less memory hungry and usable (more on that in an upcoming blog post(s)). As for 1.2.3, the new features include macro support, new command line options and being able to be invoked from KaddressBook. Important bug fixes include compilation fix on Fedora 19 beta, prevent race condition when launching SFLPhone-KDE in autostart. On the daemon side, many bugs have been fixed there too. Overall, this release should be quite stable.

]]>https://elv13.wordpress.com/2013/06/14/sflphone-kde-1-2-3-released/feed/5SFLPhone KDE now have a macro subsystemhttps://elv13.wordpress.com/2013/02/06/sflphone-kde-now-have-a-macro-subsystem/
https://elv13.wordpress.com/2013/02/06/sflphone-kde-now-have-a-macro-subsystem/#respondWed, 06 Feb 2013 20:56:33 +0000http://elv13.wordpress.com/?p=23In a world where some people still communicate with each other using some sort of sounds, they will be happy to learn that SFLPhone KDE now have an awesome new feature: Macros. Does it free you from your daily conversations where you always end up saying that something being asked today can’t be ready by… yesterday? Not really, but that would be nice. What it does allow you to do is create a set of key sequences that can be called using keyboard shortcuts, toolbars and other accessibility methods. This may solve a few corner cases previously not very well handled. Here is a little summary of a few common use cases:

Corporate SIP client where you have to press a key or a code to call the outside world

Listening to voicemails without having to enter the password manually

Clearing all voicemails

Bypass custumer services robot-menus with a pre-programmed sequences (or a ton of “0” to try to talk to a human if they still have some real customer support )

Call your most common contacts

Enable or disable some phone features accessible only a special key sequence, like do not disturb or record a new missed call voicemail message.

Here are the obligatory screenshots:

This earth shaking awesome new feature is now available in the Git master of SFLPhone KDE along with a new bugfixes and features:

There is a now a way to configure a SIP proxy

The “Display” config options are now saved correctly again

SFLPhone KDE 1.2.2 also have been released shortly after 1.2.1 to fix a serious bug with IAX calls and include translations. I would like to take this opportunity to thanks all translators for their work.

My name is Emmanuel Lepage, I am a software developer from Montreal, Canada. Over the last decade, I have been contributing to KDE in multiple ways, including many applications you have never heard of, including the KliGN interactive terminal/shell and Kimberlite WYSIWYG HTML/PHP editor. I also contribute to Umbrello and maintain a few third party patches for features that will never be merged. Since 2009, I am the developer of SFLPhone-KDE, an Open Source softphone sponsored by Savoir-Faire Linux, a Canadian Free/Libre consulting company.

Today, we are proud to announce the release of the 1.2.1 version of SFLPhone, SFLPhone-Gnome and SFLPhone-KDE. For this cycle, our main focus was usability improvments and bug fixes. I spent hours on IRC with Nuno (thanks!) to try to make this release the best one ever. The main new feature is the inclusion of a new view subsystem for displaying on-canvas background information. It is used both for visual feedback and informative tips. See the video bellow for an overview of the feature.

This feature is 100% abstracted, so if other developers are interested, you are free to use it for your own application. It can be integrated in any Qt views (QTableView, QTreeView, QListView, etc) with only a couple of lines. I will blog about this feature design in a later blog post. The other big new feature is an on-canvas toolbar to replace the traditional QToolBar. This feature was done because the older toolbar had a different set of actions for different call states and was often larger than the window width, causing discoverability and usability issues. Given that the next iteration will focus on Plasma-Active/Mer/Ubuntu mobile integration, this will also prove very useful in mobile contexts (I don’t plan to port the call view to QML just yet).

* Automatic selection of the call tab when there is a new incoming call

* Improved DTMF handling

* Bug fixes

SFLPhone is available for Ubuntu as a PPA and the source code is available from http://sflphone.org/ and http://download.kde.org/stable/sflphone/ (coming soon). The next version should focus on reviving the QML version and improve our mobile support. We may also enable the video by default (currently available via compilation option) and have a better command line interface (for KAddressBook/KDEPIM integration)). I hope you enjoy this version.