Android VoIP/SIP Softphone

Ministère de l'Enseignement Supérieur et de la Recherche
Scientifique
Université de la Manouba
École Nationale Des Sciences de l'Informatique
Rapport de projet de conception et de développement
SUJET :
Softphone pour Android
Réalisé par :
Ben Abdallah Kmar Lazâar Hamza
Sous l'encadrement de :
M. Mezghani Dhafer
Année Universitaire :
2012-2013

Signature de l'encadrant
M. Mezgheni Dhafer

Résumé
Softphone VoIP/SIP sous Android :
Ce travail, qui s'inscrit dans le cadre du projet de conception et de développement (PCD) des-
tiné aux élèves ingénieurs en deuxième année à l'École Nationale des Sciences de l'Informatique
(ENSI), a pour but la réalisation d'un client VoIP 1 mobile autour du protocole SIP 2 destiné à
la plate-forme Android.
L'application visée permetterait de téléphoner sur IP 3, gérer des contacts et garder un jour-
nal des appels. MjSIP, une implémentation troisième-tier écrite en Java de la pile des protocoles
multimédia a été utilisé et la librairie ActionBarSherlock nous a permis de surmonter les pro-
blèmes de compatibilité liées aux versions Android antérieures à 3.0 (Honeycomb).
Mots clés : VoIP, SIP, SDP 4, RTP 5, Android, MjSIP, SQLite, ActionBarSherlock, Java, POO 6
1. Voice over IP
2. Session Initiation Protocol
3. Internet Protocol
4. Session Description Protocol
5. Real-time Transport Protocol
6. Programmation Orientée Objet

Abstract
VoIP/SIP Softphone for Android :
This work, conducted under the software design and implementation project for the second
year engineering students at the National School for Computer Studies, aims to develop a VoIP
client for the Android platform based, mainly, on SIP.
The application's main purposes are telephony over IP, managing contacts and saving calls'
log. MjSIP, a third-party implementation of the multimedia protocols written in Java were used
as well as ActionBarSherlock library project which solved compatibility problems related to An-
droid versions pre 3.0 (HoneyComb).
Keywords : VoIP, SIP, SDP, RTP, Android, MjSIP, SQLite, ActionBarSherlock, Java, OOP 7
7. Object-Oriented Programming

Remerciements
Nous voudrions exprimer notre gratitude et notre reconnaissance envers tous ceux qui ont
contribué à l'accomplissement de ce travail.
Nos remerciements s'adressent en premier lieu à notre encadrant M. Dhafer Mezghani qui a
su nous faire sentir responsables et conants.
Nous tenons aussi à remercier nos camarades de classe de l'École Nationale des Sciences de
l'Informatique.
Qu'il nous soit aussi permis de remercier Mmes Nesrine Ben Yahia, Imtiez Fliss et Emna Souilah
pour leurs eorts dans la révision et dans la correction de ce rapport.
I

Table des matières
Introduction générale 1
1 Étude préalable 2
1.1 État de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Protocole SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Protocole SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Protocoles RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.5 Exemples de ux SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Etude de l'existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Etude de clients SIP/VoIP Android existants . . . . . . . . . . . . . . . . 6
1.2.2 Description de la solution proposée . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Travail à faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Analyse et spécication 10
2.1 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Spécication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Description des cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Conception 19
3.1 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Description des paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Conception de l'IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 Conception de la base de donnée locale . . . . . . . . . . . . . . . . . . . . 22
3.2.3 Traitement en arrière plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
II

4 Réalisation 27
4.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1 SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2 ActionBarSherlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3 MjSip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.4 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Description des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.1 Gestion du compte SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.2 Interface d'appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.3 Gestion des contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Chronogramme du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Conclusion générale 41
Bibliographie 41
Nétographie 42
Annexes 43
A Changer l'apparence de l'émulateur Android 44
B Ajouter la bibliothèque ActionBarSherlock à un projet Android sous Eclipse 47
Glossaire 48

Table des gures
1.1 Fonctionnement de base de SIP [3] . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Enregistrement auprès du serveur avec authentication[2] . . . . . . . . . . . . . 6
1.3 Interface de SipDroid : Activité principale avec menu apparent . . . . . . . . . . 7
1.4 Aperçu de l'interface de CSipSimple . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Diagramme des cas d'utilisation golbal . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Cas d'utilisation : Emettre appel . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Cas d'utilisation : Recevoir appel . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Cas d'utilisation : Ajouter contact SIP . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Diagramme de séquence système : Ajouter compte SIP scénario nominal . . . . . 14
2.6 Diagramme de séquence : Ajouter compte SIP scénarios exceptionnels . . . . . . 15
2.7 Diagramme de séquence : Emettre appel . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Diagramme de séquence de référence : Conversation . . . . . . . . . . . . . . . . . 16
2.9 Diagramme de séquence : Recevoir appel . . . . . . . . . . . . . . . . . . . . . . . 17
2.10 Diagramme de séquence : Ajouter contact SIP . . . . . . . . . . . . . . . . . . . . 18
3.1 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Diagramme de classes du package IHM . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Diagramme d'activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Diagramme de classes du package Base de données . . . . . . . . . . . . . . . . . 22
3.5 Diagramme de classes du package SIP . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Diagramme de séquence - Ajouter Contact . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Diagramme de séquence - Modier Contact . . . . . . . . . . . . . . . . . . . . . 24
3.8 Diagramme de séquence - Supprimer Contact . . . . . . . . . . . . . . . . . . . . 25
3.9 Diagramme de séquence - Appeler Adresse SIP . . . . . . . . . . . . . . . . . . . 25
3.10 Diagramme de séquence - Recevoir Appel SIP . . . . . . . . . . . . . . . . . . . . 26
4.1 Position de l'ActionBar dans l'écran . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Activité Ajouter compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Message d'erreur quand un des champs au moins est laissé vide . . . . . . . . . . 32
4.4 SIP URI non conforme à la norme . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Ecran de chargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 Interface de modication du compte SIP . . . . . . . . . . . . . . . . . . . . . . . 33
4.7 Boite de dialogue de changement d'identiant SIP . . . . . . . . . . . . . . . . . 33
4.8 Boite de dialogue de changement de mot de passe . . . . . . . . . . . . . . . . . . 33
4.9 Interface d'émission des appels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
IV

4.10 Interface d'appel entrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.11 Contact nom vide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.12 Contact nom existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.13 Contact SIP Uri vide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.14 Contact SIP URI invalide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.15 E-mail non valide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.16 Choisir photo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.17 Prendre photo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.18 Liste des contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.19 Sans champs optionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.20 Avec champs optionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.21 Modier Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.22 Liste après modication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.23 Achage contact modié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.24 Chronogramme du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.1 Création d'un nouveau AVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2 Ligne de commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.3 Modication du chier conf.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.4 Avant la personnalisation de l'AVD avec le skin . . . . . . . . . . . . . . . . . . . 46
A.5 Après la personnalisation de l'AVD avec le skin . . . . . . . . . . . . . . . . . . . 46
B.1 Importer Code Android existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.2 Sélectionner répertoire spécique . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.3 Ajouter la bibliothèque au projet Android . . . . . . . . . . . . . . . . . . . . . . 48

Liste des tableaux
1.1 Tableau comparatif entre solutions existantes étudiées et solution proposée . . . . 9
4.1 Caractéristiques du HP Compaq 6830s . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Caractéristiques du Dell Inspiron n5110 . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Caractéristique du Samsung Gt5570 . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Caractéristique du GALAXY Nexus . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
VI

Introduction générale
Avec la banalisation des réseaux haut débit, notamment la 3G 8, le nombre d'applications
possibles a considérablement augmenté. La voix sur IP est l'une des technologies les plus en vue
actuellement.
La réduction des coûts des terminaux mobiles, softphones et tablettes, ainsi que la vulgarisation
des connexions permanentes orent des possibilités de développement de la voix sur IP dans notre
pays. De plus, en 2012, le ministre des Technologies de l'Information et de la Communication a
annoncé la libération de la VoIP de l'emprise de l'Etat et des opérateurs téléphoniques[4]. Par
ailleurs, Android constitue le principal leader des systèmes d'exploitation embarqués, en nombre
d'activation par jour et en nombre d'application dans le Google Play Store. Il constitue aussi le
standard ouvert de fait des systèmes d'exploitations mobiles. Sans oublier son SDK 9 toujours
en évolution et dont les API 10s sont riches et variées. Toutes ces raisons encouragent à tourner
vers cette platforme.
Les intérêts pour la téléphonie sur IP sont donc, de plus en plus importants et son exploitation
est de moins en moins coûteuse surtout avec l'arrivée du protocole SIP qui a beaucoup facilité
l'échange de ux multimédia sur les réseaux IP. Il serait alors, intéressant de proter de cette
nouvelle opportunité pour découvrir le protocole SIP, qui est relativement nouveau, par le biais
de la VoIP, sa principale application actuellement qui peut être vue à la fois comme étant une
application répartie mais aussi une technologie de systèmes temps-réel.
Notre projet consiste à développer une application Android de VoIP qui prote des fonctionnalités
oertes par le protocole SIP et qui permet principalement de téléphoner sur IP avec une gestion
de contacts qui s'ajoute à ses fonctionalités.
Le présent rapport s'articule autour de quatres chapitres. Le premier est une présentation du
travail qui inclut l'essentiel des connaissances théoriques recquises et une étude comparative
des softphones VoIP/SIP les plus populaires sur Google Play Store. Le deuxième consiste à
spécier les besoins de notre application. Le troisième chapitre est consacré à la conception. La
réalisation sera présentée dans le dernier chapitre moyennant les imprimes écran des interfaces
de notre logiciel.
8. Troisième Génération
9. Sofware Development Kit
10. Application Programming Interface
1

Chapitre 1
Étude préalable
Dans ce chapitre, nous allons en premier lieu introduire les bases théoriques, terminologie
et concepts, liés à notre projet. Deuxièmement, nous allons présenter une étude comparative de
deux softphones VoIP/SIP existants sur Google Play Store. Ensuite, nous allons présenter le
cadre général du projet.
1.1 État de l'art
1.1.1 VoIP
VoIP est un abrégé de l'anglais Voice over IP. Cette technologie permet de communiquer par
voix via les réseaux IP dont Internet est le principal exemple. VoIP est donc une technique, un
procédé et non pas un protocole en lui même mais durant ce processus diérents protocoles sont
utilisés dont SIP qui est considéré aujourd'hui comme le protocole VoIP de référence.
1.1.2 Protocole SIP
Présentation :
SIP est un protocole de signalisation de bout en bout permettant l'établissement en temps
réel d'une session multimédia sur les réseaux IP. SIP possède l'avantage de ne pas être exclusif
à un médium particulier et est sensé être indépendant du protocole de transport de la couche
sous-jacente.
SIP est un protocole publié par un groupe de travail de l'IETF 1 sous la RFC 23261 (juin 2002)
et est en cours d'adoption massive.
Fiche technique :
SIP reprend des éléments techniques des protocoles SMTP 3 et HTTP 4. Voici les caractéris-
tiques techniques de SIP en bref :
Dans la pile TCP 5/IP, SIP appartient à la couche applicative.
1. Internet Engineering Task Force
2. Request For Comment
3. Simple Mail Transport Protocol
4. Hyper Text Transport Protocol
5. Transmission Control Protocol
2

Chapitre 1. Étude préalable
Le numéro de port réservé par défaut au protocole SIP est 5060.
SIP est bâti sur une architecture client/serveur.
SIP est un protocole de type requête/réponse.
SIP utilise des messages textuels structurées sous la forme de chaînes de caractères ASCII 6
directement lisibles et ressemblent à celles de HTTP.
Les messages sont transportés par les protocoles de transport réseaux TCP ou UDP 7.
Dans les messages SIP les parties établissement de session et description de session sont
séparées : L'en-tête dénit les paramètres nécessaires au routage du message et à l'éta-
blissement de la session. Le corps dénit les caractéristiques de la session à l'aide d'un
protocole de description de session.
Entités SIP
Il existe une multitudes d'entités qui interviennent dans les échanges des messages SIP parmi
lesquels nous pouvons citer[1] :
Les Agents
Agent Client (UAC 8) : Entité, qui se trouve sur tout équipement, ayant pour rôle d'en-
voyer les requêtes et recevoir les réponses. Par exemple l'appelant est considéré comme
un UAC.
Agent Serveur (UAS 9) : Entité, qui se trouve sur tout équipement SIP, ayant pour rôle
de générer et d'envoyer les réponses. Par exemple l'appelé est considéré comme un UAS
puisqu'il répond aux requêtes.
Les serveurs SIP
Les serveurs sont des fonctions (appareils logiques) qui peuvent être déployées sur un ou
plusieurs appareils physiques. Voici les principaux exemple de serveurs SIP :
Serveurs proxy (Relais mandataire) : Entités qui agissent à la fois en tant que UAC et
UAS. Ils ont surtout un rôle de routage des messages SIP et parfois il peuvent intervenir
dans une politique d'accès et de sécurité.
Serveurs de redirection : Les serveurs Redirect sont utilisés pendant la phase d'initiation
d'appel pour déterminer l'adresse de l'appareil appelé. L'UAC de l'appareil appelant est
donc redirigé vers une URI 10 alternative (le serveur proxy le plus proche du destinataire)
pour contacter l'UAS correspondant.
Serveur d'enregistrement (RG 11) : Le Registrar est un serveur qui gère les requêtes
REGISTER envoyées par les UAC pour signaler leur emplacement courant. Ces requêtes
contenant une adresse IP (avec le numéro de port), associée à une URI SIP, seront envoyés
à un serveur de localisation pour stockage.
Serveurs de localisation (LS 12) : Ce serveur, pseudo DNS 13, fonctionne comme une base
de données qui contient les enregistrements des terminaux, donc l'association entre URI
SIP et (IP,port). Le serveur de localisation est consulté par un serveur proxy ou un
serveur de redirection pour obtenir des informations sur la localisation de l'appelé.
6. American Standard Code for Information Interchange
7. User Datagram Protocol
8. User Agent Client
9. User Agent Server
10. Uniform Resource Identier
11. Registrar
12. Location Server
13. Domain Name System
Rapport de PCD 3 2012 - 2013

1.1.3 Protocole SDP
Pour décrire la session dans le corps de quelques messages du protocole SIP, le protocole
recommandé mais non obligatoire est SDP (RFC4566). Ce protocole sert à spécier les para-
mètres de session en cours d'établissement ou déjà établie an d'aider les candidats souhaitant
y participer à décider d'y joindre ou non en fonction des médias proposés et leur compatibilité
avec la conguration du candidat en question.
Un message SDP est composé d'une série de lignes dont chacune correspond à un champ iden-
tié par la première lettre minuscule de la ligne en question qui est l'abréviation du nom de ce
champ. Chaque ligne respecte un ordre précis an de simplier l'analyse lexicale. Il existe aussi
des normes d'utilisation du jeu de caractères dans les messages SDP, leur standarisation est xée
par les RFCs.
Parmi les éléments qui peuvent être présents dans un message SDP ont peut citer :
Le nom et l'objet de la session
La durée de la session (instants de début et de n)
Informations sur le ou les médias utilisés dans la session (type [audio/video], protocoles de
transport, numéro(s) de port(s) et format (codecs))
Adresse(s) du/des destinataire(s)
D'autres informations complémentaires peuvent être incluses dans un message SDP comme la
bande passante nécessaire pour la session ou les règles de sécurité à appliquer à la session.
1.1.4 Protocoles RTP/RTCP
Dans l'architecture TCP/IP, les protocoles de la couche transmission ne susent pas à assu-
rer un transport de la voix. D'une part, le mécanisme de contrôle de congestion de TCP pourrait
aecter le ux de données avec la réduction automatique du débit d'émission. D'autre part, UDP
ne prévoit pas la correction d'erreurs et ne garantie pas l'ordre de réception des paquets. Pour
remédier à ces lacunes, il est nécessaire d'utiliser un ou plusieurs protocoles supplémentaires.
Avec SIP, les protocoles conseillés mais non obligatoires sont RTP et RTCP 14. Voici quelques
caractéristiques sur ces deux protocoles :
Ces deux protocoles qui vont en pair, se situent au niveau applicatif et utilisent une stratégie
de bout en bout et n'ont donc aucun contrôle sur le réseau.
UDP est favorisé à TCP pour le transport des paquets RTP/RTCP.
Ils peuvent fonctionner aussi bien en mode Unicast (point à point) qu'en mode Multicast
(multipoint).
La plage des ports utilisables par ces protocoles est comprise entre 1025 et 65535, leurs
ports réservés par défaut sont respectivement 5004 et 5005, et bien qu'ils utilisent des ports
diérents, le numéro de port de RTP est toujours pair, et celui de RTCP est toujours le
numéro impair immédiatement supérieur.
RTP
Le but de RTP et de permettre la transmission des données ayant des contraintes de temps
réel sur les réseaux IP. Il permet entre autre de :
identier le type des données transportées
14. RTP Control Protcol

synchroniser le ux de données du côté du destinataire grâce aux marqueurs temporels ou
timestamps
garantir la reconstruction des paquets livrés et détecter les éventuelles pertes grâce aux
numéros de séquence
RTCP
RTCP est un protocole de contrôle des ux RTP. Il accompagne toujours le protocole RTP ;
dès qu'une session RTP est ouverte une session RTCP est implicitement lancée. Son fonctionne-
ment est basé sur des transmissions périodiques de paquets de contrôle par tous les participants
d'une même session. Si l'on considère une session audio avec deux participants, des paquets
RTCP peuvent être émis toutes les 5 secondes. Ces paquets de contrôles peuvent contenir des
feedbacks sur la qualité de service et des informations sur les participants.
1.1.5 Exemples de ux SIP
La gure 1.1 met en relief, dans un cas d'école simple d'appel SIP, les étapes de la découverte
de l'adresse distante, celle de l'appelé puis l'établissement d'un simple appel SIP.
Figure 1.1 Fonctionnement de base de SIP [3]
La gure 1.2 montre les échanges entre un client et un serveur SIP suite à l'envoi d'une requête
REGISTER du côté du client. L'authentication est une phase importante et non obligatoire
mais souvent imposée par les serveurs par mesure de sécurité. Dans cet exemple, la demande
d'authentication se traduit par le message SIP 401 Unauthorized contenant dans une entête

de type WWWAuthenticate une clé appelée nonce que l'utilisateur doit utiliser avec l'algorithme
de cryptage ou de hashage approprié, par exemple MD5 15, pour générer la réponse au dés lancé
par le serveur. Le mot de passe de l'utilisateur, dit secret est un autre paramètre de génération
de la réponse.
Figure 1.2 Enregistrement auprès du serveur avec authentication[2]
1.2 Etude de l'existant
1.2.1 Etude de clients SIP/VoIP Android existants
Plusieurs applications VoIP/SIP sont déjà disponibles sur le Play Store. Nous avons testé
celles qui sont les plus recommandées 16 [5] pour mieux comprendre leur objectif commun.
15. Message Digest 5
16. recherche sur Google Play Store, mot clé = sip

SipDroid
Figure 1.3 Interface de SipDroid : Activité principale avec menu apparent
SipDroid[6] est un logiciel libre sous licence GNU 17 GPL 18. Le projet SipDroid, qui a com-
mencé avec HSC 19 en 2008 puis repris par i-p-tel GmbH en 2009, reste la référence et le pionnier
des projets SIP sur Android puisqu'il existe avant même l'arrivée des APIs SIP ocielles (An-
droid API 9). Le plus grand point fort de ce client SIP donc est sa compatiblité avec les versions
d'Android à partir de 1,6 (Donut). SipDroid est basé sur MjSip : une pile SIP tierce écrite en
Java en 2005 par Luca Veltri 20.
L'aspect graphique de SipDroid n'a pas suivi l'évolution de l'aspect technique de l'application
dont la version 3.0 vient de sortir le 22 avril 2013. D'autre part, la prise en main de SipDroid
n'est pas intuitive. C'est pour celà que plusieurs modes d'emploi multilingues sont disponibles à
partir du site ociel [7] expliquant entre autres comment congurer SipDroid avec pbxes.org, le
fournisseur de services SIP favoris de SipDroid. Globalement, SipDroid nous a paru faible, côté
nition.
17. GNU's Not Unix
18. General Public License
19. Hughes Systique Corporation (États Unis)
20. Université de Parme (Italie)

CSipSimple
Figure 1.4 Aperçu de l'interface de CSipSimple
CSipSimple[8] a été créé par Régis Montoya en 2009 quand il a vu que SipDroid ne faisait
pas l'aaire[9]. Le principal avantage de ce client VoIP est sa qualité sonore dûe à PjSIP : une
librairie SIP externe dédiée aux systèmes embarqués, entièrement écrite en C. CSipSimple est
un logiciel libre sous licence GNU GPL. Ainsi le projet est activement développé ; de nouvelles
fonctions sont ajoutées à la demande des utilisateurs et par des utilisateurs même. Il existe plu-
sieurs plugins et addons téléchargeable à partir du Google Play Store.
CSipSimple est doté d'une belle interface qui prote de la libraire ActionBarSherlock pour appor-
ter la touche de beauté de Honeycomb (Android version 3.x) aux version antérieures. CSipSimple
est assez facile à manipuler et parmi les choses agréables avec CSipSimple ce sont les wizards21
de conguration.
1.2.2 Description de la solution proposée
Les applications décrites précédemment sont quasiment complètes du point de vue fonc-
tionnalités et ne pourraient être que de bons exemples pour notre projet sans pour autant les
répliquer. Le problème est qu'ils utilisent plusieurs applications par défaut d'Android comme le
gestionnaire des contacts ou le journal des appels au lieu d'implémenter des fonctionnalités équi-
valentes ce qui a provoqué l'entrelacement des données SIP avec les autres données personnelles
du téléphone. Le tableau récapitulatif 1.1 contient les principales diérences entre notre solution
proposée (nommée AndroSip) et les solutions existantes.
21. Assistants

Table 1.1 Tableau comparatif entre solutions existantes étudiées et solution proposée
Application Gestion des Contacts Journal des appels Interface graphique Facilité d'usage
CSipSimple Non Oui Soignée Elevée
SipDroid Non Non Archaïque Moyenne
AndroSip Oui Oui Simple Elevée
1.3 Présentation du projet
1.3.1 Cadre du projet
Ce travail s'inscrit dans le cadre du Projet de Conception et de Développement (PCD),
anciennement appelé Projet de deux Modules (P2M), que nous sommes amenés à eéctuer durant
le deuxième semestre en deuxième année à l'Ecole National des Sciences de l'Informatique (ENSI).
1.3.2 Travail à faire
Notre travail consiste à concevoir et à réaliser une application VoIP mobile sous Android en
exploitant le protocole SIP avec les fonctionnalités de gestion de contacts et de sauvegarde de
journal des appels.
Conclusion
Dans ce chapitre nous avons, tout d'abord, présenté les protocoles essentiels à notre applica-
tion. En deuxième lieu, nous avons eectué une étude de l'existant dans le but d'en extraire les
critères de la solution à adopter. Dans le chapitre qui suit, nous allons spécier les besoins de la
solution retenue.

Chapitre 2
Analyse et spécication
Dans le présent chapitre, nous commençons par identier l'acteur de notre application et
exprimer les services que doit lui orir l'application. Dans la deuxième partie, nous présentons la
spécication semi-formelle, suivant la norme UML 1 2.0, de ces besoins à travers des diagrammes
de cas d'utilisations et leurs scénarios respectifs.
2.1 Expression des besoins
2.1.1 Acteurs
Nous avons un seul acteur pour notre application qui est l'utilisateur qui peut à la fois être
appelant (émettre des appels) et appelé (recevoir des appels).
2.1.2 Besoins fonctionnels
L'application cible doit orir les fonctionnalités suivantes :
Gérer un compte SIP :
Ajouter un compte SIP : Un premier lancement de l'application nécessite la saisie des infor-
mations relative au compte SIP qui sera utilisé pour pouvoir téléphoner. Ces informations
sont essentiellement : l'identiant SIP et le mot de passe utilisé.
Mettre à jour un compte SIP : L'application doit permettre à tout moment de recongurer
le compte SIP utilisé en modiant ses paramètres.
Emettre des appels vers des numéros SIP :
Deux cas de gures se présentent :
L'application doit permettre à l'utilisateur de composer directement une URI SIP et
d'émettre un appel vers cet URI.
L'application doit permettre à l'utilisateur de choisir un contact SIP enregistré et de l'ap-
peler.
1. Unied Modeling Language
10

Chapitre 2. Analyse et spécication
Recevoir des appels :
L'application doit permettre à l'utilisateur de recevoir des appels sur son compte SIP.
Garder un journal des appels :
Sauvegarder le journal : L'application doit garder automatiquement la trace et les détails
de tous les appels entrants et sortants .
Consulter le journal : L'application doit permettre, à la demande de l'utilisateur, l'achage
du journal des appels.
Gérer des contacts :
Ajouter un nouveau contact : L'application doit permettre l'ajout d'un nouveau contact.
Supprimer un contact existant : L'application doit permettre la suppression des contacts.
Modier un contact existant : L'application doit permettre la mise-à-jour des informations
d'un contact.
2.1.3 Besoins non fonctionnels
L'application doit satisfaire les facteurs de qualités suivants :
Réutilisablité :
Le code source de notre application doit être bien organisé, lisible et compréhensible. Les
tabulations, espacements, indentations et autres normes (appellation des variables, paramètres,
classes, méthodes, attributs doit être signicative) sont recommandés.
Ergonomie :
L'interface doit être moderne et le passage entre les diérents menus doit être intuitif. Les
éléments présents à l'écran doivent être de faible densité.
Performance :
L'application doit permettre d'échanger de la voix dans un régime de temps réel et lancer
des sevices en arrière plan quand c'est nécessaire.
Généricité :
L'application doit pouvoir communiquer avec n'importe quel entité SIP.
Ecacité :
L'application doit être assez légère dans le sens ou elle utilise le moins possible de ressources
matérielles.
Compatibilité :
L'application doit viser le maximum de terminaux Android.

2.2 Spécication
Les diagrammes de cas d'utilisation servent à illustrer le comportement fonctionnel de notre
application. Chaque cas d'utilisation représente un type d'interaction entre l'utilisateur et notre
système.
2.2.1 Cas d'utilisation
Cas d'utilisation global
La gure 2.1 représente le diagramme de cas d'utilisation global de notre système.
Figure 2.1 Diagramme des cas d'utilisation golbal
Ranements des cas d'utilisation
Les gures 2.2, 2.3 et 2.4 sont les ranements du diagramme des cas d'utilisation général de
la gure 2.1.

Emettre appel
Figure 2.2 Cas d'utilisation : Emettre appel
Recevoir appel
Figure 2.3 Cas d'utilisation : Recevoir appel

Ajouter contact
Figure 2.4 Cas d'utilisation : Ajouter contact SIP
2.2.2 Description des cas d'utilisation
Diagramme de séquence : Gérer compte SIP
Scénario nominal :
Figure 2.5 Diagramme de séquence système : Ajouter compte SIP scénario nominal
Premier scénario exceptionnel :
1. L'utilisateur saisit des données erronées.
2. Le système vérie les données.
3. Le système n'accepte pas les données introduites.
Deuxième Scénario exceptionnel :
1. L'utilisateur saisit des données syntaxiquement correctes.
2. Le système tempte de s'enregistrer auprès du serveur SIP spécié.
3. L'enregistrement échoue et le compte n'a pas été sauvegardé

Figure 2.6 Diagramme de séquence : Ajouter compte SIP scénarios exceptionnels
Diagramme de séquence : Emettre appel
Préconditions :
1. Le compte SIP est enregistré.
2. Pas d'appel déjà en cours.
Scénario nominal :
Figure 2.7 Diagramme de séquence : Emettre appel

Figure 2.8 Diagramme de séquence de référence : Conversation
Scénario alternatif :
1. L'appelant raccroche avant que l'appelé décroche.
2. L'appel est annulé. L'écran d'appel est fermé.
Diagramme de séquence : Recevoir appel
Préconditions :
1. Le compte SIP est enregistré.
2. Pas d'appel déjà en cours.
Scénario nominal :

Figure 2.9 Diagramme de séquence : Recevoir appel
1. L'appelé appuie sur le bouton raccrocher.
2. L'appel est refusé. L'écran d'appel est fermé automatiquement.
Diagramme de séquence : Ajouter contact
Précondition :
Contact inexistant.
Scénario nominal :

Figure 2.10 Diagramme de séquence : Ajouter contact SIP
1. L'utilisateur n'introduit pas le nom du contact ou son addresse SIP et appuie sur le
bouton d'ajout.
2. Le système lui ache un message lui indiquant que l'un des deux champs au moins
est vide.
Conclusion
Tout au long de ce chapitre nous avons essayé de spécier avec le degré de détails le plus
haut possible les besoins auxquels doit répondre notre application. La conception, qui se base
sur cette spécication, fera l'objet du prochain chapitre.

Chapitre 3
Conception
Après avoir explicité les fonctionnalités de notre logiciel, nous entamons le stade de concep-
tion. Nous présentons dans la partie conception globale de ce chapitre, le diérents composants
de notre application à travers un diagramme de paquetage. Dans la conception détaillée, nous
illustrons la vue structurelle par des diagrammes de classes et la vue comportementale par un
diagramme d'activité.
3.1 Conception globale
3.1.1 Diagramme de paquetage
Notre application se décompose en trois grandes parties essentiellement comme le montre la
gure 3.1. Il faut noter que les packages MjSIP et ActionBarSherlock sont des librairies externes
utiles à notre application.
Figure 3.1 Diagramme de paquetage
19

Chapitre 3. Conception
3.1.2 Description des paquetages
1. L'interface graphique : comme la partie statique est garantie par les chiers XML 1, la
partie dynamique de l'inteface graphique qui constitut l'IHM 2 qui permet l'interaction
avec l'utilisateur est assurée soit par les classes de type Activity 3 soit par les classes de
type Fragment 4.
2. SIP : C'est la partie qui s'exécute en arrière plan et qui gère le trac SIP/RTP et nous
pouvons en distinguer ds classes de type Service 5 ou BroadcastReceiver 6.
3. Base de données : Dans notre application, les données à sauvegarder peuvent prendre trois
formes : des paramètres persistants gérés par une classe qui hérite de SharedPreference 7,
une base de données locale de type SQLite et d'autres données stockées dans une classe
ContentValues 8.
3.2 Conception détaillée
3.2.1 Conception de l'IHM
Le diagramme de classe de la gure 3.2 illustre les principales classes appartenant au package
de l'IHM.
Figure 3.2 Diagramme de classes du package IHM
Le diagramme d'activité de la gure 3.3 montre les interactions possibles avec les diérentes
interfaces de notre application. Ce diagramme résume le cycle de vie de notre application.
1. eXtanded Markup Language
2. Interface Homme Machine
3. android.app.Activity
4. android.app.Fragement
5. android.app.Service
6. android.content.BroadcastReceiver
7. android.content.SharedPreferences
8. android.content.ContentValues

Figure 3.3 Diagramme d'activités

3.2.2 Conception de la base de donnée locale
La gure 3.4 illustre les classes utilisées dans la gestion des contacts.
Figure 3.4 Diagramme de classes du package Base de données
3.2.3 Traitement en arrière plan
Le diagramme de classe de la gure 3.5 illustre les principales classes appartenant au package
SIP.

Figure 3.5 Diagramme de classes du package SIP
3.3 Diagrammes de séquence
Figure 3.6 Diagramme de séquence - Ajouter Contact

L'ajout d'un contact est une fonctionnalité de notre application exprimée à l'aide du dia-
gramme de séquence de la gure 3.6.
L'utilisateur, suite à l'appui sur le bouton Ajouter contact se trouvant dans le fragment
ContactsFrag se situe dans une nouvelle activité AddconActivity. Dans cette dernière il va
remplir les champs obligatoires Nom, SIP URI et optionellement E-mail et une image du contact.
Après l'insertion des données, le système vérie leurs validités en envoyant un message d'er-
reur dans le cas échéant.
Lorsque les données sont valides et avec l'appui sur le bouton Ajouter on va créer un nouveau
contact avec la méthode createContact(String,String,String,String) de la classe ContactDB. Fi-
nalement, un retour au fragment ContactsFrag aura lieu avec l'achage de la liste des contacts
et parmi eux le contact nouvellement ajouté.
Figure 3.7 Diagramme de séquence - Modier Contact
Notre application ore la possibilité de modier les contacts, ce qui est illustré par la gure
3.7. En eet, dans le fragment ContactsFrag, la sélection d'un élément de la liste des contacts
permet le passage à une autre activité qui est ShowContact. Dans cette dernière, l'appui sur le
bouton Modier Contact induit à son tour le passage à l'activité ModifContact. L'utilisateur
insère les modications spéciques. Le système vérie ainsi la validité des données introduites.
Dans le cas échéant, il envoie un message d'erreur jusqu'à leur acceptation. Une mise à jour du
contact est alors faite et ce à l'aide de la méthode updateContactWithId(int,Contact) de la classe
ContactDB.

Figure 3.8 Diagramme de séquence - Supprimer Contact
Une fonctionnalité de suppression de contact est décrite dans la gure 3.8 comme suit : en
appuyant sur le bouton Supprimer se trouvant dans l'activité ModifContact, nous pourrons
supprimer le contact en question grâce à la méthode RemoveContactWithName(String) de la
classe ContactDB.
Figure 3.9 Diagramme de séquence - Appeler Adresse SIP
La gure 3.9 montre l'enchaînement des actions pour émettre un appel vers une adresse SIP.

Ceci commence par la saise d'une SIP URI correcte du destinataire. Ensuite le fait d'appuyer
sur le bouton d'émission d'appel permet de lancer un dialogue SIP en background, qui une fois
terminé par un message 180 RINGING signalant que l'appelé est joignable et non occupé avec la
méthode onCallConrmed(), permet le lancement d'une nouvelle activité Call. La session audio
RTP est ouverte une fois l'appelé décroche, qui est un évènement signalé par onCallAccepeted(),
et peut nir quand l'un des deux bouts de la session décide d'appuyer sur le bouton qui permet
de Raccrocher.
Figure 3.10 Diagramme de séquence - Recevoir Appel SIP
Notre application reste à l'écoute de nouveaux appels entrants. Les appels reçus sont signalés
par l'achage en premier plan de l'activité Call qui permet soit de décrocher soit d'ignorer
l'appel comme le montre la gure 3.10. Une fois la communication établie, une session audio RTP
est automatiquement lancée. Le ux RTP n'est coupé que lorsque l'appel est terminé ; c'est-à-dire
quand un des deux extrêmités décide d'appuyer sur le bouton Raccrocher.
Conclusion
Dans ce chapitre, nous avons détaillé à l'aide des diagrammes UML, la conception de notre
application dont la réalisation va suivre dans le chapitre suivant.

Chapitre 4
Réalisation
Ce chapitre permet de présenter les résultats du travail achevé. Tout d'abord, nous y précisons
les caractéristiques du matériel utilisé et les logiciels choisis dans l'élaboration de ce projet pour
justier ensuite les choix techniques adoptés. Enn, nous nissons par exposer les diérentes
interfaces de notre application.
4.1 Environnement de travail
Il est indispensable de connaître les caractéristiques du matériel qui a permis la réalisation
de ce projet ainsi que les diérents logiciels utilisés.
4.1.1 Environnement matériel
Ordinateurs portables
Durant ce projet, nous avons utilisé chacun son ordinateur personnel dont les principales
caractérstiques sont mentionnées respectivement dans les tableaux 4.1 et 4.2.
Modèle HP Compaq 6830s
CPU Intel(R) Core(TM)2 Duo T5870 2x2.00GHz
RAM 2990 MiB
Disque dur 250Gb
Table 4.1 Caractéristiques du HP Compaq 6830s
Modèle Dell Inspiron n5110
CPU Intel(R)Core(TM) i7-2670QM CPU @ 2.20 GHz
RAM 8192 MiB
Disque dur 500Gb
Table 4.2 Caractéristiques du Dell Inspiron n5110
27

Chapitre 4. Réalisation
Smartphones
Pour debugger et tester l'application, hormis l'usage fréquent des AVD 1s, nous avons utilisé
deux smartphones de la marque Samsung totalement diérents dans leurs caractéristiques surtout
la version de l'OS 2 et le type d'achage. Les tableaux 4.3 et 4.4 résument ces caractéristiques.
Modèle Samsung GALAXY Mini Gt5570
CPU Single core, 600 MHz, ARM11
Mémoire interne 0.16 Gb
Mémoire externe 2 Gb (microSD)
Résolution 240 x 320 pixels
Table 4.3 Caractéristique du Samsung Gt5570
Modèle Samsung GALAXY Nexus
CPU Dual core, 1200 MHz, ARM Cortex-A9
RAM 1024 MB
Mémoire interne 32 GB
Résolution 720 x 1280 pixels
Table 4.4 Caractéristique du GALAXY Nexus
4.1.2 Environnement logiciel
Utilitaires SIP
Serveur SIP : Pour pouvoir tester notre application en local, nous avons opté pour le serveur
IPBX 3 open-source le plus utilisé : Asterisk de Digium. Nous avant tout d'abord essayé la
compilation AsteriskNow 11 qui n'est tout autre que la distribution GNU/Linux CentOS
avec Asterisk et FreePBX pré-installés. Cependant nous avons eu des problèmes avec cette
version d'Asterisk qui nous a obligé à migrer vers une version plus stable et nous avons
choisi d'installer Asterisk 1.8 sur Ubuntu.
Client SIP : Pour pouvoir eectuer des manipulations autour du protocole SIP nous avons
utilisé sipSAK un outil de tests SIP accessible en ligne de commande. Cet outil puissant
est qualié de couteau suisse SIP.
Logiciels divers
Tous les logiciels utilisés durant notre projet sont énumérés dans le tableau 4.5.
1. Android Virtual Device
2. Operating System
3. IP Private Branch eXchange

IDE Eclipse Juno avec ADT v21.1.0
Modélisation UML 2.0 Microsoft Visio 2013
Editeur Latex
GNU/Linux Texmaker 3.2
Microsoft Windows WinEdit
Système d'exploitation
Ordinateur 1 Ubuntu 12.04 LTS 32bits
Ordinateur 2 Microsoft Windows 7 64bits
Téléphone 1 Android 2.3.6 (Gingerbread)
Téléphone 2 Android 4.2 (Jelly Bean)
VCS 4 Git avec EGit
Table 4.5 Environnement logiciel
4.2 Choix technologiques
4.2.1 SDK
Nous avons choisi de travailler avec la dernière version disponible et stable d'Android à savoir
Android 4.2.x Jelly Bean (API 17) mais nous avons aussi pris en considération les autres versions
précedentes d'Android et nous avons xé la version minimale recquise dans le manifest.xml de
notre application à l'API 9 qui est l'équivalent d'Android 2.3.x (Gingerbread) et ceci pour viser
le maximum d'utilisateurs vu qu'il existe encore une grande partie de terminaux Android encore
équipés par cette version [10].
4.2.2 ActionBarSherlock
Figure 4.1 Position de l'ActionBar dans l'écran
ActionBar [14] est un composant graphique essentiel des applications Android, qui apparaît
en haut de chaque écran, sous la barre de notication comme le montre la gure 4.1. Il permet
notamment de donner une identité visuelle à l'application (icône et nom). Cette barre permet

également de naviguer entre les diérentes fragments de l'application. ActionBar est disponible
dans le SDK Android ociel, depuis la version 3.0 Honeycomb d'Android (avec des améliora-
tions importantes dans la version 4.0 Ice Cream Sandwich). Le souci majeur est que l'usage de
l'ActionBar dans une application, rend cette dernière incompatible avec les versions Android
antérieures à 3.0.
ActionBarSherlock est la solution à ce problème. ABS 5 est donc une extension de la librairie
de compatibilité faite pour faciliter l'utilisation de la barre d'action à travers toutes les versions
d'Android avec l'utilisation d'une seule API. La stratégie de Jake Wharton, initiateur et princiapl
développeur du projet ABS, a été plutôt simple : utiliser le code source mis à disposition sur
le projet AOSP 6 et faire les modications nécessaires pour le faire fonctionner sur des versions
antérieures. Pour résumer ABS, c'est :
l'API standard de l'ActionBar adaptée sur n'importe quelle version d'Android
l'implémentation native sur Android 4.x : il se comporte alors simplement comme une
simple wrapper
une implémentation dédiée pour toutes les versions antérieures à 4.0 en utilisant une version
largement modiée par rapport à ce qui est disponible dans le projet AOSP
4.2.3 MjSip
L'implémentation par défaut du protocole SIP dans le SDK d'Android est disponible à partir
de la version 9 de l'API, cependant cette implémentation soure de beaucoup de problèmes et
il n'existe presque pas d'applications sur le Google Play Store qui l'utilise. Parmi les défauts
majeurs de la pile SIP d'Android est son incompatiblité avec plusieurs appareils[11]. Nous avons
téléchargé et essayé l'exemple diditacticiel ociel qui montre l'utilisation des APIs SIP. Notre
test conrme ce que nous avons lu sur le web, le projet n'a pas pu s'exécuter car notre appareil
est non supporté par SipManager. Ceci ne prouve qu'une chose ; le côté SIP avec Android est
presque délaissé.
Pour ce qui est du protocole RTP, même s'il a été utilisé dès l'API 9 à côté du protocole SIP, il
n'a été rendu publique qu'en API 12[12]. Or, notre projet doit être compatible avec les versions
d'Android antérieures à l'API 12. C'est pourquoi on a délaissé l'usage des classes RTP d'Android.
C'est ainsi que nous nous sommes mis à chercher une alternative, donc une implémentation
troisième-tier de la pile SDP/SIP/RTP. Après avoir mis beaucoup de temps pour la recherche
et la documentation sur les diérents choix, nous avons nit par opter pour MjSip et nous avons
écarté JainSIP, NGN 7 Stack de Doubango et PjSIP pour les raisons suivantes :
La librairie JainSIP[17] ne peut pas s'ajouter à un projet Android à cause des conits de
nommage avec les classes SIP ocielles qui sont inspirées de celles de JainSIP[18].
PjSIP[15] est écrite en C, d'où la nécessité de développer avec le NDK 8 en utilisant les
glsJNIs. Cette approche nous a paru hazardeuse et risquée vu que nous sommes encore à
nos débuts avec Android. De plus, PjSIP ne présente pas encore de version ocielle pour
Android.
NGN-Stack de Doubango [16] est trop gourmande en espace mémoire et ajoute des fonc-
tionnalités jugés inutiles dans notre projet.
Par élémination des autres choix, nous nous sommes trouvés contraints à utiliser MjSIP[13]
qui n'était pas notre premier choix dès le début vu que cette librairie est presque stagnante
5. ActionBarSherlock
6. Android Open Source Project
7. Next Generation Network
8. Native Development Kit

et manque énormément de documentation. Nous avons découvert plus tard dans la phase de
réalisation, d'autres défauts dans MjSIP.
4.2.4 SQLite
Pour sauvegarder les contacts de notre application nous avons opté pour l'option d'une base
de données locale à l'aide du SGBD 9 SQLite. Ce dernier a été intégré sans le coeur même
d'Android.Il ne nécessite pas de serveur pour fonctionner donc son exécution se fait dans le
même processus que celui de l'application. Par ailleurs, il faut le maîtriser an de ne pas alourdir
l'application.
4.3 Description des interfaces
4.3.1 Gestion du compte SIP
Ajout du compte SIP :
Un premier lancement de l'application va automatiquement déclencher l'achage de l'activité
Ajouter Compte qui demandera la saisie de l'adresse SIP de l'utilisateur et son mot de passe
comme le montre la gure 4.2.
Figure 4.2 Activité Ajouter compte
Plusieurs tests sont exécutés en local avant la vérication avec le serveur qui peut prendre
un laps de temps d'où l'écran de chargement illustré par la gure 4.5. Parmi ces tests : le test de
champs vides dont la gure 4.3 donne un exemple et le test syntaxique du champ adresse SIP
(voir 4.4).
9. Système de Gestion de Bases de Données

Figure 4.3 Message d'erreur quand un
des champs au moins est laissé vide
Figure 4.4 SIP URI non conforme à la
norme
Figure 4.5 Ecran de chargement
Modication de compte SIP
Il est possible de modier les paramètres de votre compte SIP à tout moment, ceci grâce à
l'interface montrée par la gure 4.6.

Figure 4.6 Interface de modication du compte SIP
Les deux gures 4.7 et 4.8 montrent les boites de dialogues qui s'ouvrent lors de l'insertion
des nouvelles valeurs du compte SIP.
Figure 4.7 Boite de dialogue de change-
ment d'identiant SIP
Figure 4.8 Boite de dialogue de change-
ment de mot de passe

4.3.2 Interface d'appel
La gure 4.9 présente l'interface d'émission d'appels qui est l'interface qui est achée en
premier lieu à chaque nouveau démarrage de l'application sauf le cas où nous n'avons pas encore
conguré le compte SIP. A partir de ce fragment du menu principal, il est possible d'appeler
le contact composé dans le champ Adresse SIP après avoir vérié les tests habituels sur les
champs obligatoires ou ceux de type URI SIP.
Figure 4.9 Interface d'émission des appels
Dès que l'application détecte l'arrivé d'un appel entrant l'interface illustré par la gure 4.10
s'ache immédiatement à l'écran en premier plan.

Figure 4.10 Interface d'appel entrant
4.3.3 Gestion des contacts
Ajouter Contact :
An d'ajouter un contact, une saisie de ses données est nécessaire. On a deux champs obli-
gatoires : Nom et SIP URI et deux champs optionnels : E-mail et Image du contact. Notre
application ore la possibilté de choisir soit une image déja existante dans la galerie des photos
soit une prise instantannée d'une photo par l'appareil photo du mobile.
Dans le cas de la non sélection d'une image, une image par défaut sera aectée au contact
nouvellement ajouté.

Figure 4.11 Contact nom vide Figure 4.12 Contact nom existant
Dans les deux gures précédentes 4.11 et 4.12, nous mettons en valeur les vérifcations faites
par notre application par rapport au nom du contact. Le champ nom étant obligatoire par
conséquent il doit être non vide et an d'éliminer toute redondance des noms de contacts un test
est alors implémenté.
Figure 4.13 Contact SIP Uri vide Figure 4.14 Contact SIP URI invalide
Nous visualisons dans les deux gures 4.13 et 4.14 les vérications faites par rapport au
deuxième champ obligatoire SIP URI. Lui aussi il doit être non vide et sa validité est determinée
à partir de sa contenance à @.

Figure 4.15 E-mail non valide
La gure précédente 4.15 clarie le test fait par rapport à la saisie du champ optionnel E-mail.
Figure 4.16 Choisir photo Figure 4.17 Prendre photo
Les deux gures ci dessus 4.16 et 4.17 présentent les deux possibilités avec lesquelles l'utili-
sateur peut personnaliser l'image du contact et ce soit en choisissant une photo contenue dans
la galerie soit en prenant une capture d'image instantannée.

Figure 4.18 Liste des contacts
La gure précédente 4.18 nous permet de visualiser la liste des diérents contacts.
Acher Contact :
La sélection d'un contact se trouvant dans la liste des contacts nous permet de visualiser ses
données déja enregistrées et une possibilité de sa modication ou de sa suppression.
Figure 4.19 Sans champs optionnels Figure 4.20 Avec champs optionnels
La gure 4.19 montre l'exemple d'un contact enregistré avec seulement les champs obligatoires
(Nom et SIP URI),une photo par défaut est alors lui aectée. Quant à la seconde gure 4.20 ,
elle nous permet de visulaiser toutes les données mêmes les optionnelles.

Modier Contact :
Notre application permet de modier les données relatives aux contacts enregistrés dans sa
base de données.
Figure 4.21 Modier Contact
La gure ci dessus 4.21 illustre l'interface de modication de contact.
Figure 4.22 Liste après modication Figure 4.23 Achage contact modié
Les gures précédentes 4.22 et 4.23 permettent de visualiser les modications faites par
rapport au contact sélectionné.

Gestion du compte
4.4 Chronogramme du travail
Figure 4.24 Chronogramme du travail
Conclusion
Dans ce chapitre, nous avons décrit l'environnement de travail. Ensuite, nous avons argumenté
les diérents choix technologiques que nous avons pris. En dernier lieu, nous avons pris quelques
captures d'écran des principales interfaces de notre application.

Conclusion générale
L'objectif de ce projet a été de concevoir et de développer une application Android de télé-
phonie sur IP en se basant principalement sur le protocole SIP.
Dans ce rapport, les notions théoriques de base concernant l'architecture protocolaire de
VoIP choisie ont été explicitées ainsi qu'une étude de deux exemples de softphones SIP déjà
existant. Ensuite, les besoins auxquels est censée répondre notre application ont été énumérées
puis spéciées.
La conception a été illustrée par les diérents diagrammes de la norme UML 2.0, suivie de la
partie réalisation où les résultats pratiques de notre projet ont pu être présentés après avoir
précisé l'environnement de travail.
La réalisation de ce projet a été l'étape la plus délicate faute de variétés de choix technologiques
et de documentation. L'absence d'APIs de qualité des protocoles concernés par notre application,
à savoir SIP et RTP destinées à Android nous a rendu la tâche encore plus dicile. Même le
choix de MjSIP était mal placé. Cependant nous avons pu réaliser les parties fonctionnelles de
notre application et nous avons réussi à réaliser une interface graphique utilisant les nouveautés
d'Android et adaptées aux anciennes versions de l'OS grâce à la libraire ActionBarSherlock, mais
tout celà au dépit de la qualité de service.
Tout au long de ce projet, nous avons appris une certaine autonomie dans la prise de décision
et une meilleure gestion du temps grâce à la combinaison Git/GitHub. Nous avons eu aussi
l'occasion d'exploiter notre savoir théorique acquis surtout en matière de conception.
Notre travail pourrait servir de support pour d'autres projets Android ou VoIP. Les principales
améliorations éventuelles à notre applications seraient l'ajout de la gestion multi-comptes SIP et
d'autres codecs audio.
41

Bibliographie
[1] Gonzalo Camarillo. SIP Demystied. McGraw-Hill, 2002.
[2] Rogelio Martínez Perea. Internet Multimedia Communications Using SIP, A Modern Ap-
proach Including Java R Practice. Elsevier, Inc., 2008.
[3] Henry Sinnreich and Alan B. Johnston. Internet Communications Using SIP Delivering
VoIP and Multimedia Services with Session Initiation Protocol. Wiley Publishing,Inc., second
edition, 2006.
42

Nétographie
[4] http://thd.tn/index.php?option=com_contentview=articleid=2359:
le-ministere-des-tic-libere-la-voip-de-lemprise-de-letat-orange-tunisie-peut-relancer-s
64Itemid=361
dernière consultation 20 Janvier 2013
[5] https://play.google.com/store/search?q=sipc=apps
[6] https://play.google.com/store/apps/details?id=org.sipdroid.sipua
[7] http://sipdroid.com/
[8] https://play.google.com/store/apps/details?id=com.csipsimple
[9] http://r3gis.fr/blog/index.php?post/2009/10/31/SipDroid-and-Direct-RTP
[10] http://developer.android.com/about/dashboards/index.html
dernière consultation 12 Avril 2013
[11] http://developer.android.com/guide/topics/connectivity/sip.html
[12] http://developer.android.com/reference/android/net/rtp/RtpStream.html
[13] http://www.mjsip.org/
dernière consultation 06 Mai 2013
[14] http://actionbarsherlock.com/
dernière consultation 02 Mai 2013
[15] http://www.pjsip.org/
[16] http://www.doubango.org/
[17] https://jsip.java.net/
[18] http://stackoverflow.com/questions/tagged/jain-sip+android
43

Annexe A
Changer l'apparence de l'émulateur Android
An de modier l'apparence de l'AVD pour qu'il ressemble à un smartphone réel, il est
possible de lui faire changer de skin. Dans la dernière version du plugin ADT 1 disponible 21.1.0,
personnaliser son émulateur est devenu une tâche un peu complexe puisque l'ancienne méthode
graphique n'est plus supportée. Ainsi, une utilisation de la ligne de commande s'impose. Nous
allons décrire les diérentes étapes nécessaires de la personnalisation du skin de l'émulateur :
1. Créer un nouveau AVD en choisissant l'appareil souhaité :
Figure A.1 Création d'un nouveau AVD
2. Choisir un skin d'un appareil mobile de votre choix : Nous partageons avec vous la source
1. Android Development Toolkit
44

Annexe A : Changer l'apparence de l'émulateur Android
du skin qu'on a utilisée et qui comporte les skins pour les appareils Samsung suivants :
Galaxy Nexus, Nexus S, Nexus One, Galaxy Note, Nexus 7 et Nexus 10. http://github.
com/mingchen/android-emulator-skins/
3)Placer le dossier du skin téléchargé sous sdk/platfroms/android-[version d'API choi-
sie]/skins
Dons notre exemple nous allons mettre le dossier NEXUS-S sous : sdk/platfroms/android-
17/skins
3. Sur la ligne de commande taper :
cd .android/avd/[Nom de l'avd que vous venez de créer].avd
gedit cong.ini
Figure A.2 Ligne de commande
et là vous modier les deux champs :
skin.name=[Nom du dossier téléchargé]
skin.path=/platfroms/android-[version d'API]/skins/[Nom du dossier téléchargé]
Figure A.3 Modication du chier conf.ini
4. Exécuter votre application Android avec l'AVD nouvellement créé :

Annexe A : Changer l'apparence de l'émulateur Android
Figure A.4 Avant la personnalisation de
l'AVD avec le skin
Figure A.5 Après la personnalisation de
l'AVD avec le skin

Annexe B
Ajouter la bibliothèque ActionBarSherlock à
un projet Android sous Eclipse
1. Télécharger la version de la bibliothèque souhaitée depuis ce lien : http://actionbarsherlock.
com/download.html
Nous avons travaillé avec la version 4.3.1
2. Sous Eclipse : Choisir File - import - Existing Android Code into Workspace
Figure B.1 Importer Code Android existant
Puis parcourir l'endroit où vous avez enregistré la bibliothèqe téléchargée. Choisir la ré-
pertoire contenant la bibliothèque actionbarsherlock (pour les versions antérieures à 4.3 le
dossier est nommé library).
47

Annexe B : Ajouter la bibliothèque ABS à un projet Android sous Eclipse
Figure B.2 Sélectionner répertoire spécique
3. Ajouter la bibliothèque à votre projet : Click droit sur le projet concerné - Properties -
Android. Ajouter ensuite la bibliothèque.
Figure B.3 Ajouter la bibliothèque au projet Android
4. Supprimer le chier android-support-v4.jar localisé dans le répertoire libs de votre
projet an de xer l'erreur de type jar mismatch.

Glossary
3G Troisième Génération. 1
ABS ActionBarSherlock. 30
ADT Android Development Toolkit. 44
AOSP Android Open Source Project. 30
API Application Programming Interface. 1, 7, 29, 30, 41
ASCII American Standard Code for Information Interchange. 3
AVD Android Virtual Device. 28, 44
DNS Domain Name System. 3
GNU GNU's Not Unix. 7
GPL General Public License. 7
HTTP Hyper Text Transport Protocol. 2, 3
IETF Internet Engineering Task Force. 2
IHM Interface Homme Machine. 20
IP Internet Protocol. I, 14
IPBX IP Private Branch eXchange. 28
LS Location Server. 3
MD5 Message Digest 5. 6
NDK Native Development Kit. 30
NGN Next Generation Network. 30
OOP Object-Oriented Programming. I
OS Operating System. 28
POO Programmation Orientée Objet. I
RFC Request For Comment. 2
49

Glossaire
RG Registrar. 3
RTCP RTP Control Protcol. 4, 5
RTP Real-time Transport Protocol. I, 4, 5, 30, 41
SDK Sofware Development Kit. 1, 30
SDP Session Description Protocol. I, 4, 30
SGBD Système de Gestion de Bases de Données. 31
SIP Session Initiation Protocol. I, 15, 7, 20, 30, 36, 38, 41
SMTP Simple Mail Transport Protocol. 2
TCP Transmission Control Protocol. 24
UAC User Agent Client. 3
UAS User Agent Server. 3
UDP User Datagram Protocol. 3, 4
UML Unied Modeling Language. 10, 26, 29, 41
URI Uniform Resource Identier. 3, 36, 38
VCS Version Control System. 29
VoIP Voice over IP. I, 1, 2, 41
XML eXtanded Markup Language. 20

Android VoIP/SIP Softphone

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Android VoIP/SIP Softphone

Similar a Android VoIP/SIP Softphone (20)

Último

Último (20)

Android VoIP/SIP Softphone