COLE DE TECHNOLOGIE SUPRIEURE UNIVERSIT DU QUBEC
MMOIRE PRSENT LCOLE DE TECHNOLOGIE SUPRIEURE
COMME EXIGENCE PARTIELLE LOBTENTION DE LA MATRISE EN GNIE
CONCENTRATION RSEAUX DE TLCOMMUNICATION M.Ing.
PAR Mohamed Taib BENISSE
TRANSMISSION MDIA SUR LES RSEAUX IP EN UTILISANT LES PROTOCOLES SIP ET IAX
MONTRAL, LE 14 SEPTEMBRE 2009
Mohamed Taib Benisse, 2009
PRSENTATION DU JURY
CE RAPPORT DE MMOIRE A T VALU
PAR UN JURY COMPOS DE Stphane Coulombe, directeur de mmoire Dpartement de gnie logiciel et des TI lcole de technologie suprieure Michel Kadoch, prsident du jury Dpartement gnie lectrique lcole de technologie suprieure Nadjia Kara, membre du jury Dpartement de gnie logiciel et des TI lcole de technologie suprieure
IL A FAIT LOBJET DUNE SOUTENANCE DEVANT JURY ET PUBLIC
LE 19 AOT 2009
LCOLE DE TECHNOLOGIE SUPRIEURE
REMERCIEMENTS
La russite de la personne ne peut saccomplir sans le soutien et la contribution des autres.
Je remercie le directeur de recherche le professeur Stphane Coulombe pour son aide et ses
conseils pendant le droulement du projet.
Je voudrais aussi remercier tous les collgues de laboratoire SynchroMedia et MultiMedia
pour les conversations et les suggestions qui mont aid accomplir ce travail.
Je remercie galement le professeur Mohamed Cheriet pour les ressources quil a mises
notre disposition pour avoir un environnement exprimental adquat.
TRANSMISSION MDIA SUR LES RSEAUX IP EN UTILISANT LES PROTOCOLES SIP ET IAX
Mohamed Taib BENISSE
RSUM
Les progrs technologiques du rseau Internet ont permis le dveloppement de nouvelles applications multimdia; la voix, la vido et la vidoconfrence sont devenues des domaines importants de recherche et de dveloppement pour lindustrie des tlcommunications. Ces dernires annes ont t remarquables par la mise en uvre de connexion haute dbit, et de terminaux mobile et fixe performants. Plusieurs standards ont t conus spcifiquement pour permettre la transmission mdia sur les rseaux IP avec une meilleure qualit de service. Ce travail a pour but dtudier les protocoles de transmission mdia sur les rseaux IP, en commenant par ltat de lart de technologies principales pour accder au rseau, les techniques utilises pour encoder laudio et la vido, et en finissant par les protocoles de transport combins avec dautres protocoles temps rels. Lobjectif principal du mmoire est danalyser, et intgrer les protocoles de transmission (SIP, RTP et IAX) sur les rseaux IP. Le projet se compose de deux parties : exprimentale et applicative. La premire partie a pour objectif de mettre en place une plateforme IPPBX capable de fournir une solution assez complte de transmission mdia sur le rseau IP en utilisant les protocoles SIP et IAX. Ensuite, nous allons calculer le temps requis de signalisation SIP/IAX et la qualit de service dune communication IAX en utilisant les codecs G.711 et GSM. La deuxime partie se compose de la conception et limplmentation du protocole RTP dans les tlphones mobiles en utilisant la technologie J2ME pour permettre un environnement mobile de vidoconfrence. Nous allons effectuer un rapport technique assez complet dcrivant la technologie mobile J2ME. Nous allons galement tester les mulateurs et outils capables doffrir un environnement de vidoconfrence mobile et les difficults associes aux codecs supports Les rsultats des expriences ont montr que le temps requis de signalisation SIP et IAX est sous un seuil acceptable dans un rseau local. Selon les valeurs obtenues du dlai et de la gigue, la qualit de service de la communication IAX avec les codecs G.711 et GSM est adquate. Le rsultat obtenu de la partie applicative nous a permis de prouver que le client mobile de vidoconfrence est capable de senregistrer auprs dun Proxy/Registrar pour joindre une session multimdia et de signaliser avec dautres clients de la session via le protocole SIP. La conception du protocole RTP dans la technologie mobile adopte le RFC 3250 sur le plan thorique. Larchitecture du systme utilis et les composantes logicielles ont t bien mises en place. La transmission des paquets RTP a t bien ralise. La manipulation des paquets RTP en mode binaire a t bien effectue pour rediriger les flux audio et vido au lecteur JMStudio. Mots cls: SIP, SDP, RTP ET IAX.
MEDIA TRASMISSION OVER IP USING SIP AND IAX PROTOCOLS
BENISSE, Taib-Mohamed
ABSTRACT
Internet technology progress has enabled new multimedia applications: voice, video, videoconferencing. All applications become important areas of research and development for the telecommunication industry. Over the last few years, the worldwide telecommunication operators have started to deploy high speed bandwidth, manufacturers have increased the performance of their terminal products, and many standards have been designed specifically to enable media transmission over IP with a better quality of service. This work studies media transmission over IP. We start by an overview of the main technologies to access Internet networks and encoding voice and video. Then we present the protocols used to transport media in real time. The works main goals are to analyze, and integrate transmission protocols (SIP, RTP and IAX). This project is composed of two parts: experimental and implementation. In the first part, we present IPPBX platform able to give a complete solution to transmit media over IP networks using SIP and IAX. Then we calculate registering and signaling delays through experiments. The performance of IAX calls is also examined. In the second part, we conduct a complete technical report about Java 2 Mobile Edition technology. Then we integrate RTP protocol on mobile devices using (J2ME) to allow mobile videoconferencing. The results show that SIP/IAX signaling delays are under acceptable threshold in local area network. According to values obtained from quality of service, the quality of IAX call is adequate. The J2ME technology allows mobile phones to connect to a SIP server to make them reachable by other users in a session. SIP uses the Session Description Protocol (SDP) to define some media characteristics. J2ME does not support RTP protocol to receive media. Therefore we present architecture and implement the RTP protocol. RTP packets transmission is accomplished. The RTP packets handling are performed using binary way to redirect the audio and video streams to JMStudio player. Keywords: SIP, SDP, RTP and IAX.
TABLE DES MATIRES
Page
INTRODUCTION .....................................................................................................................1
CHAPITRE 1 LES CARACTRISTIQUES DE TRANSMISSION MDIA SUR LE RSEAU INTERNET .....................................................................................7
1.1 Rseau Internet ...............................................................................................................7 1.1.1 Lhtrognit du rseau Internet .................................................................. 7 1.1.2 Les conditions variables du rseau Internet .................................................... 8
1.2 Qualit de service ...........................................................................................................8 1.3 Transport du mdia TCP ou UDP et pour quel motif ....................................................9 1.4 Le protocole temps rel RTP .......................................................................................10
1.4.1 Format dun paquet RTP ............................................................................... 11 1.4.2 Architecture dintgration du module RTP ................................................... 12
1.5 Les codecs audio les plus utiliss en transmission mdia ............................................14 1.6 Codecs vido ................................................................................................................15 1.7 Conclusion ...................................................................................................................16
CHAPITRE 2 SIP, LE PROTOCOLE DE SIGNALISATION MULTIMDIA ..................17 2.1 Lobjectif de dveloppement du protocole SIP ...........................................................17 2.2 tablissement dune session ........................................................................................18
2.2.1 Architecture SIP ............................................................................................ 18 2.2.2 Mthodes ....................................................................................................... 19 2.2.3 Rponses de requtes .................................................................................... 20 2.2.4 Format de messages ...................................................................................... 20 2.2.5 Lenregistrement du client SIP ..................................................................... 21 2.2.6 Les messages de la signalisation ................................................................... 22
2.3 Conclusion ...................................................................................................................23
CHAPITRE 3 IAX, LE PROTOCOLE DE TRANSMISSION MDIA SUR LA PLATEFORME IPPBX .................................................................................24
3.1 Lobjectif de conception ..............................................................................................24 3.2 Appel basique IAX ......................................................................................................25
3.2.1 La squence de messages denregistrement .................................................. 25 3.2.2 La signalisation de terminaux IAX ............................................................... 27 3.2.3 Mini-Frame ................................................................................................... 29
3.3 Conclusion ...................................................................................................................30
CHAPITRE 4 ENVIRONNEMENT EXPRIMENTAL ET RECHERCHES ANTRIEURES ............................................................................................31
4.1 Les exigences de lenvironnement exprimental .........................................................31 4.2 Les lments de larchitecture tests et les alternatives ...............................................32
VII
4.3 Contexte de lenvironnement exprimental et .............................................................34 4.4 Description de la plateforme IPPBX et les recherches associes ................................36 4.5 Installation de lIPPBX Asterisk ..................................................................................39
4.5.1 Matriels utiliss ........................................................................................... 39 4.5.2 Script du dploiement ................................................................................... 40 4.5.3 Cration dextensions SIP ............................................................................. 40 4.5.4 Cration dextensions IAX ........................................................................... 41 4.5.5 Groupes et manipulations des appels ............................................................ 41
4.6 Interconnexion au rseau PSTN ...................................................................................42 4.7 Interconnexion au rseau GSM ....................................................................................43 4.8 Interconnexion de deux systmes IPPBX ....................................................................44 4.9 Conclusion ...................................................................................................................46
CHAPITRE 5 SIMULATION : SIGNALISATION (SIP/IAX) ET LA QUALIT DE LA COMMUNICATION IAX .............................................................................47
5.1 Description de la simulation calcul de signalisation SIP/IAX .....................................47 5.2 La performance dun canal IAX avec le codec G.711 .................................................49
5.2.1 La mthodologie applique pour calculer la bande passante ........................ 50 5.2.2 La mthodologie applique pour calculer le dlai inter arrive .................... 51 5.2.3 La mthodologie applique pour calculer la gigue. ...................................... 52
5.3 La performance du canal IAX avec le codec GSM .....................................................53 5.3.1 La bande passante GSM ................................................................................ 54 5.3.2 Le dlai inter-arrive GSM ........................................................................... 55 5.3.3 La gigue GSM ............................................................................................... 55
5.4 Les vnements IAX ....................................................................................................56 5.5 Conclusion ...................................................................................................................57
CHAPITRE 6 IMPLMENTATION DU PROTOCOLE RTP DANS UN CLIENT MOBILE DE VIDOCONFRENCE ..........................................................59
6.1 Dveloppement dun client de vidoconfrence mobile ..............................................59 6.1.1 La technologie utilise J2ME........................................................................ 61 6.1.2 La solution propose ..................................................................................... 62 6.1.3 JSR SIP ......................................................................................................... 62 6.1.4 JSR 135 Mobile MultiMedia ........................................................................ 64
6.2 Les paquets RTP ..........................................................................................................66 6.3 Les caractristiques supportes du client vidoconfrence mobile .............................68 6.4 Rsultats de limplmentation : vidoconfrence mobile ............................................74 6.5 Discussion de la partie applicative ...............................................................................77 6.6 Conclusion ...................................................................................................................78
CONCLUSION ........................................................................................................................79
RECOMMANDATIONS ........................................................................................................81
ANNEXE I SCRIPT DE COMPILATION LA PLATEFORME IPPBX ..............................82
VIII
ANNEXE II CONFIGURATION DES EXTENSIONS SIP..................................................84
ANNEXE III CONFIGURATION DES EXTENSIONS IAX ...............................................85
ANNEXE IV CONFIGURATION DU PLAN DE NUMROTATION ...............................86
ANNEXE V MODULE DU CALCUL BANDE PASSANTE IAX ......................................87
ANNEXE VI MODULE DU CALCUL DLAI IAX ............................................................90
ANNEXE VII MODULE DU CALCUL GIGUE ..................................................................92
ANNEXE VIII LENREGISTREMENT DU CLIENT MOBILE SIP ...................................94
ANNEXE IX LA SIGNALISATION DU CLIENT MOBILE SIP ......................................100
ANNEXE X LIMPLMENTATION DU PROTOCOLE RTP ..........................................117
LISTE DE RFRENCES BIBLIOGRAPHIQUES.............................................................120
LISTE DES TABLEAUX
Page
Tableau 1.1 Le type de contenu pour l'encodage audio .................................................14
Tableau 1.2 Les codecs d'encodage vido .....................................................................16
Tableau 4.1 La qualit de lappel en utilisant MOS (Mean Opinion Score) .................37
Tableau 5.1 Les statistiques d'enregistrement et de signalisation SIP/IAX ...................48
Tableau 5.2 Les vnements IAX ..................................................................................57
Tableau 5.3 La rcapitulation de communication avec les codecs G.711 et GSM ........58
LISTE DES FIGURES
Page
Figure 1.1 Le format dun paquet RTP. ......................................................................11
Figure 1.2 L'entte dun paquet RTP. .........................................................................12
Figure 1.3 La composition dun paquet RTP. .............................................................13
Figure 2.1 L'architecture du protocole SIP. .................................................................18
Figure 2.2 Les squences denregistrement (le dlai Setup). ......................................22
Figure 2.3 Le diagramme de signalisation SIP (le dlai Setup). .................................22
Figure 3.1 Les requtes denregistrement IAX. ..........................................................26
Figure 3.2 Les squences d'enregistrement IAX pour calculer le dlai Setup. ...........27
Figure 3.3 Les squences de signalisation IAX. .........................................................28
Figure 4.1 Larchitecture de composants techniques. .................................................34
Figure 5.1 La bande passante estime dans les deux sens. ..........................................51
Figure 5.2 Le dlai inter arrive G.711 (ms). ..............................................................52
Figure 5.3 La gigue en ms. ..........................................................................................53
Figure 5.4 La bande passante du canal IAX avec le codec GSM. ..............................54
Figure 5.5 Le dlai inter arrive d'une communication IAX avec le codec GSM
(ms). ...........................................................................................................55
Figure 5.6 La gigue d'une communication IAX avec le codec GSM (ms). ................55
Figure 5.7 Les messages envoys au cours d'une communication IAX. .....................56
Figure 6.1 Les transactions de requtes : mobile, proxy et soft phone. ......................63
Figure 6.2 Les composants multimdias supports par l'mulateur mobile. ...............65
Figure 6.3 L'enregistrement de l'mulateur mobile auprs du Proxy/Registrar. ........69
Figure 6.4 L'enregistrement de l'mulateur mobile auprs du proxy SIP (J2ME). .....70
XI
Figure 6.5 Le contenu du protocole SDP. ...................................................................71
Figure 6.6 L'tablissement de la communication vidoconfrence. ............................72
Figure 6.7 Le flux audio. .............................................................................................73
Figure 6.8 Les statistiques du protocole RTP..............................................................74
Figure 6.9 Le flux vido. .............................................................................................74
Figure 6.10 La manipulation du flux audio et vido en mode binaire. .........................75
Figure 6.11 La lecture du flux audio. ............................................................................75
Figure 6.12 La lecture du flux vido. ............................................................................76
Figure 6.13 La capacit de la mmoire utilise pendant la session vidoconfrence. ..77
LISTE DES ABRVIATIONS, SIGLES ET ACRONYMES ACK Acknowledge ADSLAsymmetric Digital Subscriber Line ATM Asynchronous Transfer Mode CIF Common Intermediary Format DCT Discrete Cosine Transform DNS Domain Name System DS Digital Signal FCS Frame Check Sequence FTP File Transfer Protocol HFCHybrid Fiber Coaxial HTTP Hyper Text Transfer Protocol IAX Inter Asterisk Exchange IEEE Institute for Electrical and Electronic Engineer IETF Internet Engineering Task Force IMSIP Multimedia Subsystem IP Internet Protocol ISDNIntegrated Services Digital Network LAN Local Area Network MAC Media Access Control MBZ Must Be Zero MD5 Message Digest MGCP Media Gateway Control Protocol
XIII
NTP Network Time Protocol OUIOrganizationally Unique Identifier PCM Pulse Code Modulation PSTN Public Switched Telephone Networks QCIF Quarter Common Intermediary Format RFCRequest For Comment RGB Red Green Blue RSA Rivest Shamir Adleman RSVP Resource Reservation Protocol RTCP Real Time Control Protocol RTP Real Time Protocol SAP Session Announce Protocol SDPSession Description Protocol SIP Session Initiation Protocol SMTP Simple Mail Transfer Protocol SQCIF Sub-Quarter Common Intermediary Format SSRCSynchronization Source TCP Transmission Control Protocol TOS Type Of Service UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol
XIV
UIT Union International Telecommunication WFQ Weighted Fair Queuing
INTRODUCTION
Les progrs technologiques du rseau Internet ont permis linnovation de nouveaux services
sur les rseaux IP. Les applications voix sur IP, vido et vidoconfrence sont devenues des
domaines importants de recherche et de dveloppement pour lindustrie des
tlcommunications. La demande pour les technologies de communication audiovisuelle
augmentera encore dans les prochaines annes [31]. Les oprateurs de tlcommunication
dploient de nouveaux services afin de rentabiliser les infrastructures mises en place (ADSL,
UMTS et IMS). Les constructeurs de terminaux mobiles et fixes laborent de nouveaux
systmes pour permettre une communication audiovisuelle universelle. De nouveaux
standards sont en cours pour unifier la transmission multimdia sur les rseaux IP sans se
soucier de larchitecture matrielle ou logicielle du support de transmission. Les grands
acteurs de lindustrie multimdia souhaitent vendre leur contenu en ligne sous forme de
bibliothque multimdia numrique [31].
Les applications de communication audiovisuelle peuvent apporter une valeur ajoute aux
entreprises en particulier et lhumanit en gnral. La communication multimdia peut
rduire le cot et le temps de dplacement des employs appartenant une entreprise
multinationale. Les ambulanciers peuvent recevoir des indications durgences par la
vidoconfrence pour traiter un patient. Les zones isoles gographiquement peuvent
galement communiquer visuellement avec un centre hospitalier pour recevoir les services
mdicaux ncessaires. Enfin, la communication visuelle permet aux familles loignes de
garder un contact visuel et rel malgr la distance qui les spare. Tous les lments
mentionns prcdemment ont motiv et encourag le dveloppement des applications
multimdia avec lutilisation du standard de communication.
Les protocoles de signalisation SIP et IAX peuvent tre excuts sur un client, un terminal
mobile ou un serveur. Les requtes denregistrement et de signalisation peuvent prsenter des
dlais significatifs sur les liaisons bas dbit, surtout si le client doit retransmettre ces
requtes plusieurs reprises. Les dlais peuvent avoir un impact important au cours dune
2
session multimdia. La transmission du flux de voix ou vido en temps rel peut tre retarde
et affecte menant une qualit de service qui nest plus adquate.
Ces dernires annes ont t remarquables par la mise en uvre de terminaux mobiles,
lutilisation de ces appareils est quotidienne, surtout plusieurs standards et systmes
dencodage et de traitement multimdia ont t conus spcifiquement pour les terminaux
mobiles. Toutefois, on constate que la gnralisation du transport voix et vido est loin
dtre fixe et continue d'voluer.
Le protocole SIP utilise des ports spars pour transmettre les donnes de signalisation et les
donnes mdia. Ce concept pose un problme sur les rseaux quips NAT (Network
Address Translation). Le client SIP choisit un port dynamique pour recevoir le flux mdia.
Ce port nest pas reconnu sur le routeur, car le client SIP est associ au port tabli pendant la
connexion.
Pour rsoudre ce problme, le rcent protocole IAX utilise un port unique pour la
signalisation et le transport des donnes mdia. Le protocole de signalisation et de transport
mdia IAX, qui se trouve actuellement sous forme draft [34], est en voie de normalisation et
offre dautres nouvelles fonctionnalits intressantes. Il permet par exemple de transporter les
donnes mdia dans un format binaire compact offrant un dbit optimis. Les diffrentes
structures de trames IAX permettront doptimiser le transfert des requtes de signalisation,
les donnes brutes mdias, et la combinaison de diffrents flux sur le mme lien [34].
Il existe dautres diffrences notables entre SIP et IAX. Lorsque la signalisation est effectue
via le protocole SIP, le transport mdia ncessite 12 octets pour len-tte du protocole RTP
alors que la signalisation IAX ncessitera 4 octets den-tte pour transmettre les donnes voix
ou vido.
3
Le protocole IAX tant rcent, il nexiste aucune tude qui traite de ses performances avec le
codec G.711 support sur le rseau tlphonique traditionnel et le codec GSM utilis sur le
rseau cellulaire.
Ce constat nous tonne et nous pousse analyser les deux protocoles sur le plan thorique
exprimental. Nous constatons aussi quil nexiste mme pas de plateforme exprimentale
permettant de mener une telle tude. En effet, il nexiste pas darchitecture exprimentale
globale capable de commuter les canaux SIP et IAX tout en offrant la possibilit dadhrer
diffrents types de clients (client SIP, client IAX et terminal mobile). Une plateforme
exprimentale devra donc tre conue et ralise. De plus, il nest pas clair quels outils seront
adquat afin dtre inclus dans cette plateforme pour mesurer le temps requis
denregistrement de signalisation SIP/IAX et aussi les performances de canaux IAX.
Finalement, nous avons constat que le protocole RTP ntait pas disponible sur les
mulateurs de terminaux mobiles. Cette composante est cruciale la plateforme
exprimentale pour permettre le transport de flux audiovisuels dans un environnement de
vidoconfrence mobile.
Cette recherche permettra de tester et analyser le protocole IAX pour mieux comprendre et
valider les avantages du protocole IAX par rapport SIP au niveau conceptuel ainsi que les
gains possibles au niveau de la bande passante. Lutilit de ce travail est de dcouvrir et
valider les avantages au plan thorique et exprimental du nouveau protocole IAX que lon
entend souvent dans le jargon VoIP (Voice Over Internet Protocol).
Lintrt dimplmenter le protocole RTP dans lmulateur de terminaux mobiles selon RFC
3550 est de pouvoir tester les services de rseaux de nouvelle gnration. Nous croyons
galement que larchitecture exprimentale pourra unifier diffrentes technologies.
4
1. Description du contexte et objectif du travail
Les protocoles de transmission mdia sont nombreux du point de vue du modle OSI. Dans
ce mmoire, le travail consiste tudier et intgrer les protocoles de transmission mdia au
niveau de la couche applicative et plus spcifiquement le protocole SIP, RTP et IAX.
La transmission mdia exige la signalisation pour permettre ltablissement dune session de
communication audiovisuelle, par lintermdiaire dun protocole comme Session Initiation
Protocole (SIP), qui ngocie les paramtres de connexion, prsence et disponibilit. Ce
dernier fait appel un autre protocole Session Description Protocol (SDP) pour ngocier les
paramtres de mdias audiovisuels, lorsque les paramtres de signalisation, connexion, et
mdia sont dtermins, la partie communicante fait appel au protocole de transfert mdia en
temps rel Real Time Protocol (RTP) pour acheminer laudio ou la vido au destinataire.
Le protocole IAX effectue la signalisation et la transmission mdia par lintermdiaire de
diffrentes structures du protocole. Ce projet propose une architecture exprimentale pour
tester et analyser les performances de SIP et IAX. Ce travail se charge de calculer le dlai
requis pour lenregistrement et la signalisation (SIP et IAX), effectuer un test de performance
des communications audio transportes via le protocole IAX, et intgrer le protocole de
transmission mdia en temps rel (RTP) dans les terminaux mobiles.
2. Contributions du mmoire
Ce mmoire apporte quatre contributions majeures :
1. Une architecture exprimentale de test capable de commuter les canaux SIP et IAX et
fournir les outils appropris pour calculer le dlai signalisation et la performance. Nous
croyons que cette conception architecturale est innovatrice au terme des moyens offerts
pour tester diffrents aspects de transmission mdia (rseau, interconnexion avec le rseau
PSTN, interconnexion avec le rseau GSM, la scurit rseau, et lencodage mdias)
5
2. Linstallation de la plateforme IPPBX pour calculer le temps requis pour la signalisation
en utilisant la mme procdure discute dans [2] et [3].
3. Le test de performances de communication audio via le protocole IAX.
4. Lanalyse du protocole RTP est effectue pour implmenter RTP dans les mulateurs de
terminaux mobiles, et pour permettre la simulation dun client de vidoconfrence mobile
via les protocoles SIP, SDP et RTP. Ensuite nous allons tester les performances associes
(la bande passante, la gigue et la taille de mmoire). Limplmentation du protocole RTP
dans les terminaux mobiles se fait via la technologie J2ME et la plateforme IPPBX. Cela
reprsente une nouvelle approche dimplmentation du protocole de transmission mdia en
temps rel dans les terminaux mobiles, base sur le travail de [8] mais utilise une nouvelle
conception dintgration de paquets RTP dans les datagrammes User Datagram Protocol
(UDP).
3. Structure du mmoire
Le mmoire se compose de six chapitres. La transmission de mdias audiovisuels est tudie
en dtail dans chaque couche en commenant par la capture du mdia, en passant par les
diffrentes oprations dencodage, construction de paquets, transmission et larrive au
destinataire.
Le chapitre 1 dcrit lhtrognit du rseau Internet meilleur-effort et son impact sur la
qualit de service des applications multimdia. Ensuite le chapitre se focalise sur le
transport et la transmission des mdias. Les protocoles de transmission Transmission
Control Protocol (TCP) et User Datagram Protocol (UDP) sont requis pour nimporte quel
transfert. On aborde les applications ncessitant TCP ainsi que celles ncessitant UDP en
prsentant les motifs. Enfin, on prsente les protocoles RTP et RTSP qui ont t conus
pour compenser la gigue et le changement dordre des paquets mdia.
6
Le chapitre 2 prsente une revue du protocole SIP en dcrivant lobjectif de cration du
protocole. Pour notre simulation, on tudie un appel basique en analysant les requtes
rponses.
Le chapitre 3 dcrit lobjectif de conception du protocole IAX. On utilise un appel basique
pour expliquer en dtail les techniques utilises pour signaliser deux parties communicantes
puis transfrer les donnes mdia.
Le chapitre 4 propose une architecture gnrale denvironnement exprimental ainsi quune
analyse des travaux de recherches effectus par dautres chercheurs dans le domaine.
Le chapitre 5 dcrit la simulation du calcul de la signalisation SIP/IAX et la qualit dune
communication IAX en utilisant les codecs G.711 et GSM. Les rsultats obtenus de la
performance IAX sont rcapituls la fin du chapitre.
Le chapitre 6 dcrit la technologie Java 2 Micro Edition (J2ME), utilise comme moyen
dimplmentation du protocole RTP pour permettre un environnement vidoconfrence
mobile. La manipulation des paquets RTP sous forme binaire est tudie par loutil rtptools
[47] et les flux audio et vido sont redirigs vers un lecteur multimdia.
Ce mmoire se termine par une conclusion qui rsume les rsultats du projet et les travaux
futurs recommands.
CHAPITRE 1
LES CARACTRISTIQUES DE TRANSMISSION MDIA SUR LE RSEAU INTERNET
Dans ce chapitre, la premire partie fournit un aperu sur le rseau Internet et ses
caractristiques : lhtrognit et la qualit de service. La deuxime partie se focalise sur le
transport et la transmission des mdias. Les protocoles TCP ou UDP y sont requis pour
nimporte quel transfert. On montre que certaines applications ncessitent TCP alors que
dautres ncessitent UDP et les motifs. On prsente galement le protocole RTP conu pour
la transmission en temps rel. Enfin, larchitecture de limplmentation du protocole RTP est
illustre.
1.1 Rseau Internet
Internet est le plus grand rseau mondial. Il connecte des millions dutilisateurs travers le
monde. Les paquets sont routs de la source la destination travers plusieurs sous-rseaux
connects sur un support physique de diffrentes capacits.
1.1.1 Lhtrognit du rseau Internet
Lhtrognit dInternet est due en partie la diversit architecturale et topologique
physique et logique. Les quipements dinterconnexion de diffrents constructeurs, utiliss
travers tout le rseau mondial Internet affectent dune faon significative lhomognit du
matriel. De plus, le lien reliant lutilisateur final et le fournisseur daccs a une part
dhtrognit, car les liaisons daccs ont une capacit diffrente (ADSL, cble, bas dbit).
Cest cette partie que Floyd et Paxon [31] ont nomme Last mile problem car elle est trs
congestionne par rapport dautres segments dans le cur du rseau.
La diversit de technologies daccs nest responsable que partiellement de lhtrognit,
la distance et lloignement physique entre les parties communicantes contribue galement
8
lhtrognit que lon reprsente par Round Trip Time (RTT), Phillipa et Sessini [23] ont
dmontr que la variance (RTT) au niveau du trafic Transmission Control Protocol (TCP) est
cause par lloignement gographique des utilisateurs, et la variabilit RTT au niveau de la
connexion est attribue au chemin emprunt pour tablir la connexion, ainsi qu la
congestion du segment utilis sur le rseau.
1.1.2 Les conditions variables du rseau Internet
Le rseau Internet varie selon diffrentes conditions, principalement dues au trafic gnr et
au chemin emprunt au cur du rseau. Les routeurs congestionns ou plutt le tampon
mmoire dbord rsultent en un changement de route. Le changement de route affecte le
RTT, le dbit, et la perte de paquets. Pour maintenir la stabilit dun segment utilis, il faut
prvoir une certaine rservation des ressources ou mettre en place la qualit de service.
1.2 Qualit de service
Le protocole IP a t conu pour transporter les fichiers de donnes et non la voix ou la
vido. La seule qualit de service pense lpoque est de ne pas perdre ou corrompre les
fichiers de donnes. Par la suite, les progrs technologiques ont permis de transporter la voix
et la vido en temps rel et il est devenu fondamental de savoir contrler la qualit de service
dans un rseau IP [15]. Les paramtres indispensables qui caractrisent la qualit de service
en mode paquet sont :
La bande passante.
Le dlai de transmission de bout en bout et la variation de ce dlai.
Le taux de perte de paquets et le taux dordonnancement de paquets.
Le fournisseur de service doit galement sassurer que la bande passante est rpartie
quitablement entre les utilisateurs du rseau. Parekh et Gallager [15] ont dvelopp une
9
approche base sur les algorithmes de gestion de file dattente pour assurer un partage
quitable de la capacit connue sous le nom Weighted Fair Queuing (WFQ).
La gigue est un lment dterminant pour les applications temps rel. La variation du temps
darrive des paquets ncessite un stockage dans un tampon mmoire. Plus linformation
arrive de manire non rgulire, plus la taille de tampon doit tre grande. Par consquent, un
dlai supplmentaire est introduit dans le flux dinformation de bout en bout.
En gnral, la perte de paquets est relie la bande passante disponible. Un point de
congestion produit un dbordement de mmoire tampon du routeur qui provoque un rejet et
une perte de paquets.
Lordonnancement de paquets est influenc par lutilisation de diffrents chemins pour
arriver la mme destination et les algorithmes de gestion de file dattente lorsque plusieurs
interfaces sont disponibles pour une mme destination. Lordonnancement de paquets nest
pas un problme en soi, mais il cause le problme de la gigue.
Les paramtres indispensables de la qualit de service (la bande passante, le dlai et la gigue)
vont tre tests et calculs pour fournir une ide sur la souplesse et la robustesse de
protocoles oprants pour la transmission mdia.
1.3 Transport du mdia TCP ou UDP et pour quel motif
La couche transport utilise lun des protocoles (TCP ou UDP) pour fournir des services aux
applications. UDP est un protocole simple. Il fournit le multiplexage et le dmultiplexage
la couche applicative. Autrement dit, il permet la livraison de donnes de la source la
destination sans acquittement. Les applications utilisent UDP typiquement pour le streaming
multimdia et la tlphonie sur internet.
Le protocole TCP est fiable au contraire dUDP. Il est capable de retransmettre les segments
perdus dans le rseau. Les applications utilisent TCP typiquement pour les courriers
lectroniques (SMTP), web (HTTP) et le transfert du fichier (FTP).
10
Le protocole TCP est orient connexion. Il ncessite ltablissement dune connexion entre le
client et le serveur avant la transmission de donnes.
Le protocole TCP implmente deux mcanismes pour contrler le flux transmission [15]:
flow control et congestion control.
Flow control permet la source de limiter le taux doctets envoys afin dempcher la
surcharge du buffer du rcepteur.
Congestion control limite le taux doctets envoys afin dempcher la congestion du rseau et
cela est indiqu par le taux de perte de paquets dans le rseau.
1.4 Le protocole temps rel RTP
Lutilisation du protocole temps rel permet de corriger les problmes dus la gigue et le
changement dordre de paquets introduits par le rseau du transport IP. RTP peut tre utilis
par nimporte quel type de donnes mdia temps rel comme la voix et la vido. RTP dfinit
un format spcifique pour les paquets IP transportant les donnes temps rel.
RTCP (Real Time Control Protocol) est un protocole conjoint du RTP. Il est utilis pour
fournir les informations concernant la qualit relle de la transmission.
Les protocoles RTP et RTCP ninfluencent pas le rseau IP et ils nont aucun contrle sur la
qualit de service. Les paquets RTP et RTCP peuvent tre dtruits ou arriver en dsordre.
RTP et RTCP permettent la destination de corriger la gigue et le dsordre de paquets via
des tampons dinformation et les mcanismes de remise en ordre de paquets. Le protocole
RTP est utilis au-dessus du protocole UDP en utilisant un port pair pour le protocole RTP
et impair pour le protocole RTCP. Cela nest pas obligatoire lorsquon utilise un protocole de
signalisation comme SIP ou H.323.
Lintgration du protocole temps rel RTP dans les applications multimdia ncessite la prise
en connaissances de quelques dfinitions : session RTP, identificateur de source de
synchronisation et format NTP (Network Time Protocol) [23] :
11
Session RTP est un ensemble de participants communiquant au moyen du protocole RTP.
Identificateur de source de synchronisation chaque source dun flux RTP doit disposer dun
identificateur de source de synchronisation SSRC (Synchronization Source) de 32 bits, les
paquets de mme SSRC ont une rfrence temporelle et un numro de squence commun.
Format NTP : le marqueur temporel utilise ce format pour indiquer le temps coul depuis
janvier 1900 00H00, il utilise 32 bits pour la partie entire et 32 bits pour la partie
fractionnaire.
1.4.1 Format dun paquet RTP
RTP utilise UDP pour transporter les donnes mdia. Les paquets perdus ne sont pas
rcuprs, car le protocole UDP est non fiable. Lapplication se charge de grer les paquets
perdus. UDP utilise un numro du port pour cibler la destination associe avec une adresse IP
destinataire (figure 1.1).
Figure 1.1 Le format dun paquet RTP.
La taille initiale dentte du protocole RTP (figure 1.2) est de 12 octets, les champs les plus
importants sont: type de contenu, numro squence, marqueur temporel et identificateur de
source de synchronisation. Les champs identificateur de source contributive (CSRC), profil
et la longueur sont extensifs [19].
RTP DONNES
DONNES UDP
DONNES IP
12
Figure 1.2 L'entte dun paquet RTP.
Le type de contenu est dfini sur 7 bits, il indique le format de linformation transporte dans
les paquets sans les analyser. Cela peut tre dfini par lapplication ou un profil RTP.
Le numro de squence de 16 bits est initialis avec lhorloge des valeurs alatoires puis
incrment pour chaque paquet RTP.
Le marqueur temporel de 32 bits utilise une unit dfinie pour chaque type de contenu.
Identificateur de source de synchronisation (SSRC).
1.4.2 Architecture dintgration du module RTP
Les applications souhaitant mettre et recevoir les donnes mdia, ncessiteront une
composante logicielle RTP. En revanche, plusieurs terminaux disposent de priphrique
multimdia capable de capturer la voix et la vido sans pouvoir la transmettre en temps rel.
Nous proposons une architecture gnrique qui rpond aux besoins dmission et rception
des paquets RTP en temps rel tout en prenant en considration les moyens disponibles pour
chaque type de terminal.
Version Remplissage Extension Type de
contenu
Numro de squence
Marqueur temporel
Identificateur de source de synchronisation (SSRC)
Identificateur de source contributive (CSRC)
Dfini par le profil Longueur
Donnes
13
La composition de paquets RTP ncessite laccs au tampon contenant les donnes mdia
transmettre suivi de la fragmentation de donnes en fonction du dbit de transmission, mais
dans la plupart de cas on utilise un chantillonnage de 20 ms pour la voix.
Les paquets fragments doivent se synchroniser avec lhorloge dchantillonnage, et
incrmenter aprs chaque envoi, cette procdure se traduit rellement par linsertion de
lentte de paquets RTP. (Voir la figure 1.3).
Figure 1.3 La composition dun paquet RTP.
DONNES MULTIMEDIA
0.....10..20..30..40..50..60..70..80..90100(ms)
Donnes transmettre (Voix)
Donnes transmettre (Voix)
En tte RTP (Type de contenu, SSRC, Numro Squence)
En tte UDP
(Port source, Port destination,
Longueur, Checksum)
DONNES
RTP
En tte RTP
(Numro squence+2)
14
1.5 Les codecs audio les plus utiliss en transmission mdia
Les codeurs audio utiliss sont standardiss par (UIT) lUnion International
Tlcommunication.
Le chapitre suivant prsentera plus de dtails sur la faon dencoder et dcoder laudio et la
manire de traiter les signaux numriques. Ici on fournit les donnes importantes de trois
diffrents codecs : G.711, G.726 et G.729.
G.711 quantifie le signal selon deux chelles logarithmiques : la loi A en Europe et la loi aux tats Unis et au Japon. Laudio cod rsulte un dbit donn de 64 kbit/s.
GSM (Global System for Mobile communications) reprsente un codec de parole standard
(utilis travers le monde) pour la tlphonie cellulaire. Le signal de la voix est
chantillonn toutes les 20 ms pour une frquence dchantillonnage de 8000 Hz et un dbit
du codec de 13 kbps.
La liste de codecs mentionns (voir le tableau 1.1) est dfinie dans un profil RTP pour les
confrences audio et vido. Leurs numros sont attribus dans RFC 3551 [29].
Tableau 1.1 Le type de contenu pour l'encodage audio
Type de contenu Codec
0 G.711 loi 8 G.711 loi A
3 GSM
15
1.6 Codecs vido
Les codecs vido utilisent la reprsentation des couleurs et le format dimage pour prsenter
une image. En fait, chaque couleur est un mlange de trois couleurs rouge, bleu et vert
(RGB). Le format dimage choisi par la plupart des codeurs pour les applications de
vidoconfrence est le CIF (Common Intermediary Format). Il dfinit une image de 352 par
288 pixels car il fait rfrence un format dcran habituel. Dautres formats sont utiliss
pour la transmission bas dbit dont le format QCIF (Quarter Common Intermediary
Format) avec une rsolution de 176 par 144 pixels, le format QVGA (Quarter of VGA) avec
une rsolution de 320x240 et le format SQCIF (Sub-Quarter Common Intermediary Format)
avec une rsolution de 128 par 96 pixels. Les applications professionnelles ncessitent une
rsolution plus grande alors les images peuvent tre codes avec le format VGA (640x480),
4 CIF (704 par 756 pixels) et 16 CIF (1408 par 1152 pixels).
Les codecs vido exploitent les redondances spatiales et temporelles des images afin de
diminuer leurs tailles. Les codecs vidos les plus utiliss dans la transmission mdia en temps
rel appartient au standard (UIT) Union International Tlcommunication ou aux normes
MPEG (Motion Picture Expert Group) dISO:
H.263 [15] est une extension de H.261 pour la vido bas dbit. Il peut produire des images
vido une dimension rduite un dbit allant de 20 64 kbps adapts aux terminaux
mobiles.
MPEG-4 peut tre utilis pour une foule dapplication allant du codage bas dbit la
tlvision haute dfinition.
Le codage H.264 [15] ou MPEG-4 AVC commence simposer en streaming vido.
Toutefois, sa complexit dencodage est encore trop grande pour lutiliser dans les
applications de vido-confrences mobiles.
16
Le codec vido H.263 va tre utilis pour tester lintgration du protocole RTP dans les
terminaux mobiles.
Le tableau 1.2 montre que chaque codec vido correspond un type de contenu.
Tableau 1.2 Les codecs d'encodage vido
Type de contenu Codec
34 H.263
31 H.261
1.7 Conclusion
Le rseau Internet se caractrise par lhtrognit, car diffrents types daccs au rseau
sont implments. La diversit matrielle et logicielle affecte la qualit de service des
applications, qui nest pas garantie pendant la transmission.
Larchitecture physique et logicielle du rseau Internet a permis douvrir de nouvelles pistes
de transcodage, denvisager de nouvelles techniques de compression pour allger la charge
du rseau et rendre la communication audiovisuelle possible.
Ce chapitre prsente galement ltat de lart des protocoles de transport TCP et UDP, leur
fonctionnement et leur intgration avec dautres protocoles sur le rseau IP.
Le protocole RTP est conu pour transmettre en temps rel la voix ou la vido encode, il
utilise un profil indiquant le type de contenu et le codec associ. Le protocole RTP permet
galement la compensation de la gigue et mettre en ordre les paquets reus.
Le mdia peut tre compress selon des codeurs audio et vido, les plus utiliss pour la voix
sont G.711 et G.729. Pour la vido en temps rel, H.263 et MPEG-4 sont utiliss.
CHAPITRE 2
SIP, LE PROTOCOLE DE SIGNALISATION MULTIMDIA
Ce chapitre prsente ltat de lart du protocole SIP (Session Initiation Protocol) conu pour
initier et terminer une session multimdia. Dans les sections du chapitre, on prsentera
lobjectif de dveloppement et les rvisions qui sont apportes la version initiale.
Pour notre valuation du dlai signalisation, on tudiera un appel basique en analysant les
requtes rponses. On montrera galement le diagramme de squence pour implmenter le
client mobile vidoconfrence.
2.1 Lobjectif de dveloppement du protocole SIP
Le protocole dinitiation de session a t dfini dans le RFC 2543 [15] par le groupe
Multiparty Multimedia Session Control (MMUSIC) appartenant IETF. Lobjectif principal
est dencadrer les protocoles oprant pendant une communication audio ou vido : le
protocole description de session (SDP), le protocole annonce dune session (SAP) et le
protocole de transmission temps rel (RTP).
Le RFC dorigine a dfini SIP pour grer les sessions multimdias en intgrant la localisation
des utilisateurs via leur adresse IP, la disponibilit des usagers, les capacits mdia
supportes par les terminaux et enfin la gestion de la session (initiation, modification de
paramtres et finalisation dune session) [28].
Le protocole SIP est devenu efficace et rapide pour un tablissement dune session, il
ncessite un aller et deux retours pour ouvrir un canal mdia entre des utilisateurs.
Le protocole SIP est capable de transporter les informations mdias de la session sans
pouvoir les traiter.
18
2.2 tablissement dune session
Le rle principal de lutilisation du protocole SIP est dtablir une session entre les usagers.
Cela ncessite la dtermination de lemplacement des terminaux, la ngociation de
paramtres mdias, la disponibilit de terminaux engags en cours de communication, et
enfin la gestion de communication. Larchitecture du protocole SIP dispose de toutes les
composantes pour rendre la session efficace.
2.2.1 Architecture SIP
Larchitecture du protocole SIP est dfinie dans RFC 3261[28]. Elle utilise les protocoles
Internet Protocol (IP), User Datagram Protocol (UDP) et Transmission Control Protocol
(TCP) pour permettre une communication audio ou vido. Dautres protocoles peuvent
collaborer tels :
RTP (Real Time Protocol) permet la transmission de donnes en temps rel pendant une
session mdia.
SDP (Session Description Protocol) dcrit les paramtres dune session mdia.
SAP (Session Annonce Protocol) annonce les sessions mdia en mode multicast.
RSVP (Ressource Reservation Protocol) rserve les ressources ncessaires.
Figure 2.1 L'architecture du protocole SIP.
UDP TCP
RTP SDP SAP RSVP
SESSION INITIATION PROTOCOL
Internet Protocol
19
Le concept client/serveur est appliqu lors de limplmentation du protocole SIP.
Le client est un composant physique qui peut tre un PC, un tlphone mobile, une passerelle
ou sous forme gnrale un terminal dispose dune pile protocolaire SIP client. Il dispose de
deux composantes logicielles :
UAC (User Agent Client) : envoie les requtes de traitement un serveur SIP et reoit les
rponses appropries.
UAS (User Agent Server) : reoit les requtes dun client SIP et envoie les rponses
correspondantes.
Il existe quatre types de serveurs SIP capables de traiter les requtes des clients SIP :
Registraire : permet un client SIP de senregistrer et tre vu pour une ventuelle
communication. Il permet aussi lauthentification si ncessaire.
Proxy : lorsque ladresse de destination est inconnue, lexpditeur envoie la requte au
proxy auquel est relie pour ragir et transmettre la requte la destination approprie.
Redirect Server : permet de rediriger une requte destine au client plusieurs sorties
lorsque ce dernier est mobile. La requte est redirige au mandataire auquel le client est
reli.
Localisateur : il fournit lemplacement actuel du client. Ce service est utilis par le
mandataire ou le registraire.
2.2.2 Mthodes
Les mthodes suivantes sont utilises pour changer les informations entre les diffrentes
entits (voir RFC 3261 [15]) :
INVITE : cette mthode permet dinviter un utilisateur ou un terminal une session mdia.
ACK : permets de confirmer la rception de la rponse finale dune requte INVITE.
BYE : cette mthode permet de terminer la session mdia.
CANCEL : annulation dune requte invalide.
OPTIONS : mentionner la liste de capacits des serveurs.
20
REGISTER : enregistrer ladresse associe au champ To : dans le serveur SIP auquel
lexpditeur est reli.
2.2.3 Rponses de requtes
Les rponses possibles lorsquon envoie la requte peuvent appartenir six catgories de
codes. Le bon traitement de la requte est indiqu par le code 2xx.
La liste de codes possibles est :
1xx : indique que la requte est reue et en cours de traitement.
2xx : indique que le traitement de la requte a bien t effectu.
3xx : Informations supplmentaires pour traiter la requte.
4xx : indique que le client a envoy une requte avec une erreur de syntaxe.
5xx : indique que le serveur ne peut pas traiter la requte
6xx : indique que la requte ne peut pas tre traite.
2.2.4 Format de messages
Les messages SIP sont bass sur le format texte, ils utilisent lencodage UTF-8 en mode
caractre dfini dans (RFC 2279) [34]. Un message SIP peut tre une requte dun client
attach une session ou une rponse dun serveur. Les messages de requte et rponse
utilisent le format standardis dans le RFC 2822[34]. Les messages SIP consistent en :
Dbut de ligne.
Un ou plusieurs champs den-tte.
Un saut de ligne pour indiquer la fin des champs den-tte.
Le corps message est optionnel.
21
SIP/2.0 200 OK Contact : To : From : Allow : Content-type : Content-Length v= 0 o=-4 2 IN IP4 192.168.1.5 Cette exemple montre un message SIP sous forme une rponse de la requte, les champs
dentte : contact, To, From, Allow, Content-Type et Content-Length. Le corps du message
est v=0 et o=-4 2 IN IP4 192.168.1.5.
2.2.5 Lenregistrement du client SIP
La partie exprimentale du projet inclura mesurer le temps requis pour lenregistrement en
se basant sur les statistiques exprimentales. Le diagramme de squences utilis pour calculer
le temps denregistrement est le suivant (figure 2.2) :
Registrar Client SIP
Register sip : nom-utilisateur@adresse-registrar
Ok 200
Temps
0
22
Figure 2.2 Les squences denregistrement (le dlai Setup). Le client SIP envoie un message Register et reoit un acquittement Ok. Le dlai
denregistrement est la dure entre lenvoi du message Register et la rception du message
Ok.
2.2.6 Les messages de la signalisation
Figure 2.3 Le diagramme de signalisation SIP (le dlai Setup).
La signalisation dun client SIP se compose dun aller et deux retours de requtes (invite,
ringing et ok) (figure 2.3). Le temps mesur pendant la procdure de la signalisation,
commence du moment denvoi de la mthode INVITE et finit la rception du message Ok
du client 2. ce moment, la ngociation de paramtres est effectue entre les deux clients et
on considre que la signalisation est termine.
Time Softphone SIP Proxy Softphone SIP
Ok Ok
Ack
Ringing
Invite Invite
Ringing
0
Temps
signalisation
23
2.3 Conclusion
Dans ce chapitre, nos avons vu le protocole SIP destin la signalisation des usagers dans
une session multimdia. Nous avons montr les diagrammes de squence utilise pendant ce
projet pour mesurer le temps requis denregistrement et de signalisation.
CHAPITRE 3
IAX, LE PROTOCOLE DE TRANSMISSION MDIA SUR LA PLATEFORME IPPBX
Ce chapitre prsente le protocole de transmission mdia IAX, conu pour lutilisation entre
IPPBX. On explique son fonctionnement en dtaillant un exemple dappel basique. Ensuite,
on prsente les lments que nous utiliserons pour calculer le temps requis denregistrement
et de signalisation.
La description du protocole dans ce chapitre est base sur le draft IAX version 5 publie
lectroniquement sur le site : www.ietf.org car le protocole nest pas standardis.
3.1 Lobjectif de conception
Le protocole IAX (Inter-Asterisk Exchange) est conu pour fournir le contrle et la
transmission de donnes mdia sur Internet. IAX a le rle dun protocole contrleur et
transporteur de donnes mdia. Il est destin spcialement pour les appels voix sur IP.
Les objectifs principaux dcrits dans le (draft-iax-05) sont :
Minimiser lutilisation de la bande passante quelle soit pour contrler ou transmettre les
donnes mdia.
Fournir une transparence de translation dadresse rseau (NAT).
Transmettre les informations de numrotation (Dialplan)
Implmenter les caractristiques dInterphone et paging.
IAX est considr comme protocole all in one pour manipuler les donnes multimdias. Il
combine le contrle, la transmission de donnes mdia dans un seul protocole. De plus, IAX
utilise un port unique et statique pour simplifier la traverse et la translation dadresse IP, et
aussi pour viter lutilisation dautres protocoles autour du serveur NAT.
25
Le protocole IAX utilise un entte compact pour minimiser lutilisation de la bande passante.
Sa nature open source permet galement lajout de nouveaux types de contenu pour supporter
des services supplmentaires.
3.2 Appel basique IAX
Le fonctionnement dun appel basique entre deux entits IAX va nous permettre de
comprendre les procdures denregistrement, de signalisation et de transmission mdia.
Lutilisation de la plateforme IPPBX avec deux clients IAX nous aidera calculer le temps
requis pour lenregistrement et la signalisation.
Ensuite, les paramtres de la transmission mdia vont tre tests et calculs pour fournir un
aperu de la qualit de service de communication IAX.
3.2.1 La squence de messages denregistrement
Lenregistrement permet un client IAX de senregistrer et de fournir son adresse IP et ses
informations dauthentification lappel.
Le protocole IAX permet lauthentification via diffrentes mthodes :
MD 5 (Message Digest Authentication) (RFC 1321) [34] utilise la somme darrangement
md5.
RSA (Rivest, Shamin Adleman) est un algorithme qui utilise la cl publique/prive (RFC
3477) [34].
Lenregistrement consiste envoyer les informations dauthentification au serveur
denregistrement (Registrar) via un message (REGREQ). Si les informations
dauthentifications sont valides, le serveur envoie un message (REGACK) en demandant
dindiquer ladresse qui sera utilise.
26
Figure 3.1 Les requtes denregistrement IAX. Tire du draft-05 publi lectroniquement [34].
Les requtes utilises pendant lenregistrement dun client IAX sont :
REGREQ : cest une requte denregistrement indpendante du mdia support. Elle est
utilise pour la demande denregistrement et pour la rponse une requte dauthentification.
Le message doit contenir le nom dutilisateur, et optionnellement le temps ncessaire pour
rafrachir lenregistrement. La mthode utilise pour lauthentification est dtermine partir
du serveur denregistrement. Cette mthode est galement incluse.
REGAUTH : authentification denregistrement est une rponse aux requtes
denregistrement et libration denregistrement. Ce message permet lauthentification dune
entit demandant lenregistrement ou la libration denregistrement. Il doit contenir le nom
dutilisateur, la mthode dauthentification (MD5 ou RSA), et la cl associe.
Client IAX Registrar IAX
REGREQ (Nom utilisateur)
REGAUTH (Nom utilisateur, mthode, challenge)
REGREQ (Nom utilisateur, mthode, temps Rafraichir)
REGACK (Nom utilisateur, temps avant expiration, adresse apparente)
ACK ()
27
REGACK : le message accus de rception denregistrement est envoy, lorsque la
procdure sest bien droule. Il peut contenir le temps en secondes avant lexpiration
denregistrement.
Le temps requis de lenregistrement dune entit IAX est calcul en se basant sur les
messages REGREQ et REGACK. Le diagramme de squence denregistrement du client
IAX est dans la figure 3.2.
Figure 3.2 Les squences d'enregistrement IAX pour calculer le dlai Setup.
3.2.2 La signalisation de terminaux IAX
Le protocole IAX peut tre utilis pour mettre en place une liaison entre deux clients IAX
avant dtablir la communication. Cette procdure appele Call legs se compose de deux
messages principaux :
Message New : contient les informations de destination. La rponse peut tre une demande
dauthentification, rejet de demande ou Call legs est tabli.
IAX entit IPPBX (REGISTRAR) Temps
REGREQ
REGAUTH
REGREQ
REGACK
ACK
28
Message Accept : indique que ltablissement dappel au niveau Call legs sest bien
droul.
Call legs permet de relier les deux entits communicantes et faire passer les messages de
contrle dappel jusqu' la fin dappel (figure 3.3).
Figure 3.3 Les squences de signalisation IAX. Tire du draft-05 publi lectroniquement [34].
Client-1 IAX Client-2 IAX
NEW ()
AUTHREQ (Nom utilisateur, mthode, challenge)
AUTHREP (Nom utilisateur, mthode, temps Rafraichir)
ACCEPT (Nom utilisateur, temps avant expiration, adresse apparente)
ACK ()
ACK ()
ANSWER ()
29
Remarque : Nous avons utilis la dure coule entre les messages NEW et ACCEPT pour
calculer la dure de signalisation IAX.
Ltablissement de lappel via le protocole IAX (Call Leg) ncessite deux requtes (NEW et
ACCEPT). Les requtes AUTHREQ et AUTHREP ne sont pas ncessaires moins que le
client IAX ne soit pas authentifi au dbut de la signalisation.
On considre dans lexprience de signalisation que le client est dj authentifi, donc la
signalisation ncessite deux requtes NEW et ACCEPT pour tablir la signalisation. Le
message ACCEPT inclut lun des codecs spcifis par la requte NEW.
3.2.3 Mini-Frame
Les paquets transportant la signalisation IAX et les donnes mdia utilisent un port unique
4569 au dessus du protocole de transport UDP. Le draft-iax dfinit deux types de paquets :
Full Frame : peut tre utilis pour transporter les donnes de signalisation et les donnes
mdia. La structure Full Frame est optimale pour initialiser, contrler et terminer un appel
IAX car les paquets Full Frame sont fiables. Ils ncessitent un accus de rception
immdiat aprs la rception. La longueur de lentte qui compose Full Frame est de 12
octets.
Mini Frame : est utilis pour transporter les donnes mdia uniquement. La taille de
lentte Mini Frame est de 4 octets. Les paquets Mini Frame sont non fiables.
Nous avons enregistr les paquets Mini Frame capturs dans un fichier pour tre analyss
ultrieurement durant le calcul de la performance IAX. Nous avons test les paramtres de
qualit de service : la bande passante, le dlai et la gigue.
30
3.3 Conclusion
Dans ce chapitre, nous avons vu le protocole IAX destin spcialement pour la signalisation
et la transmission du mdia sur IP.
Nous avons montr la procdure denregistrement et dtablissement dappel que nous
utiliserons pour calculer la dure denregistrement et de signalisation IAX.
Nous avons cit les diffrents types de paquets que nous analyserons pour tester la
performance dune communication IAX.
CHAPITRE 4
ENVIRONNEMENT EXPRIMENTAL ET RECHERCHES ANTRIEURES
Dans les chapitres prcdents, nous avons vu les diffrents protocoles utiliss pour
transmettre les donnes mdia.
Ce chapitre propose une architecture gnrale denvironnement exprimental ainsi quune
analyse des travaux de recherches antrieures dans le domaine.
La plateforme IPPBX est un outil assez complet pour tester la transmission mdia sur les
rseaux IP en utilisant les protocoles SIP sur RTP et IAX. Elle sera utilise pour nos travaux.
4.1 Les exigences de lenvironnement exprimental
Lenvironnement exprimental de la transmission mdia sur les rseaux IP en utilisant les
protocoles SIP et IAX doit contenir le client, le serveur proxy et le capteur de trames.
Le client peut tre un logiciel qui utilise le protocole SIP ou IAX pour signaliser avec
dautres clients, et transporte les donnes mdia par lintermdiaire du protocole RTP ou IAX
mini frames. On peut distinguer deux types du client :
Le client matriel : il peut tre un tlphone IP ou un tlphone analogique connect un
adaptateur ATA.
Le client logiciel : il est sous forme dun progiciel installer sur lordinateur.
Lanalyseur de trames : il permet de capturer les paquets circulant entre les clients, il est
capable de fournir les informations identifiant les donnes mdia et aussi les performances
dune communication SIP ou IAX.
Pour notre projet nous avons quelques contraintes, que lon peut dfinir comme suit :
32
Le serveur proxy doit tre capable de faire communiquer les clients SIP et IAX, cela est
ncessaire pour pouvoir calculer le temps requis de signalisation SIP et IAX. Le serveur
doit commuter galement les diffrents canaux SIP et IAX.
Le capteur de trames doit tre capable didentifier les informations du protocole SIP et
IAX, et aussi il doit fournir un environnement de dveloppement de nouveaux scripts
Les outils disponibles nous limitent utiliser le client logiciel.
Lmulateur mobile doit avoir les progiciels ncessaires pour la signalisation SIP, laccs
au rseau et le traitement mdias.
4.2 Les lments de larchitecture tests et les alternatives
Dans un premier temps, nous avons test SIP Express Router [54], qui fait le rle dun proxy,
registraire et Redirect SIP. Sa mise en uvre est conviviale. Il offre toutes les fonctionnalits
pour tester la transmission mdia sur les rseaux IP en utilisant le protocole SIP. Il peut tre
combin avec RTP proxy [55] pour offrir un relais mdia.
Ensuite, nous avons test IPPBX Asterisk [35], qui fait le rle dun autocommutateur
complet. Il supporte les protocoles SIP et IAX pour transporter la voix ou la vido sur les
rseaux IP. Il est interoprable avec le systme tlphonique traditionnel (PSTN) et le rseau
cellulaire GSM pour de futurs travaux.
Lmulateur mobile doit tre capable de simuler un terminal mobile (tlphone mobile,
Smart phone, et PDA) dot des caractristiques spcifiques en termes des ressources
mmoires et puissance de calcul. Nous avons test plusieurs solutions : Nokia, Motorola,
Windows Mobile et Sun Wireless Toolkit. Il existe une multitude de diffrences au niveau du
systme dexploitation et du langage de programmation. Symbian est un systme
dexploitation intgr dans la plupart de terminaux mobiles de la troisime gnration. Il
offre des fonctionnalits avances pour tester la transmission mdia sur les rseaux IP au
niveau de lencodage et du dcodage mdia. Le protocole de signalisation SIP et le protocole
33
de transport mdia RTP sont intgrs au terminal mobile sous forme de solution propritaire
et adaptable au lecteur multimdia.
Dautre part, la technologie J2ME utilise le concept de la machine virtuelle JAVA ddie aux
terminaux mobiles. Elle est disponible sur la plupart de terminaux, cette technologie utilise
JSR (Java Specification Request) pour couvrir un ensemble de fonctionnalits. JSR 180
apporte les lments ncessaires pour signaliser un terminal mobile dans une session
multimdia via le protocole SIP. JSR 118 offre les fonctions ncessaires pour accder au
rseau IP et manipuler les datagrammes UDP. JSR 135 gre la capture, le traitement et
laffichage de la voix et de la vido.
Les clients logiciels tests sont : Xlite [48], iaxlite [50], ekiga [51], samplephone [52] et
Zoiper-Communicator [53]. Les fonctionnalits supportes par les clients logiciels se
ressemblent : enregistrement au serveur, rejoindre une session multimdia, transport de la
voix ou de la vido, les codecs audio et vido supports sont limits aux codecs non payants.
Le client logiciel Xlite combine le transport de la voix et la vido, il est capable dtablir une
communication audio ou vido nimporte client matriel (tlphone ou tlphone IP) ou
logiciel.
Lanalyseur de trames est un outil indispensable pour visualiser et contrler le contenu des
donnes transmises. Nous avons test Ethereal [49], WireShark [38], et Unsniff network.
Ethereal [49] peut tre utilis pour analyser les trames venant de diffrents rseaux : ATM,
FDDI, Ethernet et rseau sans fil. Il est support sur diffrent mainframe mais la solution
Ethereal est plus adapte au systme dExploitation Linux. WireShark [38] analyse la
communication SIP et nous pourrons le configurer pour quil puisse calculer le temps requis
pour lenregistrement et la signalisation. Les performances dune communication SIP
peuvent tre calcules en utilisant les fonctionnalits appropries. Le flux mdia peut tre
captur et enregistr sous plusieurs formats disponibles avec loutil WireShark. Unsniff
Network Analyser [43] est capable danalyser les trames. Il offre la possibilit de dvelopper
34
des scripts spcifiques aux nouveaux protocoles. Cet outil est capable danalyser le flux
mdia en temps rel.
4.3 Contexte de lenvironnement exprimental et
Larchitecture gnrale du projet contient deux axes de travail :
Axe 1 : linstallation de la plateforme IPPBX, le calcul du temps requis de la signalisation
SIP/IAX et la performance dune communication IAX en utilisant les codecs G.711 et GSM.
Axe 2 : Limplmentation dun client mobile pour la vidoconfrence (plus de dtails au
chapitre suivant).
Larchitecture de composantes techniques est dans la figure 4.1.
Figure 4.1 Larchitecture de composants techniques.
La figure 4.1 montre larchitecture de lenvironnement exprimentale, qui se compose en :
35
Traceur de paquets WireShark [38] permet de capter les trames circulantes entre
lmulateur mobile et le softphone (SIP/RTP). Cet outil va nous permettre danalyser le
mdia capt pendant une session multimdia. Il va aussi nous servir pour calculer le temps
requis pour lenregistrement et la signalisation SIP/IAX. Les fonctionnalits offertes par
[38] par rapport [49] sont la possibilit de capturer les requtes de signalisation SIP/IAX en
temps rel, la sauvegarde dans un fichier nous facilite lanalyse et le calcul de dlai
denregistrement et de la signalisation. Limplmentation du protocole RTP dans un
terminal mobile ncessite la sauvegarde de flux RTP sous le format rtpdump pour sa lecture
ultrieurement. Lanalyse du flux RTP via loutil WireShark permettra le calcul de la bande
passante le dlai et la gigue selon RFC 3550.
Les scripts de lannexe I, II et III sont dvelopps avec le langage Ruby et ncessiteront
lenvironnement de dploiement IAX Unsniff Network Analyseur [41] car larchitecture du
capteur de trames est Plug In Play et les scripts dvelopps sont facile tre intgrs.
Linterface graphique de loutil est indpendante du protocole analys, elle est possible
dtre adhre aux scripts danalyse du protocole IAX. Nous croyons quIAX Unsniff
Network Analyseur [43] est le seul outil capable de calculer les performances du protocole
IAX.
Lmulateur mobile utilise la technologie J2ME [37] pour fournir un environnement de test
convivial de terminaux mobiles. Ce choix de la technologie est gouvern par la
disponibilit de la machine virtuelle Java ddie aux terminaux mobiles et le
dveloppement avanc des APIs ncessaires pour connecter un client mobile de
vidoconfrence une session multimdia dont JSR 180, JSR 118 et JSR 135.
Le client logiciel de la voix et la vido IP utilis pendant la communication est le softphone
(SIP/RTP) Xlite [48], il utilise la camra pour transporter la vido, il peut tablir des appels
SIP voix ou vido. Il supporte les codecs G.711 et H.323 quon utilisera pour implmenter
un client mobile de vidoconfrence. Les autres clients logiciels tels que ekiga et Zoiper-
Communicator ne supportent pas la fonctionnalit de la vido.
Le serveur registraire proxy SIP/IAX est la plateforme Asterisk IPPBX [35], on lutilisera
comme plateforme de test, car elle supporte la commutation de communication SIP/IAX.
Au contraire, Sip Express Router [54] ne supporte que le protocole SIP. Les alternatives
36
pour tester le protocole IAX ne sont pas nombreuses. Il existe des solutions qui combinent
le client et le serveur au mme progiciel comme Yate [56] mais ils sont tous drivs de la
plateforme Asterisk IPPBX. Nous utiliserons la plateforme Asterisk IPPBX comme serveur
proxy SIP/IAX car le protocole IAX a t dvelopp spcifiquement pour rsoudre
quelques problmes rencontrs lors du dploiement de la plateforme et pour connecter deux
autocommutateurs Asterisk. Nous croyons que cette plateforme pourra tre utilise pour
dautres travaux de recherche et plus spcifiquement pour sa capacit dtre interconnect
au rseau tlphonique traditionnel PSTN et au rseau cellulaire GSM. La plateforme
IPPBX est dcrite dans la prochaine section avec les travaux antrieurs.
4.4 Description de la plateforme IPPBX et les recherches associes
La plateforme IPPBX permet la commutation de canaux venant dun rseau IP et la
commutation de circuits tlphoniques. Elle remplit le rle dune passerelle entre diffrentes
technologies : le rseau tlphonique traditionnel, le rseau Internet et le rseau local.
La connexion de circuits tlphoniques la plateforme IPPBX se fait par lintermdiaire
dune carte FXO (Foreign eXchange Office) et FXS (Foreign eXchange Subscriber).
Les protocoles utiliss pour transmettre les mdias au niveau de la couche applicative sont :
SIP, SDP, RTP et IAX.
Dans larticle [1], on affirme que la plateforme Asterisk est un outil assez complet pour
conduire les expriences et les simulations VoIP. Les chercheurs ont effectu une tude
comparative et exprimentale du trafic circulant dans la mtropolitaine Ottawa. La mthode
de mesure utilise est Mean Opinion Score (MOS). Cette mthode permet la notation des
appels en fonction de la qualit (voir le tableau 4.1).
37
Tableau 4.1 La qualit de lappel en utilisant MOS (Mean Opinion Score)
La valeur (MOS) Qualit
1 Faible
3 Moyenne
5 Excellente
La performance de SIP/IAX est teste en fonction de deux paramtres (la perte de paquets et
le dlai). Onze chantillons dappels sont utiliss pour obtenir une note dopinion moyenne
(MOS). Les appels sont effectus sous les conditions similaires du rseau.
Les rsultats de test dexprience indiquent que lappel IAX maintient une qualit suprieure
lorsque le taux de perte de paquets varie entre 0,5 et 9%. Sur cet intervalle, les mesures prises
montrent que lappel IAX affiche une amlioration de performances de 0.513 MOS et une
amlioration de performance relative de SIP 24.70 % (calcul selon la formule 4.1).
2
1
1 N i ii i
IAX SIPN SIP
=
(4.1)
Dans la formule (4.1), IAXi reprsente la qualit de la mesure i pour le protocole IAX, SIPi
reprsente la qualit de la mesure i pour le protocole SIP, et N reprsente le nombre de
mesures prises.
Similairement, la qualit dappel IAX est amliore de 7.16 % par rapport SIP en
changeant le dlai darrive des paquets dans un intervalle [0, 2000 ms] par pas de 200 ms.
La formule 4.1 est utilise galement pour calculer cette amlioration.
Dautres travaux ont t effectus sur le serveur IPPBX Open source pour tester la robustesse
et les options de fonctionnement [2] et [3].
38
Larticle [2] examine les tapes dinstallation de la plateforme ASTERISK en mentionnant la
configuration approprie pour tre intgre dans un rseau htrogne (SIP et H.323).
Dans [2], on dcrit galement lutilisation de lIPPBX pour acheminer les appels entrants au
rseau local, et aussi rediriger les appels sortants vers le rseau tlphonique traditionnel.
Limplmentation [2] comprend VoIP Gatekeeper pour fournir la translation dadresses et le
contrle daccs lintrieur du rseau local. Dans ce projet on utilisera la mme procdure
dinstallation de la plateforme IPPBX, et on ajoutera un script automatisant la compilation et
linstallation de la plateforme (Annexe I).
Cependant, lauteur de larticle [3] explore linteroprabilit entre Cisco Call Manager et
IPPBX. Le rsultat montre quIPPBX sintgre parfaitement dans un rseau compos de
dautres types dautocommutateurs comme Cisco Call Manager.
Les options supportes par un autocommutateur standard : Afficheur, transfert dappel et
rpondeur sont tests et fonctionnent correctement [3].
Laspect scuritaire de la transmission mdia est tudi dans [30], lauteur a dcrit les
mthodes actuelles adaptes (confidentialit, intgrit et disponibilit) scuriser le flux
mdia ensuite il a valu la performance bande passant et CPU aprs avoir implment
chaque mthode de scurit.
Le point fort IPPBX Open source est la capacit dintgrer diffrents modules pour tester la
performance rseau [1] et [3], la scurit [30], le contrle et la signalisation de services
multimdia IP [5].
Notre objectif, dans ce projet, est dimplmenter la plateforme base sur IPPBX pour pouvoir
transmettre de la voix sur IP et de mesurer le temps requis pour lenregistrement et la
signalisation des protocoles SIP et IAX.
Les performances de la communication IAX (la bande passante, le dlai et la gigue) sont
calcules en excutant un script danalyse IAX.
39
4.5 Installation de lIPPBX Asterisk
Linstallation consiste mettre en uvre une machine dote des progiciels ncessaires du
systme Asterisk et les logiciels capables de traiter la voix et la vido sur IP.
Linstallation ncessite la rcupration et la compilation des fichiers sources.
Lorsquon souhaite utiliser une liaison au rseau tlphonique, dautres cartes permettront
linterface au rseau PSTN sont ncessaires. ce moment, la compilation du module Zaptel
est fondamentale, car il permet de faire fonctionner les cartes PRI, BRI et FXO/FXS.
4.5.1 Matriels utiliss
Pour linstallation dAsterisk, nous avons utilis une machine avec les caractristiques
suivantes :
Processeur P4 1.8 GHz
512 Mo de RAM
40 Go de disque dur
Carte rseau 10/100 Mbit.
Le choix du serveur dpendra en grande partie du nombre de canaux de voix grer. Un trs
grand nombre de lignes demande un serveur relativement puissant.
Les soft phones permettent de jouer le mme rle que les tlphones IP, mais lutilisateur
doit avoir un casque et un micro pour pouvoir passer et recevoir des appels. Il existe
plusieurs soft phones gratuits et qui supportent les protocoles SIP et IAX.
40
4.5.2 Script du dploiement
Asterisk est offert sous forme de plusieurs package adapts Linux CentOS version 4.4.
Nous avons cr un script dinstallation dAsterisk pour automatiser le dploiement (voir
Annexe I).
Nous avons rcupr les bibliothques ncessaires linstallation (zlib 1g, zlib 1g-dev,
libncurses5, libncurses-dev, libssl0.9.6, libssl-dev, libnewt-dev et libnewt0.51)
La commande dinstallation :
Apt-get install zlib 1g zlib 1g-dev libncurses5 libncurses-dev libssl0.9.6 libssl-dev
libnewt0.51.
Ensuite, nous avons rcupr partir du site de Digium, les archives de Zaptel et Asterisk. Il
faut noter que lon a utilis la version dAsterisk 1.4.4 et Zaptel 1.4.2.1 :
wget http:// ftp.digium.com/pub/asterisk/releases/asterisk-1.4.4.tar.gz &&
wget http://ftp.digium.com/pub/zaptel/ tel.tar.gz &&
wget http://ftp.digium.com/pub/libpri sionlibpri &&
wget http:// ftp.digium.com/pub/asterisk ons.tar.gz
4.5.3 Cration dextensions SIP
Les clients SIP se connectent IPPBX via les extensions du protocole SIP ensuite ils peuvent
tablir une session multimdia pour faire passer de la voix ou la vido sur IP.
Le fichier sip.conf permet dajouter les clients SIP. La procdure consiste remplir les
champs prdfinis tels que :
Username le nom dutilisateur
Secret le mot de passe
Context le contexte dans lequel le compte est associ dans le fichier extension
Type il existe trois types de compte : peer utilis pour appel le compte de loprateur,
friend pour envoyer et recevoir des appels, user pour recevoir les appels.
41
Host ladresse IP du serveur IPPBX
Allow la liste de codecs autoriss pour les paquets audio
Un exemple de configuration dun client en utilisant le protocole SIP se trouve lannexe II.
4.5.4 Cration dextensions IAX
Les clients qui se connecteront en utilisant le protocole IAX doivent tre positionns dans le
fichier iax.conf. Un exemple de configuration dun client IAX se trouve dans lannexe III.
4.5.5 Groupes et manipulations des appels
Le fichier Extension.conf contient tout le plan de numrotation du serveur. Il permet
dassocier les numros de tlphone (extension) diffrentes actions et aussi de dfinir les
groupes et les actions que IPPBX doit faire pour grer les appels en provenance et
destination de chaque groupe.
Le fichier est compos de deux axes : le contexte global qui contient les variables de portes
globales et les contextes particuliers.
Un contexte est une zone de mmoire prive dans laquelle des actions de porte limite
pourront tre excutes.
Lenregistrement dune extension se fait de la manire suivante :
Exten => extension, Numro de Squence, Action;
Le fichier Extension.conf contenant le plan de numrotation se trouve lannexe IV.
42
4.6 Interconnexion au rseau PSTN
Linterconnexion de lIPPBX au rseau tlphonique traditionnel ncessite la carte
FXO/FXS. Toutefois, pour pouvoir lutiliser il faut compiler le progiciel fournit avec la carte
Zaptel pour quelle soit prise en charge. Les deux commandes ncessaires sont :
Modprobe zaptel
Modprobe wcfxo
Ensuite, nous ajoutons la ligne suivante dans le fichier /etc/zaptel.conf pour dclarer le canal
de signalisation et le protocole utilis :
Fxsks = 1 ; la signalisation utilise est Koolstart dans le canal 1
Defaultzone = us
Loadzone = us
La dclaration de signalisation doit tre ajoute dans le fichier /etc/asterisk/zapata.conf
Signaling = fxs_ks
Group = 1
Channel => 1
Finalement, nous configurons un trunk pour que linterconnexion au rseau PSTN passe par
le canal 1, et les diffrents canaux peuvent lutiliser pour acheminer les donnes voix ou
vido. Dans le mme fichier utilis prcdemment pour grer les appels 4.5.5 nous
ajoutons un trunk zaptel
exten => s,1,Dial,Zap/1
43
4.7 Interconnexion au rseau GSM
Dans cette section, nous dcrivons la procdure dinterconnexion IPPBX au rseau GSM
mais la fonctionnalit nest pas teste. Une passerelle GSM est ncessaire pour
interconnecter la plateforme IPPBX au rseau GSM, cette passerelle est sous forme de carte
PCI, elle dispose de deux emplacements SIM pour permettre deux canaux simultanment
vers le rseau GSM.
La configuration de la passerelle GSM est spcifique au fabricant, mais la plateforme IPPBX
ncessite lajout des lignes suivantes pour pouvoir acheminer les appels vers le rseau GSM.
Dans le fichier GSM, nous ajoutons lextension suivante pour le rseau GSM :
[100]
type = friend
username = 100
password = 100
context = gateway ; le contexte des appels entrants
callerid = la passerelle GSM
host = dynamic
nat = no
allow = ulaw
allow = alaw
Ensuite, dans le fichier extensions.conf nous configurons la gestion dappel comme suit :
[gateway]
exten=> _103,1,Answer()
exten => 103,2,Set (TIMEOUT(digit) = 3);
exten => _103,3, (outgoing); le contexte pour acheminer lappel au rseau GSM
[outgoing]
44
exten => _888,1,SetCallerID(XXXXX)
EXTEN => _888,2,Dial(SIP/$EXTEN @103,60,r)
Cette configuration ajoute aux fichiers extensions.conf et sip.conf permettra de faire des
appels partir de clients locaux vers un rseau GSM.
4.8 Interconnexion de deux systmes IPPBX
Il existe trois manires pour interconnecter les deux systmes. Premirement, il sagissait de
la mthode des extensions, mais cette mthode nest pas utilisable dans le cas o plusieurs
canaux souhaitent communiquer simultanment. Dans une autre mthode, larchitecture
matre/esclave, le serveur dclar Peer est matre et peut transfrer les appels vers le serveur
esclave. Par contre, le serveur User ne peut que recevoir les appels du serveur Peer. Ce
concept est utilisable lorsque lon dsire acheminer les appels dans un sens unidirectionnel.
Finalement, le modle Friend/Friend permet aux deux systmes de communiquer entre eux et
davoir une transparence totale dans lacheminement dappel.
Nous dcrivons la configuration du modle Friend/Friend que nous avons choisie. Nous
ajoutons les champs suivants dans le fichier iax.conf :
[general]
bindadd = 0.0.0.0
tos = lowdelay
disallow = all
allow = ulaw ; nous utilisons la loi u
allow = g729 ; nous utilisons le codec G.729
register => SiteB :PassSiteB@IP-SiteB ; enregistrement dans le systme du site B ;
Nous crons un compte iax pour lIPBX du site B pour quil puisse senregistrer sur
lIPBX A
[SiteA]
45
type = friend