Ministère de l'Enseignement Supérieur et de la Recherche
Scientifique
Université de la Manouba
École Nationale Des Science...
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éveloppeme...
Abstract
VoIP/SIP Softphone for Android :
This work, conducted under the software design and implementation project for th...
Remerciements
Nous voudrions exprimer notre gratitude et notre reconnaissance envers tous ceux qui ont
contribué à l'accom...
Table des matières
Introduction générale 1
1 Étude préalable 2
1.1 État de l'art . . . . . . . . . . . . . . . . . . . . ....
4 Réalisation 27
4.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Envir...
Table des gures
1.1 Fonctionnement de base de SIP [3] . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Enregistre...
4.10 Interface d'appel entrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.11 Contact nom vide . ...
Liste des tableaux
1.1 Tableau comparatif entre solutions existantes étudiées et solution proposée . . . . 9
4.1 Caractéri...
Introduction générale
Avec la banalisation des réseaux haut débit, notamment la 3G 8, le nombre d'applications
possibles a...
Chapitre 1
Étude préalable
Dans ce chapitre, nous allons en premier lieu introduire les bases théoriques, terminologie
et ...
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 archite...
Chapitre 1. Étude préalable
1.1.3 Protocole SDP
Pour décrire la session dans le corps de quelques messages du protocole SI...
Chapitre 1. Étude préalable
 synchroniser le ux de données du côté du destinataire grâce aux marqueurs temporels ou
timest...
Chapitre 1. Étude préalable
de type WWWAuthenticate une clé appelée nonce que l'utilisateur doit utiliser avec l'algorithm...
Chapitre 1. Étude préalable
SipDroid
Figure 1.3  Interface de SipDroid : Activité principale avec menu apparent
SipDroid[6...
Chapitre 1. Étude préalable
CSipSimple
Figure 1.4  Aperçu de l'interface de CSipSimple
CSipSimple[8] a été créé par Régis ...
Chapitre 1. Étude préalable
Table 1.1  Tableau comparatif entre solutions existantes étudiées et solution proposée
Applica...
Chapitre 2
Analyse et spécication
Dans le présent chapitre, nous commençons par identier l'acteur de notre application et
...
Chapitre 2. Analyse et spécication
Recevoir des appels :
L'application doit permettre à l'utilisateur de recevoir des appe...
Chapitre 2. Analyse et spécication
2.2 Spécication
Les diagrammes de cas d'utilisation servent à illustrer le comportement...
Chapitre 2. Analyse et spécication
Emettre appel
Figure 2.2  Cas d'utilisation : Emettre appel
Recevoir appel
Figure 2.3  ...
Chapitre 2. Analyse et spécication
Ajouter contact
Figure 2.4  Cas d'utilisation : Ajouter contact SIP
2.2.2 Description d...
Chapitre 2. Analyse et spécication
Figure 2.6  Diagramme de séquence : Ajouter compte SIP scénarios exceptionnels
Diagramm...
Chapitre 2. Analyse et spécication
Figure 2.8  Diagramme de séquence de référence : Conversation
 Scénario alternatif :
1....
Chapitre 2. Analyse et spécication
Figure 2.9  Diagramme de séquence : Recevoir appel
 Scénario alternatif :
1. L'appelé a...
Chapitre 2. Analyse et spécication
Figure 2.10  Diagramme de séquence : Ajouter contact SIP
 Scénario alternatif :
1. L'ut...
Chapitre 3
Conception
Après avoir explicité les fonctionnalités de notre logiciel, nous entamons le stade de concep-
tion....
Chapitre 3. Conception
3.1.2 Description des paquetages
1. L'interface graphique : comme la partie statique est garantie p...
Chapitre 3. Conception
Figure 3.3  Diagramme d'activités
Rapport de PCD 21 2012 - 2013
Chapitre 3. Conception
3.2.2 Conception de la base de donnée locale
La gure 3.4 illustre les classes utilisées dans la ges...
Chapitre 3. Conception
Figure 3.5  Diagramme de classes du package SIP
3.3 Diagrammes de séquence
Figure 3.6  Diagramme de...
Chapitre 3. Conception
L'ajout d'un contact est une fonctionnalité de notre application exprimée à l'aide du dia-
gramme d...
Chapitre 3. Conception
Figure 3.8  Diagramme de séquence - Supprimer Contact
Une fonctionnalité de suppression de contact ...
Chapitre 3. Conception
Ceci commence par la saise d'une SIP URI correcte du destinataire. Ensuite le fait d'appuyer
sur le...
Chapitre 4
Réalisation
Ce chapitre permet de présenter les résultats du travail achevé. Tout d'abord, nous y précisons
les...
Chapitre 4. Réalisation
Smartphones
Pour debugger et tester l'application, hormis l'usage fréquent des AVD 1s, nous avons ...
Chapitre 4. Réalisation
IDE Eclipse Juno avec ADT v21.1.0
Modélisation UML 2.0 Microsoft Visio 2013
Editeur Latex
GNU/Linu...
Chapitre 4. Réalisation
également de naviguer entre les diérentes fragments de l'application. ActionBar est disponible
dan...
Chapitre 4. Réalisation
et manque énormément de documentation. Nous avons découvert plus tard dans la phase de
réalisation...
Chapitre 4. Réalisation
Figure 4.3  Message d'erreur quand un
des champs au moins est laissé vide
Figure 4.4  SIP URI non ...
Chapitre 4. Réalisation
Figure 4.6  Interface de modication du compte SIP
Les deux gures 4.7 et 4.8 montrent les boites de...
Chapitre 4. Réalisation
4.3.2 Interface d'appel
La gure 4.9 présente l'interface d'émission d'appels qui est l'interface q...
Chapitre 4. Réalisation
Figure 4.10  Interface d'appel entrant
4.3.3 Gestion des contacts
Ajouter Contact :
An d'ajouter u...
Chapitre 4. Réalisation
Figure 4.11  Contact nom vide Figure 4.12  Contact nom existant
Dans les deux gures précédentes 4....
Chapitre 4. Réalisation
Figure 4.15  E-mail non valide
La gure précédente 4.15 clarie le test fait par rapport à la saisie...
Chapitre 4. Réalisation
Figure 4.18  Liste des contacts
La gure précédente 4.18 nous permet de visualiser la liste des dié...
Chapitre 4. Réalisation
Modier Contact :
Notre application permet de modier les données relatives aux contacts enregistrés...
Chapitre 4. Réalisation
Gestion du compte
4.4 Chronogramme du travail
Figure 4.24  Chronogramme du travail
Conclusion
Dans...
Conclusion générale
L'objectif de ce projet a été de concevoir et de développer une application Android de télé-
phonie su...
Bibliographie
[1] Gonzalo Camarillo. SIP Demystied. McGraw-Hill, 2002.
[2] Rogelio Martínez Perea. Internet Multimedia Com...
Nétographie
[4] http://thd.tn/index.php?option=com_contentview=articleid=2359:
le-ministere-des-tic-libere-la-voip-de-lemp...
Annexe A
Changer l'apparence de l'émulateur Android
An de modier l'apparence de l'AVD pour qu'il ressemble à un smartphone...
Annexe A : Changer l'apparence de l'émulateur Android
du skin qu'on a utilisée et qui comporte les skins pour les appareil...
Annexe A : Changer l'apparence de l'émulateur Android
Figure A.4  Avant la personnalisation de
l'AVD avec le skin
Figure A...
Annexe B
Ajouter la bibliothèque ActionBarSherlock à
un projet Android sous Eclipse
1. Télécharger la version de la biblio...
Annexe B : Ajouter la bibliothèque ABS à un projet Android sous Eclipse
Figure B.2  Sélectionner répertoire spécique
3. Aj...
Glossary
3G Troisième Génération. 1
ABS ActionBarSherlock. 30
ADT Android Development Toolkit. 44
AOSP Android Open Source...
Glossaire
RG Registrar. 3
RTCP RTP Control Protcol. 4, 5
RTP Real-time Transport Protocol. I, 4, 5, 30, 41
SDK Sofware Dev...
Prochain SlideShare
Chargement dans…5
×

Android VoIP/SIP Softphone

4 222 vues

Publié le

Publié dans : Ingénierie
2 commentaires
4 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
4 222
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
408
Commentaires
2
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Android VoIP/SIP Softphone

  1. 1. 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
  2. 2. Signature de l'encadrant M. Mezgheni Dhafer
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. Chapitre 1. Étude préalable 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 Rapport de PCD 4 2012 - 2013
  15. 15. Chapitre 1. Étude préalable 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 Rapport de PCD 5 2012 - 2013
  16. 16. Chapitre 1. Étude préalable 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 Rapport de PCD 6 2012 - 2013
  17. 17. Chapitre 1. Étude préalable 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) Rapport de PCD 7 2012 - 2013
  18. 18. Chapitre 1. Étude préalable 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 Rapport de PCD 8 2012 - 2013
  19. 19. Chapitre 1. Étude préalable 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. Rapport de PCD 9 2012 - 2013
  20. 20. 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
  21. 21. 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. Rapport de PCD 11 2012 - 2013
  22. 22. Chapitre 2. Analyse et spécication 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. Rapport de PCD 12 2012 - 2013
  23. 23. Chapitre 2. Analyse et spécication Emettre appel Figure 2.2 Cas d'utilisation : Emettre appel Recevoir appel Figure 2.3 Cas d'utilisation : Recevoir appel Rapport de PCD 13 2012 - 2013
  24. 24. Chapitre 2. Analyse et spécication 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é Rapport de PCD 14 2012 - 2013
  25. 25. Chapitre 2. Analyse et spécication 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 Rapport de PCD 15 2012 - 2013
  26. 26. Chapitre 2. Analyse et spécication 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 : Rapport de PCD 16 2012 - 2013
  27. 27. Chapitre 2. Analyse et spécication Figure 2.9 Diagramme de séquence : Recevoir appel Scénario alternatif : 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 : Rapport de PCD 17 2012 - 2013
  28. 28. Chapitre 2. Analyse et spécication Figure 2.10 Diagramme de séquence : Ajouter contact SIP Scénario alternatif : 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. Rapport de PCD 18 2012 - 2013
  29. 29. 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
  30. 30. 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 Rapport de PCD 20 2012 - 2013
  31. 31. Chapitre 3. Conception Figure 3.3 Diagramme d'activités Rapport de PCD 21 2012 - 2013
  32. 32. Chapitre 3. Conception 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. Rapport de PCD 22 2012 - 2013
  33. 33. Chapitre 3. Conception Figure 3.5 Diagramme de classes du package SIP 3.3 Diagrammes de séquence Figure 3.6 Diagramme de séquence - Ajouter Contact Rapport de PCD 23 2012 - 2013
  34. 34. Chapitre 3. Conception 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. Rapport de PCD 24 2012 - 2013
  35. 35. Chapitre 3. Conception 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. Rapport de PCD 25 2012 - 2013
  36. 36. Chapitre 3. Conception 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. Rapport de PCD 26 2012 - 2013
  37. 37. 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
  38. 38. 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 Rapport de PCD 28 2012 - 2013
  39. 39. Chapitre 4. Réalisation 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 Rapport de PCD 29 2012 - 2013
  40. 40. Chapitre 4. Réalisation é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 Rapport de PCD 30 2012 - 2013
  41. 41. Chapitre 4. Réalisation 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 Rapport de PCD 31 2012 - 2013
  42. 42. Chapitre 4. Réalisation 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. Rapport de PCD 32 2012 - 2013
  43. 43. Chapitre 4. Réalisation 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 Rapport de PCD 33 2012 - 2013
  44. 44. Chapitre 4. Réalisation 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. Rapport de PCD 34 2012 - 2013
  45. 45. Chapitre 4. Réalisation 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é. Rapport de PCD 35 2012 - 2013
  46. 46. Chapitre 4. Réalisation 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 à @. Rapport de PCD 36 2012 - 2013
  47. 47. Chapitre 4. Réalisation 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. Rapport de PCD 37 2012 - 2013
  48. 48. Chapitre 4. Réalisation 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. Rapport de PCD 38 2012 - 2013
  49. 49. Chapitre 4. Réalisation 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é. Rapport de PCD 39 2012 - 2013
  50. 50. Chapitre 4. Réalisation 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. Rapport de PCD 40 2012 - 2013
  51. 51. 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
  52. 52. 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
  53. 53. 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 dernière consultation 11 Janvier 2013 [6] https://play.google.com/store/apps/details?id=org.sipdroid.sipua dernière consultation 15 Janvier 2013 [7] http://sipdroid.com/ dernière consultation 29 Janvier 2013 [8] https://play.google.com/store/apps/details?id=com.csipsimple dernière consultation 15 Janvier 2013 [9] http://r3gis.fr/blog/index.php?post/2009/10/31/SipDroid-and-Direct-RTP dernière consultation 15 Janvier 2013 [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 dernière consultation 15 Avril 2013 [12] http://developer.android.com/reference/android/net/rtp/RtpStream.html dernière consultation 17 Avril 2013 [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/ dernière consultation 20 Avril 2013 [16] http://www.doubango.org/ dernière consultation 15 Avril 2013 [17] https://jsip.java.net/ dernière consultation 11 Avril 2013 [18] http://stackoverflow.com/questions/tagged/jain-sip+android dernière consultation 11 Avril 2013 43
  54. 54. 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
  55. 55. 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éé : Rapport de PCD 45 2012 - 2013
  56. 56. 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 Rapport de PCD 46 2012 - 2013
  57. 57. 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
  58. 58. 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. Rapport de PCD 48 2012 - 2013
  59. 59. 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
  60. 60. 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 Rapport de PCD 50 2012 - 2013

×