A P2P Voice/Video application for Desktop and mobile … · A P2P Voice/Video application for...

A P2P Voice/Video application forDesktop and mobile Clients

Daniel OertleZürich, Switzerland

Student ID: 13-933-890

Supervisor: Dr. Thomas BocekDate of Submission: August 15, 2017

University of ZurichDepartment of Informatics (IFI)Binzmühlestrasse 14, CH-8050 Zürich, Switzerland

SO

FT

WA

RE

PR

OJE

CT

–C

omm

unic

atio

nS

yste

ms

Gro

up,P

rof.

Dr.

Bur

khar

dS

tille

r

Software ProjectCommunication Systems Group (CSG)Department of Informatics (IFI)University of ZurichBinzmühlestrasse 14, CH-8050 Zürich, SwitzerlandURL: http://www.csg.uzh.ch/

Abstract

With Skype most likely having abandoned its decentralized approach after being boughtand further developed by Microsoft, real P2P voice and video over IP application havebecome increasingly rare. The goal of this thesis is the design and implementation of afully-distributed, P2P Video and Voice over IP application. The application is developedin Java with its main focus on a desktop (Windows, Linux) version as well as an additionalmobile (Android) version. The developed application can be seen as a base for furtherdevelopment, as it can not yet match the features or stability offered by currently existingapplications.

i

Contents

Abstract i

1 Introduction 1

1.1 Description of Work and Motivation . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Related Work 3

3 Overview of Misaka 5

3.1 Startup and Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.2 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Main Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.1 Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.2 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Design Decisions and Implementation 11

4.1 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1 Account Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.2 Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2.1 Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2.2 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

iii

iv CONTENTS

5 Evaluation 17

5.1 Present . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Conclusions 21

Bibliography 23

List of Figures 23

A Installation Guidelines 27

B Contents of the CD 29

Chapter 1

Introduction

Skype was founded in 2003 by Niklas Zennstrom, from Sweden, and Janus Friis, fromDenmark. On the 29th of August 2003 the first version of it was released to the public[1]. Since then Skype has changed owners as well as architectures multiple times. First itwas bought by Ebay, then sold to an investment group four years later and subsequentlyit was bough by Microsoft in 2011 [2]. Microsoft first changed Skypes proprietary hybridP2P protocol by replacing its super nodes (which were normal users so far) with Linuxserver [3]. Later they completely abandoned its old protocol and replaced it with theirown Microsoft Notification Protocol (MSNP24). Very little is known about this protocol[4].TomP2P is a well-known DHT framework that has been developed in the CSG groupover the years. It has already been used in a number of applications such as Hive2Hive,LiveShift and many more. TomP2P has also been successfully used in academic projectssuch as EC-GIN and EMANICS [5]. TomP2P continues to be developed and has plannedan implementation of the SCTP protocolWith these two points in consideration, namely the lack of a fully P2P Skype alternativeas well as the new development on TomP2P, a new voice and video IP application wasdeveloped.

1

2 CHAPTER 1. INTRODUCTION

1.1 Description of Work and Motivation

The goal of this thesis is the design an implementation of a fully-distributed, P2P Videoand Voice over IP application. Users of the application need to be able to add each otherto their friends list. This friendship relationship is bi-directional, meaning that users cansend a friend request that can be accepted or refused by the other party. Once the re-quest has been accepted, the user becomes available in his contact list. Furthermore usersshould be able to call their friends as well as start a video communication. In order to callsomeone it is needed to know their online status. Online status as well as the friends listneed to be stored in a distributed manner. The result is a software for a fully decentral-ized video and voice application, including change and upgrade management (handlingapplication updates, and protocol versions).Open source and P2P create a transparent application that is not controlled by a central-ized third party. it is therefore in the interest of the user to support such software.

1.2 Thesis Outline

The two main platforms used in this work are Windows and Linux. Furthermore a mobileclient on Android was developed. The applications main focus however is the desktopversion.This report is divided into the following chapters: Chapter 3 gives an overview over thecreated application and introduces some of the technologies used. Chapter 4 is concernedwith the design decisions and implementation. An Evaluation is conducted in Chapter 5and a conclusion is given in chapter 6.

Chapter 2

Related Work

Voice/Video applications have been done before, such as the already mentioned Skype,Jitsi (a free and open source multiplatform voip and videoconferencing application) [6],and a myriad of others such as Ekiga, eyebeam, iCall and more[7]. It is not always clearto what extend these application truly are P2P based.Since most of these applications are proprietary a comparison can not be fully made. Nonethe less certain aspects and different solutions can be shown. From the ones mentionedearlier a small comparison is shown in the following table.

[Comparison of voice/video applications]Application Multiplatform Open Source,

licenseCosts Distributed

Misaka Windows,Linux, Android

Yes, Apache Free Yes

Skype macOS, Win-dows, Android,iOS

no, Proprietary Free Unknown

Jitsi Linux, macOS,Windows, An-droid

Yes, Apache free No

Ekiga Linux, Win-dows, OpenSo-laris

Yes, GPL Free No

eyebeam Windows No, Propri-etary

Non free No

On this small sample alone one can already see that the market on voice/video applicationseems to be quite saturated and products look and feel very similar. The major exceptionis the fully distributed nature of Misaka which is not as common anymore.

Another related work is the continued development of TomP2P by Jonas Wagner. Notableplaned features are support for SCTP hole-punching, increased IPv6 compatibility andstreaming support. These features would integrate well into a voice/video application.

3

4 CHAPTER 2. RELATED WORK

Chapter 3

Overview of Misaka

Multiple technologies and different design ideas have been used in this project. Thischapter gives a first rundown of how the application works on both, the desktop versionas well as the mobile version, and what it is capable of doing.

3.1 Startup and Login

The application is provided in the form of an executable jar. This jar is self containing anddoes not need any form of installation. The only prerequisite is having Java 8 or higherinstalled on Windows or Linux. On Android an Android Application Package (APK) isprovided that will install the application to the app drawer.

3.1.1 Desktop

At start up the user is shown a log in screen as seen in fig. 3.1. It is possible to input ausername and a password. Through the ”Login” button log ins as well as registrations arehandeled. On the top left an options menu can be opened on which the user can enteranother IP-address for connecting to a different network, as well as exiting the application.

5

6 CHAPTER 3. OVERVIEW OF MISAKA

Figure 3.1: Log In Screen on Desktop

3.1.2 Mobile

On Android the application looks similar as the desktop version with the exception ofthe options menu that can be activated through the ”three lines” button. On android theNavigation Drawer from the Lollipop API level was chosen as a design which can be seenin Fig. 3.2.

3.2. MAIN USAGE 7

Figure 3.2: Log In Screen and Options on Android

3.2 Main Usage

The main screen can be seen in fig. 3.3 and is similarly designed as many messengersnowadays with the friends list as the most Important feature on screen. Because of thebigger resolution on Desktops the message window is also visible at all times, while onmobile it is not visible from the main screen. On both versions, desktop as well as mobile,the online indication is represented next to the user name by a small circle that is eithergreen for online, red for offline or grey for unknown. Notifications of new messages arealso represented next to the user name with a orange exclamation mark. Should the userpress on the chat and therefore read the new messages the notification will disappear.


3.2.1 Desktop

Figure 3.3: Main Screen on Desktop

Through the ”three lines” button the options menu can be opened which presents itselfas an overlay similar to the Navigation Drawer of the Android options menu, thereforekeeping a similar style. In the menu it is possible to add another person as a friend, gointo the settings as well as receive information about the application itself.

3.2. MAIN USAGE 9


The chat section is fully expanded at the start. Should the users start a call or videoconference, the screen splits in a top part for the audio indication or video feed and abottom part with the chat shown in fig. 3.4.


3.2.2 Mobile


In fig. 3.5 it is shown how on mobile the friends list is the main feature of the screen. Bypressing on a friend the user is brought to the chat screen of the specified contact. Fromthere through the menu further options like calling and video conference are available.

Chapter 4

Design Decisions andImplementation

This chapter explains architecture of the DHT implementation, some of the details of theuser interface as well as the chosen data structure.

4.1 Core Network

A core network, or network core, is the central part of a communications network thatprovides various services to customers who are connected by the access network. Withoutthis part no communication would be possible.

4.1.1 Account Architecture

Due to the decentralized nature of the application a lightweight and scalable approachwas chosen that still allows interaction between the users. An account on the networkconsists of two parts, a Private user profile as well as a public user profile, detailed in fig.4.1. Both of these profiles are created at the first log in which marks the account creation.Both of these profiles are given to the DHT network.The private user profile is saved with a key consisting of the user name concatenated withthe hashed password. As Hashing algorithm SHA256 was chosen. This private user profileconsists of all the account sensitive information like the password, user name, private andpublic key and your accounts friends list.the public user profile is saved with a key consisting of only the user name. It contains thepublic facing information and is searchable. Its content are the user name, the public key,your current peer address, the pending friend request list, the application version numberas well as a limited message storage.On second log in the private as well as public profile are downloaded from the DHT toreconstruct the account, eg. loading your friends list and any messages that were sentwhile you were offline.

11

12 CHAPTER 4. DESIGN DECISIONS AND IMPLEMENTATION

Figure 4.1: Basic Account Structure

4.1.2 Behaviour

Most of the Communication happens directly, meaning a user reads his friends currentpeer address and send messages directly to his friend without using the DHT for morethan a lookup table.The most basic message is an online status message, consisting of a simple status updatewhether the account in question is online or not together with its current peer address.Such an online status message is repeatedly sent out to all friend accounts. Should theuser go offline by exiting the application a last status message is sent stating that the useris now offline. At the same time, but much less frequent, every user sends a small checkto all of his friends that asks whether they are still online. If no response is received theuser in question is assumed offline. This is to prevent friends from continuously beingonline after an unexpected shutdown.The next simple message is a ”true” chat message. Its main content being the messagetext, but also sending relevant information like the senders user name, the time it wassent and the senders peer address. The message content is encrypted with the recipientspublic key, therefore made unreadable for third parties that may intercept the message.As already mentioned such a message is normally being sent directly to the other user.Should the user be offline however the message is being added to the users public profilefor him to read the next time he logs in.

An audio frame as well as a video frame is essentially a message that has instead ofa message text byte array with the data as its content. The audio is encoded with thefree Opus Audio Codec. Opus offers a good performance and compression and is used tosave bandwidth on the communication.For video frames an implementation of Motion JPG (MJPG) was implemented. Each sentframe is a message with the JPG frame as its message content. MJPG was chosen for itssimple implementation on both desktop as well as android systems as well as its robust-ness against frame drops. Since MJPG always sends full frames dropped UDP packetswill not create any artifacts.

4.2. USER INTERFACE 13

4.2 User Interface

The user interface is an important aspect of a consumer oriented application. It is notonly used to present the application and its data but also to enable interaction with it.

4.2.1 Desktop

The user interface is built using JavaFX and follows the Model View Controller (MVC)pattern. Each single screen (eg. the log in screen) consists of an fxml file describingthe basic layout, a css file for styling and a controller class for controlling its behaviour.The main screen consists of multiple screens which are loaded onto a pane holding themtogether. Each controller is aware of the other controllers through the main controllerwhich allows for communication between them. In fig. 4.2 it can be seen which part ofthe main screen is handled by which controller

Figure 4.2: the Different UI Parts

this design allows for easy initial implementation as it offers great control over all elementsfrom every class, it does however increase the coupling of the code which inhibits bigchanges later on. Since the UI is not especially complex for this application the couplingis however still on an acceptable level.


By exchanging the css file a drastically different look can be achieved. It is planned in afuture release to make it possible to use custom style sheets.

4.2.2 Mobile

On Android the Lollipop Navigation drawer UI was chosen. Each screen is one activity,which allows for greater user control as well as flexible drawers with different options foreach screen.

Figure 4.3: The Activity Stack of Misaka

The transition between the activities is fairly self explanatory. Only the call of the log inactivity from the main activity differs in that it will log the user out. The complete pathof the activity stack is drawn out in fig. 4.3.

4.3. SERIALIZATION 15

4.3 Serialization

Since Android applications do not use normal JVM but the Dalvik Virtual Machine(DVM) as well as the Java bytecode being translated into Dalvik bytecode easy com-patibility between the platforms (Desktop, Mobile) is not possible. For this reason aserialization approach vis Json strings was chosen, as it offers good enough performanceas well as future proof any further platforms that might arise.For Converting the Java Objects into Json strings Googles library Gson was used. WhileGson is not known as having the best performance for serialization and deserialization [8]it is still fitting for this task, giving no real drawbacks even for higher data conversionslike on the audio or video frame.Every Json String has an identifier at the start which states what kind of message it is.With this identifier the deserialization engine can build the original Java Object again outof the Json string. Should in the future arrise the need for better performance a differentjsonify library like the Jackson library can be used.

Chapter 5

Evaluation

In this chapter a short evaluation of the present state of the application, it’s future andplanned features and the work that went into it is held. On the present state there will bean analysis of what is already done and how it compares with other existing application,while in the future section additional features are discussed that are now missing. Lastlythere will be an analysis of the security aspect of the application.

5.1 Present

The present state of the application is a working prototype. To truly get it on a level ofsimilar to a voice/video application like Skype a lot more work has to be done. While thebase functions of the application work a lot of features that are present on more matureapplications are still missing.What basic features can be done today:

• Adding contacts to your own friends list

• Instant messaging with your friend list contacts

• Voice calling a contact

• Video calling a contact

• Version check

more mature applications often offer additional features as well as add a lot of details totheir core services. To name a few examples, Skype as well as other applications allowadvanced options on which recording device a user can use for transmission, sensitivity ofthe microphone, add various effects to the camera feed and so on. These ”nice to have”features are still missing in Misaka. Stability of the application is also better on existingsolutions.

17

18 CHAPTER 5. EVALUATION

5.2 Future Work

In future development steps a lot of smaller features will need to be added in order to becompetitive witch established applications. For some features steps were already takenfor implementing them.

Planned features that are partly supported already:

• Decentralized updating system

• Customization of your account data

• Changing your display name

• User customization of the look of the desktop application

On the current release only a basic version check is implemented. If one of your contactshas a newer version of the application than you a small reminder is presented to you toupdate your application. At the moment this still is a centralized system with a singledownload link due to trust issues in the network, however with proper signing and trust adecentralized approach could be taken where the newest version of the application is alsostored on the DHT and made available for older clients to update.Customizing your account by adding information about yourself (e.g. e-mail address, cus-tom user picture) will be an important step to make the application look and feel morefriendly.At the moment your chosen user name at log in / registration is also the name that isdisplayed to other users. In most messaging applications this is standard practice and fornow it is also like this in Misaka. For a future release a display name system is plannedhowever, making it possible to change your display name that other users see. The login name however would still be unchangeable as it is a crucial part of the system. Thiswould be similar to how Steam handles accounts and their messaging application.While it has nowadays fallen out of fashion to let users customize their applications thestyling approach with loading a css file at the start of the screen was done with this inmind. At the moment the files are statically loaded but in the future it is planned to leta user upload their own css files, offering a powerful tool for customization.

Misakas architecture allows for easy upgrading of the application version. The networkitself does not force a specific version of the application to run, although it does inform ofnewer versions available. Because of the serialization with json message exchange futureadditions and features are simple to make.As an example one can think of a future release that adds account customization to theapplication. This would be achieved by adding more fields to the public and private userprofile while simultaneously changing the behaviour of the application. the current ver-sion would send all of its new information to everyone, including people still running anold version. An old version would however simply ignore most of it as it does not knowwhat to do with any of the new information, it would simply take the old still availableinformation. This does mean that certain key aspects can not be changed in the future

5.3. SECURITY 19

or else this coexisting of versions would break. So in short it can be said that this ap-proach offers good flexibility for adding new features while being rigid for changing thecore structure.

5.3 Security

Security in P2P applications is an important aspect, as they contain no controlled ortrusted code on a server. Multiple measurements have been taken to strengthen the se-curity and make it more robust against attacks.On the client side, all messages that are received but are not from a friend of the recipientsaccount are discarded (unless it is a friend request message). This offers some safety fromspam attacks by malicious nodes. Eavesdrop messages is made impossible by using thepublic key of the receiver to encrypt the message. The recipient will then use his ownprivate key to decrypt the message.The private user profile is saved on the DHT and managed by TomP2P, predicting orsearching for it by an unauthorized third party should not be possible, as the key is acombination of the user name and hashed password. none the less the private profile isalso encrypted with AES 128 bit encryption. As key the users password is taken.

One major weakness that exists at the moment is the fact that everyone can overwritepublic user profiles. This is necessary with the current design for offline interaction towork it allows malicious nodes however to change or completely delete a public user pro-file. Since the public key is also present in the private user profile a deleted public userprofile can be reconstructed by the next log in of the user, all friend request messagesor offline messages that have been received prior to the deletion are lost however. In theworst case scenario a malicious node could continuously overwrite the public user profileof a certain user, therefore keeping him from having any meaningful offline features.

20 CHAPTER 5. EVALUATION

Chapter 6

Conclusions

This project showed that it is possible to create a functional P2P voice/video IP applica-tion. It also showed that to truly be competitive with already existing non-P2P solutionsnow missing features still need to be added as well as improvements to the current codebase, especially on the mobile side, are necessary.

Something important to note is also the fact that even if the developed application wascompetitive with current ones, network effects are increasingly difficult to overcome insocial applications. As history has shown many times, better technology does not equalto having more users. A quick example that comes to mind is the battle of Betamax vs.VHS in the 80s where the technological superior Betamax still lost. There are howeverpositive points to take out of this, the hurdle called network effects can be overcome byreducing the barriers to entry. Misaka does not need an installation on desktop machinesand has no separate account registration or confirmation. In just a minute a user candownload the application and sign in for the first time. By launching in a smaller moreniche market (like an academic field or a developer community) a base of users can begained that then strengthen the flow of new users to the network.

Even while considering these positive points, the probability of a commercial successis low. Therefore a small deployment for the academic field as well as for P2P enthusiastswould be most fitting, as the increased support and development from the open sourcecommunity can be used to improve on the existing base application.

21

22 CHAPTER 6. CONCLUSIONS

Bibliography

[1] Microsoft: About Skype URL: https://www.skype.com/en/about/, August 13,2017.

[2] Dan Mitchell: Skype’s long history of owners and also-rans: At an end?: http://fortune.com/2011/05/11/

skypes-long-history-of-owners-and-also-rans-at-an-end/, August 13,2017.

[3] Dan Goodin: Skype replaces P2P supernodes with Linux boxes hosted byMicrosoft: https://arstechnica.com/information-technology/2012/05/

skype-replaces-p2p-supernodes-with-linux-boxes-hosted-by-microsoft/,August 13, 2017.

[4] Noah Petherbridge: Skype switched to the MSN Messenger Protocol: https://www.kirsle.net/blog/entry/skype-switched-to-the-msn-messenger-protocol,August 13, 2017.

[5] tomp2p: Applications using TomP2P: http://tomp2p.net/, August 13, 2017.

[6] Jitsi: What is Jitsi?: https://jitsi.org/what-is-jitsi/, August 13, 2017.

[7] Wikipedia: Comparison of VoIP software: https://en.wikipedia.org/wiki/

Comparison_of_VoIP_software, August 13, 2017.

[8] Fabien Renaud: Benchmark of Java JSON libraries: https://github.com/

fabienrenaud/java-json-benchmark, August 13, 2017.

23

24 BIBLIOGRAPHY

List of Figures

3.1 Log In Screen on Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Log In Screen and Options on Android . . . . . . . . . . . . . . . . . . . . 7

3.3 Main Screen on Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8



4.1 Basic Account Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 the Different UI Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 The Activity Stack of Misaka . . . . . . . . . . . . . . . . . . . . . . . . . 14

25

26 LIST OF FIGURES

Appendix A

Installation Guidelines

In order to keep the entry barriers simple the user only has to start the executable jarfor the application to work. No installation is necessary on the desktop version and notemporary or permanent file are created locally. In order for the application to work theuser has to have Java 8 or higher installed.On android the APK has to be installed on the phone, this can be as simple as puttingthe APK file onto the SD card or internal storage of the device and then executing it.This process may require the authorization of side loading APK files by the user.

For building the project it is preferred to clone the Github repositories main branchas it will always have the most up to date version. After cloning the repository, both thedesktop version as well as the mobile version it can be built with the gradle build tool.It is important to change the bootstrap IP in the class LoginWindow, as this variabledictates the first connection to the network.

27

28 APPENDIX A. INSTALLATION GUIDELINES

Appendix B

Contents of the CD

The CD contains the following material:

• Source Code of the Desktop Version

• Source Code of the Mobile Version

• Copy of this paper in pdf format

• Latex source code of this paper

• Copy of the presentations slides in pptx format

29

A P2P Voice/Video application for Desktop and mobile … · A P2P Voice/Video application for...

Documents

Transcript of A P2P Voice/Video application for Desktop and mobile … · A P2P Voice/Video application for...