MESSAGERIE MULTIMEDIA SUR UMTS

TELEPHONIE IP SUR PDA (iPAQ)
Abdelkader BELKHIR
[email protected]
Lies KADDOURI
[email protected]
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é.
TELEPHONIE IP SUR PDA (iPAQ)
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
Wave
input
device
Wave
output
device
USER AGENT SERVEUR
SMS
SMS
SOCKET
Wave
output
device
SOCKET
Messages
Messages
RESEAU IP
2
Wave
input
device
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 device). 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
device).
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
TELEPHONIE IP SUR PDA (iPAQ)
Partie émission de l’outils
Téléphone IP
Détection de
silence
Acquisition
De la parole
(Voix )
Restitution
de la parole
(Voix)
Codage
Buffer
émission
Transmission
des données
Réception du
feedback RTCP
Buffer de
réception
Décodage
Réception des
données
Emission du
feedback RTCP
Partie réception de l’outil
Téléphone IP
4.3- Module de codage
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
TELEPHONIE IP SUR PDA (iPAQ)
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