DUT Informatique de gestion IUT A Lille1, France Client de VOIP & Application Web de Flashcards Stage Erasmus Hochschule Rheinmain - Wiesbaden Alexandre Rupp, Jordan Piorun Année Universitaire : 2012-2013, Semestre 4
i
Aknowledgements First of all, we would like to thank Prof. Dr. Martin Gergeleit our supervisor and teacher in the Advanced-Networking Course at Hochschule Rheinmain. We thank him for the help he could gave us during the internship and the time he spent to organise our coming in the university. We would also like to thank Prof. Dr.-Ing. Ludger Martin, our teacher during the course of "Web-Engineering", for the very nice lectures he gave and the help he provided to us during the praktical work. Then we would like to thank Mr. Lebègue who helped us to organise the internship and to take contact with the right persons in Germany. We would also like to thank Ms. Leuschner and the German Internationnal Ressources Oce for the help they provided to us to organise our internship and to nd a room in Wiesbaden. Finally we would like to thank the Internationnal Ressources Oce of the IUT A from Lille for their help to nd an internship in Germany. ii
Abstract At the end of our studies in the "IUT A of Lille 1" in the computer science department, we have been given the opportunity to do an internship in Germany. During our stay there, we took 2 courses named "Advanced-Networking" and "Web- Engineering" respectively taught by Prof. Dr. Martin Gergeleit and Prof. Dr.-Ing. Ludger Martin. Both of these courses were accompanied by a project and a nal presentation. And in the case of Web-Engineering we had to complete weekly programming assignments. Our rst project was to developp a Voice over IP Client, and the second one was to developp a web-application of ashcards. This internship enabled us to improve both our technical knowledges, and our language knowledges in German. iii
Table des matières Aknowledgements Abstract ii iii I Présentation de l'environnement 1 I. I Présentation de Wiesbaden........................... 1 I. II Présentation de l'université d'accueil..................... 2 II Travaux réalisés 3 II. I Une semaine ordinaire............................. 3 II. IICours et projet de Web-Engineering...................... 3 II. II. 1Les cours................................ 3 II. II. 2Les travaux pratiques.......................... 8 II. II. 3Le projet................................ 8 II. II. 4Communication entre Client et serveur................ 10 II. II. 5L'interface utilisateur.......................... 11 II. IIICours et projet d'advanced-networking.................... 12 II. III. 1Les cours................................ 12 II. III. 2Le projet................................ 12 III Apports techniques et humains 18 III. IApports techniques............................... 18 III. I. 1Technologies du Web.......................... 18 III. I. 2Réseau.................................. 18 III. IIApports humains................................ 19 Conclusion 20 Annexes 22 iv
Table des gures I.1 Carte d'allemagne............................... 1 I.2 "Martkirche" : église évangélique du centre ville de Wiesbaden....... 1 I.3 Photo du batiment, où nous avons suivi nos cours.............. 2 II.1 Tableau des verbes HTTP employés par l'architecture REST......... 6 II.2 Hiérarchie des chiers de Card'it........................ 10 II.3 Processus de traitement des URL....................... 11 II.4 Fonctionnement du protocole SIP en architecture Point à Point...... 13 II.5 Fonctionnement du protocole SIP lors de l'utilisation de proxys...... 14 II.6 Exemple de contenu SDP............................ 15 II.7 Modèle de JAIN SIP.............................. 17 II.8 Fonctionnement des classes RTP_Receiver et RTP_Transmitter...... 17 v
I Présentation de l'environnement I. I Présentation de Wiesbaden Wiesbaden est la capitale du Länder (région) de la Hesse situé dans le centre-ouest de l'allemagne. Figure I.1 Carte d'allemagne C'est également la deuxième ville la plus grande (280 000 habitants) et la plus riche (PIB par habitant de 77499 euros) du Länder. Celle-ci se trouve sur la rive droite du Rhein et est l'une des plus anciennes villes thermale d'europe avec 26 sources d'eau chaude et 1 source d'eau froide. Figure I.2 "Martkirche" : église évangélique du centre ville de Wiesbaden 1
I. II Présentation de l'université d'accueil 2 I. II Présentation de l'université d'accueil Nous avons réalisé notre stage dans l'université Horschule RheinMain. Fondée en 1971, l'université RheinMain s'est spécialisée dans les sciences appliquées telles que l'informatique, l'architecture ou l'ingénierie. Elle se divise en trois sites possédant chacun leurs spécialités : Le premier site est destiné au management, avec plus de 2400 étudiants, c'est la partie la plus importante de l'université. Le second site est consacré au design, à l'architecture, ainsi qu'aux mathématiques et à la physique. Quant au troisième site, qui se trouve être celui où nous avons eectué notre stage, il couvre à la fois l'informatique et les médias. Moderne et entouré de végétation, on y reçoit des cours en accord avec les technologies actuelles, illustrés par des TP ainsi que des projets personnels qui nous orent la possibilité de mettre en pratique les notions apprises. Figure I.3 Photo du batiment, où nous avons suivi nos cours
II Travaux réalisés Au cours de notre séjour à Wiesbaden, nous avons eu à suivre deux cours : "Web- Engineering" et "Advanced-Networking". Tous deux étaient dispensés en Allemand et avaient une valeur de 10 crédits ECTS chacun. II. I Une semaine ordinaire Une semaine ordinaire se déroule de la façon suivante : le mardi matin nous avons cours puis TP de Web-Engineering, et le mercredi matin, nous avons cours puis TP d'advanced Networking. Ces séances permettent à la fois d'acquérir de nouvelles notions susceptibles d'être utiles pour le projet, mais également de faire le point de façon hebdomadaire sur l'avancée des travaux. Dans le cas des cours de Web-Engineering, les connaissances vues en cours sont systématiquement mises en application lors des séances de travaux pratiques qui suivent. En ce qui concerne l'advanced-networking, les séances de TP sont réservées dans le but de faire le point sur l'avancée du projet avec l'enseignant et d'évoquer les problèmes rencontrés. II. II Cours et projet de Web-Engineering Le cours de Web-Engineering est constitué de 2h de cours et 4h de TP hebdomadaires. Il est sanctionné par un contrôle continu (un TP à rendre chaque semaine, par groupe), ainsi que par une remise de projet, et une présentation orale en Allemand. II. II. 1 Les cours La matière Web-Engineering a pour objectif : "La Compréhension des concepts actuels, des méthodes, des techniques, des outils et de l'expérience nécessaires au développement d'applications web et la mise à prot ces connaissances au cours d'un projet réalisé en groupe." Pour cela diérents thèmes / sujets ont été abordés au l des séances. Notamment : Le langage Javascript L'utilisation du framework jquery La technologie AJAX L'utilisation de JSON L'architecture RESTful Le HTML5 (canvas) 3
II. II Cours et projet de Web-Engineering 4 Le SVG La compression/optimisation des données pour le Web La préoccupation de la qualité, les tests (PHPUnit et Sélénium IDE) Les techniques de référencement Les méthodes de statistique etc... Ces diérents enseignements représentants une part importante de notre stage, et ayants servi de base théorique pour réaliser notre projet, nous nous proposons ici de présenter certains points plus en détails. II. II. 1.1 Le langage Javascript Le langage Javascript a été créé en 1995 pour le compte de Netscape Communications Corporation. C'est un langage orienté objet à prototype. Il peut être utilisé à la fois côté client et côté serveur, bien qu'on le trouve plus souvent côté client. Lorsqu'il est employé côté client, il est interprété par le navigateur. On l'emploie pour diérents usages, par exemple pour rendre l'interface utilisateur plus agréable, plus uide ou plus dynamique. Mais aussi pour faire de la vérication de formulaires côté client, ou encore an d'envoyer des requêtes dynamiquement vers un serveur (comme c'est le cas en AJAX, cf II. II. 1.3). Voici un exemple simple de vérication de formulaire en Javascript : 1 function checkformularentries () { 2 // verifie que la valeur entree pour le pseudo ne soit pas vide. 3 if ( document. getelementbyid (" pseudo "). value!= "") { 4 document. formsaisie. submit () ; 5 } 6 else { 7 return false ; 8 } 9 } Listing II.1 Exemple de validation d'un formulaire en Javascript II. II. 1.2 Le framework jquery JQuery est une bibliothèque javascript créé en 2006. Elle permet d'eectuer les mêmes opérations qu'avec du Javascript standard (parcours du DOM 1, modication de propriétés CSS, AJAX, évènements etc.... ), mais de façon plus simple, plus rapide, et en ayant la garantie de la compatibilité entre les diérents navigateurs. Voici un exmple d'utilisation du langage, comparé avec une utilisation de Javascript classique : 1. DOM : Document Object Model
II. II Cours et projet de Web-Engineering 5 1 // Manipulation du DOM : 2 document. getelementbyid (" pseudo "); // Javascript 3 $("# pseudo "); // jquery 4 5 document. getelementsbyclassname (" links "); 6 $(". links "); 7 8 // Modification des proprietes CSS : 9 document. getelementbyid (" pseudo "). style. backgroundcolor = " blue "; // Javascript 10 $("# pseudo "). css ( ' background - color ','blue '); // jquery Listing II.2 Exemples d'utilisation de jquery, mis en comparaison avec du Javascript II. II. 1.3 La technologie AJAX AJAX 2 est une technologie qui utilise du JavaScript, les CSS, XML, le DOM et le XMLHttpRequest an d'envoyer dynamiquement des requêtes vers le serveur et de traiter les informations reçues. Cela permet notamment de créer des applications web et des sites web dynamiques, où il n'y a plus nécessairement besoin de recharger la page entièrement pour avoir du contenu nouveau. On emploie les XMLHttpRequest an de dialoguer de façon asynchrone avec le serveur, le Javascript sert à manipuler le DOM an d'y insérer les informations reçues. Enn le XML (de plus en plus souvent remplacé par du JSON 3 ) sert à structurer l'information envoyée et reçue. Voici un exemple de requête AJAX eectuée en jquery (l'emploi de l'xmlhttprequest est dès lors masqué par le framework) : 1 // Exemple de requete POST envoyee en AJAX, avec jquery et utilisant du JSON 2 3 $. ajax ({ 4 type : " POST ", 5 url : " monsiteweb. com ", 6 data : { pseudo : moi, 7 password : MonPassword 8 }, 9 success : function () { alert (" Tout est Ok!") }, 10 datatype : " json " 11 }) ; Listing II.3 Exemple d'envoie d'une requête POST avec Jquery 2. AJAX : Asynchronous JavaScript and XML 3. JSON : JavaScript Object Notation
II. II Cours et projet de Web-Engineering 6 II. II. 1.4 L'architecture REST REST 4 a été créé par Roy Fielding en 2000 dans le cadre de sa thèse de doctorat [2]. Il s'agit d'un style d'architecture permettant de modéliser les échanges entre client et serveur au sein d'une appliaction web. En utilisant l'architecture REST, les pages webs et les données qu'elles contiennent sont considérées comme des ressources. An d'identier une ressource et de pouvoir y accéder, on utilise des URIs 5. Par exemple : pour obtenir une liste de livres : http ://monsite.com/livres pour obtenir un livre en particulier : http ://monsite.com/livres/2 pour obtenir la liste des livres de Maxime : http ://monsite.com/users/maxime/livres/ pour obtenir les avis sur un livre : http ://monsite.com/livres/2/avis Ensuite pour identier les opérations à eectuer avec la ressource on utilise les verbes HTTP : Opérations Créer un ressource Acher une ressource Mettre à jour une ressource Supprimer une ressource Verbes HTTP CREATE GET PUT DELETE Figure II.1 Tableau des verbes HTTP employés par l'architecture REST. Pour supprimer un livre on utilisera donc par exemple une requête de ce genre : DELETE http ://monsite.com/livres/2 Enn, les requêtes contiennent une représentation de la ressource envoyée ou reçue. Cette représentation est le plus souvent faite en XML ou en JSON. Le client spécie dans sa requête le format qu'il désire pour la réponse. Lorsque le client reçoit une réponse, il choisit de mettre en forme comme il le souhaite les informations brutes contenues dans la réponse du serveur. D'autres aspect de REST sont importants, le serveur doit notamment renvoyer des codes de statut HTTP en fonction du traitement qu'il a eectué. Par exemple : 200 Ok 4. REST : REpresentational State Transfer 5. URI : Uniform Resource Identier
II. II Cours et projet de Web-Engineering 7 qui signie que le traitement a été eectué avec succès, 401 Unauthorized : l'utilisateur a tenté d'accéder à une ressource sans être authentié, 404 Not found : la ressource n'a pas été trouvée etc..... Il est aussi important que des informations sur la date de création de la ressource soient envoyées an de permettre la mise en cache de celle-ci. L'avantage des architectures de type REST est qu'elles permettent une bonne séparation du client et du serveur, facilitant ainsi la maintenance de l'un et de l'autre. D'autre part, le web-service peut être utilisé par n'importe quel autre client. II. II. 1.5 Canvas et SVG SVG et Canvas sont actuellement deux technologies concurrentes qui permettent de réaliser des rendus dynamiques d'image. SVG étant toutefois une technologie plus anciennes, puisque développée depuis 1999. Cette dernière technologie permet également de créer des animations. Canvas est une des nouvelles fonctionnalités d'html5. Pour créer un canvas on utilise la balise éponyme. Cette balise lorsqu'elle est utilisée, crée un nouvel objet dans le DOM, qui peut ensuite être modié en Javascript comme les autres éléments. II. II. 1.6 Optimisation L'optimisation des ressources sur le web est importante, car elle permet de garantir (entre autre) l'accès à l'application depuis diérents types de terminaux. En eet, bien souvent les terminaux mobiles disposent d'une connexion limitée. Il est donc nécessaire de réduire le poids des ressources transférées et le nombre de requêtes eectuées. Pour cela plusieurs possibilités : Compresser les chiers HTML, CSS, Javascript en enlevant tous les espaces et passages à la ligne. Raccourcir les noms employés pour les classes et id en HTML et CSS. Enlever les commentaires dans les chiers HTML, CSS et javascript. Raccourcir au maximum les noms de variables en Javascript. Raccourcir au maximum les noms de fonctions en Javascript. Grouper les diérents chiers Javascript en un seul an de réduire le nombre de requêtes HTTP. Grouper les diérents chiers CSS en un seul an de réduire le nombre de requêtes HTTP. Lors de l'emploi de librairies telles que jquery, utiliser un lien vers l'api jquery hébergée chez Google an de pouvoir bénécier d'une éventuelle précédente mise en cache. Utiliser des algorithmes de compression pour comprimer les codes (par exemple en gzip). Optimiser le poids des images avec des logiciels spécialisés.
II. II Cours et projet de Web-Engineering 8 D'autres optimisations peuvent être réalisées du côté Javascript, non plus pour réduire la taille des chiers ou le nombre de requêtes, mais pour accroître la rapidité d'exécution du code. Par exemple, remplacer les i++ par des ++i lorsque celà est nécessaire. Ou encore préférer une boucle do{ }while(i) à une boucle for (var i = 0 ;i<iter ; i++).... On préfèrera également un nommage complet à un nommage partiel (ex : window.location.href est mieux que location.href ). On peut également éviter de faire appel à une fonction dans la condition d'arrêt d'une boucle. De nombreuses autres optimisations locales permettent de rendre le code javascript plus rapide à s'exécuter. II. II. 1.7 Préocupation de la qualité En ce qui concerne la qualité, on peut eectuer diérents types de tests. Notamment des tests de boite blanche ou de boite noire. Voir même des tests de boite grise (i.e. développement dirigé par les tests). Pour cela on dispose en PHP de la librairie PHPUnit. On peut dans un second temps tester les interactions avec l'interface utilisateur de l'application web. Et même les automatiser, avec des logiciels comme Sélénium IDE. II. II. 2 Les travaux pratiques Chaque cours de Web-Engineering était suivi d'une séance de 4h de TP, avec la plupart du temps un travail à rendre pour la n de la semaine. Il y eut donc diérents travaux sur : La manipulation de Javascript Le traitement du XML avec PHP JQuery L'AJAX avec Javacript (réalisation d'un jeu de mastermind) L'AJAX avec jquery Création d'une mini API REST (système de messagerie) Authentication avec HTTP Optimisation de notre projet (crunching et optimisation locales) Tests unitiares avec PHP Unit II. II. 3 Le projet Le sujet du projet de Web-Engineering était au libre choix des étudiants. Lors de la première séance de travaux pratiques, nous avions à dénir notre projet, avec un inventaire sommaire des principales fonctionnalités. Le but était de réaliser une application web qui ferait intervenir du PHP, ainsi que les diérentes technologies que nous allions voir (i.e. javascript, jquery, AJAX, JSON, REST). II. II. 3.1 Concept En ce qui nous concerne, nous avons opté pour une application web de "Flashcards". Les ashcards étant des cartes mémoires, utilisées par les étudiants pour apprendre un
II. II Cours et projet de Web-Engineering 9 cours. On y marque d'un côté une question, et de l'autre la réponse. II. II. 3.2 Les fonctionnalités de l'application Au départ, nous avions posé diérentes fonctionnalités : Des fonctionnalités sociales : - Prol utilisateur - Système de messagerie privée - Groupes d'utilisateurs - Système déchange de cartes Les fonctionnalités liées au coeur de l'application (aux cartes) : - Gérer un deck (i.e. le créer, le voir, le modier, le supprimer). - Jouer à un deck. - Visualiser le résultat / la progression. - Gérer une carte. II. II. 3.3 La base de données Dés le deuxième TP, il nous était demandé de modéliser les principales entités de la base de données à l'aide d'un schéma de type ER-Diagram 6. En Allemagne les étudiants n'utilisaient pas Merise, mais plutôt la notation de Chen, nous avons donc fait de même. Le modèle de notre base de données est constitué de cinq entités principales : Benutzer (= Utilisateur) Gruppe (= Groupe) Deck Karte (= Carte) Nachricht (= Message) L'ER-Diagram ayant servi de base à la conception de la base de données se trouve en annexe (cf Annexe, gure 1). II. II. 3.4 Architecture et choix techniques Le projet de Web-Engineering, nommé CARD'IT se base sur les technologies PHP, Javascript, jquery, JSON, AJAX. Le projet Card'it est constitué de deux principaux dossiers : un dossier pour l'application côté serveur (dossier application) et le dossier Web qui contient les chiers HTML, CSS et Javascript qui vont être utilisés du côté client. Nous avons conçu l'application comme une API RESTful, ce qui veut dire qu'elle suit les précepts REST (i.e. tout est ressource, et l'accés à celles-ci se fait grâce aux verbes HTTP). L'API pourrait donc très bien être utilisée par autre que nous. 6. ER-Diagram : Entity Relationship Diagram
II. II Cours et projet de Web-Engineering 10 Figure II.2 Hiérarchie des chiers de Card'it L'architecture interne de l'application, est quant à elle organisée selon un modèle MVC 7 pour plus de clarté. Chaque ressource (dans notre cas : Users, Decks, Cards, Groups, Messages) possède donc un modèle, un controleur et si besoin une vue. An de pouvoir réaliser un API RESTful nous avons mis en place un système d'url rewritting. Ainsi chaque lien du type http ://cardit.fr/users/alex est ré-écrit de la façon suivante : http ://cardit.fr/index.php/users/alex. Le chier index.php sert de contrôleur principal / rooteur : il analyse l'url ainsi que la méthode HTTP employée et appel ensuite le contrôleur de la ressource appelée (ici le contrôleur de Users). Dans le cas présent, le contrôleur de User va ensuite appeler l'une des méthodes du modèle, en fonction des données que lui aura transmis le rooteur / contrôleur principal. Voici un schéma décrivant le processus de traitement des URLS : Le coeur de l'api se situe dans le modèle, car celui-ci contient l'ensemble des fonctions utilisées par l'application. Une vue globale des diérents chiers du modèle et des fonctions qu'ils contiennent est disponible en annexe (cf Annexes, gure 2). II. II. 4 Communication entre Client et serveur La communication entre l'api REST côté serveur et le client se fait grâce à des requêtes AJAX réalisées en jquery. Les données sont transmises au format JSON. Lorsque le client reçoit les données, il les met ensuite en forme avec du HTML. Sur CARD'IT, seulement trois pages sont issues de lien en dur, toutes les autres sont le fruit de requêtes AJAX (c'était le but de Web-Engineering). Le client ainsi que le code Javascript qu'il contient, jouent donc un rôle important. De nombreux évènements sont dénis en Javascript, ainsi que plusieurs requêtes AJAX qui s'y 7. MVC : Model View Controller
II. II Cours et projet de Web-Engineering 11 Figure II.3 Processus de traitement des URL rattachent. Le tout permet un rendu uide des informations, à la manière d'une application traditionnelle. II. II. 5 L'interface utilisateur L'interface utilisateur a été soignée an d'être agréable. Du Jquery a été employé an de permettre un enchainement uide des éléments graphiques. Des images de l'application web sont présentes en Annexe.
II. III Cours et projet d'advanced-networking 12 II. III Cours et projet d'advanced-networking Tout comme le cours de Web-Engineering, le cours d'advanced Networking est lui aussi constitué de 2h de cours et 4h de TP hebdomadaires. Cependant, le rôle des heures de TP dière. En eet, il s'agit d'heures réservées pour aborder avec l'enseignant l'avancement du projet et les dicultés rencontrées. Le cours est donc sanctionné par une remise de projet, et une présentation orale en Allemand. II. III. 1 Les cours Durant les cours, de nombreux thèmes ont été abordés : Qualité de service VOIP 8 WLAN (i.e. WIFI) Gestion de Réseaux IP Multicasting et Anycasting II. III. 2 Le projet Le thème du projet était laissé au libre choix des étudiants parmi une liste de proposition. Nous pouvions entre autre réaliser des "Proof Of Concept" 9, ou de montrer comment exploiter une faille réseau, ou alors d'utiliser des protocoles réseaux dans une application. Comme par exemple pour faire de la VOIP. C'est ce que nous avons décidé de faire. L'objectif qui nous était xé était de développer un client de VOIP. D'autre part, une contrainte nous était xée par l'enseignant sur place : notre client devait également pouvoir fonctionner avec d'autres clients déjà existants. Ceci an de prouver que nous avions bien respecté les protocoles. II. III. 2.1 Le principe de la VOIP Le principe de la VOIP est de transmettre un signal audio (la voix) au travers d'un réseau compatible IP, comme c'est le cas d'internet. La VOIP possède de nombreux avantages par rapport aux approches plus classiques (téléphonie standard) : Un avantage en termes de coûts Facile à installer et à congurer Implémenté par l'intermédiaire de logiciels Interopérabilité par l'intermédiaire du protocole SIP 10 Utilise les NGN 11, ce qui permet d'avoir une même plateforme pour tous les services. 8. VOIP : Voice Over IP 9. Proof Of Concept : Démonstration de faisabilité. 10. SIP : Session Initiation Protocol 11. NGN : Next Generation Network
II. III Cours et projet d'advanced-networking 13 Facile de développer de nouveaux services, ou d'améliorer le service existant (car tout est faisable par solution logicielles). II. III. 2.2 Concept La VOIP se base sur l'utilisation de diérentes technologies et protocoles. Nous avons en particulier eu recours à trois protocoles diérents : SIP, SDP et RTP (que nous allons détailler). Session Initialisation Protocol Le premier protocole est SIP (Session Initialisation Protocole). Il sert à établir le dialogue entre deux clients de VOIP, et à synchroniser les échanges. C'est également par son intermédiaire que vont transiter les informations nécessaires à l'établissement de la communication audio. Pour que les deux clients puissent initialiser une session, ils s'envoient deux types de messages : les requêtes (ex : INVITE, ACK, REGISTER, BYE etc... ) et les réponses (ex : 100 Trying, 180 Ringing, 200 OK etc... ). Le protocole est déni au travers de diérents RFC. Le principal est le RFC 3261 [1] qui détaille les diérentes étapes, les messages qui doivent être envoyés, ainsi que leur contenu. D'autre part le RFC 3665 [5] illustre les diérents scénarios que l'on peut rencontrer avc SIP. Le protocole SIP peut fonctionner selon deux types d'architecture : Point à Point (i.e. client à client directement) client-serveur-client Dans l'architecture point à point, l'un des deux clients contacte l'autre en utilisant directement son adresse IP et un port (ex : alexandre@134.31.23.18 :5060). Voici le déroulement d'un appel classique, avec SIP, en point à point : Figure II.4 Fonctionnement du protocole SIP en architecture Point à Point Une autre architecture possible passe par l'utilisation de proxy et d'un serveur Registrar. Dans ce cas, les clients n'ont pas à connaitre les adresses IP l'un de l'autre mais simplement un identiant. De cette façon lorsqu'un client se connecte, il envoie automatiquement un message vers le serveur. Le serveur associe ensuite l'adresse IP actuelle du
II. III Cours et projet d'advanced-networking 14 client à son identiant. Ensuite les autres utilisateurs n'ont besoin de connaître que l'identiant. Le message envoyé au serveur est un message de type REGISTER. En réalité deux messages de ce type sont envoyés. Le premier sert à obtenir des informations de la part du serveur (sur l'algorithme et le salage à utiliser pour crypter l'identiant et le mot de passe par la suite). Puis le deuxième REGISTER envoyé contient en plus du premier l'identiant et le mot de passe cryptés de l'utilisateur. Voici un schéma décrivant les diérents messages envoyés lors d'un échange utilisant un proxy : Figure II.5 Fonctionnement du protocole SIP lors de l'utilisation de proxys Session Description Protocol Le protocole SDP est en fait contenu dans le corps des messages INVITE et 200 OK de SIP. Il sert en quelque sorte de négociation entre les deux parties. Dans un premier temps le client qui appelle, envoie un contenu SDP dans le corps du INVITE. Plusieurs informations nécessaires à l'établissement de la communication audio y sont décrites, par exemple la durée souhaitée de l'appel, le port réseau à utiliser, les codecs audio que le client est capable de supporter etc... Ensuite l'appelé renvoie lui aussi un contenu SDP, mais cette fois dans la réponse 200 OK qu'il fournit. Les informations envoyées sont en fait les mêmes que celles reçues, mais elles ont été modiées pour correspondre aux capacités de ce deuxième client.
II. III Cours et projet d'advanced-networking 15 Lorsque les deux paquets SDP ont été envoyés. Le dernier SDP envoyé/reçu sert de contrat pour l'établissement des ux audio. Le protocole SDP est déni dans le RFC 4566 [4]. Voici un exemple type de paquet SDP : Figure II.6 Exemple de contenu SDP Real-Time Transport Protocol Le protocole RTP (de la couche application) sert à transmettre des ux audio ou vidéo en continu (par exemple pour du streaming). Il est basé sur le protocole UDP 12, de la couche transport. Il permet l'envoie de ux multimédia et supporte diérents codecs. Ce protocole est déni au travers du RFC 3550 [3]. II. III. 2.3 Implémentation L'implémentation du client de VOIP que nous avons réalisé se base sur les protocoles cités ci-dessus. Pour développer le logiciel, nous avons utilisé JAVA, ainsi que deux librairies : JAIN SIP (qui fournit une pile pour le protocole SIP) JMF RTP (qui sert pour le protocole RTP) Les étapes de développement Le développement du projet s'est eectué par étapes. Nous avons dans un premier temps cherché à faire fonctionner le logiciel selon une architecture Point à Point. Pour celà nous avons d'abord mis en place les diérentes requêtes et réponses envoyées lors de l'utilisation du protocole SIP. Par la suite, nous avons travaillé sur le protocole SDP, plus particulièrement sur le traitement et l'envoie des messages qui en contennaient. Et enn nous avons mis en place la communication audio, grâce au protocole RTP, et la librairie JMF. 12. User Datagram Protocol
II. III Cours et projet d'advanced-networking 16 Une fois que ce travail était achevé, et que notre application fonctionnait parfaitement selon une architecture Point à Point, nous avons cherché à la faire fonctionner selon l'architecture client-serveur-client. Pour celà, nous avons ms en place l'envoit des messages REGISTER, et le traitement des requêtes et réponses qui y sont associées. Architecture du projet Le projet est organisé selon un modèle MVC et est constitué de plusieurs classes. C'està-dire, les classes du modèle : SIP_Model : centralise les diérentes classes du modèle SIP_Layer : qui sert à l'établissement du protocole SIP SDP_Parser : qui sert à parser le SDP RTP_Receiver : qui sert à recevoir les paquets RTP et à émettre le son reçu RTP_Transmitter : qui sert à capter le son provenant du micro et à l'envoyer via des paquets RTP. Diérentes classes pour les vues : VOIP_GUI : la vue principale Before_Call_Panel : Panel inséré dans la vue principale avant un appel During_Transmition_Panel : Panel inséré dans la vue principale durant un appel Register_Panel : Panel inséré dans la vue principale pour permettre à l'utilisateur de s'authentier. Receiving_Dialog : Boite de dialogue qui s'ouvre à la réception d'un appel. Ainsi que des controleurs présents en tant que classes internes. Utilisation des librairies La classe la plus importante du modèle est la classe SIP_Layer qui sert à mettre en place le protocole SIP. La classe SIP_Layer implémente l'interface SIPListener fournie par la librairie JAIN SIP. SIP_Layer sert donc à réceptionner puis traiter les diérentes requêtes et réponses SIP. D'autres classes et interfaces sont fournies par JAIN SIP, notamment les factories (SIPFactory, MessageFactory, HeaderFactory etc... ) qui aident à la création de la pile de messages SIP, ainsi qu'à la création des requêtes et réponses. Les autres classes importantes fournies par JAIN, sont le SIPProvider, utilisé pour envoyer les requêtes et réponses, ainsi que le ListenningPoint Pour écouter une source de donnée, et enn la Stack qui sert à empiler les messages reçus.
II. III Cours et projet d'advanced-networking 17 Figure II.7 Modèle de JAIN SIP Nous avons également utilisé la librairie JMF RTP qui nous sert à la fois à capter et encoder les signaux audio, mais aussi à transmettre ces ux audio par le biais de paquets RTP. La librairie nous a servi à créer les classes RTP_Receiver et RTP_Transmitter. Dans le Receiver, on réceptionne les paquets RTP puis on transmet les données reçues vers le haut parleur. Dans le transmetteur, on capte les signaux audio en provenance du micro, puis on les encrypte, avant de les envoyer sous forme de paquets RTP. Figure II.8 Fonctionnement des classes RTP_Receiver et RTP_Transmitter