Abdelkader BELKHIR Kaderbelkhir@hotmail.com Lies KADDOURI lies_kaddouri@hotmail.com LSI-Département Informatique, Faculté Génie Electronique & Informatique, USTHB El Alia BP n 32, Bab Ezzouar, Alger, Algérie. Résumé : L étude d une plate forme dotée d un support de communication sans fil (ipaq+ Windows CE) ainsi que les protocoles de communications TCP/IP, SIP, SDP, RTP, RTCP a permis de mettre en œuvre une solution IP pour le transport de la voix de bout en bout. L expérimentation a révélée des résultats satisfaisants pour la qualité de la voix ainsi que les performances de distance. Cette solution a été enrichie par un système de messagerie courte ainsi que le transfert de fichiers. Mots clés : PDA ; ipaq, SIP, SDP, RTP, RTCP, voix, codage audio. 1. INTRODUCTION L'évolution des technologies réseaux ainsi que l'accroissement de leurs performances ont fait que l'internet est devenu une infrastructure viable pour supporter les services multimédias. Ces derniers concernent tous les aspects de la vie moderne : la communication personne-à-personne, la vidéoconférence, les présentations de documents multimédias synchronisés, l'enseignement et la formation à distance, etc. Pendant la même période, les services de téléphonie mobile ont intégré de plus en plus de services Internet comme la messagerie électronique ou encore l'accès au Web. Cette convergence ainsi que le faible coût des communications sur IP ont donné naissance à une nouvelle génération de téléphones mobiles, appelée UMTS (Universal Mobile Telecommunications System), est dotée d'une bande passante élevée : 2 Mb/s. Contrairement aux téléphones traditionnels, basés sur la commutation de circuit, leur fonctionnement est entièrement basé sur IP (Internet Protocol). L'un des services les plus fondamentaux en téléphonie est la signalisation des appels [1][2] (localisation, appel et redirection d'un correspondant). Il s agit d offrir les services de signalisation d appels et de messagerie pour des terminaux mobiles. La section 2 décrira l intégration des PDA dans une infrastructure IP. La section 3 présentera l architecture proposée pour la prise en charge de la communication et son fonctionnement. La section 4 définit les composants logiciels de la fonction téléphone. On terminera par une mise en œuvre expérimentale de la solution. 2. L INTEGRATION DES PDA DANS UNE INFRASTRUCTURE IP La communication nécessite en premier un mécanisme de signalisation ; celui-ci concerne l ensemble des informations échangées par des terminaux, les passerelles et tous les éléments assurant l établissement, le contrôle et la rupture d une session. Le protocole SIP [1][2] permet de satisfaire ce besoin : il est modulaire avec un codage textuel de ses messages, et n exige pas un protocole de transport spécifique. Par conséquent, il est extensible sans contrainte d usage. De plus la description de la session est nécessaire pour pouvoir y participer ; à cet effet le protocole SDP [3] est conçu pour être utilisé par d autres protocoles comme il convient, tel que Session Annoucement Protocol, Session Initiation Protocol, le Real Time Streaming Protocol [4]. En général SDP doit transporter l information suffisante pour permettre l accès à une session et annoncer les ressources pour être utilisées par les non participants qui peuvent avoir besoin de les connaître. Une fois la session établie, il s agit d analyser et d exploiter le contenu de la communication. De plus en plus ce contenu comporte des informations multimédia afin d assurer une meilleure convivialité.
L objectif de notre travail consiste à offrir les services de signalisation d appels, pour des agents mobiles équipés d ordinateurs de poches, reliés dans une infrastructure sans fils. Cette phase concerne la mise en œuvre de toutes les fonctionnalités du protocole SIP, c est à dire permettre à un agent d inviter un correspondant, d ouvrir et de libérer une session, recevoir des appels, refuser ou rediriger l invitation d un appelant. On utilisera un serveur HTTP, pour héberger les documents messages et les différents fichiers à transférer. Agent Mobile Serveur HTTP Streaming HTTP Session SIP Internet / Intranet Par ailleurs, les applications audio sur une réseau font intervenir deux aspects distincts : -la numérisation et le codage des données audio -la mise en forme (paquetisation) de ces données pour un transfert réseau La compression est un processus qui vise à réduire le flux numérique. 3. ARCHITECTURE DE LA SOLUTION Cette architecture est entièrement basée sur le model client \serveur. Elle est constituée de deux entités : l appelant (le client) et l appelé (le serveur). USER AGENT CLIENT USER AGENT SERVEUR input output SMS SMS output input SOCKET SOCKET Messages Messages RESEAU IP 2
LSI-TR- 1402 3.1 User Agent Server (UAS ) Le serveur dispose de deux types de socket, une socket serveur et une autre client. La socket serveur supporte le protocole UDP et écoute une éventuelle connexion avec le même protocole. Quant une requête de connexion client arrive, le serveur crée une socket client pour établir le lien avec ce dernier. La socket serveur reçoit les messages (données) du client, et éventuellement envoie aussi les messages au client. 3.2 User Agent Client (UAC ) L utilisateur utilise l UAC pour communiquer (envoie et réception de messages) avec le serveur après avoir initier une session avec SIP. Une fois la session établie, la communication commence. La capture et l envoi de la voix dans l UAC sont assurés à travers le périphérique audio d entrée (wave input ). Quand le client reçoit l information, elle est décodée et directement jouée par le périphérique audio de sortie (wave output ). 4. EMULATION DE LA TELEPHONIE IP Une communication téléphonique est une application temps réelle qui impose des contraintes au réseau ce qui ne l est pas pour des applications telles que FTP ou Web.Parmi ces contraintes, nous citerons: Délai de transmission (temps de latence) : il faut que le temps de transport des données entre l émetteur et le récepteur soit faible. Un delai de livraison allant jusqu à 300 ms est tolérable. Il devrait être inférieur à 150 ms pour une bonne interactivité. Ce retard est engendré principalement par les routeurs traversés (dépend de la charge du réseau) mais aussi par le traitement des éléments logiciels (lors des compressions, codages ) dans les équipements d extrémité. Bande passante : sans compression, la voix nécessite 64 Kbps de bande passante, avec compression on peut descendre jusqu à 5 Kbps. Dans ce dernier cas la qualité du son est moins bonne et le temps de traitement pour la compression et la décompression au départ et à l arrivée augmente ainsi le temps de latence. La perte de paquets : la voix supporte bien les pertes de paquets par rapport à d autres applications. On considère que le taux de pertes doit être inférieur à 20 % [5][6]. A noter que la retransmission des paquets erronés ou perdus sont inutiles car elle induirait un temps de latence trop important. La gigue : c est une variation du délai de transmission de l information. Elle provient de la variation de la charge du réseau, éventuellement des routes différentes utilisées. L écho : sur le chemin, différents équipements peuvent induire des phénomènes d écho. L intelligibilité: elle est en grande partie déterminée par le choix d'un algorithme de codage de la voix. Il existe divers type d'algorithme de codage comme PCM, ADPCM...[5][6] Afin d émettre la voix dans une infrastructure IP, nous devons réaliser trois phases essentielles qui sont : la capture de la parole, son traitement (codage et compression) et sa transmission dans un réseau sans fil. A la réception, l opération inverse doit être assurée. 4.1- Module d acquisition de la parole Une fois la session établie, la première tâche consiste à capturer la voix par le microphone en cas d activité vocale ; sinon le module de détection de l activité vocale (silence) entre en activité. Le dispositif d'acquisition audio, dont le contrôleur audio (carte son), doit être visité périodiquement pour vérifier s'il contient assez de données pour remplir une trame (qui sera envoyée dans un paquet). La voix capturée est mise dans un buffer pour ensuite être envoyer au module de codage. 4.2- Module de détection de l activité vocale (silence) Cette détection se fait sur la base d un contrôle périodique du buffer audio d entrée. La détection de silence permet bien sûr de n'émettre des données que lorsque la source audio est active. Ceci est intéressant car il a été montré que les conversations téléphoniques comportent environ 30% de silence [6]. Il est à noter que le module de détection de silence contribue à un bon usage de la bande passante. 3
Partie émission de l outils Téléphone IP Détection de silence Acquisition De la parole (Voix ) Buffer émission Codage Transmission des données Réception du feedback RTCP Restitution de la parole (Voix) Décodage Buffer de réception Réception des données Emission du feedback RTCP 4.3- Module de codage Partie réception de l outil Téléphone IP Le module de codage comprime les données numériques selon un schéma de compression afin de réduire le débit émis. Nous avons utilisé,en plus du codage PCM usuel [5][6], une variante de celui-ci à savoir ADPCM et le codage GSM. Les flux de voix sont en pleine évolution, en effet la voix codée PCM cède la place à la voix compressée par divers algorithmes de compression, notamment dans le contexte des mobiles et des nouvelles applications multimédia, comme la vidéoconférence ou la vidéo téléphonie. La diversité des algorithmes de compression et des flux qu ils engendrent poussent dans le sens de la voix paquétisée. 4.4-Module de transmission La transmission d'un flux audio sur le réseau peut se faire en utilisant l'un de deux protocoles de transport disponibles, à savoir TCP ou UDP [7]. Le protocole TCP a comme avantage qu'il chemine des données de façon fiable, c'est à dire sans pertes ni reséquencement. Malheureusement, il obtient cette fiabilité par l'utilisation de mécanismes de retransmission des paquets perdus. Les délais engendrés par ces retransmissions sont incompatibles avec les contraintes temps réel associées aux applications audio. D'autre part, TCP ne permet pas la transmission multipoint (c'est à dire entre plusieurs sources et destinations à la fois). La transmission multipoint est cependant nécessaire pour toutes les applications de type audioconférence. L'autre solution consiste donc à utiliser un protocole de transport minimal et à implémenter dans l'application les fonctionnalités spécifiques à la transmission audio. Le protocole UDP ne fournit pas de fiabilité, mais il permet la transmission multipoint, et il ne comporte pas de mécanisme (comme la retransmission) qui augmente les délais effectifs entre sources et comme protocole de transport. Compte tenu des exigences de la téléphonie, nous avons donc utilisé UDP conjointement avec les protocoles (RTP, RTCP)[7] dans le soucis d assurer la qualité de service. 4.5-Module de réception 4
LSI-TR- 1402 Le module de réception prend les paquets disponibles sur le port réseau et place l'information audio contenue dans ces paquets dans le buffer de réception. 4.6-Module de Décodage Ce module utilise l'un des schémas de décompression (algorithme de décompression) disponibles, pour restituer l'information audio. 4.7-Module de restitution Audio Le module de restitution envoie les échantillons mixés sur le driver de sortie pour qu'ils soient joués sur un haut parleur ou un casque. 5. EXPERIMENTATION ET TEST L objectif consiste à prendre en charge la voix sous une plate forme embarquée sous Windows CE [8][9] doté d un support de communication sans fil. Il s agit d ajouter la fonction «téléphone» aux ordinateurs (ici PC de poche de type ipaq) connectés à un réseau sans fil de type IP. C est la fonction d émulation de téléphone avec portage de la voix sur IP d'un pocket PC à un autre. Le pocket PC est équipé d'un micro, d'un haut-parleur, d'une carte son (full-duplex). L application va se réaliser en trois phases essentielles qui vont de la capture de la parole, son traitement (codage +compression avec un algorithme approprié), ensuite sa transmission dans un réseau IP sans fil. Elle numérise, compresse et encapsule les échantillons de voix dans les paquets IP avant de les envoyer sur le réseau. L adresse du destinataire est l adresse IP du poste de destination. Pour une communication téléphonique, on active deux processus l un pour le client et l autre pour le serveur. Ce dernier se met à l écoute sur un port de communication approprié pour une éventuelle connexion. Le client doit désigner l adresse IP du serveur désiré pour la communication. Processus Serveur. Processus Client. 5
6. CONCLUSION La solution que nous avons proposée au transport de la voix sur IP nous a permis d avoir une qualité de la voix quasi téléphonique dans un réseau sans fil (ad hoc) composé de deux terminaux mobiles. Nous avons remarqué une certaine dégradation de la voix quand le rayon de communication dépasse les 300m. Nous avons testé notre application avec des formats de compression disponible sur le SDK ; en utilisant le codage PCM à 44,1 ; 22,05 et 11,025 KHz de débit de compression. A côté de la transmission de la voix, nous avons aussi proposé la Messagerie (SMS) et le Transfert de fichiers dans le même rayon de communication précité. La signalisation offre les services fondamentaux pour les communications multimédias et constitue une première étape pour leur implémentation Ces extensions concernent aussi l'ouverture de ce système pour supporter d'autres formats multimédias. La généralisation de services à temps réel favorisera l usage des UMTS dans un environnement mobile. Références : [1] M. Handley, H. Schulzrinne, E. Schooler et J. Rosenberg, SIP: Session Initiation Protocol, Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [2] E. Wedlund et H. Schulzrinne, Mobility support using SIP, Deuxième Conférence Internationale de ACM/IEEE sur le Multimédia Sans fil et Mobile (WoWMoM'99), Août 1999, Seattle, Washington. [3] M. Handley et V. Jacobson, SDP: Session Description Protocol, Request for Comments 2327, Internet Engineering Task Force, Avr. 1998. [4] Internet Engineering Task Force, en ligne <URL: http://www.ietf.org/>. Juin 2000 [5] A. Véga Garcia, Mécanisme de contrôle pour la transmission de l audio sur Internet Thèse de Doctorat en informatique à l université de Nice Sophia Antipolis,, Octobre 1996. [6] J.F Susbielle, Internet Multimédia et Temps réel, Edition Eyrolles, 2000. [7] G. Pujolle, Les réseaux, Troisième Edition Eyrolles, 2000. [8] J. Murray, Inside Microsoft Windows CE, Microsoft Press, 1998. [9] R. O Hara, Introducing Windows CE for Handheld PC, Edition Microsoft Press, 1998. 6