Université HASSAN 1er – Settat

Ecole Nationale des Sciences Appliquées-Khouribga

Année universitaire : 2013/2014

Mise en place d’une solution ToIP OpenSource

avec :

Asterisk

Réalisé par :

Seddik DAYA

Abdessamad CHBICHEB

Khalid BENAYAD

Didi OUELD ELMOUSTAPHA

Encadré par :

Pr. Mohammed MOUGHIT

Remerciements

Nous remerciements s’orientent vers Monsieur MOUGHIT qui nous a proposé ce sujet

sur la ToIP. Il nous a guidés tout au long de notre projet afin de nous orienter sur les points

essentiels à étudier. Nous le remercions donc pour sa disponibilité et les précisions apportées

aux différentes étapes de notre projet.

Sommaire

Lexique 07

Introduction 06

1. Présentation 07

1.1. La téléphonie IP 07

1.1.1. Fonctionnement 07

1.1.2. Intérêts 09

1.1.3. Différence PABX / IPBX 09

1.2. Les protocoles 11

1.2.1. SIP / H323 11

1.2.2. RTP / RTCP 14

1.2.3. IAX 16

2. Asterisk 18

2.1. Généralités 18

2.1.1. Présentation 18

2.2.2. Fonctionnalités 18

2.2. Mise en place du serveur 19

2.2.1. Carte FXO / FXS 19

2.2.2. Installation et configuration du serveur et Clients SIP 20

3. Applications 33

3.1. Architecture locale 33

3.1.1. Schéma du réseau 33

3.1.2. Configuration du serveur 33

3.1.3. Configuration des clients 35

3.1.4. Transfert d’appels 39

3.2. Architecture étendue 41

3.2.1. Freephonie 41

3.2.2. Sécurité : Avec Firewall 42

3.3.3. Sécurité avec tunnel VPN IPSec 45

Conclusion 49

Lexique

ASCII : (American Standard Code for Information Interchange) est la norme de codage

de caractères en informatique la plus connue et la plus largement compatible.

Chipset : jeu de composants électroniques intégré dans un circuit intégré

préprogrammé permettant de gérer les flux de données numériques entre le ou les

processeur(s), la mémoire et les périphériques.

Codecs : désigne un procédé capable de compresser ou de décompresser un signal,

analogique ou numérique.

Firewall : é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.

Freephonie : un service téléphonique de l'opérateur Free, c'est une offre de téléphonie

sur IP.

FXO : l’interface Foreign eXchange Office est un port qui reçoit la ligne téléphonique.

FXS : l’interface Foreign eXchange Subscriber est un port qui raccorde la ligne

téléphonique de l’abonné.

HTTP : HyperText Transfer Protocol, est un protocole de communication client-serveur

développé pour le World Wide Web.

IP : Internet Protocol, est un protocole de communication de réseau informatique.

IPBX : système utilisé en entreprise qui assure l'acheminement de toute ou partie des

communications en utilisant le protocole internet (IP), en interne sur le réseau local

(LAN) ou le réseau étendu (WAN) de l'entreprise.

LAN : Local Area Network, désigne un réseau informatique d'échelle géographique

restreinte.

PABX : Private Automatic Branch Exchange est un Multiplexeur Téléphonique privé.

RTC : Le réseau téléphonique commuté est le réseau du téléphone fixe et mobile.

TCP : Transmission Control Protocol, est un protocole de transport fiable, en mode

connecté.

UDP : User Datagram Protocol est un des principaux protocoles de télécommunication

utilisé par Internet. Contrairement au protocole TCP, il travaille en mode non-

connecté.

WAN : Wide Area Network, est un 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.

Introduction

L'évolution des télécommunications fait que les centraux téléphoniques ont subi de

nombreuses évolutions, notamment l'arrivée des IPBX qui a permis l'interconnexion du réseau

téléphonique avec le réseau de données. Ceci permet aux entreprises de réduire les coûts et

de faciliter l'administration. Notre but a donc été de mettre en place un IPBX dans un

environnement « Open Source », c'est-à-dire qu’aucun investissement financier n’est

nécessaire pour le fonctionnement de la maquette basique.

Durant la réalisation du projet, nous avons appris à maitriser le logiciel et ainsi s’en

servir de la façon la plus optimale. Le test de certaines fonctionnalités indispensables comme

la messagerie ou le transfert d’appel a été réalisé et validé. La compatibilité avec des

téléphones IP Cisco a aussi été approuvée. Au niveau de la sécurité, qui est un point

fondamental, nous avons utilisé plusieurs méthodes telles qu’un firewall, VPN IPSec afin de

protéger des attaques notre installation.

Nous avons décidé de diviser notre rapport en 3 parties distinctes. Dans un premier

temps, nous allons vous parler de la téléphonie IP en la définissant et en présentant la

différence avec la téléphonie classique. Les protocoles associés à la ToIP comme SIP et RTP

seront ici aussi présentés. La seconde partie du document va présenter l’application qui nous

a permis de réaliser notre projet. En effet, nous allons décrire le serveur Asterisk en détaillant

son installation, sa configuration ainsi que ses fonctionnalités. La présentation des clients

utilisés dans la maquette sera abordée dans cette partie. Pour terminer, la troisième partie va

décrire les différents types d’architecture que nous avons pu tester. Il s’agit par exemple de

l’utilisation de la freephonie, la simulation en entreprise avec firewall ou encore la topologie

locale simple.

1. Présentation

1.1. La téléphonie sur IP

1.1.1. Fonctionnement

La téléphonie sur IP est un service de transport de la voix afin d’effectuer des

appels sur réseaux IP au lieu d’utiliser une ligne téléphonique traditionnelle. Ainsi la

voix circule sur un réseau unique (voix, données, vidéos) permettant de réduire

considérablement les coûts d’investissement.

La téléphonie sur IP est une transmission de la voix en mode paquets au format

TCP/UDP.

Fig. 1 : Le traitement de la voix

Lorsqu’un utilisateur veut entrer en communication avec un autre, une connexion est

alors établie entre les deux terminaux. L’utilisateur peut alors émettre un son par le biais d’un

micro (signal analogique) qui est ensuite numérisé et compressé par la machine (signal par

synthèse). Une fois les données encapsulées dans un paquet, il est envoyé au destinataire qui

procèdera aux opérations inverses assurant ainsi la mise en forme d’un message audible.

Les différentes étapes sont :

La numérisation : Les signaux de la voix (analogiques) doivent être convertis sous

forme numérique suivant le format PCM (Pulse Code Modulation) à 64kbit/s. La

modulation d’impulsion codée est une technique d’échantillonnage quantifiée sur

une série de symbole dans un code numérique (binaire). L’ordinateur ne comprend

que le code binaire, la numérisation est donc primordial.

La compression : Lors de la numérisation, le codage PCM se contente de mesurer

des échantillons indépendamment des uns des autres. Un échantillon du signal

n’est pas isolé, mais corrélé avec d’autres (précédent ou suivant).

En tenant compte des informations, il est possible de prévoir la valeur du nouvel

échantillon et donc de transmettre qu’une partie de l’information. C’est ce qu’on appelle la

prédiction. Cela permet de réduire la taille du paquet pour optimiser la bande passante.

Il existe deux grands types de compressions : le codage différentiel et le codage par

synthèse. La norme de compression est variable selon les codecs utilisés.

Les codecs sont des chipsets qui font office de codeurs/décodeurs. Certains terminaux

IP-PHONES n'acceptent qu'une partie ou même un seul codec, tout dépend du modèle de

terminal et du constructeur. Les principaux taux de compression de la voix sont les codecs

officiels suivants :

Méthode de compression Débit en Kbits/s

G.711 PCM 64

G.726 AD PCM 32

G.728 LD CELP 16

G.729 CS ACELP 8

G.729 x 2 Encodings 8

G.729 x 3 Encodings 8

G.729a CS ACELP 8

G.723.1 MPMLQ 6,3

G.723.1 ACELP 5,3

Les différents codecs et taux de compression

Le transport : L’information voyage dans des datagrammes UDP ne garantissant

pas la livraison car il n’effectue aucune vérification concernant la perte de paquet

et ne transmet aucune information sur les configurations utilisés. Il a donc fallu

définir un nouveau protocole fournissant plusieurs fonctionnalités :

Le numéro de séquence pour la remise en ordre des paquets ;

Un champ horodatage (timestamp) pour la restauration de la base de temps ;

Détecte la perte de paquets pour informer la source dans des délais

compatibles avec le service ;

Identifier le contenu des données et permettre leur transmission ;

Intègre des solutions pour traverser des passerelles de certains réseaux locaux

Ce protocole est appelé RTP (Real-Time Transport Protocol) qui se complète par un

protocole de contrôle qui transmet des rapports de réception RTCP (Real-Time Transport

Control Protocol). Par exemple lors d’une conférence regroupant plusieurs participants, RTCP

permet d’identifier différentes sources d’émissions contribuant à la session, mais il n’est

cependant pas obligatoire.

L’établissement de la connexion : Avant de pouvoir communiquer directement, les

membres de la discussion doivent établir un protocole pour la démarrer.

Les principaux protocoles utilisés pour l’établissement de la communication sont :

H323 ;

SIP ;

IAX (SIP amélioré, issu du projet de PABX Asterisk) ;

1.1.2. Son utilisation (Intérêts)

La convergence des services de communications données, vidéos et voix offre de

nombreux avantages. En effet, le téléphone et le PC partagent le même câble Ethernet, les

frais de câblage sont réduits, les frais d'administration du réseau sont également minimisés. Il

est ainsi possible de réaliser des économies à court et à long terme sur de nombreux postes :

administration d'un seul réseau, fournisseur d'accès unique, unique contrat de maintenance,

câblage commun, gratuité des communications interurbaines, réduction de la complexité de

l'intégration d'applications. Enfin, la migration de la solution actuelle vers la Téléphonie sur IP

s'effectue en douceur. Les solutions de téléphonie sur IP sont conçues pour dégager une

stratégie de migration à faible risque à partir de l'infrastructure existante. De plus, en

positionnant la voix comme une application supplémentaire sur le réseau IP, l’entreprise ne

va pas uniquement substituer un transport opérateur RTC à un transport IP, mais simplifié la

gestion de la voix, des données et vidéo par ce seul transport.

Aujourd’hui la position des opérateurs est menacée par l’arrivée massive de la

téléphonie sur IP, dont la tarification tend vers la gratuité.

1.1.3. Différence PABX / IPBX

Dans une architecture avec PABXs, il est nécessaire d’avoir deux infrastructures différentes. La premières constituées du réseau de PABXs où sont reliés physiquement les téléphones. Ce réseau est ensuite connecté au Réseau Téléphonies Commuté (RTC) permettant de communiquer avec l’extérieur.

Réseau de PABXs

Il y a ensuite le réseau de données classiques constitué d’ordinateurs, serveurs et

firewall connecté au WAN / Internet.

Réseau IP

Ces deux réseaux sont donc reliés afin de fournir un service complet de téléphonie et

de données. C’est notamment pour cela que le coût d’une infrastructure comme celle-ci est

plus élevée et l’administration plus complexe. Elle a par contre l’avantage d’une fiabilité plus

élevée car les deux réseaux sont séparées, par exemple si le réseau IP ne fonctionne plus, les

utilisateurs pourront continuer à utiliser la téléphonie.

Infrastructure générale

Dans une architecture avec un IPBX, il y a une unique infrastructure, où l’on intègre

directement les téléphones IP et l’IPBX sur le réseau IP existant. Ce réseau peut ensuite être

relié au Réseau Téléphonique Commuté en rajoutant une carte FXO / FXS sur le serveur de

téléphonie. Mais ceci est facultatif car le grand avantage de ce type de communication est

justement de pouvoir sortir sur le réseau Internet.

Infrastructure IPBXs

1.2. Les protocoles

1.2.1. SIP / H323

Session Initiation Protocol (SIP) est un protocole standardisé et normalisé par l'IETF

(RFC 3261). Il est de plus en plus utilisé actuellement dans le monde de la voix sur IP.

Son but principal est d’établir, modifier et terminer des sessions multimédias. SIP n’a aucune

connaissance concernant les détails d’une session ouverte. C’est grâce à lui que l’on va pouvoir

authentifier et localiser des multiples participants dans une session. Pour toutes actions au

niveau d’une session, SIP va utiliser le port 5060 via le protocole UDP qui offre une rapidité

d’échange du fait qu’il n’y est pas l’établissement de la connexion contrairement à TCP.

SIP ne s’occupe pas du transport des données échangées durant la session comme la voix ou

la vidéo. Il est indépendant de la transmission des données, c’est en cela que 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. Dans notre

cas c’est RTP qui se charge du transport de la voix. SIP est un protocole d'égal à égal (Peer-to-

Peer).

Dans une session, on appelle les extrémités des agents utilisateurs (User Agents). Un

agent utilisateur peut avoir un des rôles suivants:

User-Agent Client (UAC) - Une application cliente qui initie une requête SIP.

User-Agent-Server (UAS) - Une application serveur qui contacte l'utilisateur quand une

requête SIP est reçue et qui retourne une réponse à la demande de l'utilisateur.

Typiquement, une extrémité SIP est capable de fonctionner dans les modes UAC et

UAS, mais fonctionne dans l'un ou l'autre mode.

Les Clients SIP :

Des Soft phones.

Des téléphones IP.

Les Serveurs SIP :

Proxy Server : Il reçoit les requêtes SIP d'un client et les achemine vers l'autre

client.

Redirect Server : Il fournit au client l'information sur le ou les prochains sauts

qu'un message doit atteindre. Ensuite le client contacte le serveur du prochain

saut ou l'UAS directement.

Registrar Server : Il traite les requêtes des UACs pour l'enregistrement de leur

localisation courante. Les serveurs d'enregistrement sont très souvent localisés

avec le redirect server ou le proxy server.

Un utilisateur veut entrer en communication avec un autre via SIP. L’application

qu’utilise ce client fait donc appel au protocole SIP en précisant la nature des échanges. SIP va

par la suite définir le nombre de session à ouvrir et les ouvrir. (Pour échanger de la vidéo par

exemple, l’ouverture de 2 sessions est nécessaire : une session pour l’image et une autre pour

le son). SIP partage de nombreuses similitudes avec le protocole HTTP comme le codage en

ASCII et les codes de réponse. Le client envoie des requêtes au serveur, qui lui renvoie une

réponse.

SIP utilise des requêtes et des réponses pour établir des communications parmi les divers

composants d'un réseau.

Les méthodes de bases utilisées par SIP afin d’établir une session sont :

REGISTER : UAC authentifié

au niveau du serveur

INVITE : Initiation de la

session

ACK : confirmation

l’établissement de la session

CANCEL : annule un INVITE

en suspens

BYE : Fin de la session

On rencontre plusieurs types de communication utilisant le protocole SIP :

Mode Point à point : on parle dans ce cas-là « d’unicast » qui correspond à la

communication entre 2 machines.

Mode diffusion : on parle dans ce cas-là de « multicast ». Communication intégrant

plusieurs participants.

Combinatoire : combine les deux modes précédents.

Il existe également un autre protocole de signalisation nommé H323 englobant un

ensemble de normes utilisées pour l'envoi de données audio et vidéo sur Internet. Il existe

depuis 1996 et a été initié par l'ITU (International Communication Union), un groupe

international de téléphonie qui développe des standards de communication.

H323 est un protocole assez daté qui est actuellement dépassé par le SIP. Un des avantages

du SIP est sa simplicité et sa ressemblance aux protocoles HTTP. C’est pourquoi la plupart du

matériel VoIP disponible aujourd’hui répond aux normes SIP. L’équipement plus ancien par

contre suivra les normes du protocole H323.

1.2.2. RTP / RTCP

Real-Time Transport Protocol (RTP) est un protocole de communication informatique.

RTP offre un moyen d’échanger de bout en bout, via le protocole IP, des données

possédant des contraintes de temps réel (audio, vidéo, ...). Bien que ce protocole possède

dans son acronyme le terme « transport », on ne peut pas réellement parler de protocole de

transfert car RTP utilise un protocole de niveau 4 (transport) afin de véhiculer les données. En

effet, il utilise le protocole UDP (User Datagramme Protocol). UDP est préféré à TCP car ce

dernier ne peut pas utiliser la fonction multicast et ne permet pas un envoi immédiat de

données. RTP peut donc être utilisé pour la diffusion de contenus vidéo en direct (multicast),

pour des applications multimédia et dans notre cas pour la Voice Over IP utilisée par

téléphonie sur Internet.

Le protocole RTP ajoute aux paquets un en-tête fournissant les informations

nécessaires à la synchronisation du flux temps réel et du type son et vidéo.

L’entête RTP contient des champs spéciaux comme :

Le champ padding P : indique si le paquet contient des octets additionnels de bourrage.

Le champ extension X : précise si l'en-tête est suivi d'un paquet d'extension.

Le champ CSRC count CC : contient le nombre de CSRC qui suivent l'entête.

Le champ payload type PT : identifie le type du payload (audio, vidéo, image, texte, html,

etc.)

Le champ séquence number : sa valeur initiale est aléatoire et il s'incrémente de 1 à chaque

paquet envoyé, il peut servir à détecter des paquets perdus.

Le champ timestamp : 32 bits, reflète l'instant où le premier octet du paquet RTP à été

échantillonné.

Le champ SSRC : identifie de manière unique la source, sa valeur est choisie de manière

aléatoire par l'application.

Le champ CSRC : 32 bits, identifie les sources contribuant.

Capture wireshark visualisation d’une trame RTP

Le protocole SRTP (acronyme de Secure Real-time Transport Protocol) est le pendant

sécurisé (chiffré) de RTP. Nous ne l’avons pas mis en place ni étudier durant ce projet. Il doit

être intéressant de l’implémenté dans une architecture requérant un fort niveau de

confidentialité.

Le protocole RTP fonctionne en étroite collaboration avec RTCP (Real-Time Transport

Control Protocol). C'est un protocole de contrôle des flux RTP, permettant de véhiculer des

informations basiques sur les participants d'une session, et sur la qualité de service. Il

fonctionne grâce à l’envoi périodique de paquets de contrôle par tous les participants dans la

session. RTCP est situé au-dessus du protocole de transport UDP. Ce « feedback » apporté par

RTCP, peut par exemple informer la source sur les propriétés temps-réel du canal, l'état du

tampon du récepteur.

Par contre il n'offre pas de garantie de transfert… En effet, pour une transmission correcte, il

faut bien s'assurer dès le départ, que les liens de communications utilisés sont correctement

dimensionnés par rapport à l'utilisation qui en est faite.

Fig. 2 : Fonctionnement de RTP et RTCP

L’utilisation simultané des protocoles SIP, RTP et RTCP est la base d’une

communication en ToIP dans le cas de l’utilisation d’Asterisk. En effet, SIP permettra d’établir

la session entre l’appelant et l’appelé via le serveur ; RTP entrera en jeu afin de transporter le

« flux voix » entre les deux participants, RTCP lui fournira un contrôle ; SIP pourra intervenir à

tout moment pour modifier la session (rajout d’un participant) et dans tous les cas clôturera

la session lors de la fin de l’appel.

Il est nécessaire d’identifier les deux types de protocoles. SIP est un protocole de signalisation

il entre en jeu entre les clients et le serveur pour établir la session, tandis que RTP/RTCP est

un protocole qui va servir au transport de la voix et opérera toujours entre les participants

d’une session, jamais via le serveur.

Etablissement d’une communication (SIP RTP)

1.2.3. IAX

Inter-Asterisk Exchange est un protocole qui permet la communication entre client et

serveur ainsi qu'entre serveurs. Le nom IAX est souvent utilisé pour parler de la version 2 du

protocole en effet la première version n'est pratiquement plus utilisée. Il est plus puissant que

SIP car il a été conçu pour le contrôle et la transmission de flux multimédia avec un débit plus

faible. IAX utilise le protocole UDP et le port 4569 pour la signalisation et les données.

IAX supporte les authentifications de type PKI et le trunking. L’avantage qu’offre IAX est dans

l’utilisation du trunking, en effet la bande passante allouée correspond exactement à celle

utilisée.

Le trunking permet à plusieurs flots de données vocales de partager un seul "trunk"

avec un autre serveur, réduisant ainsi les congestions induites par le trafic IP.

IAX est en train de rattraper son retard, de plus en plus d’opérateurs supportent ce protocole

et de nombreux équipement commencent à faire leur apparition.

Ce succès grandissant d’IAX n’est pas une réelle menace pour SIP de la manière que SIP l’a été

pour H323.

Ayant étudié le principe de la ToIP, la comparaison avec une installation téléphonique

standard ainsi que les différents protocoles utilisés comme SIP et RTP nous avons pu

comprendre le fonctionnement de cette nouvelle technologie.

Nous allons maintenant décrire le serveur et les clients utilisés pour la mise en œuvre

d’une solution ToIP. Le serveur Asterisk ainsi que les différents matériels associés seront

présentés dans cette partie.

2. Asterisk

2.1. Généralités

2.1.1. Présentation Asterisk

Asterisk est un commutateur téléphonique privé à part entière mais d’implémentation

logicielle, compatible linux, qui s’interconnecte avec quasiment tous les équipements de

téléphonie de base standard et peu coûteux. C’est un logiciel « Open Source », qui a été

développé par Mark Spencer à l’origine, de l’entreprise Digium, (anciennement Linux Support

Services Inc.) et qui continue, grâce à de nombreux contributeurs, à évoluer régulièrement.

Ce logiciel a été conçu pour une flexibilité maximale et reste un système ouvert à de nouvelles

applications. Il fournit par exemple, des services de messagerie vocale, permet la conférence

à plusieurs, l’identification de l’appelant, etc.

Asterisk fournit donc toutes les fonctionnalités attendues d’un PABX mais aussi la voix

sur IP et n’a besoin d’aucun matériel supplémentaire pour l’assurer. Dans l’interconnexion

avec les équipements de téléphonie numériques et analogiques, Asterisk reconnaît une large

gamme de dispositifs matériels, et notamment ceux fabriqués par ses sponsors, tels que

digium, ou encore Quicknet.

Digium propose une gamme de cartes d’interfaçage autorisant une à quatre liaisons

de type T1 et/ou E1, permettant l’interconnexion à des liaisons de type PRI, ou à des banques

de canaux, comme à un port unique d’une carte de type FXO, ou l’un des quatre ports de la

carte modulaire FXS.

2.1.2. Fonctionnalités

Les solutions téléphoniques de base d’Asterisk offre une gamme importantes de

fonctionnalités. Asterisk offre à la fois les fonctionnalités d’un PABX classique et des

fonctionnalités innovantes.

Messagerie vocale ;

Transfert d’appel ;

Conférence téléphonique ;

Standard automatique ;

Renvoi d’appel ;

Mise en attente ;

La mise en place de ces fonctionnalités est relativement intuitive, nous allons détailler la

configuration du standard automatique qui nous a demandé un peu plus de réflexion.

Cette fonctionnalité est très appréciée des entreprises, elle permet à l’appelant de choisir et de

s’orienter vers le service qu’il désire. Ceci est pratique dans des grandes entreprises avec différents

services. Nous avons donc testé cette fonctionnalité en décomposant comme présenté ci-dessous :

Standard automatique

Lors de l’appel du numéro, un 1er message vocal est diffusé, il s’agit du Message Vocal

de Bienvenue. Il accueille les personnes et introduit un autre message qui va permettre de

choisir le service vers lequel on veut s’orienter (Message Vocal de choix des services). Ce

message annonce donc qu’en tapant la touche 1 ,2 ou 3 l’utilisateur va être respectivement

dirigé vers le service Comptabilité, le service Informatique et pour finir au service Production.

Selon la touche pressée, l’utilisateur va être orienté vers le poste 5555, 5545, 5556.

2.2. Mise en place du serveur

2.2.1 Carte FXO / FXS La carte TDM 400P permet d’interconnecter le serveur Asterisk avec le réseau LAN (IP)

et le réseau RTC (Réseau Téléphonique Commuté). Cette carte est distribuée par la société

« Digium ». Nous avons choisi une carte possédant un module FXO et un module FXS afin de

connecter une ligne et un téléphone analogique.

C’est une carte PCI qui se présente comme ceci :

On utilise les termes FXS et FXO pour nommer les ports utilisés par des lignes

téléphoniques analogiques (Réseau Téléphonique Commuté (RTC) en français, Plain Old

Telephone Service (POTS) en anglais).

FXS (Foreign Exchange Station) : permet le branchement de téléphones

analogiques.

L’utilisation des téléphones analogiques nécessite la génération d’une tonalité. Pour la

tonalité il faut donc un courant de sortie. C’est pour cela que l’on branche la carte sur un

connecteur 12V de l’alimentation. Le module FXS est VERT sur la carte.

FXO (Foreign Exchange Office) : permet la connexion au RTC France Télécom

donc pas de tonalité à générer. Le module FXO est ROUGE sur la carte.

Selon les besoins ressentis, on peut rajouter des modules. Par exemple, un module

FXO pour connecter une nouvelle ligne RTC ou le module FXS pour la connexion d’un nouveau

téléphone analogique.

Cette carte n’est pas nécessaire au fonctionnement d’Asterisk. L’installation peut

fonctionner sans cette carte mais les utilisateurs n’accèderont pas au RTC. Le moyen pour

accéder au RTC sans cette carte est d’utiliser le service freephonie.net que l’on expliquera par

la suite.

2.2.2 Asterisk-current-11.5.1 :

Nous avons choisi d’utiliser Asterisk-current qui est une légère d’Asterisk qui s’installe

sur une distribution Linux par contre les autres versions comme AsteriskNOW conçue

spécialement pour être un serveur de téléphonie indépendant. Pour l’OS on choisit la

distribution CentOS 6.4 d issue d’un projet gratuit de RedHat et qui est dédiée pour les

serveurs.

Structure des fichiers :

La table en dessous contient les différents chemins d’installations des fichiers et bibliothèques

Asterisk. Cette liste n’est pas exhaustive, seulement les composantes essentielles pour une

installation de base sont listées :

Chemin Description

/etc/asterisk Fichiers de configuration

/usr/sbin Chemin pour les fichiers binaires d’exécution

/var/log/asterisk Fichier d’erreurs et CDR (rapports)

/usr/lib/asterisk/modules Bibliothèques des composantes des modules

Ports par défaut :

Protocole Port Transport

SIP 5060/5061 TCP/UDP

IAX2 4569 UDP

MGCP 2727 UDP

SCCP 2000 TCP

RTP 1000-20000 UDP

Manager 5038 TCP

H.323 1720 TCP

DUNDI 4520 UDP

Unistim 5000 UDP

Dépendances et pré-installation :

Téléchargement :

Le paquet source d’Asterisk-current peut être téléchargé par la commande « wget » et

disponible sur le lien suivant :

Prérequis :

Pour que Asterisk s’installe correctement il faut que les paquets suivants soient

installés, pour CentOS/RedHat on utlise la commande « yum » pour Ubuntu/Debian « apt-

get » :

Compilation et installation :

Extraction du paquet :

Compilation et installation :

Configuration serveur Asterisk :

Commandes d’exécution :

yum install autoconf.noarch corosync.x86_64 corosynclib.x86_64 cyrus-sasl-

devel.x86_64 elfutils-devel.x86_64 elfutils-libelf-devel.x86_64 expat-devel.x86_64 file-

devel.x86_64 gnutls-devel.x86_64 libgcrypt-devel.x86_64 libgpg-error-devel.x86_64

libibverbs.x86_64 libidn-devel.x86_64 librdmacm.x86_64 lm_sensors-devel.x86_64

postgresql.x86_64 rpm-devel.x86_64 tcp_wrappers-devel.x86_64 unixODBC.x86_64

root@localhost:/usr/src/#wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz

root@localhost:/usr/src/#tar –zxvf asterisk-11-

current.tar.gz

root@localhost:/usr/src/asterisk-

11.5.1/#./configure

root@localhost:/usr/src/asterisk-11.5.1/#make

root@localhost:/usr/src/asterisk-11.5.1/#make

install

Diagnostique :

Le serveur Asterisk permet d’interagir directement avec le système sans avoir à

modifier les fichiers de configuration avec la CLI« Interface de ligne de commande ». Nous

utiliserons cette interface uniquement pour afficher et vérifier la configuration et l’état des

téléphones. Cette CLI est exécutée en tapant la commande suivante :

Ou bien :

Une fois la CLI ouverte nous pouvons afficher l’état des téléphones avec la commande

suivante :

Nous pouvons également afficher l’état des lignes quand le serveur Asterisk se

comporte comme un client SIP avec la commande suivante :

root@localhost~: /etc/init.d/asterisk stop

root@localhost~: /etc/init.d/asterisk start

root@localhost~: /etc/init.d/asterisk restart

root@localhost:/etc/asterisk#asterisk –r

root@localhost:/etc/asterisk#rasterisk

Configuration :

Fichiers de configuration :

Sip.conf :

Le fichier sip.conf est utilisé pour configurer les logins et mots de passe de tous les

périphériques. Ces périphériques peuvent être des téléphones, des passerelles analogiques

ou encore d’autres serveurs. Ce fichier est organisé en différentes zones appelées «context ».

Context general

Le context general définit :

Le context par défaut des comptes créés.

les paramètres TCP/IP du serveur.

le langage des messages vocaux.

Voici un exemple opérationnel :

Contexte utilisateur

Plusieurs options permettent de définir et de paramétrer un client (utilisateur) :

type : Type de client (peer, user ou friend)

defaultuser: Identifiant de l'utilisateur

secret : Mot de passe de l'utilisateur

host : Méthode pour trouver le client (dynamique, nom d'hôte ou adresse IP)

callerid : Identité de l'utilisateur

[general]

context= local ; contexte par défaut pour les utilisateurs

bindport= 5060 ; port UDP pour le protocole SIP

bindaddr= 0.0.0.0 ; @IP de l’interface sur laquelle asterisk va

;écouter le trafic 0.0.0.0 pour toutes les interfaces

language= fr ; langue par défaut des messages vocaux

language : Langue par défaut pour l'utilisateur Pour chacun des paramètres précédents,

plusieurs valeurs sont disponibles selon la configuration désirée.

Type :

peer : Client SIP auquel Asterisk pourra envoyer des appels

user : Client SIP qui pourra passer des appels via Asterisk

friend : Client qui sera à la fois en mode 'peer' et 'user'

Host :

dynamic : Le client s'enregistre auprès du serveur

nom d'hôte : Nom d'hôte du client

adresse IP : Adresse IP du client

Language :

us : Langue par défaut

fr : Langue française

D’autres contextes sont utilisés pour créer des comptes utilisateur. Les paramètres des

comptes peuvent êtres :

le login

le mot de passe

context, ce paramètre permet de gagner de la souplesse dans le routage des appels

mailbox, ce paramètre est utile pour la messagerie vocale

c’est avec les paramètres nat et cannreinvite que l’on peut contrer le problème du

routage NAT.

Contexte pour les passerelles

Il existe différentes passerelles. Ces passerelles permettent les communications vers le réseau

analogique ou numérique mais aussi GSM. Pour pouvoir fonctionner, ces passerelles doivent

avoir des comptes. Ces comptes se configurent de la même façon que les comptes utilisateurs,

exemple :

extensions.conf :

[1001] ; login SIP (obligatoire)

secret= s1001 ; mot de passe SIP (obligatoire)

callerid= ensak1001 ; facultatif, nom afficher sur le post de l’appelé

context= asterisk ; les appelles effectués par l’utilisateur seront gérés

;dans le contexte locale du ficher «extensions.conf »

mailbox= 1001@default ; facultatif, compte de messagerie vocale, voir

;« voicemail.conf »

type= friend ; obligatoire, autorise les appels entrants et sortants

host= dynamic ; @IP du client

nat= yes ; facultatif, résout le problème d’enregistrement SIP

;quand le post est derrière un NAT

[SPA-3102-PSTN]

secret=azerty

context=asterisk

type=friend

host=dynamic

Le fichier extension.conf est utilisé pour router les appels vers un utilisateur ou vers

sa messagerie. Par exemple, les appels provenant de comptes SIP dont le context est «

asterisk» seront traités dans l’extension « asterisk » du fichier extension.conf.

Les instructions exten sont utilisées comme suit :

Numéro

composé

Ordre

d’instructions

Action à éffectuer Durée avant de passer à

linstruction suivante (s)

Exten=> 200, 1, Dial(SIP/1001, 20)

Description des paramètres :

exten : permet de définir une nouvelle extension :

200 : numéro d’appel (ou d’extension) du serveur vocal ;

1 : ordre de priorité pour l’exécution ;

Dial : Commande à exécuter.

La configuration du fichier extensions.conf est interprétée comme suit :

Si un appel arrive au numéro 200 par exemple, Asterisk va premièrement appeler celui qui

s’est logé en user 1001 pendant 20 secondes et va s’arrêter si le 1001 ne décroche pas pendant

ce temps.

Au niveau de ce fichier, on peut implémenter beaucoup de scénarios comme la mise

en attente, accepter l’appel directement, mettre un message automatique … ou bien faire une

combinaison de toutes ces actions.

Routage d’appel vers un utilisateur:

Dans l’exemple suivant, les appels arrivant sur le serveur Asterisk à destination du

numéro 200 sont envoyés vers le téléphone de 1001 pendant 20 secondes puis sont envoyés

sur la messagerie de 1001.

[asterisk]

exten => 200, 1, Dial(SIP/1001, 20)

exten => 200, 2, VoiceMail(200)

Routage d’appel vers un groupe d’utilisateurs:

Dans l’exemple suivant, les appels arrivant sur le serveur Asterisk à destination du

numéro 205 sont envoyés vers le téléphone de 1001 puis vers le téléphone de 1002.

Remarque : l’instruction Goto() permet de renvoyer l’appel où l’on veut dans le fichier

extension.conf.

Dans notre cas, l’appel basculera du téléphone de 1001 au téléphone de 1002 jusqu’à

ce qu’un des deux décroche.

Routage vers plusieurs téléphones en même temps:

L’exemple suivant montre comment faire sonner deux téléphones en même temps.

Quand on compose le 206, les téléphones de 1001 et de 1002 sonnent.

Accès à la messagerie vocale:

Voici deux exemples d’accès à la messagerie. Dans le premier cas, l’utilisateur doit

composer sur son clavier numérique son login et son code pin. Dans le second exemple, le

login correspond au numéro de l’appelant. L’utilisateur doit juste composer son code pin.

Routage d’appel vers une passerelle analogique:

[asterisk]

exten => 200, 1, Dial(SIP/1001, 20)

exten => 200, 2, VoiceMail(200)

[asterisk]

exten => 206, 1, Dial(SIP/1001&SIP/1002, 20)

exten => 298, 1, VoiceMailMain() exten => 299, 1, VoiceMailMain(${CALLERIDNUM})

Dans l’exemple suivant, tous les appels commençant par quatre cent sont envoyés vers

la passerelle. La passerelle va composer le numéro sur la ligne analogique.

Dans l’exemple suivant, les appels commençant par 01, 02, 03, 04 ou 05 composés de

10 chiffres sont envoyés vers la passerelle. La passerelle va composer le numéro sur la ligne

analogique.

Dans l’exemple suivant, quand on compose le zéro, l’appel est envoyé vers la passerelle

et l’on obtient la tonalité. Nous pouvons ensuite composer le numéro vers l’extérieur.

Standard automatique:

Le standard automatique permet à un utilisateur d’écouter un message lui indiquant

les choix possibles. Après, il lui suffit de presser une des touches pour effectuer l’action voulue.

Il est possible de combiner les menus pour développer une architecture plus complexe.

Dans l’exemple suivant, quand l’utilisateur compose le 210, il entend un message vocal

qui l’invite à taper 1, 2 ou 9 sur son clavier. S’il tape 1, l’appel est envoyé à 1001. S’il tape 2,

l’appel est envoyé à 1002. S’il tape 9, Asterisk raccroche. Si l’utilisateur ne fait rien, le message

est joué en boucle.

exten => _4xx, 1, Dial(SIP/SPA-3102-PSTN/${EXTEN})

exten => _0[1-5]xxxxxxxx, 1, Dial(SIP/SPA-3102-PSTN/${EXTEN})

exten => 0, 1, Dial(SIP/SPA-3102-PSTN)

Astuce : pour enregistrer le message vocal au bon format, il vous suffit de laisser un message

sur la boîte vocal d’un utilisateur et de copier le fichier dans le répertoire /var/msg/ avec la

commande suivante.

Horloge parlante:

Dans l’exemple suivant le serveur Asterisk décroche, annonce la date et l’heure, attend

3 secondes et recommence.

[asterisk]

exten => 210, 1, Goto(Menu,s,1) ; appel du standard automatique

[Menu] ; standard automatique

exten => s, 1, Background(/var/msg/Menu) ; le message audio enregistré

;/var/msg/Menu.gsm et joue

exten => s, 2, WaitExten(2) ; on attend 2 sec

exten => s, 3, Goto(Menu,s,1) ; on recommence le tout

exten => 1, 1,SayNumber(1)

exten => 1, 2, goto(asterisk,1001, 1) ; 1 Appel 1001

exten => 2, 1, SayNumber(2)

exten => 2, 2, Goto(asterisk,1002, 1) ; 2 Appel 1002

exten => 9, 1, SayNumber(9)

exten => 9, 2, Hang up() ; 9 On raccroche

cp /var/spool/asterisk/voicemail/default/200/INBOX/msg0000.gsm

/var/msg/Menu.gsm

Outil de test de flux:

Dans l’exemple suivant Asterisk décroche et joue un message expliquant le

fonctionnement de la fonction de test. C’est ensuite à l’utilisateur de parler dans le combiné

et de vérifier que le serveur Asterisk renvoie le son vers le combiné avec un petit décalage.

voicemail.conf :

Le fichier voicemail.conf permet de configurer la messagerie vocale d’Asterisk. Nous

pourrons y paramétrer la notification par email des messages et les logins des utilisateurs de

la boîte vocale.

Contexte general

Le context general permet de spécifier :

Le format des fichiers audio enregistrés

Si l’on veut attacher le fichier audio à l’email

L’objet de l’email

Le corps de l’email

exten => 211, 1, Answer ; horloge parlante

exten => 211, 2, SayUnixTime(,CET,AdbY \'digits/at\' kM)

exten => 211, 3, Wait(3)

exten => 211, 4, Goto(local,211, 2)

exten => 212, 1, Answer ; permet de tester les flux entrant et sortant

exten => 212, 2, Playback(demo-echotest)

exten => 212, 3, Echo()

[general]

format=gsm

attach=yes

emailsubject=Nouveau message vocal provenant de ${VM_CIDNAME}

Voici une liste des variables utilisables dans l’objet et le corps des emails :

VM_NAME nom d'utilisateur

VM_DUR durée du message

VM_MSGNUM numéro du message

VM_MAILBOX numéro de l'utilisateur

VM_CIDNUM numéro du l'appelant

VM_CIDNAME nom de l'appelant

VM_DATE date du message

\n retour à la ligne

\t tabulation

Contexte default

Voici un exemple de context default, on y retrouve

Le numéro de boîte vocale

Le code pin de la boîte vocale

Le nom de l’utilisateur

L’adresse email de l’utilisateur

Le nom des contextes utilisateurs n’est pas important. Il faut toutfois faire attention à

utiliser le même nom dans les extensions utilisateurs du fichier sip.conf et le fichier

voicemail.conf.

emailbody=\n\tBonjour ${VM_NAME},\n\n\t Tu as un message de la part de

${VM_CIDNAME} d'une durée de ${VM_DUR} datant du ${VM_DATE}

[default]

200 = 123, ensa, ensa@toto.ma

201 = 456, uh1

202 = 789, fpk

Notification par email :

Pour qu’Asterisk puisse envoyer les emails aux utilisateurs, il faut installer un serveur

SMTP sur le serveur Centos.

sip.conf

[ensa]

mailbox=200@default

3. Applications

3.1. Architecture locale : 3.1.1. Schéma du réseau :

Dans le schéma en dessus on dispose d’un serveur Asterisk sous une machine linux

virtuelle et 3 client x-lite 2 virtuelles et le troisième représenté par l’OS de notre machine.

Pour avoir le tous dans le même réseau locale on doit choisir une carte de type « host only »

ou « local network » (sur VirtualBox) pour les machines virtuelles plus l’attribution des

adresses IP appartenant au même réseau 192.168.130.xx dans notre cas.

3.1.2. Configuration du serveur :

Fichier sip.conf :

On commence la configuration par configurer le serveur Asterisk sous linux (dans notre

cas le système est CentOS) : En accède au dossier /ect/asterisk puis en lance le nano pour

modifier le fichier sip.conf.

On ajoute ce texte dans le fichier sip.conf, afin de configurer 3 clients SIP qui sont 1001,1002

et 1003.

Fichier extensions.conf :

On lance nano pour configurer le fichier extensions.conf, afin de créer les scenarios

des appels.

# cd /etc/asterisk

# nano sip.conf

[1001]

type=friend

context=asterisk

defaultuser=1001

secret=s1001

host=dynamic

callerid="1001"

[1002]

type=friend

context=asterisk

defaultuser=1002

secret=s1002

host=dynamic

callerid="1002"

[1003]

type=friend

context=asterisk

defaultuser=1003

secret=s1003

host=dynamic

callerid="1003"

Après cette modification, on a configuré les scénarios des appels, par exemple, si un

client SIP veut appeler le 1001, le téléphone 1001 va sonner pendant 20 seconde, après il va

passer au 2éme processus, c’est de couper l’appelle avec la commande Hangup().

Après on redémarre le serveur Asterisk pour prendre ces configurations en

considération.

3.1.3. Configuration des clients:

Client SIP 1 :

En premier lieu on lance sous Windows le logiciel X-lite, après on clique sur le triangle

inversé qui est en haut, puis on clique sur SIP Account Settings.

[asterisk]

exten => 1001,1,Dial(SIP/1001,20,Tr)

exten => 1001,2,Hangup()

exten => 1002,1,Dial(SIP/1002,20,Tr)

exten => 1002,2,Hangup()

exten => 1003,1,Dial(SIP/1003,20,Tr)

exten => 1003,2,Hangup()

# rasterisk

> core reload

Puis on clique sur le bouton « add » pour ajouter un nouveau compte SIP.

Les champs du compte SIP :

Name Display : le nom qui va s’afficher sur ce spftphone.

User Name : nom du compte comme il est configurer dans sip.conf

Password : mot de passe du compte dans le fichier sip.conf

Domain : Adresse du serveur qui contient Asterisk

Dans la partie Domain Proxy on coche le bouton radio « Domain » puis on ne change

rien. Si le compte est bien configurer le softphone va être en état Ready.

Pour tester on va essayer d’appeler le « 1001 » à partir de « 1002 » et dans la figure

suivante on voit que la communication a été établit :

3.1.4. Transfert d’appels :

Si on n’a pas de touches pour effectuer un transfert d’appel sur notre téléphone SIP on

peut configurer une touche de raccourcis pour effectuer un transfert d’appel aveugle ou

supervisé vers un autre poste.

Transfert d’appels aveugle :

Le transfert d’appel dit aveugle est le fait de transféré un appel directement à une

autre personne.

Exemple de transfert aveugle:

1. 1 appel 2

2. 1 et 2 sont en communication

3. 2 transfère à 3 (transfert aveugle)

4. 1 et 3 sont en communication

5. 2 est raccroché

Transfert d’appels supervisé :

Le transfert d’appel dit supervisé est le fait d’appeler le destinataire du transfert avant

de lui transférer l’appel.

Exemple transfert supervisé:

1. 1 appel 2

2. 1 et 2 sont en communication

3. 2 appelle 3 (transfert supervisé)

4. 1 est en attente

5. 2 et 3 sont en communication

6. 2 raccroche

7. 1 et 3 sont en communication

Configuration et mise en place du transfert d’appels :

Dans le fichier « features.conf » se trouvant dans le repertoire « /etc/asterisk », on

repère les lignes suivantes :

Ces lignes permettent de configurer une ou plusieurs touches pour transférer un appel.

Pour notre part on a dans ce fichier de configuration mis comme touches ## pour le transfert

aveugle et ** pour le transfert supervisé, donc au final les lignes ressemblent à ceci :

Puis dans le fichier extensions.conf on rajoute l’option tT à l’application Dial ().

Donc la ligne:

exten => 1001, 1, Dial(SIP/1001,20)

;blindxfer => #1 ;

;atxfer => *2 ;

blindxfer => ## ;

atxfer => ** ;

Devient:

exten => 1001, 1, Dial(SIP/1001,20,tT)

Maintenant, après avoir fait un reload d’Asterisk on peut au cours d’un appel appuyer

sur les touches ## pour un transfert aveugle ou ** pour un transfert supervisé, une voix dira

« Transfert » on n’aura qu’alors qu’à taper le numéro de téléphone de la personne à qui on

souhaite transférer l’appel.

3.2. Architecture étendue : 3.2.1. Freephonie

Interconnexion freephonie

Afin de pouvoir passer des appels vers le RTC, l’utilisation d’un fournisseur SIP est une

méthode de plus en plus utilisée. Nous avons choisi d’utiliser le service du fournisseur d’accés

Free qui propose sur la freebox le service freephonie.net. Cette option est supplémentaire

mais son activation n’est pas payante. Les appels émis sont facturés de la même manière que

les appels normaux via la freebox.

La freephonie nous a donc permit de faire le lien entre notre installation et le RTC et

ainsi tester la compatibilité et valider son fonctionnement. Ce service va permettre la

convergence entre la téléphonie classique (RTC), le réseau GSM et le réseau IP.

Les utilisateurs présents sur le réseau local ont donc pu passer des appels vers l’extérieur. Il

a suffi de connecter notre serveur Asterisk à Internet afin que celui-ci puisse accéder au

serveur freephonie.net.

3.2.2. Sécurité : Avec Firewall

Pour simuler une situation en entreprise, nous avons réalisé notre maquette en y

insérant un firewall réalisé avec une distribution Linux Ubuntu ;

En effet de nos jours toutes les entreprises possédant un réseau local disposent aussi

d’un accès à Internet, afin d’avoir à portée, toutes les informations nécessaires, et pouvoir

communiquer avec l'extérieur. Cette ouverture vers l'extérieur est dangereuse. Ouvrir

l'entreprise via Internet signifie aussi laisser l’accès aux étrangers qui essayent de pénétrer le

réseau local de l'entreprise. Cette action est considérée comme une attaque et peut se définir

comme ceci :

« Accomplir des actions douteuses, parfois gratuites, de destruction, vol d'informations

confidentielles… »

Il a donc fallu mettre en place une architecture sécurisée pour parer à ces attaques. Pour cela,

on utilise un firewall. Cet outil va essayer au maximum de sécuriser le réseau local de

l'entreprise. Il va dans un premier temps, « filtrer » le trafic arrivant à partir d’internet sur le

réseau local.

Interconnexion avec un firewall

De plus, il peut permettre de restreindre l'accès interne vers l'extérieur. En plaçant

un firewall limitant ou interdisant l'accès à des services, l'entreprise peut donc avoir un

contrôle sur les activités se déroulant dans son enceinte.

La politique par défaut de l’utilisation d’un firewall est de bloquer tout le trafic et

autoriser seulement les protocoles et surtout les ports que l’on souhaite et sur des

interfaces précises. Avant d’écrire les iptables qui vont nous servir à restreindre le trafic, il

faut s’assurer qu’aucune ne soit déjà renseignée en vidant toutes les tables et supprimant

les règles utilisateurs.

• Réinitialisation des tables :

• Blocage de tout le trafic :

Pour notre maquette de test, nous avons voulu valider l’utilisation du port 5060 par

le protocole SIP. Nous avons dans un premier temps bloqué tout le trafic entre notre réseau

local et l’extérieur. Pour cela, on ignore tous les paquets transitant via le pare-feu. Il faut

donc ignorer dans les 3 cas possible de traitement des paquets :

INPUT : paquets entrant dans un processus local

OUTPUT : paquets sortants d’un processus local

FORWARD : paquets traversant la machine

En affichant les tables de notre firewall via la commande iptables -L, nous visualisons

bien que toutes les tables sont vides et que le trafic et bloqué (policy DROP).

Visualisation des iptables avant les règles

> iptables –P INPUT DROP

> iptables –P OUTPUT DROP

> iptables –P FORWARD DROP

> iptables –F –t filter

> iptables –F –t nat

> iptables -X

En bloquant tout le trafic, même le ping (protocole ICMP) vers internet ne fonctionnait pas.

Le test d’un appel vers l’extérieur était aussi négatif. En interne les appels fonctionnaient

correctement vu que le firewall n’a pas à traiter ces paquets. Le serveur étant sur le réseau

local l’échange s’effectuait localement.

• Natage :

Nous avons aussi réalisé aussi une opération de translation d’adresse pour toutes les

machines en 192.168.200.0 /24 qui traversent le firewall vers internet en sortant par eth0.

• Ouvrir le port 5060 SIP:

Pour terminer, nous avons ouvert le port 5060 et vérifié que les communications

fonctionnaient. En effet, le protocole SIP fonctionnait correctement mais il a aussi fallu ouvrir

une plage de port afin que le protocole RTP puisse transmettre la voix. Pour notre test nous

avons ouvert une plage assez grande (10000 à 20000). En réalité, il faudrait restreindre cette

plage pour ne pas avoir une faille importante dans notre pare-feu.

Visualisation des iptables après les règles

> Iptables –A FORWARD –p udp –dport 5060 –j ACCEPT

> Iptables –A FORWARD –p udp –dport 10000:20000 –j ACCEPT

> Iptables –t nat –A POSTROUTING –s 192.168.200.0/255.255.255.0 –o eth0 –j MASQUERADE

3.2.3. Sécurité avec Tunnel VPN IPSec :

La configuration du VPN IPSec se fait au niveau des deux routeurs passerelles entres

les sites distants afin de sécuriser le trafic entre les deux réseaux locaux comme le montre le

schéma suivant :

Configuration du tunnel VPN IPSec (192.168.55.0/30):

Création de tunnel :

R1:

interface Tunnel 12

ip address 192.168.55.1 255.255.255.252

tunnel source FastEthernet0/0

tunnel destination 192.168.2.2

R2:

On transforme le tunnel à un tunnel IPSec IPv4 sur les deux routeurs :

Le tunnel va passer en mode DOWN car les paramètres IPSec ne sont pas

encore configurés.

Création de mécanisme d’échange IKE via le protocole ISAKMP sur les deux

routeurs :

Configuration d’une clé pré-partagée « ENSAK » :

R1 :

R2 :

interface Tunnel 12

ip address 192.168.55.2 255.255.255.252

tunnel source FastEthernet0/0

tunnel destination 192.168.1.2

tunnel mode ipsec ipv4

crypto isakmp policy 10

encryption aes 256

authentication pre-share

group 5

exit

crypto isakmp key 0 ENSAK address 192.168.2.2

crypto isakmp key 0 ENSAK address 192.168.1.2

Création d’un jeu de traitement « transform-set » avec les paramètres

suivants :

ESP (Encapsulatiing Security Payload)

Encryption: AES 256

Hashing: SHA-HMAC

Affectation du transfom-set à un profile IPSec :

Vérification de configuration VPN avec la commande « show crypto ipsec

transform-set »

R2 :

crypto ipsec transform-set MYTRANS esp-aes esp-sha-hmac

crypto ipsec profile PROTECT

set transform-set MYTRANS

exit

int tunnel 12

tunnel protection ipsec profile PROTECT

Conclusion

La téléphonie n’a jamais été une application simple. Les contraintes temps réel et de

synchronisation pèsent lourdement sur sa mise en œuvre, et la téléphonie par paquet ne fait

que compliquer le transport.

Cependant, plusieurs raisons expliquent le succès de la téléphonie par paquet, et plus

spécifiquement de la téléphonie sur IP :

Convergence ;

Optimisation des ressources ;

Coût de transport quasiment nul ;

Disparition des commutateurs locaux ;

L’unicité de l’administration ;

La mobilité ;

La maintenance centralisée ;

L’autonomie de l’entreprise ;