Installer un serveur Asterisk

Introduction

Cet article traite de l’installation et de la configuration d’un serveur Asterisk sur une machine fonctionnant sous Linux. Il présente mon expérimentation dans ce domaine, depuis la phase de prise de connaissance jusqu’à la mise en exploitation.

Le logiciel Asterisk est un logiciel Open source initialement développé sous Linux. Il s’agit en fait d’un autocommutateur de voix sur IP, ou plus communément désigné sous le terme d’IP-PBX (IP Private Branch eXchange). Il agit sur la voix sur IP de la même manière qu’un autocommutateur de réseau commuté agit, à savoir mettre en relation des téléphones via des lignes téléphoniques analogiques. Il est hautement configurable et il faut son permis de conduire pour le maìtriser mais une fois la compréhension de son fonctionnement acquise, vous serez en mesure de créer n’importe quel plan de numérotation, que ce soit pour un réseau domestique ou pour un véritable réseau d’entreprise.

En prime, cet article vous montrera comment vous interfacer avec un opérateur SIP ce qui vous permettra d’appeler n’importe quel téléphone fixe ou mobile de part le monde, et ceci à des tarifs très intéressants.

Architecture

Le schéma suivant présente l’architecture que j’ai mise en place.

Dans ce schéma, le serveur Asterisk tourne sur la machine triton. Ce serveur a une adresse IP fixe, de même que la passerelle. Les autres machines du réseau ont une adresse IP attribuée dynamiquement. La particularité est que toutes les demandes de connexion entrantes sur le protocole SIP sont systématiquement redirigées par le routeur sur le serveur Triton pour qu’il les traite. Une modification des règles de votre routeur est donc absolument indispensable.

Sur les machines clientes du réseau, un client VoIP implémentant le protocole SIP est exécuté et est enregistré auprès du serveur Asterisk. Il peut s’agir des logiciels suivants :

 ZoIPer
 X-Lite
 QuteCom
 Firefly
 DIAX Softphone
 Express Talk
 Damaka
 AdoreSoftphone
 Minipax Softphone
 Mizu Softphone
 Faram phone
 Twinkle
 Ekiga
 IAXcomm
 SJPhone
 ...

Tout autre logiciel client (que ce soit sous Linux, Mac ou Windows) et implémentant le protocole standard et ouvert SIP peut convenir. Notez qu’un logiciel comme Skype ne fonctionnera pas étant donné qu’il utilise un protocole complètement propriétaire et fermé. En général les logiciels et protocoles propriétaires sont à bannir.

Une question de protocoles

Les mécanismes de voix sur IP utilisent des protocoles standardisés et ouverts.

 H.323
 SIP
 RTP
 RTCP

Le protocole SIP tend à supplanter progressivement le protocole H.323. De ce fait, nous ne parlerons pas de ce dernier dans cet article. Le schéma suivant montre comment les protocoles SIP et RTP/RTCP fonctionnent.

Le besoin est de transférer des données d’un client A vers un client B. Cependant, la nature même des données (audio) fait que l’aspect temps réel doit être pris en compte. On utilise pour cela le protocole RTP pour le transport des données et le protocole RTCP pour son contrôle. Ces protocoles ajoutent des indicateurs temporels aux données audio afin de pouvoir les restituer correctement. La voix ainsi transportée doit rester intelligible sinon tout ceci n’aurait aucun intérêt.

Afin d’optimiser la transmission, la liaison se fait directement en peer to peer, soit en point à point. Il est donc important de pouvoir établir une liaison directe entre le client A et le client B. Cependant, un client n’a aucune information sur l’autre, en particulier il ne connait pas l’adresse IP de l’autre ni sur quels ports il va pouvoir transmettre le flux audio.

Chaque client est enregistré auprès de son serveur respectif. Ces serveurs sont inter connectés et communiquent. Lors de l’établissement d’une communication entre les clients A et B, le client A dialogue avec le serveur auprès duquel il est enregistré (serveur A) en utilisant le protocole SIP. Le serveur A va ensuite communiquer avec le serveur B soit en utilisant le protocole SIP, soit en utilisant un autre protocole (IAX, Inter Asterisk eXchange). Le serveur B va alors prévenir le client B (toujours par le protocole SIP) qu’un client cherche à le joindre. Il y aura un échange d’adresses IP afin que chaque client sache comment atteindre directement l’autre client.

On dit que le protocole SIP est un protocole de signalisation, c’est-à-dire qu’il permet de mettre en relation deux peers mais qu’il ne transporte aucune donnée audio. Les données audio sont transportées en utilisant le protocole RTP, mais encore faut-il établir les numéros de ports à utiliser ! Ces numéros de ports sont établis lors des négociations entre le client A et le client B via les serveurs A et B en utilisant le protocole SIP. Une fois ces numéros de ports établis, chaque client peut ouvrir une connexion directe vers l’autre client en utilisant les adresses IP échangées et les protoles RTP et RTCP sur les numéros de ports choisis. A partir de ce moment, le protocole SIP n’est plus nécessaire.

Une fois les clients A & B mis en relation, tout le flux autio transite directement entre les points A et B, s’affranchissant ainsi de passer par les serveurs qui pourraient ralentir le traffic. Notez cependant que s’il y a des routeurs entre les clients A et B (ce qui est très souvent le cas), le flux audio passera par eux. Dans certains cas, cela peut être un facteur qui peut considérablement dégrader la communication. Certains routeurs peuvent être configurés afin de donner une priorité élevée à tout flux à caractère temps réel (audio, vidéo).

L’aspect dynamique des numéros de port rend la traversée de translateurs d’adresse (NAT) et de firewall délicate. Mais des solutions existent et feront l’objet d’un paragraphe dans cet article.

Installation d’Asterisk

L’installation ne pose pas de problèmes particuliers. Vous récupérez l’archive officielle ici. Je me suis basé sur la version 1.6.0.5 (la dernière en date au moment de la rédaction de cet article).

Vous décompressez l’archive et procédez à la compilation de manière tout à fait classique.

La dernière ligne contenant le make config permet de créer l’ensemble des fichiers de configuration dont Asterisk va avoir besoin pour fonctionner. Nous aurons à modifier quelques uns d’entre eux comme nous le verrons dans la section Configuration.

Au final, vous obtenez un exécutable installé sous /usr/sbin.

Configuration

Il y a toute une série de fichiers de configuration utilisable par Asterisk. Cependant, nous n’allons modifier que les quelques fichiers suivants pour les adapter à notre plan de numérotation. Nous n’allons pas dans cet article expliquer de manière détaillée la configuration d’Asterisk. Pour cela, je vous renvoie à l’excellent site voip-info.org. Les fichiers de configuration sont situés dans le dossier /etc/asterisk de votre serveur.

Fichier sip.conf

Ce fichier définit le comportement du serveur d’un point de vue du protocole SIP ainsi que la liste des comptes enregistrés, c’est-à-dire, la liste des personnes qui pourront se connecter en utilisant un identifiant et un mot de passe.

Il définit également des contextes d’utilisation qui peuvent être vus comme des groupes. Nous verrons cela un peu plus loin.

Enfin, ce fichier contient une directive [general] définissant des options générales au fonctionnement du protocole SIP, et définit un contexte par défaut. En voici un exemple :

On définit un contexte par défaut mais lorsqu’on définira des utilisateurs, on spécifiera explicitement le contexte auquel ils appartiennent. Cela permettra de mettre en place des autorisations, c’est-à-dire qui a le droit d’appeler les numéros nationaux, qui peut appeler des téléphones portables, etc. L’option bindaddr permet simplement d’indiquer l’adresse sur laquelle Asterisk se met à l’écoute. Mon serveur n’ayant qu’une seule interface réseau, j’indique directement l’adresse IP. De même, j’indique le masque de sous-réseau via l’option localnet. L’option language permet de spécifier la langue par défaut, ici le français. Par la suite, il sera possible de spécifier une langue différente pour chaque utilisateur. Mais si rien n’est précisé, par défaut ça sera le français. L’option realm définit le domaine dans lequel le serveur fonctionne. En fait, il est possible de mettre ce que vous voulez ici, mais cette information est utilisée pour authentifier les utilisateurs comme nous le verrons par la suite. L’option register permet l’enregistrement auprès d’un provider SIP (voir plus loin). Enfin, on définit les codecs utilisables. Dans mon cas, je définis les codecs suivants :

1. GSM
2. ALAW
3. ULAW

Ensuite, on trouve les définitions par utilisateur, comme dans l’exemple suivant :

Le nom du compte est identifié entre des crochets et permet d’indiquer que les options qui suivent ne correspondent plus à l’option [general] mais deviennent spécifiques à l’utilisateur en cours de définition. L’option defaultuser définit le nom de l’utilisateur. Cette option remplace l’ancienne option username qui est devenue obsolète. L’option type identifie le type d’entité SIP. En fait, on peut avoir 3 possibilités :

 peer
 user
 friend

Ici on définit le compte [charles] comme étant une entité de type friend. Cela signifie que cet utilisateur pourra émettre des appels mais aussi en recevoir. Le mot clé friend est en fait équivalent à peer + user. Une entité SIP de type peer est considérée comme un provider SIP et dans ce cas ne peut que recevoir des appels. A l’inverse, une entité de type user est considéré comme un utilisateur et ne peut donc qu’émettre des appels. Dans notre cas, on souhaite que chaque utilisateur puisse émettre et recevoir des appels, d’où le type friend. Ca sera le cas pour la majorité des personnes pour qui vous allez créer un compte.

Le mot clé auth indique comment cet utilisateur sera identifié. Ici on souhaite faire une authentification via un mot de passe crypté. Ce mot de passe est présent dans la chaine introduite par l’option md5secret. Evidemment, il n’apparaît pas en clair et il n’est pas possible de le retrouver en partant de cette chaîne. Calculer cette chaîne est simple, il suffit d’indiquer les éléments suivants :

 Nom d’utilisateur
 Domain (ou realm)
 Mot de passe

et de fournir tout ça à l’outil md5sum qui va calculer la chaîne à indiquer pour l’option md5secret. En voici un exemple :

On retrouve le domaine (ou realm) défini dans la section [general] du fichier de configuration. On spécifie l’option -n afin de dire à la commande echo de ne pas ajouter le caractère de retour à la ligne. Et on fournit le tout à md5sum qui nous calcule une signature numérique.

Le mot clé context indique à quel contexte appartient cet utilisateur. Ces contextes sont utilisés dans le plan de numérotation.

Le mot clé CallerId permet contient la chaîne qui sera affichée sur votre softphone/téléphone IP lorsque vous recevrez un appel. En général, on indique le nom complet et on le fait suivre par le numéro d’appel attribué à cet utilisateur entre les signes ’<’ et ’>’.

fichier extensions.conf

Ce fichier contient le plan de numérotation. Il peut être très simple ou très complexe selon vos besoins. Celui fournit par défaut avec votre installation d’Asterisk peut être complexe et pour bien comprendre, il vaut mieux partir d’un fichier vierge et l’enrichir au fur et à mesure.

Dans le fichier sip.conf, vous avez créé des utilisateurs qui pourront se connecter et exploiter la téléphonie sur IP que vous mettez en place. Cependant, il faut spécifier de manière précise quoi faire lors de la réception d’un appel, qui a le droit d’appeler qui, comment gérer les personnes absentes, quand basculer sur la messagerie, etc.

C’est l’objectif du fichier extensions.conf.

Chaque utilisateur déclaré dans le fichier sip.conf est placé dans un contexte via la directive suivante :

Le fichier extensions.conf fournit tout le plan de numérotation, contexte par contexte. Un utilisateur appartenant à un contexte déclaré dans ce fichier héritera de tout le plan de numérotation qui y est défini.

Article en cours de rédaction