Rapport projet Asterisk

Transcription

Licence Réseaux et Télécoms
Année 2008/2009
Projet tuteuré
Redondance de serveur de téléphonie
sur IP avec le logiciel Asterisk
Asterisk
Tuteur IUT : Joël TOUSSAINT
Chargé du projet : Laura REDONDO / Maxime BOSCIA
Année 2008/2009
Remerciements
Nous tenons tout d’abord à remercier M. Joël TOUSSAINT, qui fut notre tuteur durant
la période de notre projet, de l’écoute et du temps qu’il nous a accordé quand nous en avions
besoin.
Nous souhaitons remercier aussi Mme. Nadine GIRAUD pour les cours de
communication et d’expression qui ont contribué à l’élaboration de ce rapport et de notre
soutenance.
Nous remercions aussi l’ensemble de la communauté informatique qui a contribué
sans le savoir à ce projet par le biais de site web ou bien de forums. Un remerciement tout
particulier est adressé à M. Laurent PERRIN qui nous a fourni la documentation nécessaire
essentielle à la bonne réalisation de ce projet.
Melle REDONDO Laura
M. BOSCIA Maxime
Tuteur : M. TOUSSAINT
Année 2008/2009
Sommaire
Introduction ................................................................................................................................ 1
1
Gestion de projet ................................................................................................................ 2
1.1 Avant Projet Synthétique (APS) .................................................................................. 2
1.2 Avant Projet Détaillé (APD)........................................................................................ 2
1.3 Cahier des charges fonctionnel (CCF)......................................................................... 2
1.4 Work Breakdown Structure (WBS) ............................................................................. 5
1.5 Tableau d’antériorité des tâches (TAT) ....................................................................... 6
1.6 Diagramme de GANTT ............................................................................................... 6
1.7 Bilan personnel ............................................................................................................ 8
2
La VoIP et Asterisk .......................................................................................................... 10
2.1 Définition de la VoIP ................................................................................................. 10
2.1.1
Fonctionnement de la VoIP ................................................................................ 10
2.1.2
Avantages ........................................................................................................... 10
2.1.3
Inconvénients ..................................................................................................... 11
2.2 Présentation d’Asterisk .............................................................................................. 12
2.2.1
Avantages ........................................................................................................... 12
2.2.2
Inconvénients ..................................................................................................... 13
2.3 SIP ............................................................................................................................. 14
2.3.1
Présentation ........................................................................................................ 14
2.3.2
Fonctionnement .................................................................................................. 14
3
Installation de la plateforme VoIP.................................................................................... 16
3.1 Configuration matérielle ............................................................................................ 16
3.2 Installation et configuration d’Asterisk ..................................................................... 17
3.2.1
Fichier sip.conf ................................................................................................... 18
3.2.2
Fichier extensions.conf....................................................................................... 19
3.2.3
Fichier voicemail.conf ........................................................................................ 19
3.2.4
Fichier iax.conf................................................................................................... 21
3.3 Mise en place des clients X-Lite................................................................................ 23
4
La haute disponibilité ....................................................................................................... 25
4.1 Présentation ............................................................................................................... 25
4.2 Le Fail-Over avec Heartbeat...................................................................................... 26
4.2.1
Présentation ........................................................................................................ 26
4.2.2
Configuration du cluster Heartbeat .................................................................... 28
4.2.3
Etat du système................................................................................................... 29
4.3 Répartition de charge avec IPVS et ldirectord .......................................................... 29
4.3.1
Ipvs ..................................................................................................................... 29
4.3.2
Ldirectord ........................................................................................................... 32
4.4 Scripts d’amélioration................................................................................................ 36
4.5 Ipv.sh ......................................................................................................................... 36
4.6 test_ldirectord.sh........................................................................................................ 37
4.7 Schéma d’une plateforme optimisée.......................................................................... 39
5
Test de notre solution ....................................................................................................... 40
Conclusion ................................................................................................................................ 43
English Summary ..................................................................................................................... 44
Glossaire ................................................................................................................................... 45
Bibliographie ............................................................................................................................ 49
Annexes .................................................................................................................................... 50
Melle REDONDO Laura
M. BOSCIA Maxime
Année 2008/2009
Introduction
Dans le cadre de notre licence professionnelle Réseaux et Télécommunications, option
Administration Et Sécurité des Réseaux, à l'Institut Universitaire de Technologie de
Clermont-Ferrand, nous avons eu l’occasion de réaliser un projet tuteuré.
Celui-ci porte sur une étude de redondance de serveurs de téléphonie Asterisk. Cette
technologie étant de nos jours en plein essor dans les entreprises, ce sujet nous permet de
compléter notre expérience dans le domaine de la VOIP (voix sur IP), compétence qui nous
sera utile dans le monde du travail.
Notre objectif ici est de mettre en place une solution de haute disponibilité du service
Asterisk dans un contexte de grande entreprise, incluant des coupures ou encore des
surcharges du système.
Face à ces objectifs, nous pouvons donc nous poser les questions suivantes :
Pourquoi étudier la haute disponibilité du système Asterisk ?
Quelle technologie utiliser et comment la mettre en place ?
En premier lieu, nous verrons les outils de gestion de projet. Ensuite, nous étudierons
la VOIP puis le logiciel Asterisk et son mode de fonctionnement. Dans une troisième partie,
nous installerons notre plateforme de téléphonie. Puis nous rechercherons quelles
technologies permettent de mettre en place un service de haute disponibilité et quelles sont
leurs fonctionnalités. Enfin, nous effectuerons des tests afin de nous assurer du bon
fonctionnement de notre solution.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 1
Année 2008/2009
1 Gestion de projet
Ce projet a été l’occasion de s’exercer à mettre en place les techniques de gestion de
projet apprise pendant les cours de Monsieur CLAVAUD afin de se rendre compte des
difficultés que représente la charge de « Chef de projet ».
On retrouvera donc dans cette partie tous les documents utiles qui ont dû être produit afin
d’analyser, gérer et répondre aux exigences du projet.
1.1 Avant Projet Synthétique (APS)
Téléphonie sur IP :
Le but est ici de mettre en place une solution de téléphonie telle qu’Asterisk. Après
avoir étudié les fonctionnalités de base, le but est de réaliser l’interconnexion de plusieurs
serveurs, afin d’étudier comment peut-être déployée une telle solution dans un environnement
multi-site et avec beaucoup d’usagers.
1.2 Avant Projet Détaillé (APD)
Dans le cadre de notre projet, nous mettrons en place un serveur de téléphonie sur IP
grâce au logiciel Asterisk ainsi que des logiciels de téléphonie clients comme X-Lite. Puis
nous déploierons un deuxième serveur Asterisk afin d’étudier comment le connecter au
premier et ainsi obtenir une interconnexion de serveurs de téléphonie. Enfin, nous utiliserons
un logiciel de test comme SIPp afin d’étudier le comportement des serveurs quand ils sont
surchargés de communications, pour simuler le contexte de téléphonie de grande entreprise
avec de nombreux utilisateurs.
1.3 Cahier des charges fonctionnel (CCF)
Le cahier des charges fonctionnel permet de définir le besoin du client au moyen de
fonctions détaillant les services rendus par le produit et de contraintes auxquelles il est
soumis.
Pour cela, on utilise d’abord la méthode de questionnement QQOQCCP : Quoi ? Qui ?
Où ? Quand ? Comment ? Combien ? Pourquoi ?
Puis on établit enfin le tableau des fonctions et des contraintes du produit.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 2
Année 2008/2009
Méthode de questionnement :
Réponses
Qui ?
Quoi ?
Ou ?
Quand ?
Comment ?
Combien ?
Pourquoi ?
Chefs de projet : Laura REDONDO et Maxime BOSCIA
Client / Utilisateur : Mr TOUSSAINT
Interconnexion de serveurs de téléphonie sur IP
Au centre de formation (IUT), dans les salles informatiques
réservées
De Novembre à Mai, environ 13 semaines, durant les périodes au
centre de formation.
-
Mettre en place une architecture matérielle composée
d’un serveur de téléphonie sur IP et de postes clients
- Etablir un nombre important de connexions téléphoniques
simultanées grâce à un utilitaire à trouver par nous même
afin d’établir une situation de surcharge de connexion sur
un serveur.
- Ajouter un second serveur de téléphonie sur IP et
l’interconnecter avec le premier.
- Gérer la répartition de charge entre les deux serveurs lors
d’une surcharge de connexions simultanées.
Notre budget ne dépassera pas celui de l’achat éventuel de
téléphone IP (à compléter pour connaître le budget accordé à cet
achat), le reste du matériel nécessaire étant fournit par l’IUT.
Analyser le comportement d’un logiciel libre de téléphonie sur IP
dans un contexte de grande entreprise nécessitant de nombreuses
communications téléphoniques simultanées. Ce projet permettra
d’assurer une continuité de service au niveau de la téléphonie.
Melle REDONDO Laura
M. BOSCIA Maxime
Pourquoi ?
Nous avons choisi ce projet.
Répartir les communications téléphoniques simultanées lors
de la surcharge d’un serveur
Le matériel nécessaire à la réalisation du projet est mis à
notre disposition dans ces locaux.
Le travail en entreprise ne nous permet pas de disposer d’un
intervalle de temps plus important pour travailler sur le
projet.
Grâce à cette procédure, nous pourrons déterminer le nombre
de connexions simultanées que peut supporter un serveur.
Cette information nous sera donc nécessaire pour gérer par la
suite la répartition de charge entre l’ancien serveur et celui
ajouté.
Le matériel est fournit par le centre de formation, seul l’achat
éventuel de téléphone IP représentera un coût.
Page | 3
Année 2008/2009
Cahier des charges fonctionnel
N°
F1
F2
Fonction
Fonction
Type
F3
Fonction
F4
Fonction
C1
C2
C3
C4
C5
C6
Contrainte
Contrainte
Contrainte
Contrainte
Contrainte
Contrainte
Nature
Service de téléphonie
Connexions simultanées au
serveur
Redondance du service
téléphonique
Interconnexion
Délai
Temps de réalisation
Logiciel
Système d’exploitation
Budget
Matériel
C7 Contrainte Lieu
Melle REDONDO Laura
M. BOSCIA Maxime
Critère
Serveurs Asterisk
Nombre
Niveau
Flexibilité
0%
Maximum
Deux serveurs Asterisk
Equilibrage de charge en terme de
communications.
Date de la soutenance
Semaine
Serveur de téléphonie
Serveur support de la solution téléphonique
Euro
Nombre
Centre de formation
0%
Répartition équitable
0%
20 mai
13 environ
Asterisk
Linux Debian
0
2 serveurs Asterisk sur Linux
Debian
2 clients X-Lite sur Windows
XP
Salles réservées
0%
0%
0%
0%
0%
0%
0%
Page | 4
Année 2008/2009
1.4 Work Breakdown Structure (WBS)
Le « Work Breakdown Structure » est un outil de gestion de projet qui permet de déterminer les tâches à effectuer au cours de notre projet.
Interconnexion de
serveurs de
téléphonie Asterisk
Installer les
serveurs
Installer
Linux Debian
sur deux
postes
physiques
(A)
Installer
VMWare
sur les
serveurs
(I)
Melle REDONDO Laura
M. BOSCIA Maxime
Installer les
postes clients
Installer et
configurer le
logiciel de
téléphonie
Asterisk
(B)
Installer les
clients
virtuels sur
les serveurs
(C)
Configurer les
logiciels
clients
(D)
Créer une situation de
surcharge sur l’un des
deux serveurs
Utiliser un
logiciel
créant des
surcharges
(E)
Analyser les
conséquences
de la
surcharge
(F)
Gérer la haute
disponibilité et la
répartition de charge
Etudier la
configuration
à mettre en
place
(G)
Installer la
solution
(H)
Page | 5
Année 2008/2009
1.5 Tableau d’antériorité des tâches (TAT)
Le tableau d’antériorité des tâches vient à la suite du WBS et permet de hiérarchiser
l’ensemble des tâches définis dans le temps.
Tâches
A
B
C
D
E
F
G
H
I
Nom
Installer Linux Debian
Installer/configurer Asterisk
Installer les clients
Configurer les clients
Créer la surcharge
Analyser les conséquences
Etudier les solutions
Installer notre solution
Installer VMWare
Antériorité
/
A
A, I
A, B, C, I
A, B, C, D, I
A, B, E, C, D, I
/
A, B, D, E, F, G, I
A
Temps x Hommes
8
40
8
20
56
40
40
80
8
1.6 Diagramme de GANTT
Le diagramme de GANTT est un outil de planification des différentes tâches du projet
afin de suivre son état d’avancement. Cela permet de savoir si l’on est en avance, dans les
temps ou bien en retard sur le projet.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 6
Année 2008/2009
Diagramme de GANTT
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 7
Année 2008/2009
1.7 Bilan personnel
Laura :
Ce projet m’a permis d’améliorer mes compétences dans la maîtrise des systèmes
Linux. De plus, issue d’une formation de BTS Informatique de Gestion option Administrateur
des Réseaux Locaux d’Entreprise, je ne disposais d’aucune connaissance dans le domaine de
la téléphonie sur IP. L’exécution de ce projet m’a donc apporté de nouvelles connaissances
dans ce domaine, qui est aujourd’hui en plein essor dans le monde de l’entreprise.
J’ai également pu acquérir des compétences humaines telles que le travail en équipe et
la répartition du travail. En effet, devant travailler en binôme, certaines tâches à effectuer ont
été réalisées en parallèle les unes des autres. J’ai donc pu apprendre à diviser certaines tâches
et à rendre compte de l’avancement de mes propres actions auprès de mon binôme. De cette
façon, nous avons pu suivre l’avancement du projet sans oublier certains éléments qui
auraient pu être essentiels à sa bonne réalisation.
Mes capacités rédactionnelles ont permis l’avancement du projet et notamment du
rapport. En effet, ayant l’habitude de prendre des notes, j’ai pu établir un suivi de
l’avancement du projet, qui a pu permettre de résoudre les différentes difficultés que nous
avons rencontré en relevant d’éventuelles erreurs de configuration que nous avions effectuées.
Ne me reposant jamais sur mes acquis, j’ai effectuée de nombreuses recherches afin de
trouver des solutions aux problèmes que nous avons pu rencontrer. Ces recherches ont permis
la résolution de certaines difficultés, et parfois, elles ont abouties à de nouvelles solutions à
mettre en place pour contourner nos problèmes techniques.
Face au retard que nous avons pu prendre sur certaines tâches, je n’ai pas cédé au
stress et j’ai su gérer la situation en instaurant une répartition dans notre travail afin que nous
puissions terminer ce dernier dans les délais.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 8
Année 2008/2009
Maxime :
Pendant toute la durée de ce projet, j’ai pu apporter mes connaissances aussi bien sur
le plan technique, organisationnel ou humain. En effet, mes compétences techniques en
matière de réseaux ont permis de résoudre de nombreux problèmes qui se sont posés lors de
cet exercice et notamment sur la partie concernant l’interconnexion des serveurs Asterisk
entre eux. Au niveau organisationnel, j’ai apporté ma rigueur dans la rédaction et la mise en
forme de documents. De plus, étant méticuleux dans mon travail et organisé dans l’ordre des
différentes tâches à effectuer, cela nous a permis d’éviter en grande partie les erreurs ou de les
retrouver très rapidement. Sur le plan humain, j’ai utilisé mes connaissances précédentes du
travail en équipe, basé sur mes expériences précédentes, afin de bien collaborer avec ma
collègue et de fournir du bon travail.
Ce projet m’a quant à lui apporté de nombreuses compétences sur ces mêmes plans.
Ainsi, au niveau technique, j’ai mieux appris à connaître les systèmes Linux. De plus, la
téléphonie sur IP et les techniques de haute disponibilité étaient des domaines complètement
inconnus pour moi. Sur le plan organisationnel, j’ai pu voir ce qu’était toute la difficulté de
bien gérer un projet et qu’il ne suffisait pas d’être bon techniquement pour mener son projet à
bien. Cela demande de multiples connaissances autant au niveau de la gestion de projet qu’au
niveau de la création de documents ou encore au niveau du sens des relations humaines. J’ai
donc appris que de nombreux outils de gestion existe afin de nous aider à gérer au mieux un
projet. Pour ce qui est des compétences humaines, ce projet m’a enseigné à demander de
l’aide lorsque cela est nécessaire. La communauté informatique est très grande et toujours
prête à se rendre service si c’est nécessaire. Sans cela, notre projet n’aurai jamais pu aboutir à
son terme.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 9
Année 2008/2009
2 La VoIP et Asterisk
2.1 Définition de la VoIP
La Voix sur IP, ou Voice Over IP en anglais, est une technique qui permet le transport
de la voix via la technologie IP (1)1 à travers Internet ou tout autre réseau acceptant le
protocole TCP/IP (2).
Celle-ci est employé grâce à un IPBX (Internet Protocol Private Branch Exchange) qui
n’est autre qu’un commutateur téléphonique comme un PABX (Private Automatic Branch
Exchange) sauf qu’il fonctionne via la technologie IP.
2.1.1
Fonctionnement de la VoIP
La voix est avant tout un signal analogique (3). Elle est donc d’abord échantillonnée
afin de la numériser (4) pour qu’elle puisse être transmise par voix numérique. Des codecs (5)
sont ensuite utilisés afin de compresser (6) ce signal.
La téléphonie traditionnelle utilise la commutation de circuits (7) pour le transport de
la voix. La téléphonie sur IP, quant à elle, effectue ce transport à l’aide de la commutation de
paquets (8).
La voix est transformée en paquets qui vont transiter sur le réseau en utilisant le
protocole UDP (9). UDP est un protocole de transport qui procure de meilleurs délais d’envoi
des paquets que TCP (10) car il n’utilise pas de contrôle de réception, dit acquittement.
2.1.2
Avantages
La VoIP possède différents avantages qui la rendent intéressante dans un contexte
d’entreprise :
Réduction des frais de facture téléphonique. En effet, avec une solution IPBX, les appels
internes à l’entreprise ne sont pas facturés. Des avantages interviennent également dans la
mutualisation voix/données du réseau IP inter-sites (WAN (12) )
1
Gain de mobilité. Les postes peuvent être déplacés et ne sont plus physiquement reliés à
des lignes. Les numéros des utilisateurs les suivent lors de leurs déplacements.
technologie IP (1) : Voir le glossaire, définition n°1.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 10
Année 2008/2009
Permet une centralisation des équipements qui sont maintenant tous reliés au réseau
informatique. (ordinateurs, téléphones, fax...)
Les services opérateurs ouvrent les alternatives VoIP. Non seulement l'entreprise peut
opérer son réseau privé VoIP en extension du réseau RTC (13) opérateur, mais l'opérateur
lui-même ouvre de nouveaux services de transport VoIP qui simplifient le nombre d'accès
locaux à un site et réduit les coûts induits. Le plus souvent les entreprises opérant des
réseaux multi-sites louent une liaison privée pour la voix et une pour la donnée, en
conservant les connexions RTC d'accès local. Les nouvelles offres VoIP opérateurs
permettent, outre les accès RTC locaux, de souscrire uniquement le média VoIP intersites.
La VoIP intègre une gestion de la voix mais également une gestion de la vidéo. En effet,
le réseau VoIP peut accueillir des applications vidéo de type vidéoconférence, vidéo
surveillance, …
2.1.3
Inconvénients
La VoIP implique des contraintes sur les performances du réseau telles que :
le délai de latence (RTD = Round Trip Delay) : c’est le temps que met un paquet IP pour
traverser le réseau. (valeur acceptable : inférieur ou égal à 200 ms)
la gigue (ou Jitter): c’est la variation du délai de latence. (valeur acceptable : inférieur ou
égal à 75 ms)
le taux de perte de paquets : parfois, certains datagrammes (11) UDP sont détruits (surtout
à cause de l’engorgement du réseau). Pour qu’une conversation soit compréhensible, la
dégradation du signal voix ne doit pas dépasser un certain seuil. (valeur acceptable :
inférieur ou égal à 3%)
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 11
Année 2008/2009
d’Asterisk
2.2 Présentation d’
Asterisk
Asterisk est un logiciel qui, installé sur un ordinateur, fait office de PABX.
C’est un logiciel libre (Open Source), publié et créé par Mark Spencer de la société Digium
en 1999. Il tourne sur Linux, BSD et Mac OS X (14).
Asterisk offre tous les services de téléphonie « classiques » d’un PABX ainsi que des
fonctions avancées :
Boîte vocale (avis par courriel de réception d’un message vocal, voyant indicateur de
message en attente…)
Conférence téléphonique
Serveur vocal interactif
Applications CTI (ex : possibilité de composer un numéro de téléphone à partir
du carnet d’adresses d’Outlook)
Visiophonie
Rapport détaillé sur les appels
Asterisk utilise différents protocoles afin de faire de la téléphonie, tels que SIP ou encore
H323 et IAX.
Les protocoles SIP (Session Initiation Protocol) et H323 sont des protocoles qui permettent
d’établir, modifier et terminer des sessions multimédia. Nous utiliserons ici le protocole SIP
que nous décrirons dans la partie suivante.
Le protocole IAX (Inter-Asterisk eXchange) permet la communication entre client (15) et
serveur (16) ainsi qu'entre serveurs Asterisk.
2.2.1
Avantages
Le logiciel Asterisk présente plusieurs avantages. Le premier est avant tout son coût. En
effet, issue du monde libre, Asterisk et l’ensemble des paquets (17) qui lui sont rattachés sont
disponibles en téléchargement gratuit sur Internet.
La configuration d’Asterisk est également un avantage car elle se résume
essentiellement à quelques lignes de commandes à rajouter dans des fichiers, et la
communauté Linuxienne (18) permet grâce aux différents forums de s’approprier assez
rapidement ces commandes et donc cette configuration.
Il permet également de passer sur le réseau RTC (téléphonique commuté) via des cartes
de téléphonie type PCI (19) à incorporer au serveur.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 12
Année 2008/2009
Enfin, Asterisk propose toutes les fonctionnalités ou presque d’un commutateur
PABX (20) classique.
2.2.2
Inconvénients
Asterisk dispose néanmoins d’un inconvénient majeur. En effet, son utilisation est
dédiée uniquement aux plateformes Linux. Aujourd’hui, de plus en plus de serveur dispose de
système Linux tel que Debian (21) ou encore Red Hat (22). Néanmoins, Windows est le plus
souvent présent dans les petites entreprises et cela peut être un frein au développement de
cette solution.
Une solution Asterisk sous Windows est actuellement en cours de développement mais
la version la plus stable reste actuellement celle sous Linux.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 13
Année 2008/2009
2.3 SIP
2.3.1
Présentation
SIP est un protocole normalisé et standardisé par l'IETF (23). Il a été conçu pour
établir, modifier et terminer des sessions multimédia (24). Il se charge de l'authentification et
de la localisation des multiples participants mais également de la négociation sur les types de
média utilisables par les différents participants.
SIP ne transporte pas les données échangées durant la session comme la voix ou la
vidéo. SIP étant indépendant de la transmission des données, tout type de données et de
protocoles peut être utilisé pour cet échange. Cependant le protocole RTP (Real-time
Transport Protocol) assure le plus souvent les sessions audio et vidéo. SIP remplace
progressivement H.323.
2.3.2
Fonctionnement
SIP permet de créer et gérer des sessions entre participants pour échanger des données.
SIP est un protocole ouvert (25) à base de texte ce qui le rapproche du protocole http (26).
SIP
-
utilise
un
ensemble
de
méthodes
qui
lui
sont
propres
telles
que
:
INVITE (première requête envoyée pour débuter un appel)
ACK (Accusé envoyé par le client qui indique la bonne réception de la réponse du
serveur à la requête précédemment transmise).
-
CANCEL (code d'annulation de INVITE).
-
BYE (fin de session d’appel).
De nombreux codes de réponse nous indiquent les différentes étapes suivies par SIP, ces
codes sont regroupés par famille :
- 1XX : nous donnes des informations sur l’action en cours (ex: 100 TRYING, 180
RINGING, 183 SESSION PROGRESS…)
- 2XX : indique la bonne réception et l’acceptation d’une requête (ex: 200 OK)
- 3XX : redirection, une autre action doit être menée afin de valider la requête.
- 4XX : nous indique une erreur du client, la requête contient une syntaxe erronée ou ne peut
pas être traitée par ce serveur (ex: 400 BAD REQUEST, 401 UNAUTHORISED, 404 NOT
FOUND….)
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 14
Année 2008/2009
- 5XX : nous indique une erreur du serveur, ce dernier n’ a pas réussi à traîter une requête
apparemment correcte (ex : 500 INTERNAL SERVER ERROR , 502 BAD GATEWAY…)
- 6XX : échec général, la requête ne peut être traitée par aucun serveur ( ex : 600 BUSY
EVERYWHERE).
Nous pouvons analyser les échanges de SIP via un analyseur de trames (27) comme le logiciel
WireShark.
Le schèma ci-dessous représente un échange lors de l’établissement d’une communication via
le protocole SIP.
Figure 1 : Schéma de l’établissement d’une communication
On peut donc voir sur ce schéma que lorsque l’utilisateur A souhaite établir une
communication avec B, une trame INVITE est envoyée au serveur. Ce dernier renvoie alors
une trame TRYING qui stipule à A qu’il est en train d’essayer d’établir la communication.
Le serveur envoie ensuite une trame INVITE à l’utilisateur B qui lui répond également
à l’aide d’une trame TRYING, puis d’une trame RINGING lui indiquant que le téléphone de
B sonne. Cette trame est transmise à A qui doit entendre la tonalité dans son téléphone
indiquant que celui de B est en train de sonner.
B décroche alors et une trame OK signale au serveur que la requête de communication
avec B a bien été reçu. Cette trame est transmise à A qui envoie alors un ACK (acquittement)
à B pour que la communication puisse s’établir. A et B peuvent alors discuter.
Lorsque A raccroche, une trame BYE est alors envoyée au serveur qui la transfert à B.
Celui-ci répond par une trame OK stipulant qu’il a bien reçu la trame BYE qui termine la
communication.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 15
Année 2008/2009
3 Installation de la plateforme VoIP
3.1 Configuration matérielle
Notre objectif étant de créer une redondance du service Asterisk pour assurer une haute
disponibilité (28), nous avons du mettre en place une plateforme disposant de deux serveurs
Asterisk. Des machines clientes étaient également nécessaires pour pouvoir tester notre
configuration à l’aide de softphones (29). Nous avons choisi de virtualiser notre plateforme à
l’aide du logiciel VMWare (30). Nous avons adopté cette solution pour des raisons
matérielles. En effet, sans la virtualisation, nous aurions du disposer d’au minimum 4
machines physiques, à savoir deux serveurs et deux clients. Nous avons donc utilisé deux
machines physiques équipées de VMWare, puis nous avons créé sur chacune d’elle deux
postes clients Windows XP virtuels et un serveur Linux Debian pour hébergé notre service de
téléphonie.
Nous avons donc appliqué la structure suivante :
Figure 2 : Schéma de notre plateforme d’origine
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 16
Année 2008/2009
d’Asterisk
3.2 Installation et configuration d’
Asterisk
Pour installer Asterisk, nous avons choisi d’utiliser le système Linux Debian que nous
avions eu l’occasion d’exploiter au sein de notre formation. Nous avons donc procédé à une
installation classique de Debian en renseignant différentes informations telles que le nom des
postes, les mots de passe et nom de connexion des utilisateurs...
Une fois notre poste Debian installé et configuré, nous pouvons mettre en place le
service Asterisk. Nous l’installons via la commande « apt-get install asterisk » après avoir
effectué les différentes mises à jour nécessaires.
Asterisk se compose de différents fichiers de configurations qui respectent
l’architecture suivante :
/etc
asterisk
sip.conf
extensions.conf
iax.conf
voicemail.conf
Figure 3 : Schéma de hiérarchisation des fichiers d’Asterisk
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 17
3.2.1
Année 2008/2009
Fichier sip.conf
Pour effectuer notre configuration, nous nous rendons dans le fichier sip.conf qui nous
permet de renseigner les utilisateurs du service Asterisk et leurs caractéristiques. Le fichier
sip.conf se présente de la façon suivante :
[121]
type=friend
username=121
secret=212
host=dynamic
callerid="Maxime"
context=projet
Voici les explications concernant ces différents paramètres :
[121] : numéro utilisé pour appelé l’utilisateur
type : trois types peuvent être choisi pour définir les « droits » de l’utilisateur
- friend : droit d’émettre et de recevoir des appels.
- peer : droit d’émettre uniquement des appels.
- user : droit de recevoir uniquement des appels.
username : nom de l’utilisateur
secret : mot de passe de l’utilisateur
host : deux situations peuvent se présenter
- dynamic : l’utilisateur peut utiliser tous les clients pour se connecter à son compte.
- adresse IP (ex : 192.168.0.3) : l’utilisateur ne pourra qu’utiliser le client à l’adresse
IP indiquée pour se connecter à son compte.
callerid : variable identifiant l’utilisateur. On pourra ensuite réutiliser cet variable dans les
autres fichiers de configuration du serveur. Cela permet aussi d’afficher le nom de la personne
qui appel à l’écran du softphone.
context : définit quel contexte du plan de numérotation est attribué à l’utilisateur
Nous créons donc de la même façon différents utilisateurs, (131, 141, 151) dans le
fichier sip.conf en nous assurant de créer le même fichier sip.conf sur les deux serveurs. En
effet, pour pouvoir mettre en place une solution de redondance, il faut que nos deux serveurs
aient la même configuration de ce fichier pour que les clients puissent se connecter aux deux
serveurs dans l’éventualité ou l’un des deux tomberait, ou encore, si on instaure une
répartition de charge sur les deux serveurs.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 18
3.2.2
Année 2008/2009
Fichier extensions.conf
Une fois le fichier sip.conf configuré correctement, nous nous intéressons au fichier
extensions.conf. Celui-ci permet de définir le plan de numérotation qui sera utilisé par le
serveur pour savoir quelles actions il doit effectuer lorsque qu’un numéro est composé. A la
fin de ce fichier, sur le serveur Asterisk-1, nous rajoutons donc les lignes suivantes :
[projet]
exten => _1XX,1,Dial(SIP/${EXTEN},20)
exten => _1XX,2,HangUp
[projet] représente le contexte auquel appartiennent les clients. C’est dans cette partie
que nous indiquons les actions à effectuer par le serveur lorsqu’un numéro est composé.
exten => _1XX,1,Dial(SIP/${EXTEN}) permet d’indiquer au serveur que lorsque
qu’un client appel avec un numéro commençant par le chiffre « 1 », il doit dans un premier
temps appeler le client SIP dont le numéro vient d’être composé. Ce numéro est ici représenté
par la variable ${EXTEN}. L’option 20 située après le SIP/${EXTEN} signifie au serveur qu’il
doit attendre 20 secondes avant de passer à la règle suivante.
exten => _1XX,4,HangUp permet de terminer correctement la communication une fois
que celle-ci est fini.
Le numéro après la variable _1XX indique l’ordre de priorité des règles c’est-à-dire l’ordre
dans lequel elles doivent être exécutées.
3.2.3
Fichier voicemail.conf
Le fichier voicemail.conf sert à définir un contexte de boite vocale qui sera utilisé par
les clients SIP. Il doit être le même que celui indiqué dans les fichiers sip.conf et
extensions.conf.
On configure notre fichier de la manière suivante :
[projet]
121 => 212,Maxime,121@ServeurMail,,|attach=yes|review=yes
131 => 313,Laura,131@ServeurMail,,|attach=yes|review=yes
141 => 414,Fabien,141@ServeurMail,,|attach=yes|review=yes
151 => 515,Mathieu,151@ServeurMail,,|attach=yes|review=yes
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 19
Année 2008/2009
[projet] représente le contexte utilisé par nos différents clients lorsque l’appel est
redirigé vers leur boite vocale.
121 => 212,Maxime,121@ServeurMail,,|attach=yes|review=yes permet de définir les
différents paramètres lorsque l’on tombe sur la boite vocale d’un client. Ici, il est défini que
pour la boite vocale correspondant au numéro « 121 », on utilise le mot de passe « 212 ». Elle
correspond à l’utilisateur « Maxime ». Un mail sera envoyé, pour signifié qu’un message est
en attente, à l’adresse « 121@ServeurMail ». On a défini deux options. La première,
« |attach=yes », indique que l’on joindra au mail le fichier audio *.wav correspondant au
message enregistré. La seconde option « |review=yes »permet d’autoriser l’utilisateur à
réenregistrer son message si jamais celui-ci veux le faire.
Les autres lignes correspondent aux mêmes options mais pour nos autres utilisateurs.
Ces lignes sont identiques sur nos deux serveurs mais pour pouvoir l’utiliser et qu’il
fonctionne correctement, il faut apporter quelques changements aux fichiers sip.conf et
extensions.conf.
Ainsi, on rajoute la ligne suivante pour chaque utilisateur dans notre fichier sip.conf :
[121]
type=friend
username=121
secret=212
host=dynamic
callerid="Maxime"
context=projet
mailbox=121@projet
mailbox : numéro de la boite vocale dans le contexte projet du fichier voicemail.conf
On rajoute aussi les lignes suivantes dans le fichier extensions.conf :
[projet]
exten => _1XX,2,Voicemail(${EXTEN}@projet)
exten => 888,1,VoicemailMain(@projet)
exten => _1XX,3,Voicemail(${EXTEN}@projet) indique au serveur d’utiliser la
messagerie vocale de l’appelé situé dans le contexte projet du fichier voicemail.conf pour que
l’appelant puisse laisser un message.
exten => 888,1,VoicemailMain(@projet) sert à consulter sa boite vocale. Lorsqu’un
utilisateur compose le « 888 », le serveur l’envoi sur le menu interactif de la boite vocale du
contexte projet défini dans le fichier voicemail.conf.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 20
3.2.4
Année 2008/2009
Fichier iax.conf
iax.conf
Nos deux serveurs sont maintenant configurés mais ils ne communiquent pas entre eux
et donc leurs clients respectifs ne peuvent pas s’appeler. Sans un lien, les clients connectés au
serveur Asterisk-1 ne peuvent appeler que les clients qui sont également connectés à ce
serveur. Il en est de même pour les clients connectés au deuxième serveur. Or, si nous
voulons établir une redondance et du load balancing (31) entre nos deux serveurs, il faut que
les clients puissent s’appeler d’un serveur à l’autre. Nous avons donc utilisé le protocole IAX
pour créer ce lien entre nos deux serveurs.
On définit ce lien dans le fichier iax.conf de la façon suivante :
Sur le serveur Asterisk-1 « clermont » :
[paris]
type=friend
host=192.168.206.131
context=projet
trunk=yes
Sur le serveur Asterisk-2 « paris » :
[clermont]
type=friend
host=192.168.206.130
context=projet
trunk=yes
[paris] / [clermont] indique ici le nom du contexte attribué au serveur avec lequel
nous allons établir le lien. Ce nom peut être différent du nom du contexte qui est créé dans le
fichier extensions.conf ([projet]).
type=friend représente ici le droit d’émettre et de recevoir des appels venant de ce
serveur.
host=192.168.206.131 correspond à l’adresse IP de l’autre serveur avec lequel
Asterisk doit communiquer.
context=projet correspond au nom du contexte du plan de numérotation du deuxième
serveur sur lequel les appels transmis s’appuieront.
trunk=yes signifie que l’on autorise le trunk (32).
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 21
Année 2008/2009
Notre lien IAX est créé, mais cela ne suffit pas aux serveurs pour qu’ils puissent
émettre des appels de l’un vers l’autre. En effet, nous n’avons pas encore modifié le plan de
numérotation d’appels pour que les communications aient lieu entre nos deux serveurs
respectifs. Pour cela, nous retournons dans le fichier extensions.conf et ajoutons les lignes
suivantes :
Sur le serveur Asterisk-1 « clermont » :
[projet]
exten => _1XX,2,Dial(IAX2/paris/${EXTEN},20)
Sur le serveur Asterisk-2 « paris » :
[projet]
exten => _1XX,2,Dial(IAX2/clermont/${EXTEN},20)
exten => _1XX,2,Dial(IAX2/paris/${EXTEN},20) signifie au serveur d’utiliser le lien
IAX avec le deuxième serveur pour contacter le numéro composé. Le serveur utilisera alors
son fichier iax.conf pour récupérer les informations utiles à la transmission de l’appel.
Pour le serveur Asterisk-1, par exemple, il utilisera le contexte « paris » que l’on lui a
indiqué dans le fichier extensions.conf. Il va ensuite utiliser l’adresse 192.168.206.131 défini
dans ce fichier pour contacter le second serveur et va lui transmettre la requête d’appel à
résoudre en utilisant le contexte « projet » de ce dernier.
On peut constater que cette action intervient en second car le serveur doit d’abord
cherché si l’utilisateur appelé est enregistré sur lui-même. Si cet utilisateur est connecté, via
son softphone, sur l’autre serveur, il ne le trouvera pas. Il passera donc à la deuxième règle
qui lui dit d’utiliser son lien IAX.
Ainsi, l’ensemble des utilisateurs seront joignables qu’ils soient enregistrés sur le
serveur Asterisk-1 ou le serveur Asterisk-2.
La configuration de nos serveurs Asterisk est désormais terminée. Avant de pouvoir
lancer le service il faut éditer le fichier /etc/default/asterisk et indiquer l’option
RUNASTERISK=yes.
Nous pouvons maintenant démarrer notre service Asterisk avec la commande
/etc/init.d/asterisk start.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 22
Année 2008/2009
X--Lite
3.3 Mise en place des clients X
Pour tester notre configuration, nous avons dû installer des postes clients avec des
softphones afin que ceux-ci puissent utiliser le service de téléphonie sur IP Asterisk. Nous
avons choisi d’utiliser le système d’exploitation Windows XP pour les postes clients et les
softphones X-Lite qui nous permettent de tester l’ensemble des fonctionnalités que nous
avons mises en place.
Les softphones X-Lite se présentent de la façon suivante :
Figure 4 : Softphone X-Lite
On peut voir que le numéro de l’utilisateur est ici le numéro 121. L’interface ci-dessus
est celle qui s’affiche à l’écran de l’utilisateur. Pour appeler un correspondant, il lui suffit de
cliquer sur les numéros. Pour décrocher, un simple clic sur le téléphone vert suffit.
L’utilisateur a la possibilité d’enregistrer sa conversation via l’option record ou de faire un
« bis » via le bouton Redial. D’autres options sont disponibles mais nous ne les détaillerons
pas car nous avons uniquement besoin de pouvoir appeler un correspondant pour tester notre
configuration.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 23
Année 2008/2009
Pour configurer notre softphone, nous nous rendons dans l’onglet SIP Account
Settings visible ci-dessous :
Figure 5 : Menu de X-Lite
L’écran de configuration suivant apparaît alors :
Figure 6 : Configuration d’un compte SIP
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 24
Année 2008/2009
Via cet écran de configuration, nous renseignons le numéro de l’utilisateur, son nom,
son mot de passe pour accéder à son compte SIP, et enfin, dans le champ « Domain » nous
indiquons l’adresse IP du serveur auquel il est connecté : ici 192.168.206.130 à savoir
Asterisk-1.
Une fois connectés, nos clients peuvent communiquer d’un serveur à l’autre grâce à
notre lien IAX.
Notre plateforme est donc en place, nous pouvons maintenant passer à l’étude de la
solution de haute disponibilité.
4 La haute disponibilité
4.1 Présentation
On appelle "haute disponibilité" (en anglais "high availability") toutes les dispositions
visant à garantir la disponibilité d'un service, c'est-à-dire assurer le fonctionnement correct et
continu d'un service. Le terme "disponibilité" désigne la probabilité qu'un service soit en bon
état de fonctionnement à un instant donné.
La disponibilité est aujourd'hui un enjeu important des infrastructures informatiques.
On estime aujourd'hui que la non-disponibilité d'un service informatique peut avoir des coûts
se chiffrant en millions, particulièrement dans le domaine de l'industrie où l'arrêt d'une chaîne
de production peut avoir un effet dévastateur.
La haute disponibilité est donc un sujet d’actualité et elle peut être mise en place par
différents moyens :
•
•
•
•
•
la redondance des équipements ;
la sécurisation des espaces de stockage ;
l'équilibrage de charge et la répartition de charge ;
l'emploi des technologies de réplication de bloc et de surveillance;
la sécurisation des sauvegardes : externalisation, stockage sur site tiers.
L’ensemble de ces moyens permettent de mettre en place une solution fiable et disponible
pour n’importe quel système. Néanmoins, pour des raisons matérielles et de délais, nous n’en
avons sélectionné que deux qui permettraient à notre système d’être suffisamment fiable, à
savoir, la redondance de serveur à laquelle nous avons ajouté du Fail Over (33), et la
répartition de charge.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 25
Année 2008/2009
Fail--Over avec Heartbeat
4.2 Le Fail
4.2.1
Présentation
Le Fail-over se traduit en français par « passer outre la panne ». Ce procédé a la
capacité de faire basculer un équipement réseau automatiquement vers un chemin réseau (34)
alternatif (autre équipement).
Cette capacité existe pour tout type d'équipements réseau, du serveur au routeur (35)
en passant par les pare-feu (36) et les commutateurs réseau (switch). Le basculement
intervient généralement sans action humaine et même bien souvent sans aucun message
d'alerte. Le basculement est conçu pour être totalement transparent.
Les concepteurs de systèmes prévoient généralement cette possibilité dans les serveurs
ou les réseaux qui nécessitent une disponibilité permanente (HA=High Availability). Dans
certains cas, le basculement automatique n'est pas souhaité et le basculement requiert une
action humaine ; c'est ce que l'on appelle automatisation avec approbation humaine.
Il existe deux modes principaux de basculement :
• actif/actif qui s'apparente plus à de l'équilibrage de charge (ou load-balancing) ;
et le mode classique couramment répandu,
• actif/passif où l'équipement secondaire (passif) est en mode veille tant que
l'équipement primaire (actif) ne rencontre aucun problème.
Pour effectuer notre fail-over, nous avons étudié le programme Heartbeat qui est un
système de gestion de la haute disponibilité sous Linux, FreeBSD, OpenBSD, Solaris (37) et
MacOS X.
Heartbeat met en place un système classique de clustering (38) en haute disponibilité basé
sur des battements de cœur. Il exécute des scripts d'initialisations (39) lorsqu’une machine
tombe (plus d'entente du battement de cœur) ou est à nouveau disponible (battement de cœur
retrouvé).
Heartbeat fonctionne à l’aide d’une adresse IP virtuelle qu’il attribue à son cluster. Ce
dernier se compose de deux machines, en l’occurrence nos deux serveurs Asterisk.
Le serveur Asterisk-1 sera alors considéré comme Actif et le Asterisk-2 comme Passif.
L’adresse IP virtuelle sera physiquement visible seulement sur le serveur actif (Asterisk-1) et
nos clients interagiront donc uniquement avec ce même serveur. Néanmoins, si ce serveur
devait ne plus fonctionner, Heartbeat redirigera alors l’IP virtuelle sur le serveur passif
(Asterisk-2) qui assurera la continuité de service. Une fois que le serveur Asterisk-1 sera
remis en service, Heartbeat lui réattribuera automatiquement l’adresse IP virtuelle et il
redeviendra le serveur actif. Les serveurs seront alors considérés comme des « nœuds »du
cluster. Nos clients Asterisk auront alors comme adresse de référence du domaine l’IP
virtuelle qui sera 192.168.206.150 et non pas une des deux adresses IP de serveur.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 26
Année 2008/2009
Le schéma ci-dessous illustre cette configuration :
Figure 7 : Schéma de notre plateforme avec Heartbeat
Ici nous pouvons constater que notre lien Heartbeat est bien monté entre nos deux
serveurs, mais seul le premier dispose de l’adresse IP virtuelle. Nos clients utilisent donc tous
ce dernier pour envoyer leurs requêtes SIP.
Figure 8 : Schéma de la plateforme quand un serveur tombe en panne
Ce schéma nous montre que si le serveur Asterisk-1 tombe, le second récupère
l’adresse IP virtuelle et les requêtes des clients lui sont alors transmises. Lorsque le serveur
Asterisk-1 sera de nouveau en service, il reprendra automatiquement l’adresse IP virtuelle et
nous retournerons à la configuration illustrée sur le schéma précédent.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 27
4.2.2
Année 2008/2009
Configuration du cluster Heartbeat
Nous installons le paquet Heartbeat via la commande « apt-get install heartbeat ».
La configuration d’Heartbeat s’effectue dans différents fichiers que nous devons tout d’abord
créer. Cette configuration sera identique sur les deux serveurs.
Le premier fichier de configuration à créer est le fichier ha.cf à l'emplacement
/etc/ha.d/. Ce fichier donne les caractéristiques du cluster monté par Heartbeat :
logfacility daemon
node asterisk-1
node asterisk-2
keepalive 1
deadtime 10
bcast eth0
auto_failback on
logfacility daemon signifie que les logs seront envoyé au syslog dans la catégorie
daemon.
node asterisk-1 / node asterisk-2 est la liste des membres du cluster Heartbeat.
keepalive 1 définit la vitesse de contrôle des nœuds entre eux.
deadtime 10 est le temps avant de déclarer qu'un des nœuds est en panne.
bcast eth0 définit l’interface réseau à utiliser pour les trames de broadcast de Heartbeat
auto_failback on définit si le nœud maître du cluster reprend son rôle lorsqu’il est
redétecté.
Nous créons ensuite le fichier haresources au même emplacement. Ce fichier indique
au service Heartbeat quel est le serveur qui sera actif pour le cluster.
asterisk-1 IPaddr2::192.168.206.150/24/eth0
On indique ici le nom du serveur actif, et l’adresse IP virtuelle qui lui sera attribuée sur son
interface (carte réseau), ici eth0.
Enfin, le fichier authkeys sera nécessaire pour sécuriser le service. En effet, le
authkeys contient les informations nécessaires à l'authentification des noeuds du cluster entre
eux, pour maximiser la sécurité. Chaque serveur dispose du même fichier authkeys qui
contient la « clé secrète ». Voici sa configuration :
auth 1
1 sha1 password
Ces lignes nous permettent d’indiquer que l’on utilise l’authentification numéro « 1 » qui
correspond à l’utilisation d’une clé secrète (« password ») qui sera cryptée en sha1.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 28
4.2.3
Année 2008/2009
Etat du système
Notre redondance de serveurs est donc mise en place et nous permet de gérer la haute
disponibilité du service en cas de panne d’un serveur.
Néanmoins, étant donné que nous avons dans cette configuration un serveur actif (qui
exécute le service asterisk) et un passif (qui prend la relève en cas de panne du premier
seulement) , nous n’utilisons pas toutes les ressources des serveurs mises à notre disposition.
Il faut donc que nous mettions en place un système de répartition de charge entre nos
deux serveurs qui permettra de disposer de deux fois plus de capacité pour gérer notre service
Asterisk qu’actuellement en exploitant les deux serveurs en même temps.
4.3 Répartition de charge avec IPVS et ldirectord
4.3.1
Ipvs
Ce paquet va gérer l’équilibrage de charge entre nos deux serveurs via la commande
« ipvsadm ». Il redirige les paquets entrants vers d'autres serveurs en utilisant divers
algorithmes (41) de répartition de charge.
IPVS propose 10 algorithmes de répartition dont les principaux sont :
•
•
•
•
rr (Round-Robin) : les requêtes sont transmises à tour de rôle sur chaque noeud du
cluster.
wrr (Weighted Round Robin) : identique au précédent, mais peut gérer une
pondération associée à chaque noeud, l'objectif étant de charger les machines
proportionnellement à leur puissance.
lc (Least Connection) : IPVS transmet la requête au serveur sur lequel il y a le moins
de connexions actives.
wlc (Weighted Least-Connection) : il agit comme lc, néanmoins on peut ajouter un
« poid » à un serveur en fonction de sa puissance.
Pour des facilités de démonstration lors de nos analyses de trames, nous avons choisi
d’utiliser l’algorithme de répartition rr (Round-Robin). En effet, cet algortihme transmettant
les requêtes à chacun des serveurs à tour de rôle, il est plus facile d’en analyser les effets avec
un analyseur de trame. Néanmoins, dans un contexte d’entreprise, l’algorithme lc ou wlc
serait préférable car il va répartir les paquets en fonction de la charge du serveur.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 29
Année 2008/2009
4.3.1.1 Configuration
La configuration d’IPVS s’effectue à l’aide de ligne de commande. Nous allons tout
d’abord voir comment créer un service de redirection des requêtes. Pour cela, nous utilisons la
commande suivante :
ipvsadm -A -u 192.168.206.150:5060 -s rr
L’option –A indique que nous allons créer un service de redirection, le –u signale que
ce service va utiliser le protocole UDP.
L’adresse IP qui suit est notre adresse IP virtuelle, nous indiquons donc que toutes les
requêtes qui auront pour destination cette adresse IP virtuelle sur le port (42) 5060 qui est le
port sip, seront redirigées par IPVS.
Enfin, l’option –s indique l’algorithme de répartition que nous allons utiliser, ici rr
pour Round-Robin.
Puis nous utilisons les lignes de commande suivantes pour indiquer à quel serveur
physique il doit rediriger les requêtes :
ipvsadm -a -u 192.168.206.150:5060 -r 192.168.206.130:5060 –g
ipvsadm -a -u 192.168.206.150:5060 -r 192.168.206.131:5060 –g
Les lignes de commande ci-dessus sont sensiblement les deux mêmes. Nous
retrouvons ici différentes options.
Le –a indique au service IPVS que nous ajoutons un serveur, l’option –u signale
comme précédemment que le protocole utilisé va être de l’udp.
Nous signalons ensuite l’adresse IP virtuelle et le port à partir desquels seront
redirigées les requêtes. L’option –r permet d’ajouter un serveur « réel » à la règle. Nous
indiquons ensuite l’adresse IP d’un de nos deux serveurs physiques et le port SIP.
Enfin, nous terminons par l’option –g qui indique que le serveur que nous avons
ajouté, répondra directement au client sans passer par le répartiteur de charge pour ne pas
surcharger le trafic réseau.
Au vu de ces nouvelles règles, lorsque nos clients enverront une requête SIP à notre IP
virtuelle, le répartiteur enverra ces requêtes à tour de rôle sur chacun de nos serveurs. Ces
derniers répondront alors directement au client, sans repasser par le répartiteur de charge.
Pour vérifier notre table de répartition, nous utilisons la commande :
ipvsadm –L
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 30
4.3.1.2
Année 2008/2009
Schéma explicatif
Le schèma ci-dessous illustre la répartition à l’aide de l’algorithme Round-Robin que
nous avons mis en place.
Figure 9 : Schéma explicatif de la répartition de charge
Pour simplifier le schéma et sa compréhension, nous ne prenons que deux postes
clients. On peut donc voir que lorsque le client 1 émet une trame en premier, le serveur
Asterisk-1, qui est également le répartiteur de charge, la redirige sur lui-même et envoie un
accusé de réception au client 1 pour lui signaler qu’il a bien reçu sa trame.
La deuxième requête qu’il reçoit est émise par le client 2. En respectant son
algorithme de répartition Round-Robin, il transfert cette deuxième requête au serveur
Asterisk-2. Ce dernier répond directement au client 2, sans passer par le répartiteur de charge.
Notre répartiteur de charge est donc mis en place et permet d’exploiter au mieux les
capacités de nos deux serveurs Asterisk. Néanmoins, si le service Asterisk sur l’un de nos
deux serveurs devait ne plus fonctionner, notre répartiteur ne s’en rendrait pas compte et
continuerait d’envoyer les requêtes aux deux. Nous devons donc gérer cette situation en
ajoutant un paquet supplémentaire qui va surveiller le service Asterisk et indiquer à IPVS si
ce-dernier ne fonctionne plus.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 31
4.3.2
Année 2008/2009
Ldirectord
Pour éviter à l'équilibreur de charge d'aiguiller des requêtes vers un nœud (un serveur)
défaillant, nous utilisons le paquet “ldirectord”. Ecrit en Perl, ce programme a pour rôle la
surveillance applicative des noeuds et modifie, en temps réel, les règles d'équilibrage de
charge.
En effet, si le service Asterisk du serveur 1 ne tourne plus, ldirectord va modifier la
table de répartition d’IPVS et indiquer à ce dernier qu’il doit rediriger toutes les requêtes SIP
vers le serveur 2. Pour cela, nous effaçons la configuration faite statiquement dans IPVS.
4.3.2.1
Configuration
La configuration de ldirectord est identique sur les deux serveurs. Nous devons avant
tout créer le fichier ldirectord.cf à l'emplacement /etc/ha.d/. Voici la configuration de ce
fichier :
checktimeout=10
checkinterval=10
emailalert="root@localdomain"
emailalertfreq=0
quiescent=no
virtual=192.168.206.150:5060
real=192.168.206.130:5060 gate
real=192.168.206.131:5060 gate
checktype=negotiate
service=sip
checkport=5060
login="121"
passwd="212"
scheduler=rr
protocol=udp
checktimeout=10 indique le temps d’attente d’une réponse du serveur avant que le
programme ne le déclare "mort".
checkinterval=10 indique le temps écoulé entre deux tests effectués par ldirectord
pour vérifier qu’Asterisk fonctionne correctement sur les deux serveurs.
emailalert="root@localdomain" définit l’adresse mail sur laquelle envoyer les alertes.
emailalertfreq=0 définit la fréquence des alertes. Le « 0 » indique ici que nous
souhaitons n’avoir qu’une seule alerte par problème afin d’éviter de surcharger notre boite
mail.
quiescent=no indique que nous souhaitons supprimer le serveur « mort » de la table
ipvsadm pour que celui–ci ne lui envoie plus de requête
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 32
Année 2008/2009
virtual=192.168.206.150:5060 indique l’adresse IP virtuelle du cluster et du port dont
il faut répartir la charge.
real=192.168.206.130:5060 gate / real=192.168.206.131:5060 gate définissent les
serveurs réels vers lesquels la charge doit être redirigée. Le mot-clé « gate » signifie que les
serveurs doivent répondre directement au client.
checktype=negotiate définit la méthode à utiliser afin de tester le bon fonctionnement
de notre service Asterisk.
service=sip indique que nous utilisons le service SIP.
checkport=5060 indique que la surveillance doit se faire sur le port 5060.
login="121" / passwd="212" définit les informations d’identification à utiliser afin de
vérifier le bon fonctionnement du protocole.
scheduler=rr signifie que nous utilisons l’algorithme de répartition Round-Robin.
protocol=udp indique que les requêtes SIP envoyées s’appuieront sur de l’UDP.
Nous avons donc actuellement un répartiteur de charge géré par ldirectord sur chaque
serveur Asterisk. Néanmoins, nous n’avons pas besoin que ce service soit actif sur les deux
serveurs, un seul nous suffit pour gérer la répartition et l’autre peut donc rester passif sur le
deuxième serveur dans l’éventualité ou le premier « tomberait ».
Nous devons donc enlever ldirectord du démarrage automatique (43) sur les deux
serveurs pour le faire interagir avec Heartbeat.
En effet, Heartbeat gérant le fail-over, il est actif sur le premier serveur et est en
« stand-bye » sur le deuxième serveur.
Il ne deviendra actif sur le deuxième serveur que si le premier « tombe ». Nous lui
indiquons donc qu’en cas de panne du premier serveur, il récupérera l’adresse IP virtuelle et
démarrera le service ldirectord.
Pour enlevez ldirectord du démarrage "standalone" nous tapons la commande
suivante :
update-rc.d -f ldirectord remove.
Nous devons également indiquer à Heartbeat qu’il doit lancer le service ldirectord.
Pour cela nous nous rendons dans le fichier /etc/ha.d/ et nous ajoutons le service ldirectord à
la ligne suivante :
asterisk-1 IPaddr2::192.168.206.150/24/eth0 ldirectord
Nous avons donc une architecture qui gère la répartition de la charge et surveille le
bon fonctionnement du service Asterisk pour pouvoir modifier ces règles de répartitions en
cas de défaillance de ce dernier.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 33
Année 2008/2009
4.3.2.2 Schéma explicatif
Le schéma ci-dessous illustre le fonctionnement de ldirectord et d’IPVS.
Figure 10 : Schéma de la plateforme avec IPVS et ldirectord
Dans la configuration ci-dessus, nous avons un échange qui fonctionne correctement
avec de la répartition de charge entre nos deux serveurs. On obtient la table de répartition
suivante :
Figure 11 : Table de répartition de charge normal
On constate dans cette table que l’on retrouve bien la règle de redirection que l’on a
définit dans ldirectord avec les serveurs qui lui sont associés. On peut aussi voir le nombre de
connexions établit sur chaque serveur.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 34
Année 2008/2009
Le schéma ci-dessous illustre ce qu’il se passe si le service Asterisk ne fonctionne plus
sur le serveur Asterisk-1.
Figure 12 : Schéma de la plateforme lorsque Asterisk tombe en panne
Le programme ldirectord met alors la table du répartiteur de charge IPVS à jour, et lui
indique qu’il doit rediriger toutes les requêtes sur le deuxième serveur. On obtient alors la
table suivante :
Figure 13 : Table de répartition de charge modifié par ldirectord
Enfin, si le service Heartbeat tombe sur le serveur 1, il est remonté sur le serveur 2 et
lance le ldirectord en même temps. De ce fait, le deuxième serveur récupère à la fois l’adresse
IP virtuelle et le répartiteur de charge.
Figure 14 : Schéma de la plateforme lorsque Heartbeat tombe en panne
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 35
Année 2008/2009
4.4 Scripts d’amélioration
Notre plateforme est en place, néanmoins nous avons pu soulever différents problèmes.
En effet, notre adresse IP virtuelle qui gère notre cluster, n’est physiquement présente
que sur le serveur 1, cela ne nous posait aucun problème lors de notre première configuration
avec une architecture ne disposant que d’un serveur actif et un passif, néanmoins, avec la
répartition de la charge, les deux serveurs sont amenés à répondre à des requêtes ayant pour
destination cette adresse IP virtuelle.
Nous devons donc créer un script qui permettra au deuxième serveur de répondre aux
requêtes qui lui sont transmises et qui ont pour destinataire l’adresse IP virtuelle. Nous avons
nommé ce script ipv.sh.
Nous avons également constaté que notre service de redondance n’était pas optimisé
pour le service ldirectord. En effet, lorsque le serveur 1 ou le service Heartbeat tombe, celui-ci
lance correctement le service ldirectord en récupérant l’adresse IP virtuelle grâce aux
paramètres que nous lui avons indiqué précédemment. Néanmoins, si le service ldirectord ne
fonctionne plus sur le serveur 1 mais que Heartbeat lui continue de tourner, il ne récupère pas
l’adresse IP virtuelle sur le serveur 2 et ne lance donc pas le service ldirectord.
Notre second script, que nous avons nommé test_ldirectord.sh consistera donc à
« tuer » le service Heartbeat sur le premier serveur si ldirectord venait à ne plus fonctionner
sur ce dernier. De cette façon, le serveur 2 récupérera l’adresse IP virtuelle et Heartbeat
lancera le service ldirectord sur ce dernier.
4.5 Ipv.sh
L’objectif est de permettre au serveur 2 de répondre aux requêtes ayant pour
destinataire l’adresse IP virtuelle, nous devons nous assurer qu’il ne réponde qu’aux requêtes
SIP à destination du service Asterisk, et pas aux requêtes ARP qui sont émises par les clients.
En effet, seul le serveur 1, qui dispose physiquement de l’adresse IP virtuelle, doit
répondre aux requêtes ARP des clients car c’est lui qui redirige les requêtes sur les différents
Asterisk.
Nous allons donc indiquer au serveur qu’il ne doit répondre aux requêtes ARP que si
celle-ci sont à destination de son adresse IP primaire (celle qui est paramétrée physiquement
sur sa carte réseau).
Nous créons le script ipv.sh à l’emplacement /etc/init.d et nous le configurons comme
suit :
#!/bin/bash
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
ip addr add 192.168.206.150/32 dev lo
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 36
Année 2008/2009
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore permet de signaler que les requêtes
ARP ayant pour destination une adresse IP qui ne serait pas primaire au système seront
ignorées.
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce permet de définir que si l’adresse
IP de destination de la requête ARP est une adresse primaire du système, ce dernier va lui
répondre.
ip addr add 192.168.206.150/32 dev lo indique l’adresse IP virtuelle comme étant
présente sur l’interface de loopback du système mais non primaire afin que les requêtes SIP à
destination de l’adresse virtuelle puissent être acceptées par ce serveur.
Puis nous exécutons la commande suivante pour indiquer au système qu’il doit lancer
le script à chaque démarrage de l’ordinateur :
update-rc.d ipv.sh defaults
4.6 test_ldirectord.sh
Afin d’avoir une parfaite redondance de l’ensemble de nos services, nous allons créer
un script qui permettra de gérer les éventuels disfonctionnements du service ldirectord.
Ce script a pour but de tester le fonctionnement du service ldirectord, et dans l’éventualité ou
ce dernier tomberait, de stopper le service Heartbeat sur le serveur 1 afin qu’il se lance sur le
serveur 2 et qu’il démarre ldirectord sur ce dernier.
Sur le serveur Asterisk-1 :
#!/bin/bash
i=0
while [ $i == 0 ]; do
testldirectord=`ipvsadm -L | wc -l`
testheartbeat=`/etc/init.d/heartbeat status | grep running | wc -l`
if [ "$testldirectord" -le 4 ]; then
if [ "$testheartbeat" == 1 ]; then
/etc/init.d/ldirectord restart
if [ "$testldirectord" -eq 4 ]; then
/etc/init.d/heartbeat stop
fi
fi
fi
sleep 10
done
Dans ce script, nous créons une boucle qui va tourner à l’infini car il s’effectue tant
que la valeur i est égale à 0, or sur la ligne précédente nous avons initialisé la valeur de i à 0.
Ce script va donc s’exécuter à l’infini toutes les 10 secondes grâce à la ligne sleep 10 qui lui
indique qu’il doit « dormir » pendant 10 secondes avant de se relancer.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 37
Année 2008/2009
La ligne suivante nous permet de tester si le service ldirectord tourne.
On affecte ici une variable $testldirectord dans laquelle on effectue la commande
ipvsadm -L | wc -l. Cette commande nous permet de voir si la table de répartition est remplie
ou non et donc de connaitre ainsi le statut du service. La commande va compter le nombre de
lignes du tableau et va renvoyer le nombre « 5 » ou « 6 » si le service fonctionne
correctement, sinon on obtiendra la valeur « 1, 2, 3 ou 4 ».
La ligne suivante permet d’afficher l’état du status de Heartbeat, de chercher la chaîne
de caractère « running » et de compter le nombre de lignes renvoyées (« 0 » ou « 1 »).
Nous testons ensuite les valeurs retournées par les variables :
fi
fi
fi
Ces test nous permettent de tenter un redémarrage du service ldirectord ou un arrêt de
Heartbeat selon les valeurs renvoyées par les différents tests. En effet, dans le cas où le
service ldirectord s’est arrêté (valeur 3) ou ne redirige plus aucune requêtes (valeur 4) mais
que le service Heartbeat est toujours en marche (valeur 1), le fail-over n’aura pas lieu. On
exécute donc un redémarrage du service ldirectord et on relance un test pour savoir si cela a
fonctionné. Dans le cas contraire, on arrête le service Heartbeat.
Sur le serveur Asterisk 2, nous créons également un script sur le même modèle qui
nous permet de tester le bon fonctionnement du service Heartbeat.
#!/bin/bash
i=0
while [ $i == 0 ]; do
/etc/init.d/heartbeat restart
fi
sleep 10
done
Notre architecture est donc entièrement redondante et effectue du load-balancing entre
nos deux serveurs. Nous disposons donc d’une solution de clustering assurant la haute
disponibilité de notre service Asterisk.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 38
Année 2008/2009
Schééma d’une plateforme optimisée
4.7 Sch
Notre solution nous permet d’assurer une continuité de service correcte face à
d’éventuelles pannes ou erreurs système.
Néanmoins, nous effectuons ici toutes nos opérations sur nos propres serveurs Asterisk
ce qui peut engendrer une surcharge sur ceux-ci dans le cas d’une forte activité. Pour des
raisons matérielles évoquées précédemment, nous n’avons pu exploiter d’autres postes afin de
réaliser une structure au sein de laquelle les serveurs Asterisk ne géreraient pas d’autres
services que la téléphonie IP. En effet, une solution optimale inclurait deux serveurs
supplémentaires qui géreraient la répartition de charge et qui seraient tous deux reliés via un
Heartbeat pour gérer le fail-over.
Le schéma ci-dessous illustre cette solution :
Figure 15 : Schéma de notre plateforme finale
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 39
Année 2008/2009
5 Test de notre solution
Maintenant que notre configuration est terminée sur chacun de nos deux serveurs ainsi
que sur nos deux clients, il faut mettre en place un protocole de test de notre solution afin de
la valider.
Au niveau de notre script ipv.sh :
Pour que notre solution fonctionne correctement, il faut avant tout que le second
serveur prenne bien son adresse IP « cachée » et ses paramètres ARP au démarrage de la
machine. Pour vérifier cela, on redémarre notre machine et on effectue la commande
suivante : « ip addr show »
Voici le résultat de cette commande :
Figure 17 : Adresse virtuelle « cachée » sur Asterisk-2
Au niveau de la redondance des services :
Nous avons déjà vu précédemment que lorsque le service Asterisk tombe en panne sur
l’un des serveurs, le programme ldirectord le détecte et modifie la table de répartition en
conséquence. Nous ne reverrons donc pas ce point ici.
Nous allons désormais nous intéresser au programme Heartbeat. Pour vérifier son bon
fonctionnement, nous allons le stopper sur le serveur Asterisk-1 et constater ce qu’il se passe.
On observe ainsi que le serveur Asterisk-2 récupère bien l’adresse IP virtuelle :
Figure 17 : Adresse IP virtuelle récupérée sur Asterisk-2
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 40
Année 2008/2009
On constate aussi que ce même serveur a bien démarré son service de répartition ldirectord :
Figure 18 : Statut du service ldirectord
Lorsque Heartbeat redémarre sur le serveur Asterisk-1, le serveur Asterisk-2 stoppe
son service de répartition et « rend » l’adresse IP virtuelle au serveur 1.
Regardons maintenant ce qu’il se passe au niveau de notre système lorsque nous
arrêtons ldirectord sur la machine Asterisk-1. Ce test nous permettra de valider le bon
fonctionnement de notre script test_ldirectord.sh.
Voici ce que l’on peut constater :
Figure 19 : Relance de ldirectord par le script test_ldirectord.sh
On remarque que le script a détecté l’arrêt de ldirectord et a réussi à le relancer avec
succès. Notre service est donc toujours disponible. Dans le cas où le service se relance
correctement, on analyse le tableau de répartition de charge afin de savoir s’il contient des
données. S’il n’en contient pas, cela signifie qu’il ne peut donc pas répartir correctement la
charge. On obtient alors les lignes suivantes :
Figure 20 : Arrêt de Heartbeat par le script test_ldirectord.sh
Au niveau de la répartition de charge :
Afin de constater les effets de la répartition de charge, nous utiliserons en plus de la
commande « ipvsadm –L » le logiciel d’analyse de trame Wireshark que nous avons
précédemment installé sur nos postes clients.
Ainsi on constate qu’à chaque nouvelle tentative de connexion d’un client, le
répartiteur de charge redirige les requêtes de connexion SIP à tour de rôle sur chacun des deux
serveurs Asterisk.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 41
Année 2008/2009
On constate ici qu’une connexion est déjà active sur le serveur Asterisk-2.
Figure 21 : Table de répartition
Connectons-nous maintenant avec un deuxième client X-Lite afin d’analyser les
trames envoyées. On obtient la capture suivante :
Figure 22 : Capture de trames SIP
On constate que le client envoie une trame REGISTER à l’adresse IP virtuelle
192.168.206.150 mais que c’est notre serveur Asterisk-1 qui lui répond avec une trame
TRYING puis une trame OK pour valider son enregistrement auprès de lui.
On constate désormais que deux connexions sont actives et chacune sur un serveur
différent.
Figure 23 : Nouvelle table de répartition
On peut donc affirmer maintenant que nous disposons d’une infrastructure hautementdisponible qui permet en plus de répartir équitablement les différents clients sur nos différents
serveurs Asterisk.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 42
Année 2008/2009
Conclusion
Au cours de notre licence professionnelle, nous avions pour projet de réaliser une
interconnexion de serveurs Asterisk sous la tutelle de Mr Toussaint. Ce projet avait une durée
de 150 heures.
Nous avons dans un premier temps effectué une approche théorique de la téléphonie
sur IP et du logiciel Asterisk afin de nous familiariser avec le protocole SIP. Grâce à cette
approche, nous avons pu réaliser une plateforme de test comportant deux serveurs Asterisk
auxquels des clients SIP pouvaient se connecter afin d’établir des communications entre eux.
Ensuite, nous avons effectué des recherches sur les différentes technologies qui nous
permettraient de réaliser une redondance du service Asterisk et d’instaurer de la haute
disponibilité ainsi que de la répartition de charge. Nous avons cherché à établir une
architecture fiable afin de pouvoir l’adapter dans un contexte d’entreprise avec une utilisation
intense et continue du service de téléphonie sur IP.
Enfin, après avoir déployé notre solution, nous avons effectué différents test qui nous
ont permis de valider sa fiabilité. Nous n’avons néanmoins pas eu l’occasion de tester les
effets lié à une surcharge d’un serveur avec l’outil SIPp que nous n’avons pas eu le temps de
nous approprier dans les délais imposés par le projet.
Nous avons pu rencontrer des difficultés lors du respect des délais. En effet, nos
recherches sur les technologies à utiliser et leur appropriation nous a pris plus de temps que
nous n’en avions prévue. De plus, nous avons pu constater différentes incohérences dans
notre architecture ainsi que des erreurs de configuration qu’il nous a fallu résoudre.
Néanmoins, nous avons pu réaliser ce projet dans le temps imparti et nous sommes
actuellement capables de déployer une solution de haute disponibilité du système Asterisk
totalement redondante. Cette solution pourrait être exploitée dans le monde de l’entreprise car
elle est fiable et peut parer à de nombreuses pannes.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 43
Année 2008/2009
English Summary
As part of our degree in Network Engineering and Telecommunications, we had to
realise a project. Our project team was composed by two students : Laura Redondo and
Maxime Boscia. We chose the Voice Over IP project so our tutor was the Headmaster of the
Department, Mr. Joël Toussaint.
Our project involved installing and using an Open Source software called Asterisk to
study how it reacts in case of fault and what solutions could we bring at this matter. Asterisk
is often used in companies to save money because it permits to cross free internal phone calls.
Furthermore, it provides numerous services as conference for example.
In first, we had to search information about Asterisk and VoIP on the web and in
books because this project requires specifical knowledges. Then we installed Asterisk on two
computers which had a Debian operating system. We had configure several basic options of
Asterisk and we had test if it worked with software telephony client, also called softphone.
Then, we connected two Asterisk servers with redundancy and load-balancing to
permit a high availability of Asterisk services. It means we had a continuity of the telephony
services if one of the Asterisk servers break down.
The main difficulty was to search an learn information about technologies of
redundancy and load-balancing that we had never seen. Furthermore, we wasted a lot of time
at the begining of the project because we didn’t succeed to install the operating system on the
computers which be at our disposition. But we resolve all of these problems.
This project was the opportunity for us to deepen our knowledge in VoIP. In fact, we
began to study Asterisk software during Mr. Toussaint’s lessons but it was more nonspecialized. This project allowed us to improve our technicals skills on Linux operating
system and redundancy technologies.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 44
Année 2008/2009
Glossaire
1 - téléphonie sur IP : Service de communication vocale utilisant le protocole de
télécommunications créé pour Internet (IP). La voix est numérisée et envoyée dans le réseau
Internet comme n'importe quelle donnée.
2 - protocole TCP/IP : Suite de protocoles. Le sigle TCP/IP signifie «Transmission Control
Protocol/Internet Protocol». TCP/IP représente d'une certaine façon l'ensemble des règles de
communication sur internet et se base sur la notion adressage IP, c'est-à-dire le fait de fournir
une adresse IP à chaque machine du réseau afin de pouvoir acheminer des paquets de données
3 - signal analogique : Un signal analogique est un signal continu. Il change de valeur en
passant par toutes les valeurs intermédiaires. L’inconvénient majeur d’un signal analogique
réside dans le fait qu’il est techniquement difficile de détecter et encore moins corriger les
détériorations du signal dû soit à l’affaiblissement de celui-ci, soit à des parasites.
4 - numériser : La transformation d'un signal analogique en signal numériqueLa numérisation
comporte deux activités parallèles : l'échantillonnage (en anglais sampling) et la
quantification. L'échantillonnage consiste à prélever périodiquement des échantillons d'un
signal analogique. La quantification consiste à affecter une valeur numérique à chaque
échantillon prélevé.
5 - codecs : Algorithme permettant de compresser et de décompresser des fichiers audio et
vidéo sans perdre une quantité considérable d'informations.
6 - compresser : Procédé permettant de réduire le volume (en bits) ou le débit (en bit/s) des
données numérisées (parole, images, textes, ...).
7 - commutation de circuits : Un réseau est constitué de plusieurs noeuds interconnectés par
des lignes de communication. Il existe plusieurs méthodes permettant de transférer une
données d'un noeud émetteur à un noeud dit récepteur. La commutation de circuits consiste à
mettre en relation successivement les différents noeuds intermédiaires afin de propager la
donnée du noeud émetteur au noeud récepteur. Dans ce type de scénario, la ligne de
communication peut être assimilé à un tuyau dédié à la communication.
8 - commutation de paquets : Elle consiste à segmenter l'information en paquets de données,
transmis indépendamment par les nœuds intermédiaires et ré assemblés au niveau du
destinataire.
9 - UDP : Protocole de transport de l'information non orienté connexion de la couche
transport du modèle TCP/IP. Ce protocole est très simple étant donné qu'il ne fournit pas de
contrôle d'erreurs (il n'est pas orienté connexion...).
10 - TCP : Protocole de Contrôle de Transmission) est un des principaux protocoles de la
couche transport du modèle TCP/IP. Il permet, au niveau des applications, de gérer les
données en provenance (ou à destination) de la couche inférieure du modèle (c'est-à-dire le
protocole IP).
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 45
Année 2008/2009
11 - datagrammes : Les datagrammes sont une représentation structurée de l'ensemble des
données constituant un paquet d'information pour un protocole donné. Par exemple, on
rencontre très fréquemment des datagrammes pour les paquets du protocole IP, protocole de
couche internet du modèle TCP/IP
12 - WAN : Réseau informatique couvrant une grande zone géographique, typiquement à
l'échelle d'un pays, d'un continent, voire de la planète entière. Le plus grand WAN est le
réseau Internet.
13 - réseau RTC : Le réseau téléphonique commuté (ou RTC) est le réseau du téléphone (fixe
et mobile), dans lequel un poste d'abonné est relié à un central téléphonique par une paire de
fils alimentée en batterie centrale (la boucle locale). Les centraux sont eux-mêmes reliés entre
eux par des liens offrant un débit de 2 Mb/s : ce sont les Blocs Primaires Numériques (BPN).
14 - Linux, BSD et Mac OS X : Différents systèmes d'exploitations basés sur le noyau Unix.
15 - client : Poste informatique utilisateur dans un réseau qui attend et reçoit les réponses du
serveur.
16 - serveur : Poste informatique maître d'un réseau, il peut avoir différents rôles, serveur
d'applications, de fichiers, de terminaux, ou encore de messagerie électronique. Les clients se
connectent au serveur pour obtenir différentes informations de configuration ou encore de
données. Un serveur est généralement capable de servir plusieurs clients simultanément.
17 - paquet (linux) : Une distribution Linux est un ensemble cohérent de logiciels rassemblant
un système d'exploitation composé d'un noyau Linux et de logiciels supplémentaires - le plus
souvent libres, ces logiciels sont alors appelé paquets et téléchargeable gratuitement sur
Internet.
18 - communauté Linuxienne : communauté des utilisateurs utilisant les systèmes Unix.
19 - PCI : Le Peripheral Component Interconnect (PCI) est un standard de bus local (interne)
permettant de connecter des cartes d'extension sur la carte mère d'un ordinateur.
20 - commutateur PABX : Équipement situé en un noeud de réseau pour assurer des
connexions appel par appel entre voies de transmission selon les besoins des usagers.
21 - Debian : Distribution Linux très stable utilisé dans notre cas pour installer nos serveurs.
22 - Red Hat : Distribution Linux très utilisée pour les serveurs.
23 - IETF : Littéralement traduit de l'anglais en « Détachement d'ingénierie d'Internet » est un
groupe informel, international, ouvert à tout individu, qui participe à l'élaboration de
standards pour Internet. L'IETF produit la plupart des nouveaux standards d'Internet.
24 - sessions multimédia : Une session est l'exécution d'un programme pour un utilisateur
donné. L'exécution du programme est alors paramétrée par les informations du profil de
l'utilisateur (ses caractéristiques, ses préférences, l'historique de ses interactions avec le
programme, etc.). Multimédia ici défini le transport de la voix.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 46
Année 2008/2009
25 - protocole ouvert : Format de données interopérable et dont les spécifications techniques
sont publiques et sans restriction d’accès ni de mise en œuvre, par opposition à un format
fermé.
26 - http : Protocole utilisé pour la création de page web. Il se compose de ligne de commande
visibles par l'utilisateur.
27 - analyseur de trames : une trame est un bloc d'information véhiculé au travers d'un support
physique (cuivre, fibre optique, etc.), elle se situe au niveau 2 du modèle OSI. Un analyseur
de trame permet de capturer l'ensemble des trames qui circules sur un média afin d'en faire
une analyse.
28 - haute disponibilité : On appelle haute disponibilité le fait de rendre un service disponible
24h/24h pour ses utilisateurs en parant aux éventuelles pannes du système.
29 - softphones : Type de logiciel utilisé pour faire de la téléphonie par Internet depuis un
ordinateur plutôt qu'un téléphone. Les communications peuvent se faire au moyen d'un
microphone et d'un casque ou de haut-parleurs reliés à la carte son, mais il existe aussi un type
de périphérique dédié à cette tâche, semblable à un téléphone et se branchant sur un port USB.
Les interfaces des softphones sont souvent intuitives et de la forme d'un téléphone. Les
fonctionnalités des softphones sont les mêmes que celles des téléphones classiques.
30 - VMWare : Nom d'une gamme de logiciels de virtualisation. La virtualisation est
l'ensemble des techniques matérielles et/ou logicielles qui permettent de faire fonctionner sur
une seule machine plusieurs systèmes d'exploitation et/ou plusieurs applications, séparément
les uns des autres, comme s'ils fonctionnaient sur des machines physiques distinctes. Les
outils de virtualisation servent à faire fonctionner ce qu'on appelle communément des serveurs
privés virtuels (Virtual Private Servers ou VPS) ou encore environnements virtuels (Virtual
Environments ou VE).
31 - load balancing : La répartition de charge (load-balancing en Anglais, littéralement
équilibrage de charge) est une technique utilisée en informatique pour distribuer un travail
entre plusieurs processus, ordinateurs, disques ou autres ressources.
C'est une forme d'optimisation. Les avantages sont nombreux :
* Augmentation de la qualité des services.
* Amélioration des temps de réponse des services.
* Capacité à pallier la défaillance d'une ou de plusieurs machines.
* Possibilité d'ajouter des serveurs sans interruption de service.
32 - trunk : Aggrégation de plusieurs lignes de télécommunication ou de VLAN afin
d'augmanter la bande passante.
33 - Fail Over : Le basculement (en anglais, fail-over qui se traduit par passer outre à la
panne) est la capacité d'un équipement à basculer automatiquement vers un chemin réseau
alternatif ou en veille.
34 - chemin réseau : Chemin composé d'équipements réseaux possédant des adresses IP et
dont le but est de permettre à un poste d'atteindre son correspondant.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 47
Année 2008/2009
35 - routeur : Un routeur est un élément intermédiaire dans un réseau informatique assurant le
routage des paquets. Son rôle est de faire transiter des paquets d'une interface réseau vers une
autre, selon un ensemble de règles formant la table de routage.
36 - pare-feu : Un pare-feu est un élément du réseau informatique, logiciel et/ou matériel, qui
a pour fonction de faire respecter la politique de sécurité du réseau, celle-ci définissant quels
sont les types de communication autorisés ou interdits.
37 - FreeBSD, OpenBSD, Solaris : Distributions basées sur le noyaux Unix.
38 - clustering : Technologie qui permet de créer une grappe de serveurs.On parle de grappe
de serveurs ou de ferme de calcul (cluster en anglais) pour désigner des techniques consistant
à regrouper plusieurs ordinateurs indépendants (appelés nœuds, node en anglais) pour
permettre une gestion globale et dépasser les limitations d'un ordinateur pour :
* augmenter la disponibilité
* faciliter la montée en charge
* permettre une répartition de la charge
* faciliter la gestion des ressources (CPU, mémoire, disques, bande passante réseau)
39 - scripts d'initialisations : Programme informatique qui ne nécessite pas de compilation
avant d'être exécuté. Pour fonctionner, les scripts doivent être interprétés par un programme
ou un serveur dédié au langage dans lequel ils ont été écrits.
40 - broadcasts : Le broadcast est un terme anglais définissant une diffusion de données à un
ensemble de machines connectées à un réseau. En français on utilise le terme diffusion.
41 - algorithme : Un algorithme est un ensemble de prescriptions et de règles qui définissent «
ce qu’il faut faire » et « dans quel ordre » pour résoudre un problème (ou une classe de
problème).
42 - port : Correspondant à la couche de transport du modèle OSI, la notion de port logiciel
permet, sur un ordinateur donné, de distinguer différents interlocuteurs. Ces interlocuteurs
sont des programmes informatiques qui, selon les cas, écoutent ou émettent des informations
sur ces ports. Un port est distingué par son numéro.
43 - démarrage automatique : repertoire dans lequel on indique des programmes qui
démarreront au lancement du système.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 48
Année 2008/2009
Bibliographie
Livres :
• Jim Van Meggelen, Leif Madsen & Jared Smith
Asterisk The Future of Telephony 2nd Edition, Edition ‘O’REILLY’, année 2007
• Sébastien Déon
VoIP et ToIP Asterisk : La téléphonie sur IP, Edition ‘ENI’, année 2007
Revues :
• Haute-disponibilité et équilibrage de charge
Edition ‘Linux Magazine/France n° 97’, année 2007
Site internet :
• Asterisk : The Open Source PBX & Telephony Platform, www.asterisk.org
• Asterisk Guru – Tutorials and howto’s for the asterisk PBX, www.asteriskguru.com
• Community Asterisk France, www.asterisk-france.net
• Linux Virtual Server, www.linuxvirtualserver.org
• VoIP-Info.org : A reference guide to all things VOIP, www.VoIP-info.org
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 49
Année 2008/2009
Annexes
A1
Fichier sip.conf
51
A2
Fichier extensions.conf du serveur Asterisk-1
52
A3
Fichier extensions.conf du serveur Asterisk-2
52
A4
Fichier iax.conf du serveur Asterisk-1
52
A5
Fichier iax.conf du serveur Asterisk-2
52
A6
Fichier voicemail.conf
53
A7
Fichier authkeys
53
A8
Fichier haresources
53
A9
Fichier ha.cf
53
A10
Fichier ldirectord.cf
54
A11
Fichier ipv.sh
54
A12
Fichier test_ldirectord.sh du serveur Asterisk-1
55
A13
Fichier test_ldirectord.sh du serveur Asterisk-2
55
A14
Compte-rendu de la réunion de lancement de projet
56
A145
Compte-rendu de la réunion de fin de projet
58
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 50
Année 2008/2009
A1. Fichier sip.conf
[121]
type=friend
username=121
secret=212
host=dynamic
callerid="Maxime"
context=projet
mailbox=121@projet
[131]
type=friend
username=131
secret=313
host=dynamic
callerid="Laura"
context=projet
mailbox=131@projet
[141]
type=friend
username=141
secret=414
host=dynamic
callerid="Fabien"
context=projet
mailbox=141@projet
[151]
type=friend
username=151
secret=515
host=dynamic
callerid="Mathieu"
context=projet
mailbox=151@projet
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 51
Année 2008/2009
A2. Fichier extensions.conf du serveur Asterisk-1
[projet]
exten => _1XX,1,Dial(SIP/${EXTEN})
exten => _1XX,2,Dial(IAX2/paris/${EXTEN})
A3. Fichier extensions.conf du serveur Asterisk-2
[projet]
exten => _1XX,1,Dial(SIP/${EXTEN})
exten => _1XX,2,Dial(IAX2/clermont/${EXTEN})
A4. Fichier iax.conf du serveur Asterisk-1
[paris]
type=friend
host=192.168.206.131
context=projet
qualify=yes
trunk=yes
A5. Fichier iax.conf du serveur Asterisk-2
[clermont]
type=friend
host=192.168.206.132
context=projet
qualify=yes
trunk=yes
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 52
Année 2008/2009
A6. Fichier voicemail.conf
[projet]
121 => 212,Maxime,121@localhost,,|attach=yes|review=yes
131 => 313,Laura,131@localhost,,|attach=yes|review=yes
141 => 414,Fabien,141@localhost,,|attach=yes|review=yes
151 => 515,Mathieu,151@localhost,,|attach=yes|review=yes
A7. Fichier authkeys
auth 1
1 sha1 password
A8. Fichier haresources
asterisk-1 IPaddr2::192.168.206.150/24/eth0 ldirectord
A9. Fichier ha.cf
logfacility daemon
node asterisk-1
node asterisk-2
keepalive 1
deadtime 10
bcast eth0
auto_failback on
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 53
Année 2008/2009
A10. Fichier ldirectord.cf
checktimeout=10
checkinterval=10
autoreload=yes
emailalert="root@localdomain"
emailalertfreq=0
quiescent=no
virtual=192.168.206.150:5060
real=192.168.206.130:5060 gate
real=192.168.206.131:5060 gate
checktype=negotiate
service=sip
checkport=5060
login="121"
passwd="212"
scheduler=rr
protocol=udp
Attention : exécuter la commande « update-rc.d ldirectord remove » afin de ne plus le
lancer en mode « standalone » au démarrage de l’ordinateur. Celui-ci sera géré par Heartbeat.
A11. Fichier ipv.sh
#!/bin/bash
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
IP addr add 192.168.206.150/32 dev lo
Attention : exécuter la commande « update-rc.d ipv.sh defaults » afin de le lancer
automatiquement au démarrage de l’ordinateur.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 54
Année 2008/2009
A12. Fichier test_ldirectord.sh du serveur Asterisk-1
#!/bin/bash
i=0
while [ $i == 0 ]; do
fi
fi
fi
sleep 10
done
Attention : exécuter la commande « update-rc.d test_ldirectord.sh defaults » afin de le
lancer automatiquement au démarrage de l’ordinateur.
A13. Fichier test_ldirectord.sh du serveur Asterisk-2
#!/bin/bash
i=0
while [ $i == 0 ]; do
/etc/init.d/heartbeat restart
fi
sleep 10
done
Attention : exécuter la commande « update-rc.d test_ldirectord.sh defaults » afin de le
lancer automatiquement au démarrage de l’ordinateur.
Melle REDONDO Laura
M. BOSCIA Maxime
Page | 55
Année 2008/2009
Aujourd’hui, les technologies de l’information et de la communication prennent de
plus en plus d’ampleur au sein de toutes les entreprises, de la plus petite à la plus grande.
C’est dans ce contexte de travail que nous avons réalisé ce projet de haute
disponibilité du service de téléphonie, service essentiel au bon fonctionnement de chaque
entreprise.
En effet, vous verrez dans ce rapport comment mettre en place de manière très efficace
un service de téléphonie sur IP, Open Source et entièrement gratuit, avec le logiciel
Asterisk. Vous trouverez aussi toutes les étapes conduisant à assurer la continuité de service
24h/24h et 7j/7j grâce à des logiciels déjà existant ou à des petits scripts a écrire vous-même.
Melle REDONDO Laura
M. BOSCIA Maxime

Rapport projet Asterisk

Transcription

Documents pareils

Option Service Télécom

XR1000 Asterisk®iIP-PBX Caractéristiques techniques.

TP trixbox

VOIP - notions de base

Une configuration minimale d`Asterisk

Asterisk, configuration et mise en œuvre

installer le serveur VOIP Asterisk

Asterisk pour la visioconférence en enseignement à

Partition MELLE

Imagine the diary entry the narrator wrote after the