LOGICIEL DE TELEPHONIE SUR IP

Transcription

1 REPUBLIQUE FRANCAISE LIBERTE* EGALITE* FRATERNITE UNIVERSITE D AVIGNON ET DES PAYS DE VAUCLUSE CENTRE D ENSEIGNEMENT ET DE RECHERCHE INFORMATIQUE PROJET N 17 RAPPORT DU SECOND SEMESTRE LOGICIEL DE TELEPHONIE SUR IP Présenté par : ERICK BRUNO YOUMBI Chryst Girel MPIBI FOULISSIA Noureddine SERGHINI Année Académique TUTEUR: Rachid El AZOUZI 1

2 I - Présentation du projet Intérêt du projet II Architecture du protocole SIP et de L application 1) Architecture et Fonctionnement du protocole sip a)modèle client serveur b) URL Sip 2)Les codes d état 3) Architecture de L application III Implémentation du protocole SIP 1) Fonctionnement du programme initial (seulement la voix d implémenter) 2) Notre Implémentation 2-1 Identification du media 2-2 Ouverture de session IV - Transmission audioconférence et vidéoconférence 1) Envoi de l audio 2) Reception de l audio V - Transfert de fichier 1. L'interface graphique 1.1 Classes 1.2FileSenderGUI 2. La partie Serveur : création du Socket serveur. 2.1 Classe FileSender 2.2 Classe FileTransfer 3. La partie Cliente : création du Socket client. 3.1 Classe FileReceiver 2

3 VI Fonctionnement et test de l application. 1) Fonctionnement 2) Tests VII Améliorations possibles VIII Organisation des taches 1) Répartition des tâches 2) Diagrammes de Gantt VIIII - Difficultés rencontrées Conclusion. 3

4 I - Présentation du projet Ce projet de première année de master est la suite du projet 10 de l année dernière. Dans ce projet, les étudiants ont commencé à réaliser leur propre logiciel téléphonique pour que tous les membres de l IUP puissent l utiliser comme téléphone standard. L objectif du projet est d implémenter un modèle de communication multimédia (voix et vidéo) en temps réel entre deux (et plusieurs) ordinateurs. Et ce, en nous basant sur la modélisation orientée objet du protocole de signalisation SIP. Il s agit de développer une application utilisant une interface graphique homme machine (interface utilisateur). Dès lors, elle permettra un échange de données multimédia (audio, vidéo et messagerie instantanée). Intérêt du projet Ce logiciel devra permettre au membre de l IUP de communiquer en utilisant les technologies IP, entre deux, ou plusieurs personnes en conférence, peut importe leur localisation. Ce projet a été commencé il y a trois ans, et a plusieurs intérêts. Le logiciel doit être réutilisable, puisque plusieurs personnes auront à travailler dessus, le code doit donc être compréhensible, clair et facile à modifier et réutiliser. L objectif de ce projet étant que le logiciel soit compréhensible, clair, facile à modifier et réutiliser. Le but final étant que le logiciel soit opérationnel. De notre part, nous devons reprendre le travail qui a déjà était fait par les anciens étudiants, le comprendre afin de lui apporter des améliorations et lui ajouter de nouvelles fonctionnalités. II Architecture du protocole SIP et de l application 1) Architecture et Fonctionnement du protocole SIP Application Multimédia Audio Video Données SIP RTP RTCP SAP SDP UDP TCP IP Figure 1 : L architecture de SIP 4

5 A chacune des couches de l architecture SIP sont associés des protocoles tels que : RTP (Real Time Transport protocol) : protocole de transport des données en temps réel RTCP (Real Time Control Protocol) : protocole qui assure le contrôle de flux des données multimédia SAP (Session Annoucement Protocol) : protocole pour annoncer si les sessions multimédia ouvertes sont en multicast SDP (Session Description Protocol) : protocole de description des sessions multimédia a ) Modèle client-serveur Pour établir une communication, l appelant, que l on désignera par client, adressera sa requête à un serveur SIP, qui lui donnera les moyens de communiquer. Ils existent cinq types de serveurs : L UAS (User Agent Server) : c est l application du terminal d abonné qui reçoit les requêtes. L UAC (User Agent Client) est l application cliente qui émet les requêtes; Le relais mandataire ou PS (Proxy Server) : auquel est relié un terminal fixe ou mobile agit à la fois comme client et serveur. Un tel serveur peut interpréter et modifier les messages qu il reçoit avant de les transmettre; Le RS (Redirect Server) : réalise simplement une association d adresses vers une ou plusieurs adresse (lorsqu un client appelle un terminal mobile - redirection vers le PS le plus proche - ou en multicast, le message émis est redirigé vers toutes les sorties auxquelles sont reliés les destinataires); Le LS (Location Server) fournit la position courante des utilisateurs dont la communication traverse les RS et PS auxquels ils sont rattachés : Cette fonction est assurée par le service de localisation; le RG (Registrar) est un serveur qui accepte les requêtes REGISTER et offre également un service de localisation comme le LS. Chaque PS ou LS est généralement relié à un Registrar. Pour établir la communication entre l UAC (Agent utilisateur client) du terminal appelant et l UAS (Agent utilisateur serveur) du terminal appelé, ceux-ci doivent être identifiés.ainsi, chaque utilisateur et sa machine est identifié par une adresse appelée URL SIP qui se présente comme une URL Mailto ou Telnet : utilisateur@machine. La partie utilisateur est composé d un nom ou un numéro de téléphone alors que la partie machine est un nom de domaine ou une adresse IP. Si le client souhaite communiquer avec son destinataire, il envoie une requête URI directement vers le port d entrée de l UAS du destinataire de la requête. Le protocole utilisé (TCP ou UDP), l adresse IP et le port d entrée du serveur du destinataire doivent être 5

6 précisés, lors de l émission d une requête URI. Une fois le client connecté à un serveur SIP distant, il peut lui adresser une ou plusieurs requêtes SIP et recevoir une ou plusieurs réponses de ce serveur. Les réponses contiennent certains champs identiquement remplis à ceux des requêtes : ce sont les champs Call-ID dont le rôle est de définir de façon unique une invitation particulière, le champ Cseq qui est utilisé pour identifier un message faisant partie d une né gociation d invitation, le champ Via qui indique le chemin pris par la requête pour arriver jusqu à destination et les url To et From qui contiennent les adresses sources et destination des clients. Les échanges client-serveur se font à l aide de requêtes (INVITE, ACK, BYE, REGISTER, OPTION, CANCEL). Celles-ci sont définies dans les paragraphes ultérieurs. b./url SIP Il existe cinq types de format de nommage universel SIP (URL SIP) qui sont : (FROM, COURANTE, TO, CONTACT et EXTERNAL). URL TO : contient l adresse du destinataire de la requête SIP. URL FROM: contient l adresse source du client qui émet la requête SIP. URL COURANTE ou requête URI: précise la destination de la requête REGISTER c est à dire son domaine d enregistrement. La requête REGISTER est transmise de serveur en serveur jusqu à ce qu elle ait atteint le serveur dont le domaine correspond à celui listé dans la requête URI. URL CONTACT : les requêtes autres que REGISTER à destination de l URL TO sont redirigés aux adresses données dans l URL CONTACT. URL EXTERNAL : réservé à des applications futures. La structure de l URL est la suivante : sip :informations_utilisateur@domaine paramètres en-têtes avec informations_utilisateur = (nom de l utilisateur :mot de passe) ou (numéro de téléphone si user = phone), domaine = nom de domaine ou adresse IP : port paramètres = ;transport = udp ou tcp; user = phone ou IP. method = INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER ttl = 0 à 255 maddr = adresse IP de multicast tag = compteur en héxadécimal en-tête =?hname= hvalue & hname = hvalue. Seules les URL CONTACT et EXTERNAL contiennent les paramètres transport, method, ttl, maddr et des en-têtes. 6

7 2) Les codes d état Une réponse à une requête est caractérisée par un code appelé code d état. Le tableau suivant récapitule ces codes : Code Signification 1xx Information 2xx Succès 3xx Réacheminement 4xx Erreur requêtes 5xx Erreur serveur 6xx Erreur globale 3) Architecture de l application La figurere 2 illustre l architecture de notre logiciel proposé et les interactions entre les différentes composantes durant le processus d échange des requêtes SIP et de la visioconférence. Pour rendre l architecture plus lisible et moins encombrée, nous avons représenté un cas simple de trois clients et d un serveur proxy. Interface utilisateur graphique Traitement des messages SIP Agent utilisateur client-serveur (UAC/UAS) Serveur proxy Agent utilisateur client-serveur (UAC/UAS) Serveur proxy Interface utilisateur graphique Traitement des messages SIP Communication voix et vidéo (RTP/RTCP) Interface utilisateur graphique Traitement des messages SIP Communication voix et vidéo (RTP/RTCP) Agent utilisateur client-serveur (UAC/UAS) bserveur proxy (MCU) Profil agent utilsateur(client) Communication voix et vidéo (RTP/RTCP ) Traitement des messages SIP Gestion des ports de communications Enregistrement / désenregistrement du client 7

8 III Implémentation du protocole SIP Le projet que nous avons choisit est un projet qui avait déjà était entamé et qu il a fallut compléter avec de nouvelle fonctionnalité. Partie de ce constat, nous avons cherché à calquer notre implémentation à celle déjà réalisé en réutilisant les méthodes et les classes déjà implémenter dans la mesure du possible. Dans cette partie, nous allons détaillés comment nous avons mis en ouvre les possibilités du protocole SIP pour pouvoir réaliser nos objectifs. 1) Fonctionnement du programme initial( audio, vidéo et messagerie instantanée Le logiciel récupérer dans sa version initiale devrait permettre d ouvrir 4 types de session : Session audio Session vidéo Session message Session transfert de fichier (intégration dans le logiciel pas encore effectué). Pour ouvrir une session l utilisateur doit avoir un compte SIP. Ensuite il peut enregistrer les paramètres de son compte dans l onglet Edition-> Preference. La fenêtre suivante s ouvre et vous n avez plus qu à rentrer vos parètres de connexion. Pour avoir un compte SIP, on peut s inscrire sur le site sipphone.com par exemple. Evidement, l utilisateur doit être obligatoirement connecté à internet pour utiliser le logiciel. Pour communiquer avec un utilisateur, ouvrir le type de session souhaité, et choisir l utilisateur avec qui on veut communiquer. Le logiciel sonne chez l autre utilisateur, celui-ci doit répondre ét enfin les deux utilisateurs peuvent communiquer. 8

9 Mais après plusieurs tests sur le logiciel nous nous sommes rendu compte que seul les fonctionnalités de méssagerie instantanée fonctionnaient parfaitement. pour ce qui des communications audio ou de la transmission vidéo nous avons pas pû ouvrir de session la dessus car les codecs ne fonctionne pas. 2/ Notre Implémentation 2-1 Identification du media Pour réaliser notre implémentation, nous avons utilisé l entête SDP pour diffuser en plus de l adresse multicast et du port, des informations sur le media qui concerne l ouverture de la session. Concrètement nous avons procéder comme suit. Création d un INVITE pour l audioconférence (code se situant dans l UAC) : // Creation du message SDP String sdpdata = "v=0\r\n" + "o=- 2 2" + " IN IP /63\r\n" + "s=mysessionssession\r\n" + "c=in IP /63 \r\n" // Connexion audio IP/TTL + "t=0 0\r\n" + "m=audio " + portlibreaudio + " RTP/AVP \r\n" + "a=rtpmap:0 PCMU/8000\r\n" // Codecs utlisés + "a=rtpmap:110 SPEEX/8000\r\n" // Codecs utlilisés + "a=rtpmap:98 ilbc/8000\r\n" // codecs utlilisés + "a=nortpproxy:yes\r\n" + "a=type:broadcast\r\n" + "a=cat:mbone/other\r\n" //+ "a=ptime:20\r\n"; + "a=sendrecv\r\n"; byte[] contents = sdpdata.getbytes(); Le terme «m» désigne le media, portlibreaudio désigne le port libre qui sera utilisé pour recevoir la video et IP, l ip de la machine qui émet l invite. Le terme «a» désigne les attributs de notre entête SDP ; ici comme attributs supplémentaires nous avons ajoutés : 9

10 Type :broadcast et cat:mbone pour indiquer que nous fesonsdu broadcast et que nous utilisons un Backbone multicast. A la réception (UAS), il suffit de récupérer le message SDP contenu dans le HEADER, d extraire le media M, le port ainsi que l IP : // Envoi de la réponse OK à l'invite reçue st.sendresponse(okresponse); String codecchoisi ="ULAW/rtp"; av = new AVCustomTrans (IPrtp, PortrtpAudio, Utils.ULAW_RTP); rc = new AVCustomRecv (IP, portlibreaudio, 50); // On démarre le streaming RTP Thread tone = new Thread (av); Thread ttwo = new Thread (rc); tone.start(); ttwo.start(); sipgui.gettextarea().settext("en communication...\n"+"codec Audio: "+codecchoisi); encom = true; A la réception, le récepteur émet à son tour un message «OK» contenant un entête SDP qui décrit l IP et le PORT a utilisé pour réaliser la communication video. Les medias sont décrit comme suit : - Audio : Ouverture d une session audio ou audioconférence - Vidéo : Ouverture d une session vidéo - Message : Ouverture d une session messagerie instantanée - Fichier : Ouverture d une session de transfert de fichier 2-2 Ouverture de session Pour l ouverture des sessions, nous avons choisit de permettre l ouverture de n importe quel session indépendamment des autres sessions. De même pour les sessions audio et messagerie instantanée. Exemple sur le programme : 10

11 Chaque choix de session donne lieu à l affichage d une nouvelle fenêtre ou l on choisit le Correspondant pour établir la communication. IV - Transmission Audioconférence La transmission Audioconférence entre plusieurs entités équipés de notre softphone a était un des axes majeur de notre projet. Nous allons en détaillés le fonctionnement, l utilisation ainsi que les étapes de réalisation. Le plus difficile a été l ouverture des sessions en multicast. Ce que nous avons reussi à faire et qui marche très bien. Cette ouverture de session de fait en manipulant les classes UAC, UAS et UA. En effet quand on se connecte avec une adresse multicast sur le proxy de sipphone.com celui crée un groupe et nous retourne une adresse unicast public avec laquelle nous devrons communiquer sur le réseau. Chaque participants qui veut se joindre a notre groupe doit se connecter au proxy avec la même adresse multicast que les autres. L entité permettant de gérer les conférences au niveau du proxy est le MCU. Par défaut le MCU est intégré au protocol Sip. Une fois que le groupe est crée il nous faut maintenant transmettre les flux entre les différents participants. Dans notre cas nous avons cloné le data source. Une fois les flux récupérer et afficher on c est attelé a transmettre les flux Audio capturés via le réseau en local entre plusieurs machines via le protocole RTP. Pour se faire nous avons modifier les classes : AVCustomRecv 11

12 AVCustomTrans Ces classes ont été implémenter comme Thread pour permettre une exécution de ceci en parallèle avec d autre transmission, la vidéo par exemple. IV-1 Envoi de l audio L envoi de l audio se fait au moyen de la classe AVCustomTrans. L émetteur et le récepteur doivent avoir les mêmes codecs Nous n allons pas ici détaillés chaque ligne du programme mais plutôt vous donné le code source de quelques lignes importantes : //Création du tableau RTPmanager pour gérer le clonage de datasource Array rtpmgr [] = new rtpmgr (); for (int i=0;i<rtpmgr.length;i++) try { //on crée une nouvelle instance pour notre RTPManager rtpmgr[i] = RTPManager.newInstance() ; // on définie l adresse local et de avec laqelle on devra communiqué ipaddr = InetAddress.getByName(ipAddress localaddr = new SessionAddress(InetAddress.getLocalHost(), portbase); destaddr = new SessionAddress(ipAddr, portbase); //Ajout de la cible au manager rtpmgr[i].initialize(localaddr); rtpmgr[i].addtarget(destaddr); rtpmgr[i].addtarget(localaddr); IV-2 Réception de l audio C est la classe AVCustomRecv qui va s occuper de récupérer les flux et de les afficher dans une 12

13 frame. AVCustomRecv implémente ReceiveStreamListener pour permettre de déclencher le mécanisme de récupération dés la réception des flux évitant ainsi l emploi de boucle d attente consommatrice de ressource inutilement. La réception se fait en 2 grandes étapes : Création d une instance de RTPManager pour la gestion des flux RTP. A la réception, création d un DataSource et démarrage du Player puis affichage dans une Frame. Array rtpmgr[] = new rtpmgr(); Array sessions[] = new sessions(); rtpmgr = new RTPManager(sessions.length); Initialisation du manager sur l adresse locale rtpmgr[i].initialize(localaddr); Ajout de chaque cible rtpmgr[i].addtarget(destaddr); V. Le transfert de fichier Dans cette partie on a développé deux classes permettant de faire le transfert de fichier entre un Serveur et un Client. Le transfert de fichier se fait par Sockets et il intègre une interface graphique pour envoyer et recevoir le fichier. La réalisation d'un tel projet necessite un découpage en étapes distinctes. Ce découpage est le suivant : 1. L'interface graphique : nous ne nous attarderons pas sur cette étape sauf sur l'affichage de la fenêtre qui va permettre d'explorer le disque dur. 2. La partie Serveur : création du Socket serveur. 3. La partie Cliente : création du Socket client. V1) L'interface graphique 13

14 V1.1) Classes Nous allons commencer par créer les 2 classes graphiques nécessaire à notre serveur et à notre client. Il s'agira de 2 JFrames que nous appelerons : 1. FileSenderGUI : côté serveur. 2. FileReceiverGUI : côté client. Nous ne nous attarderons pas sur cette classe puisqu'il s'agit de créer un bouton Recevoir qui instanciera un nouvel objet de la classe FileSender V1.2) FileSenderGUI Le JFrame serveur se compose uniquement d'un champ de saisie de l'emplacement du fichier à envoyer ainsi que d'un bouton Parcourir et enfin d'un bouton Envoyer. Nous allons nous occuper en premier lieu du bouton Parcourir. En effet nous voulons ouvrir une fenêtre contenant notre disque dur. Pour cela nous allons utiliser l'élement Swing JFileChooser. Son implémentation est très simple puisqu'il suffit d'appeler la méthode showdialog() pour afficher la fenêtre. Explication : this défini notre classe principale qui s'étend à la classe JFrame. La méthode showdialog prend comme premier argument la fenêtre parente auquel le dialogue du jfilechooser est rattaché. Maintenant nous allons nous occuper de récupérer le chemin du fichier à envoyer dans notre JTextField. Cela se fait dans le bloc de code du JFileChooser : Au passage l'intérêt du test if permet de s'assurer que l'on ne remplira le JtextField que si l'on valide avec le bouton "Ouvrir" pour ainsi eviter de remplir le JTextField alors que l'on aurait cliquer sur "Annuler". 2 Application serveur 2.1 Classe FileSender La classe FileSender est chargée d'accepter la connexion d'un socket client. Nous allons tout d'abord décrire les différents objets dont nous aurons besoin : File : contient le fichier à envoyer. ServerSocket : le socket serveur qui va permettre d'initialiser la connection avec le client. Socket : le socket client 14

15 La classe FileSender est étendue à la classe Thread pour permettre l'envoie multiple de fichiers.elle prend en arguments le port sur lequel on souhaite écouter ainsi que le fichier à envoyer que l'on aura récupérer de notre interface graphique. Implémentons maintenant notre méthode run qui va écouter en boucle en vue d'accepter un socket client. Lorsque le client a été accepté, on créer un nouvel objet de la classe FileTransfer expliquée plus bas et on sort de la boucle d'écoute. FileTransfer prend en arguments le socket client ainsi que le fichier à envoyer. 2.2 Classe FileTransfer La classe FileTransfer comprend plusieurs étapes : 1. Création du flux de sortie permettant l'envoie des données. 2. Création du flux d'entrée permettant de lire dans le fichier à envoyer. 3. Envoie du fichier. Nous aurons donc besoin des variables suivantes : File Socket DataOutputStream FileInputStream La création du flux de sortie prend en argument le socket client récupéré de la classe FileSender. Dernière étape : l'envoi de notre fichier. Nous créons pour cela une mémoire tampon qui va stocké le fichier lu au fur et à mesure : 3 Application client 3.1 Classe FileReceiver La classe FileReceiver se divise en plusieurs étapes : 1. En premier lieu nous allons nous connecter au socket serveur. 2. Le client récupère ensuite les données envoyées par le serveur. 3. Création d'un nouveau fichier. 4. Début de l'écriture des données reçues dans le fichier. 15

16 Nous aurons donc besoin des élements suivants : Socket : pour la connexion au serveur. DataInputStream : pour lire le flux entrant par notre socket. File : pour la création de notre fichier. FileOuputStream : pour l'écriture dans le nouveau fichier. Maintenant, occupons nous de la partie connexion au serveur et de la récupération du fichier. La classe Socket prend en argument l'ip ou le nom d'hôte de la machine ( ici localhost, on aurait pût tout aussi bien faire un new Socket(" ",4004); ) ainsi que le port sur lequel on se connecte. On créer ensuite notre flux entrant en passant le socket crée en argument. Une fois le fichier créer on créer notre flux d'écriture dans un fichier avant de lancer l'écriture grâce à la méthode read() de notre DataInputStream. VI. Fonctionnement et test de l application VI.1 Fonctionnement Le pogramme nous permet d ouvrir un session d audioconférence en Multicast. Après s être authentifié, le client choisi la session qu il veut ouvrir Il clique dessus.si il clique sur audioconférence il ouvrira une session De groupe et le proxy sipphone lui donnera une adresse public avec Il pourra communiquer sur le réseau. Pour le moment le transfert de fichier n est pas intégré au programme Nous avons écrit un programme en JAVA qui permet de faire le transfert de fichier entre 2 machines. V.2 Test : Nous avons éffectué plusieurs test notamment au labo de l IUP Voici un extrait du méssage obtenu : 16

17 Audioconférence : REGISTER sip:proxy01.sipphone.com SIP/2.0 Call-ID: 6073dccbd467f990f39aa84b55e5d315@ CSeq: 1 REGISTER From: "erick" <sip: @proxy01.sipphone.com>;tag= To: "erick" <sip: @proxy01.sipphone.com> Max-Forwards: 99 Contact: " " <sip: @ :5060> Call-Info: < Via:SIP/2.0/UDP :5060;branch=z9hG4bK9389c727901e26d558cc94f f2 Content-Length: 0 null Une réponse a été reçue... Response reçue : Status = 401 CSeq: 1 REGISTER L'événement Fin de transaction a été reçu media: Maudio INVITE envoyé: INVITE sip: @proxy01.sipphone.com SIP/2.0 Call-ID: 5dc f21e080a85e1eade0ed966@ CSeq: 1 INVITE From: "erick" <sip: @proxy01.sipphone.com>;tag= To: "Appelé le" <sip: @proxy01.sipphone.com> Via: :5060;branch=z9hG4bK3ad7adee651e731a44caf82ac891723e Max-Forwards: 99 Contact: " " <sip: @ :5060> Content-Type: application/sdp Call-Info: < Content-Length: 215 SIP/2.0/UDP Dialog apres INVITE: gov.nist.javax.sip.stack.sipdialog@8a548b Invité à la conférence Une réponse a été reçue... Response reçue : Status = 200 CSeq: 1 INVITE audio test: audio Sending ACK SDP recu: v=0 o=username 0 0 IN IP s=session c=in IP t=0 0 m=audio 1092 RTP/AVP 0 a=direction:passive media: Maudio : Nous avons mis Maudio pour différencier le audio de l audioconférence : adresse multicast envoyé au serveur : adresse public unicast retourné par le proxy. 17

18 Transfert de fichier : Voici à quoi ressemble l interface graphique de notre transfert de fichier. L utilisateur clique sur ouvrier fichier, choisi le fichier et clique sur envoyer pour l envoyer à la destination. Pour le moment nous arrivons pas à ouvrir vraiment le fichier. Voici ce que nous obtenons. VII Amélioration possible Si un groupe venait à reprendre notre projet, voici quelque amélioration et piste de réflexion pour améliorer ce soft : Résoudre le problème de codecs. Palier de façon définitive au problème de boges du logiciel. 18

19 Intégration du transfert de fichier : Le soft est déjà préparé à accueillir le transfert de fichier, les sources sont déjà crées et fonctionnent parfaitement. Il faudra également permettre au soft de faire un transfert en multicast Implémenter la partie DTMF permettant la mise œuvre d une communication vers un poste fixe. Développer leur propre proxy SIP ce qui leur permettrait d éviter d être confronter aux problèmes d adresses Ajouter une fonction permettant de choisir le périphérique audio et vidéo, les codecs audio et vidéo, choisir la résolution de l image etc. tous ceci via l interface du programme. VIII Organisation des tâches 1./ Diagramme de gant 2./ Répartition des tâches 19

20 VIII Difficultés rencontrés Nous avons évalué nos contraintes envers ce projet: Nous avons eu des réunions ou nos visions n était pas les mêmes, mais nous avons réussi à finalement à s entendre et à tous travailler ensemble pour le même but. Obtenir les adresses SIP car les sites qui proposaient les adresses SIP gratuit étaient tous en maintenance à l exemple de Gyzmo. Cela à considérablement ralentit notre travail.car on ne disposait pas d adresse à un moment donné le tuteur à proposé acheter des adresses Sip sur internet, mais nous avons contacter un ancien étudiant qui avait déjà travailler sur ce projet l année passé et ils nous a donné trois adresses dont nous avons besoin. La maitrise du langage de programmation JAVA utilisé. Vu que nous ne maitrisons pas le langage de programmation Java cela a été une des grosses difficultés de ce projet. Il est pas toujours évident de reprendre un travail qui a été déjà commencer : car le programme initial comprend plus d une vingtaine de classe et chaque avaient en moyenne près de 700 lignes de codes qu il nous a fallu étudier, comprendre les fonctionnalités de chacune de ces classes les relations entre elle et cela nous a pris une bonne partie du temps prévu pour cette applications. Lorsque nous avons commencé à travailler sur le logiciel mais nous avons eu des boges de celui ci. Comme nous n arrivions pas modifié certains fonctionnalité du logiciels à cause de ces boges, nous avons préféré développer un programme à part et intégré au soft par la suite, ce qui a été le cas pour le transfert de fichier et la visioconférence. Pour la visioconférence les résultats nétaient pas concluant, nous sommes retourné au soft et avons compris d où venait certains de ces boges. On avait la responsabilité d'ajouter les fonctionnalités suivante à l'ancienne version du logiciel sipphone : Visioconférence, transfert de fichier. Or l ancienne version du logiciel était sensé faire la transmission audio et video.mais après plusieurs test nous nous sommes rendu compte que ces fonctionnalités ne marche pas. Il y avait des problèmes liées aux codecs. Du coup on ne pas tester les fonctionalités que nous avions developpés. 20

21 On a eu du mal à comprendre le fonctionnement des sessions multicast. Du coup on arrivait pas à ouvrir une session en multicast, mais apres plusieurs modifications sur le protocole sip nous y sommes parvenue Conclusion : En conclusion, notre équipe de projet vous remercie de nous avoir fait confiance en acceptant de nous attribuer ce projet et de lire ce document. Bien que beaucoup reste à faire, Nous espérons que les différents points évoqués au cours des précédentes parties ont de manière exhaustive répondue à vos attentes. 21