Rapport de stage de deuxième année de maîtrise informatique option systèmes distribués et réseaux Gestion de signaux DTMF & Prise de contrôle d ordinateurs distants sur tablette Auteur : Superviseur : Sébastien Seiller M. Tan Chen Wei Tuteur : Référent : M. Jean-Christophe Lapayre M. Siah Bing Keong Stage du 13 février au 2 juin 2012 Université de Franche Comté Faculté de Sciences et Technologies de Besançon Année Universitaire 2011/2012 5 juin 2012
Remerciements Avant tout, il me semble important de remercier les personnes qui ont permis le bon déroulement de ce stage. M. Jean-Christophe Lapayre sans qui ce stage n aurait pas été possible et pour ses conseils concernant celui-ci. M. Sureswaran Ramadass pour m avoir permis d intégrer son entreprise et offert l opportunité de prouver mes capacités. M. Tan Chen Wei qui m a proposé des sujets de stage intéressants qui m ont donné l occasion de découvrir de nouvelles technologies et pour son suivi lors des réunions. M. Siah Bing Keong qui a balayé toutes les incertitudes que j aurai pu avoir quant aux besoins de l entreprise et qui m a suivi tous les jours tout au long du stage. MM. Dawood Mossad et Othman Baqer Hussein pour leur disponibilité et leur dévouement. Ainsi que tout le personnel de Nav6 pour leur affabilité. 2
Table des matières Remerciements 2 1 Introduction 5 2 Environnement de travail et présentation du sujet 6 2.1 Localisation............................ 6 2.2 Nav6............................... 7 2.3 L équipe NLTVC........................ 7 2.4 Présentation du sujet....................... 7 2.4.1 Gestion de signaux DTMF............... 7 2.4.1.1 Qu est-ce qu un signal DTMF?....... 8 2.4.1.2 Qu est-ce que le protocole H.323?...... 8 2.4.1.3 Qu est-ce qu un MCU?............ 9 2.4.1.4 Pourquoi utiliser des signaux DTMF?... 9 2.4.1.5 Sujet....................... 9 2.4.2 Application Android................... 9 3 Cahier des charges 10 3.1 Gestion de signaux DTMF................... 10 3.2 Application Android....................... 10 3.2.1 Implémentation des différents menus.......... 11 3.2.2 Écran d édition de documents.............. 13 3.3 Technologies et outils utilisés................... 13 3.3.1 Environnements de développement........... 13 3.3.2 Langages et technologies................. 14 3.4 Organisation du temps de travail................ 14 4 Mise en œuvre 15 4.1 Gestion de signaux DTMF................... 15 4.1.1 Génération de signaux DTMF............. 15 4.1.2 Interface utilisateur.................... 16 3
4.1.3 Classes importantes.................... 18 4.1.3.1 CDirectCall et IDirectCall......... 18 4.1.3.2 CMyEndpoint................ 19 4.1.3.3 CMyPasswordKeypad........... 19 4.1.3.4 CH323ControlDlg.............. 20 4.2 Application Android....................... 21 4.2.1 Débloquer la tablette................... 21 4.2.2 Configuration du WiFi.................. 22 4.2.3 Gestion des interactions avec les menus......... 22 4.2.4 Écran d édition de documents.............. 24 4.2.5 Traitement des actions utilisateur............ 26 4.2.5.1 Actions souris.................. 26 4.2.5.2 Actions clavier................. 29 4.2.6 Interface utilisateur.................... 30 4.2.6.1 Interface principale et différents menus.... 30 4.2.6.2 Gestion des participants à la conférence... 35 4.2.6.3 Clavier virtuel................. 37 5 Bilans 39 5.1 Bilan pour l entreprise...................... 39 5.2 Bilan humain........................... 39 5.3 Bilan pédagogique......................... 40 6 Conclusion 41 Table des figures 42 Liste des Algorithmes 43 Glossaire 44 Résumé 46 Note 1 : dans tout le document les mots à la fois en gras et en italique sont référencés dans le glossaire. Note 2 : pour la version numérique du document tous les numéros référençant sections, figures et algorithmes sont des liens cliquables, de même que les mots définis par la note 1. 4
Chapitre 1 Introduction L informatique offre un panel de possibilités extrêmement vaste. Le nombre de ces possibilités s étant très nettement agrandi avec l avènement des réseaux informatiques et des services associés. Parmi ces services nous pouvons citer la consultation de mail, ou encore la navigation sur internet. Mais l un de ces services connait un essor lié à l augmentation de la bande passante des réseaux informatique. La téléconférence nécessite en effet beaucoup de bande passante pour faire transiter les données audio et vidéo. Ceci étant du au fait que la vidéo est extrêmement gourmande en espace mémoire, même si les différents algorithmes de compression ont permis de limiter quelque peu cela. L accroissement du nombre d utilisateur d un service ne dépend pas seulement de ses capacités techniques. En effet un service, aussi fabuleux soit-il, ne se démocratisera pas s il est complexe à utiliser. Il faut donc obligatoirement créer une méthode d accès à ce service qui soit la plus simple possible. C est dans cette optique que Nav6, par l intermédiaire de son equipe de développement NLTVC, à décidé de créer le logiciel de téléconférence Crystalview. Ce logiciel se veut simple, fonctionnel et attractif. C est pourquoi lors de mon stage au sein de cette structure, il m a été demandé d ajouter une fonctionnalité plébiscitée par les clients de Nav6, et de permettre le pilotage de leur logiciel de téléconférence depuis une tablette tactile exécutant le système d exploitation. Ce rapport relate le déroulement de ce stage en vous présentant l environnement de travail, en vous exposant le sujet, puis en vous détaillant le cahier des charges et la mise en œuvre, pour finir par dresser un bilan et une conclusion. 5
Chapitre 2 Environnement de travail et présentation du sujet L environnement de travail regroupe aussi bien l emplacement géographique au sein duquel le stage s est effectué que le contexte applicatif dans lequel j ai pu évoluer. La présentation du sujet concerne en fait deux parties distinctes qui seront décrites dans deux sous-sections différentes. 2.1 Localisation Figure 2.1 Localisation de Nav6 6
Le stage s est effectué au sein de l Universiti Sains Malaysia (voir plan ci-dessus (Figure - 2.1)) située en Malaisie et plus précisément sur l île de Penang. Cette université fondée en 1962 fût la deuxième de Malaisie et comptait alors 57 étudiants. De nos jours elle en accueille plus de 30 000 répartis sur trois sites distincts, à savoir Penang, Kubang Kerian, et Nibong Tebal. L université intègre aussi différents centres de recherche comme le National Advanced IPv6 Centre au sein duquel ce stage s est déroulé. 2.2 Nav6 Le National Advanced IPv6 Centre est un organisme gouvernemental dont le rôle est de promouvoir et de permettre la transition vers l IPv6 à l échelle de la Malaisie. Cet organisme est aussi organisé en entreprise (Nav6 ) comprenant différentes composantes dont NLTVC qui édite des solutions de téléconférence clés en main comme la solution Crystalview 9100 qui prend en charge trois protocoles : le H.323, et un protocole propre à NLTVC. 2.3 L équipe NLTVC L équipe est dirigée par M. Tan Chen Wei et comporte quatre autres membres, Siah Bing Keong, Iznan Hausainy Hasbullah, Peter Lau et Effendy Khairul. 2.4 Présentation du sujet Pendant la durée du stage deux sujets ont été abordés. Le premier sur la période du 13 février au 5 mars concerne la gestion de signaux DTMF au sein d un module d une application de téléconférence. Le deuxième du 6 mars au 2 juin concerne, le pilotage de cette même application par l intermédiaire d une tablette tactile exécutant le systême. 2.4.1 Gestion de signaux DTMF Avant toute chose, il convient de définir quelque peu les différents termes que nous allons employer, à savoir le signal DTMF, le protocole H.323 et le MCU. 7
2.4.1.1 Qu est-ce qu un signal DTMF? Un signal (ou code) DTMF (Dual-Tone Multi-Frequency) est une combinaison de fréquences. Ce signal associe deux fréquences : chacune est choisie dans deux groupes de quatre fréquences différentes. Il y a donc 4 x 4 = 16 signaux DTMF distincts dont les combinaisons sont décrites dans le tableau ci-dessous (Figure - 2.2). 1209 Hz 1336 Hz 1477 Hz 1633 Hz 697 Hz 1 2 3 A 770 Hz 4 5 6 B 852 Hz 7 8 9 C 941 Hz * 0 # D Figure 2.2 Signaux DTMF Ces signaux sont utilisés dans la téléphonie, ils servent lors de la numérotation et dans les menus interactifs. Ils correspondent à notre clavier téléphonique bien que les touches A, B, C et D ne soient pas présentes sur tous les téléphones. 2.4.1.2 Qu est-ce que le protocole H.323? En fait H.323 n est pas un protocole à proprement parler mais une recommandation émise par l ITU-T (International Telecommunication Union) qui regroupe un ensemble de protocoles permettant la communication audio et vidéo sur IP (Internet Protocol). Nous pouvons voir sa structure dans la figure ci-après (Figure - 2.3). Figure 2.3 Structure de H.323 8
2.4.1.3 Qu est-ce qu un MCU? Un MCU (Multipoint Control Unit) est un composant logiciel ou matériel permettant la création de salles de vidéoconférence. 2.4.1.4 Pourquoi utiliser des signaux DTMF? L utilisation d un MCU dans l environnement H.323 nécessite l utilisation de signaux DTMF pour communiquer avec celui-ci. En effet un MCU ne comprend que ce type de signal, donc dans l éventualité ou nous désirions par exemple nous connecter à un MCU nécessitant une authentification, il est indispensable que notre application permette la génération et l envoi de signaux DTMF. 2.4.1.5 Sujet Il m a été demandé d ajouter le support des signaux DTMF à une application de téléconférence existante. Cette fonctionnalité devra s intégrer dans le module H.323 de l application. Ceci implique la génération de signaux DTMF, la création d une interface utilisateur permettant de manipuler ceux-ci, et l analyse de l existant permettant l intégration dans l interface de l application. 2.4.2 Application La composante NLTVC désirait développer une application permettant de piloter leur logiciel de téléconférence pour leur module propriétaire. Cette application doit permettre de se passer au maximum du clavier et de la souris et fonctionner en ad hoc, c est à dire que la tablette devra se connecter directement à l ordinateur sans passer par un point d accès. Cela implique qu il faut gérer les différents menus permettant la connexion à une salle de téléconférence et qu une fois connecté à celle-ci il faut afficher l écran d édition de documents directement sur la tablette. Il est donc nécessaire de mettre en place différents protocoles de communication entre l application mobile que nous appellerons client dans la suite du document et l application existante que nous appellerons serveur. 9
Chapitre 3 Cahier des charges Ce chapitre décrit le cahier des charges élaboré au fur et à mesure des différentes réunions d état d avancement hebdomadaires. Il a été complété de mes recommandations personnelles pour les deux sujets traités. 3.1 Gestion de signaux DTMF L implémentation de la gestion de signaux DTMF se découpe en différentes parties : la génération de signaux DTMF. l appel de signal DTMF au sein de l application existante. l envoi d un signal DTMF à un MCU. la création d une interface utilisateur. 3.2 Application Le cahier des charges imposé par l entreprise n était pas détaillé. Il se décomposait de la façon suivante et concerne l application : création des différents menus de l application. mise en place d un protocole de communication entre le serveur et le client. reproduction de l écran concernant l édition de documents. reproduction des interactions sur la tablette de l écran d édition de documents. 10
Ces quatre contraintes peuvent être divisées en deux parties. L une concernant l implémentation des différents menus et le protocole associé à ceci. L autre concernant la reproduction de l écran d édition de documents sur la tablette ainsi que la gestion des différentes interactions sur celle-ci et les protocoles associés à cela. Les détails du cahier des charges que j ai personnellement défini sont donnés aux aux sous-sections 3.2.1 et 3.2.2. Il est aussi à noter que l on ne considère qu un seul périphérique mobile connecté à la fois au serveur cela étant imposé par la connexion ad hoc. De plus l application devra permettre d accéder à un menu de configuration permettant de paramétrer celle-ci. 3.2.1 Implémentation des différents menus Il est primordial d assurer qu à tout moment une tablette connectée au serveur affichera le même menu que celui-ci. Afin de garantir ceci il faut donc mettre en place un diagramme d états-transitions (Figure - 3.1) qui devra être respecté à tout moment. Figure 3.1 Diagramme d états-transitions 11
Ce diagramme n est pas complet pour des raisons de lisibilité. En effet plusieurs autres actions peuvent être effectuées à partir du menu numéro huit. Parmi celles-ci il y a les actions autorisées pour tous les utilisateurs : menu 8 end : termine la téléconférence (retour au menu 4). menu 8 reqrel : demande à être actif/inactif (reste au menu 8). menu 8 options : ouvre le menu des options (reste au menu 8). menu 8 options change : valide les changements (reste au menu 8). Puis les actions qui ne sont disponibles qu au créateur de la téléconférence : action switch change l état d un utilisateur (reste au menu 8). action activate rend actif un utilisateur (reste au menu 8). action deactivate rend inactif un utilisateur (reste au menu 8). action drop exclu un utilisateur (reste au menu 8). Il faut noter que normalement l action menu 8 options doit ouvrir un nouveau menu, toutefois étant donné que la version du logiciel de téléconférence utilisée pour le développement diffère de la dernière version en date, il a été demandé de créer tout ce qui est nécessaire (interface et prise en charge sur la partie serveur) mais de ne rien lier à l application. À tout moment le serveur devra mémoriser le menu courant. Dans l éventualité ou le serveur reçoit un message qu il n est pas autorisé à traiter depuis le menu courant il renvoie un message précisant celui-ci. Étant donné que l application mobile ne change d état qu après réception d un message du serveur elle attendra celui-ci qu il soit une confirmation d action ou un refus. Les messages sont codifiés de la façon suivante : ajout de ok au message d origine et envoi si l action est valide. envoi de nok menu [n o menu courant] si l action est invalide. Prenons pour exemple un cas simple. Le serveur est dans l état menu 4, si il reçoit un message menu 2 ok il renverra alors nok menu 4 qui correspond à un message de refus précisant le menu actuel (dans ce cas précis cela ne change rien, nous irions dans tous les cas à l état menu 4). Si en revanche il réceptionne menu 4 create il effectuera le traitement associé et il renverra menu 4 create ok. 12
3.2.2 Écran d édition de documents Concernant l écran d édition de documents, il faut bien comprendre qu en réalité le logiciel de téléconférence utilisé pour le développement ne prenait pas encore en charge cette fonctionnalité. Toutefois cela ne pose pas de problème particulier étant donné qu il s agit de reproduire un écran choisi parmi ceux gérés par le logiciel de téléconférence sur la tablette, pour finalement permettre les différentes interactions possibles avec un clavier et une souris. Pour simplifier il s agit en fait d implémenter une fonctionnalité de prise de contrôle d ordinateurs distants sur la tablette. Le protocole propriétaire RDP de a été choisi par M. Chen Wei pour permettre ceci. Mais il est bien évident qu un périphérique tactile n offre pas la même expérience utilisateur qu une souris. Il a donc été décidé de procéder comme suit pour gérer les différents types de clics : clic gauche : touché simple sur la tablette. clic droit : touché long sur la tablette. double clic : touché double sur la tablette. Quant au clavier, il faut mettre en place un clavier virtuel comprenant à terme toutes les touches possibles d un clavier conventionnel. Il a été demandé de réduire le nombre de touches prises en charge au départ, car c est un travail qui sera effectué par un autre étudiant, mais de faire en sorte qu il n ait qu a faire du copier-coller pour compléter le clavier. 3.3 Technologies et outils utilisés 3.3.1 Environnements de développement La partie de gestion des signaux DTMF tout comme la partie serveur de l application de prise de contrôle d ordinateurs distants nécessite l emploi de l IDE (Integrated Development Environment) les projets ayant été créés avec cet outil. Pour le développement de l application l IDE a été privilégié car avec le module d extension ADT (Android Development Tools) c est l environnement le plus adapté au développement sur cette plateforme. 13
3.3.2 Langages et technologies Plusieurs langages de programmation ont étés utilisés, le C++ et le C# pour la gestion de signaux DTMF, et les langages C# et pour l application. Bien évidemment toute la partie interface et interaction avec les périphériques est différente du conventionnel, c est en effet spécifique à. 3.4 Organisation du temps de travail Dès l arrivée en entreprise, il a fallu donner un planning prévisionnel du déroulement du stage, celui-ci est représenté dans le tableau ci après (Figure - 3.2) : N o Début Fin Tˆache 1 13/02 20/02 Prise de contact, présentation des sujets, analyse. 2 20/02 27/02 Génération de signaux DTMF, interface utilisateur. 3 27/02 05/03 Intégration et documentation. 4 05/03 12/03 Rendu projet DTMF, début initiation à. 5 12/03 19/03 Analyse des besoins, analyse des possibilités. 6 19/03 26/03 Développement client/serveur simple entre C# et. 7 26/03 02/04 Interface utilisateur pour les menus. 8 02/04 09/04 Intégration du serveur dans l application. 9 09/04 16/04 Essai d intégration de RDP au sein d. 10 16/04 23/04 Développement d un protocole de prise de contrôle à distance. 11 23/04 30/04 Renouvellement du visa. 12 30/04 07/05 Prise de contrôle à distance - reproduction de l écran. 13 07/05 14/05 Prise de contrôle à distance - gestion des clics. 14 14/05 21/05 Prise de contrôle à distance - gestion du clavier. 15 21/05 28/05 Prise de contrôle à distance - tests. 16 28/05 04/06 Rédaction rapport de stage. Figure 3.2 Organisation du temps de travail 14
Chapitre 4 Mise en œuvre Ce chapitre expose le travail réalisé tant pour la partie de gestion de signaux DTMF que pour l application. 4.1 Gestion de signaux DTMF Pour mettre en place la gestion de signaux DTMF, il a fallu dans un premier temps faire une analyse de l existant. Ce ne fût pas chose aisée étant donné qu aucune personne ayant travaillé sur le projet n était encore dans l entreprise et que le code de l application était extrêmement conséquent. Toutefois le projet se base en grande partie sur un projet open source nommé H323Plus il était donc possible de trouver de la documentation. 4.1.1 Génération de signaux DTMF Un autre étudiant, Trinetra Sundrasagra avait essayé de générer des signaux DTMF. Il n avait cependant pas réussi à générer des signaux conformes ni à intégrer son travail développé en C# au sein de l application en C++. L idée de base était de générer un signal au format PCM utilisant le conteneur WAV et de lire le fichier obtenu dans un canal audio servant normalement à transmettre l entrée microphone de l ordinateur. Il fallait donc d une part créer un fichier WAV valide et d autre part trouver un moyen de lire celui-ci sur le canal. 15
Après différents tests il s est avéré que cela était impossible, mais surtout inutile. En effet dans une version postérieure à celle utilisée au sein de notre application, le projet H323Plus prenait en charge cette fonctionnalité. Il a donc été décidé d intégrer les modifications effectuées au sein du projet H323Plus dans l application existante. Pour ce faire il a fallu importer les fichiers rfc2833.h et rfc2833.cpp et faire diverses modifications afin de pouvoir utiliser les fonctions qu ils offrent. Ces deux fichiers permettent d envoyer directement sur un canal un signal DTMF. Ce signal n était toutefois pas joué sur les haut-parleurs de l ordinateur, l utilisateur n avait donc aucun retour sur ce qu il faisait. C est pourquoi le code C# permettant de générer des signaux fût quand même utilisé afin de combler ce manque. Mais ceci posa problème, car le code en C# devait être appelé depuis le code en C++. Il a donc fallu trouver un moyen d effectuer cette action. Le problème a pu être résolu en modifiant le code C# pour que celui-ci permette de générer une bibliothèque et de transformer celle-ci en objet COM. Malheureusement une fois que ce problème fût résolu un autre survint, le code joué par les haut-parleurs était dans certains cas enregistré par le microphone et était donc reçu plusieurs fois par le MCU. Une solution très simple fût mise en œuvre : elle consiste à désactiver le microphone tant que l interface utilisateur décrite ci-après est accessible et de le réactiver dans le cas contraire. 4.1.2 Interface utilisateur L interface développée est relativement simple. Sur l interface de vidéoconférence de base vient se greffer un icône représentant un clavier, cet icône permet d ouvrir ou de fermer le clavier. À l ouverture, le microphone est désactivé et l utilisateur en est informé. Les lettres S et H sont utilisées pour représenter respectivement * et #. Les changements dans l interface de base après ouverture ou fermeture du clavier peuvent être constatés sur les deux figures suivantes (Figure - 4.1 et Figure - 4.2) : 16
Figure 4.1 Interface principale (clavier fermé) Figure 4.2 Interface principale (clavier ouvert) 17
4.1.3 Classes importantes Cette sous-section décrit les classes les plus importantes de l application, à savoir les classes : CDirectCall et son interface IDirectCall, CMyEndpoint, CMyPasswordKeypad, et CH323ControlDlg. 4.1.3.1 CDirectCall et IDirectCall Cette classe et son interface sont utilisées pour générer des sons correspondants aux signaux DTMF envoyés. Voici la liste de ces fonctions : Wave call0(double volumemixed) ; Wave call1(double volumemixed) ; Wave call2(double volumemixed) ; Wave call3(double volumemixed) ; Wave call4(double volumemixed) ; Wave call5(double volumemixed) ; Wave call6(double volumemixed) ; Wave call7(double volumemixed) ; Wave call8(double volumemixed) ; Wave call9(double volumemixed) ; Wave calla(double volumemixed) ; Wave callb(double volumemixed) ; Wave callc(double volumemixed) ; Wave calld(double volumemixed) ; Wave callh(double volumemixed) ; Wave calls(double volumemixed) ; Wave callto(string tocall, String savepath, double volumemixed) ; Toutes ces fonctions prennent en paramètre une variable de type double qui représente le volume auquel nous désirons jouer les sons. Ce volume peut varier entre 0 et 0.5. Les fonctions de type Wave callx(double volumemixed) avec X pouvant prendre les valeurs {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, H, S} correspondent à un seul et unique signal contrairement à la fonction Wave callto(string tocall, String savepath,double volumemixed). 18
Cette fonction n est pas utilisée pour le moment mais pourrait être utile dans le cas ou l on stockerait un mot de passe pour un MCU et que l on voudrait numéroter celui-ci en une seule fois. Elle prend en plus en paramètres deux String. Le premier est une chaîne de caractères que l on désire jouer parmi les caractères suivants : {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, *, #}. Tout caractère n étant pas dans cet ensemble est ignoré. Le second paramètre est un chemin vers lequel un fichier WAV est enregistré. Celui-ci est composé de la suite de caractères joués entre lesquels sont insérés des silences afin que la suite de sons soit plus agréable à entendre. 4.1.3.2 CMyEndpoint Cette classe est celle qui doit importer le fichier rfc2833.h qui nous permettra d utiliser les fonctions : void OnUserInputTone(char tone, unsigned duration, unsigned logicalchannel, unsigned rtptimestamp) ; void SendUserInputTone(char tone, unsigned duration, unsigned logicalchannel, unsigned rtptimestamp) ; void SendUserInput(const PString & value) ; La fonction que nous utiliserons systématiquement est void SendUserInput(const PString & value). Le paramètre en entrée représente la suite de signaux DTMF que nous désirons envoyer sur le réseau. 4.1.3.3 CMyPasswordKeypad Cette classe fournit une interface utilisateur qui permet la saisie de signaux DTMF. Elle va aussi générer un son après chaque appui de touche en utilisant l interface IDirectCall. Enfin elle appellera la fonction void SendUserInput(const PString & value) qui enverra le signal sur le réseau. 19
Elle possède différents accésseurs permettant de définir divers paramètres : void setendpoint(cmyendpoint *endpoint) : nous devons définir notre CMyEndPoint qui permettra d accéder au fonctions indispensables void SetSendUserInputMode(SendUserInputModes mode) et void SendUserInput(const PString & value). void settonesound(bool sound) : permet d activer ou non le son des touches. void setvolume(double volume) : permet de fixer le volume à une valeur comprise entre 0 et 0.5. double getvolume() : permet de connaître la valeur de volume courante. Il y a d autres fonctions dans cette classe qui lient chaque touche de l interface à une action. Puis ces fonctions envoient un code unique à la fonction void SendVirtualKey(WORD vk) qui est la fonction la plus importante vis-à-vis de la gestion de signaux DTMF. En effet c est celle-ci qui sera chargée de faire appel aux différentes fonctions inhérentes à la fonctionnalité DTMF comme les différentes fonctions Wave callx(double volumemixed) ou encore la fonction void SendUserInput(const PString & value). 4.1.3.4 CH323ControlDlg Cette classe permet de gérer toutes les actions de l utilisateur une fois que la vidéoconférence a démarré. C est l interface utilisateur principale, nous devons donc intégrer celle que nous avons créée (CMyPasswordKeypad) en ajoutant un bouton qui permettra d ouvrir ou de fermer le clavier virtuel. Ce bouton lancera la fonction void OnBnClickedMfcbuttonKbd() laquelle en plus d afficher ou non le clavier, activera ou désactivera le microphone afin de prévenir un envoi de signal non désiré au MCU. Si nous désactivons le microphone il faut bien entendu le faire savoir à l utilisateur. Nous devons donc ouvrir le panneau de contrôle des options audio et afficher l icône de désactivation du microphone. Il faudra bien évidemment faire l inverse lors de la réactivation de celui-ci. Enfin nous devons empêcher l accès de l activation manuelle du microphone à l utilisateur. Pour cela il faut modifier la fonction void OnBnClickedMfcbuttonMic() en testant si l interface de saisie de signaux DTMF est ouverte ou non. 20
4.2 Application Avant de commencer le développement de l application il m a été nécessaire de suivre divers tutoriels afin de m initier à l environnement. En effet il faut connaître les possibilités de celui-ci avant d entamer une quelconque phase de développement et ceci afin de répondre au mieux aux contraintes formulées dans le cahier des charges. C est d autant plus important car je n avais aucune connaissance dans ce domaine avant le début stage. Les phases de développement successives sont détaillées dans les sous-sections suivantes. 4.2.1 Débloquer la tablette Dans un premier temps il a fallu débloquer la tablette en la mettant en mode root car nous ne pouvions utiliser le en mode ad hoc avec la configuration originale de celle-ci. Le mode root a permis de remplacer le wpa supplicant par une version modifiée qui permet d utiliser le en mode ad hoc. Voici la suite de lignes de commandes permettant d effectuer ceci (Figure - 4.3) : Commandes adb push wpa supplicant /system/bin adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system cp /system/bin/wpa supplicant /sdcard/wpa supplicant.original cp /sdcard/wpa supplicant /system/bin/. chmod 755 /system/bin/wpa supplicant chown system.wifi /data/misc/wifi/wpa supplicant.conf Figure 4.3 Commandes pour rooter la tablette Ces commandes nécessitent l installation préalable de l utilitaire ADB qui est fourni dans le SDK d. 21
4.2.2 Configuration du Le paramétrage de la connexion doit se faire manuellement. Du coté de la machine serveur qui exécute l environnement Windows 7 il faut créer une nouvelle connexion de type ad hoc. Ceci peut se faire grâce à l utilitaire intégré au sein du système. Nous devons ensuite affecter une adresse IP fixe qui sera utilisée coté client. Coté client nous devons nous connecter manuellement au réseau créé précédemment et saisir l adresse IP du serveur en tant que passerelle. Nous ne pouvons pas configurer cette connexion de manière logicielle car c est une connexion ad hoc qui n est donc pas prise en charge par les services et utilitaires du système d exploitation. Une fois la connexion créée il n est pas nécessaire de faire une quelconque configuration dans notre application. En effet notre application va automatiquement essayer de se connecter à la passerelle du réseau actif. De plus avant d essayer de se connecter au réseau actif notre application désactive (s il est actif) et réactive le afin d être sûr que nous nous connectons automatiquement au réseau le plus prioritaire. Il suffit donc que notre réseau soit privilégié par rapport aux autres pour nous assurer de toujours nous connecter au bon réseau et que l utilisateur n ai jamais à intervenir dans la configuration. 4.2.3 Gestion des interactions avec les menus Afin de gérer les menus, plusieurs algorithmes ont étés mis en place. Le premier coté serveur décrit la prise en charge des messages envoyés par le client qui lui parviennent (Algorithme - 1) : Algorithme 1: réception des messages (serveur) 1 si message recu est dans liste messages valides alors 2 effectuer l action sur le menu 3 message reponse concaténer(message recu, ok ) 4 sinon 5 message reponse menu courant 6 finsi 7 retourner message reponse 22
Le second est quant à lui coté client. Il décrit comment une modification sur la tablette (clic sur un bouton, remplissage de champ texte, selection d items, etc.) est traitée (Algorithme - 2) : Algorithme 2: traitement des actions utilisateur (client) 1 envoi d un message de demande d action 2 message reponse attendremessage() 3 si message reponse est dans liste reponses valides alors 4 valider l action 5 sinon si message reponse est dans liste menus alors 6 changer le menu courant par le menu message reponse 7 finsi Le troisième décrit le comportement de la tablette lors de l envoi d un message (Algorithme - 3) : Algorithme 3: envoi des messages (client) 1 envoi termine faux 2 nombre envois 0 3 répéter 4 envoi termine envoyer(message a envoyer) 5 si envoi termine = faux alors // erreur d envoi 6 si message a envoyer message de terminaison alors 7 nombre envois nombre envois + 1 8 si nombre envois > 4 alors 9 envoi termine vrai 10 sinon 11 attente de 500ms /* on laisse le temps à la socket d être recréée */ 12 finsi 13 sinon 14 envoi termine vrai /* l application doit être quittée le plus rapidement possible */ 15 finsi 16 finsi 17 jusqu à envoi termine = vrai 23
L algorithme 3 essaiera de renvoyer un message tant que l envoi ne s est pas déroulé correctement, sauf si ce message est une demande de terminaison de l application, car en effet personne ne voudrait d une application mobile qui mettrait plus de 2s à quitter. L envoi échoue dans le cas ou l on rencontre une exception qui peut être de différents types (entrée/sortie, socket fermé, timeout, etc.). Dans ce cas, la socket est recréée. Ce mode de fonctionnement offre plusieurs avantages. L un d eux est que si une perte de connexion survient (si la distance est trop grande par exemple), alors dès que nous serons à nouveau à portée et que nous renvoyons un message, la socket sera automatiquement recréée. Il y a d autres avantages liés aux exceptions qui peuvent survenir, lesquels se terminent toujours par le fait que l application se reconnecte automatiquement sans aucune intervention particulière de l utilisateur. L interface des différents menus est décrite dans la sous-section 4.2.6. 4.2.4 Écran d édition de documents La fonctionnalité d édition de documents n est pour le moment pas prise en charge par l application Crystalview toutefois il m a été demandé de mettre en place un système permettant de la prendre en charge sur la tablette. À la base le protocole RDP devait être utilisé. Cependant étant donné que c est un protocole fermé son implémentation n est pas des plus aisée. Une piste a bien été explorée avec un logiciel open source prenant en charge ce protocole mais malheureusement il était d une part complexe, et d autre part il n avait pas le fonctionnement désiré. En effet celui-ci permettait bien à un utilisateur de se connecter à une session Windows 7 mais en déconnectant l utilisateur actuellement connecté dessus. Or, il faut justement avoir l écran disponible simultanément sur la machine et sur la tablette. Il a donc été décidé de ne pas poursuivre avec RDP, mais de mettre en place un protocole créé de toutes pièces avec d une part l envoi de l écran désiré sous forme d image et d autre part la gestion des actions utilisateur traitée dans la sous-section 4.2.5. Voici les algorithmes associés à l envoi et la réception d images (Algorithmes - 4 & 5) : 24
Algorithme 4: envoi des images (serveur) 1 deconnexion faux 2 répéter 3 envoyermessage( image +longeur image+ +largeur image) 4 créer un processus qui enverra l image 5 message reponse attendremessage() /* on attend confirmation de la réception de l image avant d en envoyer une autre */ 6 si message reponse = déconnexion alors 7 deconnexion vrai 8 finsi 9 jusqu à deconnexion = vrai Algorithme 5: reception des images (client) 1 deconnexion faux 2 répéter 3 si demande d arrêt du processus par le processus principal alors 4 deconnexion vrai 5 sinon 6 message reponse attendremessage() /* on attend un message annonçant une image */ 7 largeur récupérerlargeur( message reponse ) 8 longueur récupérerlongueur( message reponse ) 9 créer un processus qui réceptionnera l image 10 initialiser( longueur, largeur ) /* le processus attendra une image de longueur longueur et de largeur largeur */ 11 image receptionimage() /* on réceptionne l image provenant du processus précédemment créé */ 12 redimensionner(image) /* on redimensionne l image afin qu elle corresponde à la résolution de la tablette */ 13 afficher( image ) // on affiche l image sur la tablette 14 finsi 15 jusqu à deconnexion = vrai 25
Le redimensionnement de l image se fait en gardant le ratio originel de celleci. Il est nécessaire de connaître et de garder le ratio afin de faire correspondre par la suite un touché sur la tablette à un clic sur l ordinateur distant. Les différents calculs de correspondance sont détaillés dans la sous-section ciaprès (4.2.5). 4.2.5 Traitement des actions utilisateur Les actions de l utilisateur sont de deux types, les actions souris et les actions clavier. Les actions souris sont en fait des touchés de l utilisateur sur l image reproduisant l écran de l ordinateur distant. 4.2.5.1 Actions souris Étant donné que la résolution de l écran reproduit n est pas forcément la même que celle de l écran de la tablette (surtout que seule une partie est utilisée) il faut convertir les coordonnées des touchés afin de les faire correspondre aux coordonnées sur l écran distant. La procédure est en deux étapes. La première consiste à initialiser certaines variables qui seront utilisées lors de chaque action souris (Algorithme - 6). Ces variables sont ensuite utilisées lors de la deuxième étape qui consiste à calculer la correspondance entre les coordonnées sur la tablette et celles sur l ordinateur distant (Algorithme - 7). Les variables les plus importantes des algorithmes 6 et 7 sont les suivantes : coefficient : c est la variable la plus importante pour le calcul de coordonnées. Elle représente un coefficient de réduction ou d agrandissement qui sera appliqué aux coordonnées du touché sur la tablette. offset longueur et offset largeur : ces variables représentent un décalage en X ou en Y qui correspond aux bandes qui peuvent apparaitre de part et d autre soit en largeur soit en longueur lorsque le ratio de la tablette n est pas identique à celui de l écran de l ordinateur distant. longueur affichee et largeur affichee : ces variables représentent la longueur et la largeur de l image telle qu elle est affichée (la résolution de la zone d affichage sur la tablette moins les offsets éventuels). clic superieur : cette variable permet de savoir si l utilisateur a cliqué sur la partie haute ou la partie basse de l écran. Cela est nécessaire afin de pouvoir positionner le clavier sur l interface (Voir section - 4.2.5.2). 26
Algorithme 6: initialisation des variables pour le calcul de coordonnées 1 coefficient 1 2 offset longueur 0 3 offset largeur 0 4 longueur ecran local obtenirlongueur( zone affichage ) 5 largeur ecran local obtenirlargeur( zone affichage ) 6 longueur ecran distant longueur ecran local 7 largeur ecran distant largeur ecran local 8 longueur affichee longueur ecran local 9 largeur affichee largeur ecran local 10 image recevoirimage() 11 si longueur ecran local / largeur ecran local > obtenirlongueur( image ) / obtenirlargeur( image ) alors /* ratio supérieur */ 12 longueur affichee longueur ecran local obtenirlongueur( image ) / obtenirlargeur( image ) 13 coefficient obtenirlongueur( image ) / longueur ecran local 14 offset longueur ( longueur ecran local - longueur affichee ) / 2 15 sinon si longueur ecran local / largeur ecran local < obtenirlongueur( image ) / obtenirlargeur( image ) alors /* ratio inférieur */ 16 largeur affichee largeur ecran local obtenirlargeur( image ) / obtenirlongueur( image ) 17 coefficient obtenirlargeur( image ) / largeur ecran local 18 offset largeur ( largeur ecran local - largeur affichee ) / 2 19 sinon /* ratio identique */ 20 si longueur ecran local > obtenirlongueur( image ) alors 21 coefficient longueur ecran local / obtenirlongueur( image ) 22 sinon si longueur ecran local < obtenirlongueur( image ) alors 23 coefficient obtenirlongueur( image ) / longueur ecran local 24 finsi 25 finsi 27
Algorithme 7: calcul de coordonnées Entrées : x, y Sorties : x reel, y reel, clic superieur 1 x reel -1 2 y reel -1 3 si x > (0 + offset longueur) x < (longueur ecran local - offset longueur) y > (0 + offset largeur) y < (largeur ecran local - offset largeur)) alors 4 x reel ((x - offset longueur) coefficient 5 y reel ((y - offset largeur) coefficient 6 si y > largeur ecran local alors 7 clic superieur faux 8 sinon 9 clic superieur vrai 10 finsi 11 finsi Il faut noter que l algorithme 6 est appelé à chaque fois qu un processus de réception d image est créé (Algorithme - 5 ligne : 9). Cela permet de gérer les changements de résolution. En effet dans notre application, si du coté serveur nous changeons de résolution, les nouvelles longueur et largeur d image sont envoyées ce qui mettra à jour le coefficient et les offsets. Nous avons donc une gestion parfaitement dynamique des changements de résolution. De plus si l écran sur lequel l édition de document doit se faire est désactivé en cours de fonctionnement, nous basculons automatiquement sur l écran principal afin par exemple de résoudre le problème qui a conduit à la désactivation de l écran secondaire. L appel de l algorithme 7 se fait à chaque fois qu un touché est effectué. Une fois les valeurs x reel et y reel obtenues elles sont envoyées avec le type d action (simple clic, double clic, etc.) vers le serveur. Les messages sont envoyés sur la même socket que les messages de changements de menu. Ils sont structurés de la façon suivante : input mouse + action + + position x + + position y. 28
Les valeurs possibles de action sont : move : mouvement de la souris (après un press ) press : clic gauche pressé et maintenu release : clic gauche relâché left : clic gauche pressé et relâché right : clic droit double : double clic gauche Lorsque le serveur réceptionne ces données il retranche systématiquement les coordonnées de l origine de l écran choisi. Prenons pour exemple un écran secondaire placé à la gauche de l écran primaire et d une résolution de 1280 par 720. Les coordonnées de l origine de cet écran seront de (-1280, 0). Si le serveur reçoit une demande de clic gauche en (450, 600) il effectuera en fait un clic en (-830, 600). L écran dupliqué par défaut est l écran numéro 1, l indice de l écran principal étant le 0. Si l on désire dupliquer un autre écran, il suffit de modifier une seule variable sur le serveur (usedscreen) et de lui affecter le numéro de l écran désiré. Les calibrages des coordonnées d origines et de sa résolution sont ensuite effectués automatiquement. 4.2.5.2 Actions clavier Le clavier virtuel doit pouvoir être ouvert ou fermé à n importe quel moment. En effet lorsque nous effectuons un touché sur la tablette, nous ne sommes pas en mesure de savoir si ce touché a été fait dans une zone de texte ou non. Nous nous pouvons donc pas ouvrir le clavier automatiquement comme cela serait fait sur une zone de texte créée sur la tablette. De plus, afin de ne pas obstruer la vue de l utilisateur lors de l apparition du clavier nous l affichons soit sur la partie supérieure de la tablette, soit sur la partie inférieure. Le choix de l une ou l autre partie se fait en fonction des coordonnées du dernier touché sur la tablette. Si nous effectuons un touché sur la partie supérieure de l écran, le clavier sera affiché sur la partie inférieure et inversement. C est la variable booléenne clic superieur (Voir algorithme 7) qui nous permet de déterminer où afficher le clavier. 29
Le cahier des charges stipule que le clavier virtuel se doit d être le plus complet possible. Toutefois et comme précisé dans le cahier des charges, toutes les touches n ont pas été implémentées car elle doivent l être par un autre étudiant. Cependant tous les types de touches ont étés implémentés (lettre, chiffre, caractère spécial, touche de contrôle). Et le protocole est prêt à gérer toutes les touches possibles, seul l ajout de ces touches au clavier virtuel est à faire. L envoi d un touche vers le serveur suit la même logique que pour la souris. On envoie : input keyboard + touche. touche pouvant prendre une valeur correspondant à une touche ou à un ensemble de touches. 4.2.6 Interface utilisateur Voici maintenant ce que l utilisateur pourra voir lorsqu il utilise notre application. Il faut noter que les captures d écran sont en basse qualité et que la colorimétrie n est donc pas respectée. L aspect visuel de l interface est beaucoup plus satisfaisant dans des conditions réelles. Nous allons aborder l interface en trois parties, l interface principale et les menus (Voir - 4.2.6.1), le menu de gestion des participants à une conférence (Voir - 4.2.6.2), et enfin le clavier virtuel (Voir - 4.2.6.3). 4.2.6.1 Interface principale et différents menus L interface principale (Figure - 4.4) se veut simple et claire. Trois boutons permettant d ouvrir le menu d authentification, d options et de quitter l application. Chaque menu comportera ce bouton car on doit pouvoir quitter l application à tout moment. De plus à l extrémité supérieure de l écran nous avons un bouton de la largeur de l écran qui permet d ouvrir le clavier virtuel (Voir - 4.2.6.3). Et sur la gauche un bouton à glisser qui permet de dérouler la fenêtre de gestion des participants à la conférence (Voir - 4.2.6.2). L image en fond d écran est en fait notre zone d affichage pour le moiteur distant. L image que vous pouvez voir est le fond d écran du deuxième moniteur de l ordinateur distant. Vous pouvez constater le changement de cette zone dans la section 4.2.6.3 ou l on peut voir l interface d un programme en cours d exécution sur l ordinateur distant. 30
Figure 4.4 Interface principale Figure 4.5 Menu d option avant connexion 31
La figure 4.5 ci-dessus présente le menu des options. Il faut noter que celui-ci est diffère en fonction de l état de l utilisateur (authentifié ou non). Le menu lorsque l utilisateur est connecté est visible sur la figure 4.5 ci-après et est accessible depuis le bouton option du menu principal (Figure - 4.8). Figure 4.6 Menu d option après connexion Après avoir lancé l application l utilisateur doit s authentifier (Figure - 4.7). Pour cela il doit remplir deux champs texte. Ceux-ci sont automatiquement pré-remplis avec les données stockées par l application distante. Figure 4.7 Menu d authentification 32
Le menu principal (Figure - 4.8) permet d initier des actions que l on ne peut que faire une fois authentifié. Ce menu est dynamique car si jamais l utilisateur a reçu une invitation à une conférence, il verra apparaître sur ce menu un bouton supplémentaire. Celui-ci lui permet d accéder à la liste de ses invitations en attentes dans le but de choisir une conférence à rejoindre. Les boutons systématiquement présents lui permettent de se déconnecter du serveur, d accéder au menu d options que l on a pu voir précédemment (Figure - 4.6), de quitter l application, mais aussi de créer une conférence (Figure - 4.9). Figure 4.8 Menu principal Lors de la création d une conférence (Figure - 4.9), l utilisateur doit spécifier un nom de conférence. Ce champ est pré-rempli de la même manière que le champ d authentification (Figure - 4.7). Il doit aussi choisir quel est le type de conférence qu il souhaite créer entre un conférence point à point (un seul participant en plus de lui) et une conférence multiple (plus de deux participants). Figure 4.9 Menu de création de conférence 33
Après avoir choisi le type de conférence qu il souhaitait créer, l utilisateur doit choisir des participants parmi une liste (Figure - 4.10). Cette liste ne lui autorise qu un seul choix si la conférence est de type point à point et bien évidemment plusieurs dans le cas d un conférence multiple. Un code de couleur a été mis en place afin de simplifier le choix des participants. Si la ligne est verte l utilisateur est connecté et n est pas en conférence. Si elle est orange l utilisateur est connecté mais est déjà en conférence. Enfin si elle est rouge l utilisateur est déconnecté. L utilisateur peut choisir d inviter des personnes soit en tant que participant, soit en tant qu observateur. Pour cela un bouton est associé à chaque ligne et peut prendre deux états correspondants à une invitation en tant que participant ou en tant qu observateur. Figure 4.10 Menu d invitation des utilisateurs 34
4.2.6.2 Gestion des participants à la conférence Lorsque la conférence est créée, l utilisateur peut voir la liste des participants en ouvrant le menu déroulant situé sur la gauche (Figure - 4.11). Figure 4.11 Menu de gestion des participants L utilisateur de la tablette peut soir être un simple utilisateur, soit celui qui a créé la conférence. L application suivra deux comportements différents en fonction de ce paramètre. Si l utilisateur est un simple participant il peut voir la liste des utilisateurs, quitter la conférence, ou encore demander à prendre la parole (par l appui sur un bouton qui apparait seulement pour les participants). En revanche si l utilisateur préside la conférence il peut en plus administrer les participants en effectuant différentes actions accessibles à lui seul. Les actions qu il peut effectuer dépendent de l état de l utilisateur dans la conférence. Il y a quatre états différents correspondant au quatre sections que l on peut voir dans la figure 4.11 ci-dessus. 35
Si l utilisateur sélectionné a la parole (état ON AIR ), ou qu il est autorisé à parler mais que la limite du nombre de locuteurs simultanés de la conférence l empêche temporairement de jouir (état ON QUEUE ), le président a accès à un menu (Figure - 4.12) lui permettant de reprendre la parole à l utilisateur ou encore de l exclure de la conférence. Figure 4.12 Menu flottant (état ON AIR ou ON QUEUE ) Si l utilisateur a rejoint la conférence (état JOINED ), le président a accès à un menu (Figure - 4.13) lui permettant de donner la parole à l utilisateur, de l exclure de la conférence ou encore de changer son état de participant à observateur. Figure 4.13 Menu flottant (état JOINED ) Si l utilisateur est invité à la conférence mais n a pas encore accepté l invitation (état INVITED ), le président a accès à un menu (Figure - 4.14) lui permettant de l exclure de la conférence ou encore de changer son état de participant à observateur. Figure 4.14 Menu flottant (état INVITED ) Enfin il faut noter que si le président quitte la conférence, celle-ci se termine automatiquement. 36
4.2.6.3 Clavier virtuel Comme précisé en 4.2.5.2, le clavier peut apparaître soit en haut, soit en bas de l écran de la tablette, et ce pour ne pas obstruer la vue de l utilisateur lors de la saisie. Le clavier virtuel s ouvrira après appui sur le bouton Open Keypad que l on a pu voir sur la figure 4.4. La fermeture se fait simplement en touchant une zone externe à la zone du clavier virtuel. On peut voir ci-après deux captures d écran montrant le clavier en haut (Figure - 4.16) ou en bas (Figure - 4.15). De plus quand le clavier est en haut nous pouvons aussi voir que la touche Caps Lock a été pressée et est donc mise en surbrillance jusqu à un appui ultérieur. Enfin, on peut se rendre compte qu il y a une bande centrale que le clavier ne vient jamais obstruer afin de permettre à l utilisateur la saisie, même si il sélectionne une zone de texte exactement au milieu de l écran. Figure 4.15 Clavier virtuel (position basse) 37
Figure 4.16 Clavier virtuel (position haute) 38
Chapitre 5 Bilans Après une expérience telle qu un stage il est nécessaire de dresser un bilan du travail effectué et de ce qu il a apporté. Trois points vont être abordés dans ce chapitre. En premier lieu le bilan pour l entreprise (Section - 5.1) suivi d un bilan humain (Section - 5.2) pour finir par un bilan pédagogique (Section - 5.3). 5.1 Bilan pour l entreprise Nav6 peut maintenant offrir à ses clients la possibilité de se connecter à des MCU nécessitant un mot de passe. C est une fonctionnalité qui était expressément demandée par l un de ses clients et elle va donc pouvoir le fidéliser en lui proposant ce qu il désire. L entreprise peut aussi offrir à ses clients un moyen novateur de piloter leur logiciel de téléconférence d une façon simple et efficace. Elle pourra aussi s appuyer sur les compétences acquises dans le développement pour l environnement afin de proposer des produits attractifs sur cette plateforme. Enfin, la documentation rédigée pour chacun des deux travaux permettra aisément à l équipe NLTVC de poursuivre le développement de ceux-ci. 5.2 Bilan humain Ce stage a été extrêmement enrichissant d un point de vue humain. En effet la découverte de la culture, du mode de vie, de l entreprise et de la façon de travailler en Malaisie permet d appréhender d une autre manière les problèmes que l on peut rencontrer. 39
De plus, beaucoup de personnes de Nav6 viennent de pays étrangers (Chine, Inde, Japon, Corée du sud, Ouganda, etc.) ce qui entraine un brassage culturel et des discussions très intéressantes. Enfin, l intégration dans l équipe s est faite sans aucun problème car tous les employés de Nav6 se sont montrés accueillants et bienveillants. 5.3 Bilan pédagogique Ce stage fût pour moi une source de nouvelles connaissances car je n avais que des bases concernant le développement C# et.net et n avais absolument aucune connaissance de la programmation sur plateforme. J ai pu toutefois effectuer le travail demandé en m appuyant sur les enseignements de mon cursus scolaire. En outre j ai du organiser mon travail en livrant un planning prévisionnel, faire des comptes-rendus d avancement lors des multiples réunions et éditer de la documentation qui sera reprise pour les développements futurs. Tout ceci m a donc initié aux problématiques de l entreprise et du travail de groupe. Finalement j ai eu à communiquer en langue anglaise ce qui m a permis d améliorer ma compréhension, ma diction et mon vocabulaire dans cette langue. 40
Chapitre 6 Conclusion Au terme de ce stage riche en enseignements, il apparait que pour répondre au mieux au cahier des charges, il est nécessaire de l expliciter le plus possible en encourageant l échange et la communication. En effet la communication, l analyse, et la planification du travail sont essentielles à la bonne conduite d un projet. Suite à ce travail préalable, le cahier des charges a pu être parfaitement respecté. L équipe NLTVC dispose aujourd hui d un logiciel de téléconférence intégrant toutes les exigences de ses clients. Elle peut aussi se targuer de posséder un outil novateur, permettant le pilotage de son application d une façon simple et efficace. De plus, la maîtrise de l environnement ouvre un champ de possibilités à l entreprise. Celui-ci laisse présager des développements futurs, se basant sur l application développée et la documentation produite pendant la durée de ce stage. Finalement nous pourrions très bien imaginer aller encore plus loin dans l intégration, en développant une application client pour le logiciel de téléconférence Crystalview 9100 qui fonctionnerait nativement sur la plateforme. 41
Table des figures 2.1 Localisation de Nav6...................... 6 2.2 Signaux DTMF......................... 8 2.3 Structure de H.323....................... 8 3.1 Diagramme d états-transitions.................. 11 3.2 Organisation du temps de travail................ 14 4.1 Interface principale (clavier fermé)................ 17 4.2 Interface principale (clavier ouvert)............... 17 4.3 Commandes pour rooter la tablette............. 21 4.4 Interface principale........................ 31 4.5 Menu d option avant connexion................. 31 4.6 Menu d option après connexion................. 32 4.7 Menu d authentification..................... 32 4.8 Menu principal.......................... 33 4.9 Menu de création de conférence................. 33 4.10 Menu d invitation des utilisateurs................ 34 4.11 Menu de gestion des participants................ 35 4.12 Menu flottant (état ON AIR ou ON QUEUE )..... 36 4.13 Menu flottant (état JOINED )................ 36 4.14 Menu flottant (état INVITED )............... 36 4.15 Clavier virtuel (position basse).................. 37 4.16 Clavier virtuel (position haute)................. 38 42
Liste des Algorithmes 1 réception des messages (serveur)................. 22 2 traitement des actions utilisateur (client)............. 23 3 envoi des messages (client).................... 23 4 envoi des images (serveur)..................... 25 5 reception des images (client)................... 25 6 initialisation des variables pour le calcul de coordonnées.... 27 7 calcul de coordonnées....................... 28 43
Glossaire ADB ADT Android COM Android Debug Bridge est un utilitaire de développement en ligne de commandes pour. Android Development Tool est un module d extension de l IDE pour l environnement. Système d exploitation open source basé sur le noyau Linux orienté pour une utilisation mobile. Le langage de programmation utilisé pour ce système est une version de. Component Object Model permet à un objet d exposer ses fonctionnalités à d autres composants et d héberger des applications. Il permet par exemple d appeler du code C++ au sein d un code C# et inversement. DTMF Dual-Tone Multi-Frequency (voir 2.4.1.1). Eclipse Logiciel permettant de développer des logiciels dans un grand nombre de langages de programmation. Associé au module d extension ADT il devient un environnement de choix pour le développement. H.323 Ensemble de protocoles pour la vidéoconférence. (voir 2.4.1.2). H323Plus Projet open source ayant pour but une implémentation complète de H.323 en C++. IDE IP Un Integrated Development Environment est un environnement de développement logiciel. Internet Protocol. MCU Multipoint Control Unit (voir 2.4.1.3). 44
Nav6 NLTVC PCM RDP Entreprise spécialisée dans les réseaux informatiques comprennant l équipe NLTVC (voir 2.2). Équipe de développement qui édite la solution Crystalview 9100 sur laquelle le travail de développement de ce stage porte (voir 2.3). Pulse Code Modulation est un format audio numérique non compressé utilisé notamment avec le conteneur WAV. Remote Desktop Protocol est un protocole propriétaire et fermé de prise de contrôle d ordinateurs distants. SDK Un Software Development Kit est un ensemble d outils de développement propre à une plateforme comme par example le kit de développement pour. Skype Logiciel propriétaire permettant de passer des appels téléphoniques via Internet. Il permet aussi à deux utilisateurs du logiciel de communiquer gratuitement avec de l audio de la vidéo ou du texte. socket Les sockets sont des modèles logiciels permettant la communication entre processus. Visual Studio Logiciel permettant de développer des logiciels dans de multiples langages de programmation et particulièrement adapté au développement sur plateforme.net. WAV Contraction de WAVEform audio file format est un format de conteneur audio prenant en charge différents format parmi lesquels le PCM est le plus utilisé. Wi-Fi Ensemble de protocoles de communication sans-fil.. Windows 7 Système d exploitation édité par qui est embarqué sur les solutions de NLTVC. wpa supplicant Logiciel libre implémentant la norme IEEE 802.11i concernant les mécanismes de sécurité du sans-fil. 45
Résumé Ce rapport relate le stage de fin d études de Master Informatique spécialité Systèmes Distribués et Réseaux, effectué par l étudiant Sébastien Seiller de l Université de Franche- Comté, promotion 2011/2012. Le sujet de ce stage a porté sur l amélioration et le développement de nouveaux services pour un logiciel de téléconférence se basant notamment sur l environnement. Mots-clés :, DTMF, téléconférence,. Abstract This report exposes the final internship before IT Master s degree diploma obtention in the distributed systems and networks speciality, done by student Sébastien Seiller from the university of Franche-Comté, year 2011/2012. The subject was on the improvment and the development of new services for a teleconferencing system based on the environment. Key words :, DTMF, teleconference,.