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