Meshenger – P2P local network messenger – final update

Meshenger is meant to be an open-source, P2P audio and video communication application, that works without centralized servers, thus without a connection to the internet, does not need DHCP servers and can be used in LAN networks such as Freifunk community networks.

It was brought to life to demonstrate the use of such networks other than simply internet access as well es to discover the decentralized use of WebRTC in conjunction with IPv6.

I spent the last few weeks polishing and improving my project, getting it to a usable and stable state.

An APK with version 1.0.0 can be found here, as well as the whole source code.

In the last month i fixed a some bugs, like a wrong serialization of IPv6 addresses, making a phone ring even with the screen off, preventing duplicate contact entries, prevented the app from freezing and some more.

Of course, the app gained some new features, including a ‘settings’ page with the language, the username etc., additional information for each contact, a possibility to share contacts through third-party messengers or a QR-codeignoring calls from unsaved contacts and several more.

Oh, and if you suddenly dislike someone, you can now simply delete him.

Contact options





The app now has an ‘about’ page containing some meta-data about Meshenger as well as the license:

About page


I extraced a lot of hard-coded strings in order to make it easier to translate the app into different languages.


As of now, it is planned for the future to implement profile photos, file transfer and asynchronous messaging.

All in all, i would conclude that Meshenger was a successful project and reached most of its goals.

It gave me the chance to dive into new subjects and learn a lot about VoIP and IPv6 as well as get to know the Freifunk community and learn about other interesting ideas.

Meshenger – P2P local network messenger – Update 2

Just a few days after the first update I figured out how to use WebRTC, which I shortly after implemented into Meshenger.

To shortly describe the way signalling is working in my app:

  1. On phone A a call to phone B is issued by tapping the contact, hence phone A already knows the destination address
  2. A sends a call request to B, which B may accept or decline. This is done through a custom JSON-based protocol designed by me
  3. In case of success A creates a Session Description, also called SDP offer, which it transmits to B, using the same protocol
  4. B creates an SDP answer which it transmits back to A, still using my JSON-based protocol
  5. Using the exchanged offer and answer a RTCPeerconnection is established, where the data is transmitted through separate DataChannels/Streams. Upon this moment, WebRTC handles all the communication
  6. Finally, the phones have a RTCPeerconnection which they use to send Audio/Video as well as service messages, e.g. when a camera is connected


Besides the sheer implementation of WebRTC the front/back camera can be turned on and even switched on the fly.

The app has undergone some graphical improvements, all buttons containing text has been replaced with Image Buttons,

many of them even show a animation depending on their effect.


I even tried to cover the case of the user switching a network, if the link-local address loses its reachability.

Instead of simply trying to reach the last known address, the app now examines every address the phone has

and tries to replace its own MAC address in those addresses with the MAC of the target.

This leads to a higher chance of re-finding a contact even if the phones have switched networks.


As you can see in the following screenshot, bidirectional video-transmission is enabled, and the buttons at the bottom now have cute icons.


Phone A
Phone B












From now on I will focus on polishing the app, cleaning the source code, finding and resolving bugs and,

last but not least, writing sufficient documentation.

I may even write a blog post somewhere, explaining how to archieve a serverless WebRTC connection,

since the documentation i have found so far was not really helpful and mainly focused on JavaScript.

Meshenger – P2P local network messenger – Update 1


In the recent weeks i have made quite some improvements on my initial demo application:

  • share information using channels like Telegram instead of a QR-Code
  • turn off the screen when the earpiece is held to the ear during a call,
  • use IPv6 link-local adress when possible, IPv4 as fallback.


I have jumped into WebRTC development, searched and evaluated different projects with similar goals:

  • serverless-webrtc-android
    • barebone example of WebRTC without signalling servers
    • I ported the code from Kotlin to Java for a better understanding and integration into the project
  • webrtc-android-codelab
    • loopback example: WebRTC PeerConnection through localhost, providing insight into how to connect two nodes running on the same device
  • android-webrtc-tutorial
    • insight into how signalling works through an external server

The given examples helped me to collect a knowledge- as well as a codebase which I will further use to implement video and audio transmission over WebRTC.

Evaluation, hacking and testing of those examples helped me to get a understanding of the inner-workings of WebRTC and will surely support me in the Integration of WebRTC into Meshenger.


Here are some screenshots of the current state of the application:

Contact list
Scannable QR-Code
Manual information exchange









My next step will be the adaptation of said projects to the newest WebRTC-version

as well as further dealing with the fundamentals of WebRTC and finding a way to circumvent a central server.



Meshenger – P2P local network messenger

Hi, my name is Daniel, I am a 19-year-old student from Augsburg, Germany, and I have been working with Android and networking for several years now.

Thus, i am very excited to participate in the GSoC for the first time, hoping to learn new ways of connecting people with “Meshenger”.




We realized that there are no solutions that provide audio/video communication without using any centralized server while still working in networks such as the Freifunk community networks.

In this context I will try to fill that void, also to demonstrate possible uses of the network created by the Freifunk community in contrast to simply using it as a hotspot for Internet access.

Another issue of Freifunk community networks is that it is often perceived as nothing more than a way to access the Internet. Thus, we want to demonstrate a possible use of community-build networks, which do not neccessarily have access to the Internet by creating a way to phone each other over a local network.

The goal is to make an Android app, which allow audio- as well as videocalls through a local network, not requiring a server.



As seen above, there are several redundant servers for our project which I will need to circumvent.


The signaling, e.g. the exchange of nessecary network-related information will then happen through the scan of a QR-code generated by one of the connecting devices.


WebRTC is an open standard used by many mobile and browser applications like “WhatsApp” to establish a connection in order to make video/audio calls.

It is already implemented in all major browsers as well as systems like Android, thus providing a common base to build our app and, as a potential future goal, to expand it to other platforms.


Of course there are several challenges i will have to tackle, like having to get WebRTC running without a STUN-server, which is normally required.


In the next post i will share my progress as well as my collected experiences, explaining my approaches and trade-offs that will eventually have to be made.


Project source: