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