Ring-KDE 3.0.0 has been released

Hello Planet,

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:

timeline.gif

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

video

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

call4

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.

chat

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.

search.gif

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.

For everyone else, Ring-KDE is available as an easy to use AppImage:

https://download.kde.org/stable/ring-kde/3.0.0/ring-kde_3.0.0_x86_64.AppImage

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.

akademy.jpg

Advertisements

What is Ring and how it works

Hello Planet,

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.

snapshot12
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.

snapshot13

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.

Announcing Ring, a distributed and secure multimedia communication platform

Savoir-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

snapshot10

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:

$ cp ~/.config/sflphone/sflphone.yml ~/.config/ring/dring.yml
$ cp -a ~/.kde/share/apps/sflphone-client-kde/ ~/.local/share/ring-kde
$ cp ~/.kde/share/config/sflphone-client-kderc ~/.config/ring-kderc

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).

Packages are available for Kubuntu 15.04, Fedora 21 and Fedora 20:

$ sudo sh -c "echo 'deb [arch=amd64] http://nightly.apt.ring.cx/ubuntu_15.04/ ring main' >> /etc/apt/sources.list.d/ring-nightly-man.list"
$ sudo apt-get update && sudo apt-get install ring-kde
$ sudo wget http://nightly.yum.ring.cx/fedora_21/ring-nightly-man.repo -O /etc/yum.repos.d/ring-nightly-man.repo
$ sudo yum install ring-kde
$ sudo wget http://nightly.yum.ring.cx/fedora_20/ring-nightly-man.repo -O /etc/yum.repos.d/ring-nightly-man.repo
$ sudo yum install ring-kde

snapshot11

Read more:

Say Hello to Ring ― Ultimate Privacy and Control for your Voice, Video and Chat Communications
https://blog.savoirfairelinux.com/en/2015/ring-ultimate-privacy-and-control-for-your-voice-video-and-chat-communications
The Ring Project — Decoding a Decentralized and Secure Communication System
https://blog.savoirfairelinux.com/en/2015/the-ring-project-decoding-a-decentralized-and-secure-communication-system/
At the Heart of Ring: OpenDHT — A Distributed Hash Table
https://blog.savoirfairelinux.com/en/2015/ring-opendht-a-distributed-hash-table/

SFLPhone-KDE 1.4.0 released!

Savoir-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

Common features

  • Jack support
  • Video support by default
  • Ability to share screen
  • Ability to stream videos, images and text files
  • Support GnuTLS as an alternative to OpenSSL
  • Persistent camera configuration (per device)
  • Switch video sources during a call
  • Enable or disable video per account
  • Packet loss concealment
  • RTCP support
  • Builds with clang

libqtsflphone

  • Pluggable history storage
  • Improved pluggable storage backends
  • Datasource extensions support

KDE client

  • Now a fully featured contact manager
    • Add, edit and manage contact sources
    • Delete contacts from the interface
    • Attach contact sources to auto completion or presence tracker
  • Basic video effects like rotate or enforce aspect ratio
  • Video full screen mode

2 3 1

Stats

KDE client:   203 files changed, 10979 insertions, 3933 deletions, 102 commits, 36 issues closed, 19 bugs closed
Daemon: 256 files changed, 14448 insertions, 9781 deletions, 628 commits, 543 issues closed, 214 bugs closed

 

Get SFLPhone-KDE

Kubuntu packages are available at: https://launchpad.net/~savoirfairelinux/+archive/ubuntu/ppa

The source get be obtained from  git://anongit.kde.org/sflphone-kde or from http://sflphone.org .

SFLPhone-KDE 1.3.0 released!

Hello planet!

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.

Changelog

Common

  • SIP Presence subscription and publishing support
  • Video multiparty conferencing [EXPERIMENTAL]
  • Multichannel ringtone support
  • Additional Flac and OGG ringtone support
  • Improved NAT support
  • Improved audio quality, noise suppression and automatic gain control
  • Bug fixes
  • New volume controls for PulseAudio
  • New mute DTMF option

libqtsflphone

  • API version 2.0
  • Qt5 support
  • Full Model/View support (19 new models)
  • New phone number statistics API
  • Full QML / QtScript compatibility
  • Improved performance
    • Now supports up to 15000 contacts and 10000 history entries
  • Faster load time
  • Now provides a complete DBus API abstraction
  • Bug fixes

KDE client

  •  Smart autocompletion [EXPERIMENTAL]
    • Call using the right account
    • Fast lookup
    • Call using contact information
    • Gather information from 11 sources to provide accurate results
  • Improved Akonadi integration
    • Support live contact list update
  • Usability improvements
    • Highlight missed calls in history
    • New “flat design” Contact/History/Bookmark widgets
    • More reliable canvas notifications
    • Improved account settings dialog
    • DTMF feedback
    • Network issue detection
  • Presence integration in contact, bookmarks and history views
  • Status publishing support in the statusbar
  • Dial tone support
  • Translation updates
  • Bug fixes

network account

autocompletion presence

dtmf

Statistics

Issues closed: 996
Bug fixed: 311
KDE related issues fixed: 148
KDE related bug fixed: 49
Daemon diff size: 19523 lines
Gnome client diff size: 3792 lines
KDE client diff size: 47582 lines
Total diff size: 70897 lines
Total commits: 1584
Total KDE related commits: 331

call

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 is available at http://sflphone.org/download/stable-release or at http://download.kde.org/stable/sflphone/ . Do not forget to first install the sflphone daemon before SFLPhone-KDE (it is a runtime dependency). Packages for (K)Ubuntu are available at https://launchpad.net/~savoirfairelinux/+archive/ppa and will get into your favorite distribution soon.  Enjoy!

SFLPhone-KDE 1.2.3 released!

Hello planet!

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.

The Ubuntu packages should be available soon at https://launchpad.net/~savoirfairelinux/+archive/ppa and on KDE servers.

Enjoy!

Image

SFLPhone KDE now have a macro subsystem

In 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:
Macro subsystem  wizard-welcome2

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.