Implementation analysis
Implementation of a peer-to-peer SIP User Agent has been started. The aim is to obtain a client with the following features:
• SIP for signaling;
• peer-to-peer DHT protocol for user location; • NAT-friendly (Distributed Relay Service support); • audio, video and Instant Messaging support; • multi-platform (Linux, Windows, MacOS X).
The implementation work started from an already existent and open-source SIP client. From our analysis, Wengophone NG [54] resulted the most advanced, portable and actively maintained client.
For what is concerning the DHT protocol, SIPDHT [85] revealed an in-teresting project: its primary goal is to provide a library to be used in ap-plications for creating and using SIP based distributed hash tables.
A.1
OpenWengo
The OpenWengo [54] project is developing and maintaining the WengoPhone NG. Wengophone NG is a user-friendly audio/video SIP client, written in
C/C++ programming language and entirely released as open-source under the terms of the GNU General Public License (GPL, [30]).
WengoPhone is complex project, linked against multiple libraries (figure A.1), among which:
• Qt for the GUI (Graphical User Interface); • boost for threading and signals;
• PhApi (custom library) for SIP and RTP support.
A.1.1
PhApi
OpenWengo developers wrote PhApi (Phone API, figure A.2) which is a C library that wraps and coordinates SIP, RTP, codecs and sound libraries. Regarding the SIP support, PhApi is linked against the eXosip [49] and oSIP [50] libraries. Those software layers provide a dialog-level abstraction API over SIP. eXosip and oSIP are lightweight and portable C libraries with no additional dependencies, often used in embedded devices.
PhApi is kept separated from the rest of WengoPhone and, in fact, it can also be used as a standalone library for creating a SIP based UA. Wengo-Phone makes use of PhApi wrapping it inside a C++ class PhApiWrapper.
A.1.2
Development pattern
Object structure is was carefully designed, and the PAC (Presentation– Abstraction–Control, [25], figure A.3) architectural pattern was employed.
PAC is used as a hierarchical structure of agents, each consisting of a triad of presentation, abstraction (called model in OpenWengo) and control parts. The agents (or triads) communicate with each other only through the control part of each triad.
This pattern is similar to the MVC (Model–View–Controller, [31]) one. It differs from it in the hierarchical structure and in that within each triad, it completely insulates the presentation (view in MVC) and the abstraction (model in MVC). This provides the option to create two separate threads,
C++ C PhApiWrapper
PhApi
eXosip
oSIP STUN oRTP sound . . .
Figure A.2: PhApiWrapper and PhApi libraries
one for the model and one for the presentation, giving the user experience of very short program start times, as the user interface (presentation) can be shown before the abstraction has fully initialized.
A.1.3
Threading and signals
WengoPhone is a threaded application. Running threads are: • model thread, which is the engine of the application; • presentation thread, which runs the GUI;
• eXosip thread, which manages the SIP stack and its transaction state machine;
• NetworkObserver thread, which monitors the presence of Internet con-nectivity;
• oRTP thread, which manages the RTP flows.
C++ threads (model and presentation) are based on boost libraries, a collection of peer-reviewed, open source libraries that extend the functionality
CWengoPhone QtWengoPhone WengoPhone Control Presentation Abstraction CProfileManager QtProfileManager ProfileManager CUserProfile QtUserProfile UserProfile
Figure A.3: PAC schema
of C++. In particular model thread and presentation thread are implemented using Boost.Threads.
Signals across objects and threads are exchanges using Boost.Signals li-brary. Signals are callable objects that can be connected to some slots (call-back functions). When a signal is fired, all the call(call-backs associated to con-nected slots are called. Other than implementing this mechanism, boost libraries offer automatic slot disconnection when the handling object is de-stroyed, avoiding that a callback function is called against a no longer existing object.
A.2
SIPDHT
SIPDHT [85] is a C library meant to be used for creating SIP based Dis-tributed Hast Tables. The algorithm implemented is loosely based on P2P SIP work draft-bryan-sipping-p2p-02 [11], which is a previous version of [12].
SIPDHT maintains a Chord overlay by means of SIP messages, according to the guidelines described in section 5.1.1. The SIP protocol stack being used is Sofia-SIP [52], a C library developed by Nokia.
SIPDHT API offer three main object:
• peer: used to create a DHT peer able to create or join a Chord overlay; • put: used to contact a peer node and store a pair (key, value) in the
DHT;
• get: used to contact a peer node and get the value associated to a key. Each one of these three object is independent from the other, although it can share the same network socket (or, more precisely, the same Sofia-SIP agent).
In figure A.4 an example of request for peer registration in the DHT is reported and in figure A.5 an example of a successful response to a DHT GET request. The DHT-Node header is used to convey sender node information, while the DHT-Link headers are used to transfer the content of the Chord finger table.
REGISTER sip:10.0.0.5 SIP/2.0 To: <sip:14@10.0.0.14;user=peer> From: <sip:14@10.0.0.14;user=peer> Contact: <sip:14@10.0.0.14;user=peer> Expires: 600 DHT-PeerID: <sip:14@10.0.0.14;user=peer>; algorithm=sha1;overlay=chat;expires=600 Require: dht Supported: dht
Figure A.4: Example of SIPDHT peer registration request
A.3
Work on WengoPhone
A.3.1
Bugfixing
On a deeper analysis, WengoPhone revealed itself quite unstable, especially under the Linux environment. Major problem were threading issues (race
SIP/2.0 200 OK To: <sip:14@10.0.0.14;user=peer> From: <sip:14@10.0.0.14;user=peer> Contact: <sip:14@10.0.0.14;user=peer> Expires: 600 DHT-PeerID: <sip:3@10.0.0.3;user=peer>; algorithm=sha1;overlay=chat;expires=600 DHT-Link: <sip:10@10.0.0.10;user=peer>;link=P1;expires=125 DHT-Link: <sip:5@10.0.0.5;user=peer>;link=S1;expires=919 DHT-Link: <sip:5@10.0.0.5;user=peer>;link=F0;expires=919 DHT-Link: <sip:5@10.0.0.5;user=peer>;link=F1;expires=919 DHT-Link: <sip:10@10.0.0.10;user=peer>;link=F2;expires=125 DHT-Link: <sip:3@10.0.0.3;user=peer>;link=F3;expires=600 Require: dht Supported: dht
Figure A.5: Example of SIPDHT successful response to a DHT GET request conditions) and memory corruption. The first part of the work was devoted to make the code more stable for user registration and call establishment.
A.3.2
Generic SIP account
OpenWengo is supported by Wengo, a French telecom company, which offers cheap phone calls to the PSTN from WengoPhone. Consequently Open-Wengo developers concentrated their efforts in ensuring correct functionality with the Wengo network and did not assured interoperability with a generic SIP server1.
When logging to the Wengo network, the SIP UA configuration is down-loaded at runtime from an HTTPS server, after provider a registered e-mail and password. Such configuration, is the stored in a WengoAccount object and passed to the SIP engine via the PhApiWrapper.
As we wanted to be able to connect to our SIP server, the code was mod-ified in order to use a generic SipAccount class (parent of WengoAccount). Then, additional derived classes have been defined (see figure A.6):
• GenericSipAccount: connects to an RFC-compliant SIP server;
1This will be true until the next 2.1 release, where generic SIP account support will be
• DirectIPSipAccount: does not connect to a SIP server, rather is useful to make and receive direct UA to UA calls;
• P2PSipAccount: connects to a P2P SIP overlay.
WengoAccount GenericSipAccount DirectSipAccount P2PSipAccount SipAccount
Figure A.6: SipAccount new hierarchy
At login time, the WengoPhone user is given the opportunity to choose the account type to use (see figure A.7, and, of the case, specify additional configuration parameters (like the registrar server for GenericSipAccount ot the bootstrap peer for P2PSipAccount).
A.3.3
Integration with SIPDHT
The integration between WengoPhone has been done in a way so as to mini-mize changes to the already existing code. Modularity of the code and C++ polimorphysm allowed easy extension of object functionality (see figure A.8).
C++ C PhoneLine P2PPhApiWrapper PhApiWrapper PhApi SipDhtWrapper DhtWrapper SIPDHT startPeer(bootstrap, identity) stopPeer() isRunning() : bool getContact(user) : contact
Figure A.8: SipAccount new hierarchy
A DhtWrapper interface has been defined, which provides the following methods:
• startPeer(bootstrap, identity): starts the P2P engine; if boot-strap is empty creates a new overlay, otherwise contacts bootboot-strap; then it register the AOR identity with the local SIP contact address; • stopPeer(): de-registers the user from the overlay and stops the P2P
engine;
• isRunning(): returns true if the P2P engine is running and the peer has joined the overlay;
• getContact(user): returns the contact address associated with the AOR user stored in the DHT.
Actual implementation for this interface has been written inside the de-rived class SipDhtWrapper, which uses SIPDHT API.
In second place, a new class P2PPhApiWrapper has been derived from PhApiWrapper. In the new class, the following methods have been overridden: • addVirtualLine()/removeVirtualLine(): virtual lines are a mech-anism built into the PhApi that allows registration to multiple SIP servers (even though, currently, it is working just for one line); regis-tration to a SIP registrar is triggered by calling these functions, which have been modified in order to invoke DhtWrapper::startPeer() and DhtWrapper::stopPeer() if the user created a P2PSipAccount ; • makeCall(): if the user created a P2PSipAccount, the actual contact
address is fetched from the DHT using DhtWrapper::getContact() and then passed to the PhApi library in order to initiate a direct session with that URI.
A.4
ALEX on Wengophone
ALEX for IPv4/IPv6 has been been implemented on WengoPhone at the “Politecnico di Torino”. ALEX does not require modifications to the ap-plication core, bur rather places itself between the apap-plication and the SIP stack, driving also the STUN engine. ALEX accepts a session description from the application and manages the underlying software layers. ALEX must also take care of the management of network socket. In fact, on the same socket SIP or RTP packets are multiplexed with STUN packets.
In case of WengoPhone, ALEX implementation is at the eXosip level, plus a lower layer at socket level (A.9).
C++ C PhApiWrapper
PhApi
eXosip+ALEX
oSIP STUN oRTP
ALEX socket management
Figure A.9: ALEX in WengoPhone
A.5
Future development
Next steps in the development of WengoPhone towards a fully-functional P2P SIP client are:
• further development of ALEX extending it with NAT traversal support using centralized STUN servers; this modification will stil be performed at the PhApi level;
• merge of current P2P OpenWengo with the ALEX-enabled version; this merge will be quite easy, because modification took place ad different application layers;
• implementation of the Distributed Relay Service; this modification has to be performed mainly at the PhApi level (in fact the Distributed Re-lay Service is running thanks to SIP messages); however, coordination with the P2P engine is required at the P2PPhApiWrapper level.
Relevant Statistics
In this appendix statistical notion used in this work will be briefly discussed.
B.1
Exponential distribution
An exponential distribution is a continuous probability distribution, often used to model the time between independent events that happen at a constant average rate.
Its probability density function (f ) and cumulative distribution function (F ) are: fexp(x; λ) = ( λe−λx , x ≥ 0 0 , x < 0 Fexp(x; λ) = ( 1 − e−λx , x ≥ 0 0 , x < 0 Where λ is the rate parameter and represents the mean number of events per unit of time. The mean value of an exponential function is:
E[Xexp] =
1 lambda which is the mean time between two events.
B.1.1
Memorylessness property
An important property of the exponential distribution is that it is memory-less:
P (T > s + t | P > t) = P (T > s) ∀ s, t ≥ 0
This expression means that, if we have been waiting for an event to hap-pen for t units of time, the probability that it will not haphap-pen in the next s units of time is independent of the time we have already waited (t).
B.2
Power-law: Pareto distribution
Power-law distributions satisfy the property: P (T > t) ∝ t−α
A power-law distribution is Pareto distribution, which was originally used to describe the allocation of wealth among individuals since it seemed to show rather well the way that a larger portion of the wealth of any society is owned by a smaller percentage of the people in that society. This idea is sometimes expressed more simply as the Pareto principle or the “80-20 rule” which says that 20% of the population owns 80% of the wealth.
Pareto probability density function (f ) and cumulative distribution func-tion (F ) are: fpar(x; k, xm) = k xk m xk+1 for x ≥ xm Fpar(x; k, xm) = 1 − xm x k where x ≥ xm> 0.
Its mean value is:
E[Xpar] =
k xm
k − 1 k > 1
For k ≤ 1 the mean is infinite, while for k ≤ 2 its variance is infinite. In such case the distribution is said to be heavy-tailed.
B.3
Weibull Distribution
The Weibull distribution[89] has probability density function (f ) and cumu-lative distribution function (F ):
fweib(x; k, λ) = k λ x λ k−1 e(x/λ)k Fweib(x; k, λ) = 1 − e−(x/λ) k for x, k, λ ≥ 0.
The useful characteristic of the Weibull distribution is that it can mimic different behaviors: when the shape parameter k is 1 it is an exponential distribution, when k = 3.4 it is similar to a normal distribution. The other parameter λ is called the scale parameter.
Another interesting feature of theshape parameter is connected to the memory of the distribution:
k < 1 ⇒ P (T > s + t | P > t) > P (T > s) ∀ s, t ≥ 0
This property means that, if k is smaller than 1, means that the popula-tion has a decreasing “failure rate”, i.e. there are some defective items in the population, but they fall of it soon. In other words, the more time an item has been working without failing, the more time it is likely to keep working. On the other side, a k > 1 is typical of “wear out” parts, i.e. the proba-bility of failure increases as time passes.
B.3.1
Modified Weibull distribution
In this section, a modified Weibull distribution will be considered. The new distribution is constructed by zeroing all the values of the PDF for x < θ, shifting the function towards left of θ and than re-normalizing it:
ˆ fweib(x; k, λ, θ) = 1 N · ( fweib(x + θ; k, λ) , x ≥ 0 0 , x < 0
where N is the normalization values, equal to N = Z ∞ 0 ˆ fweib(x; k, λ, θ)dx = Z ∞ θ fweib(x; k, λ, θ)dx = 1 − Fweib(θ) Therefore: ˆ fweib(x; k, λ, θ) = 1 e−(θ/λ)k · k λ x λ k−1 e(x/λ)k = k λ x + θ λ k−1 e(x/λ)k+(θ/λ)k for x ≥ 0, 0 otherwise.
The mean value of this distribution can be computer as follows:
Eh ˆXweib i = Z ∞ 0 x ˆfweib(x)dx = R∞ 0 xfweib(x + θ) 1 − Fweib(θ) = = R∞ 0 (x + θ)fweib(x + θ)dx − θ R∞ 0 fweib(x + θ)dx 1 − Fweib(θ) = R∞ θ xfweib(x)dx 1 − Fweib(θ) − θ = = E[Xweib] − Rθ 0 xfweib(x)dx 1 − Fweib(θ) − θ where E [Xweib] = λΓ 1 + 1 k
Γ is the gamma function defined as Γ(z) =
Z ∞
0
First of all, I would like to thank my supervisors, in particular Prof. Fulvio Risso for welcoming me to work on this subject at the Politecnico di Torino and for the guidance and support during the preparation of this thesis.
I would to thank also Ing. Livio Torrero for the many precious hours spent discussing with me and revising this work.
Without their contribution this work could not have been done.
I am very grateful to CSP Innovazione nelle ICT for supporting this activity with a scholarship, and for providing me a friendly environment. Particularly my gratitude goes to Andrea Ghittino and Giovanni Coriasco.
Additionally, I feel grateful to Luca De Marco for his help with Open-Wengo development.
I do not want to forget to thank my friend Luca Foschini for his many and always useful advices, and for being available for questions at any hour of the day.
I owe a debt of gratitude to “my” Simona, who has always believed in me and constantly encouraged me.
Endless gratitude goes to my family, who allowed me to fulfill my wishes and supported me in everything I did.
Last but not least, I would like to thank all my study mates and friends in Pisa, who made enjoyable my University years in Pisa.
