Expérience d'un déploiement Asterisk dans une entreprise française

Auteur : Alexis de Lattre <alexis _arobase_ via.ecp.fr>

Vous avez le droit de copier, distribuer et/ou modifier ce document selon les termes de la GNU General Public License version 3 ou n'importe quelle version ultérieure, telle que publiée par la Free Software Foundation.

La version la plus à jour de ce document se trouve à l'adresse http://people.via.ecp.fr/~alexis/asterisk/

N'hésitez pas à m'envoyer un mail pour me faire part de votre propre expérience, qu'elle soit positive ou négative, me donner un conseil, me suggérer une solution alternative, me signaler une erreur ou une faute d'orthographe dans le document, etc...

Historique

Introduction

Ce document a pour objectif de faire profiter les personnes envisageant un déploiement d'Asterisk dans leur entreprise de l'expérience que j'ai acquise ; il détaille l'architecture mise en place, les choix techniques que nous avons fait et la motivation de ces choix, les erreurs à éviter et il fourni des liens vers nos fichiers de configuration à titre d'exemple. C'est d'une certaine façon ma contribution à la communauté Asterisk francophone. Ce document n'est pas un tutoriel sur Asterisk ; il existe déjà suffisamment de tutoriels qui expliquent la configuration et le paramétrage d'Asterisk.

La version initiale de ce document a été rédigée à l'issue du déploiement d'Asterisk dans mon entreprise en Août 2007. Ce déploiement a été réalisé par Baptiste Sadoul et moi-même pour toute la phase d'étude, de test et de déploiement, avec le support d'Adrien Pestel de la société Morea pour la phase finale de déploiement. Quand nous avons réalisé ce déploiement, nous n'avions aucune compétence et aucune expérience en VoIP. Par contre, nous avions une solide expérience en administration Linux et en réseaux IP. Ce document a été mis à jour au gré des évolutions de notre installation VoIP, des ajouts de matériel, des mises à jour logicielles, etc...

Pourquoi préciser dans le titre dans une entreprise française ? La plupart des informations contenues dans ce document ne sont pas spécifiques à la France. Seules certaines informations sur les opérateurs télécom et les sociétés de service sont spécifiques à la France. Les lignes RNIS sont très classiques pour les installations téléphoniques d'entreprise en Europe, mais pas forcément sur les autres continents.

Pré-requis conseillés pour la lecture de ce document :

• la lecture du livre Asterisk, the Future of Telephony, 2nd Edition, dont la version électronique est disponible gratuitement sur le site d'Oreilly,
• de bonnes compétences en administration Linux,
• de bonnes compétences en réseaux.

Installation précédente

Notre installation téléphonique précédente était centrée autour d'un PABX Alcatel Diatonis S2 (loué à France Telecom) qui était doté de :

• 4 ports RNIS,
• 8 ports numériques, reliés à des téléphones Alcatel,
• 4 ports analogiques : 1 relié à notre fax et 3 reliés à des téléphones analogiques classiques.

Ce PABX était relié à 3 lignes RNIS T0 de France Telecom. Rappel : une ligne T0 permet d'avoir 2 conversations téléphoniques simultanées.

Ce PABX ne convenait plus à nos besoins car, avec la croissance des effectifs de l'entreprise, il n'y avait plus de ports libres pour brancher des téléphones supplémentaires !

Installation VoIP avec Asterisk

Schéma d'architecture depuis Juillet 2010

Voilà l'architecture depuis l'arrêt de l'utilisation de nos lignes RNIS et le passage vers l'opérateur IP Acropolis Telecom :

Version des composants logiciels actuellement utilisés

Matériel utilisé et budget

Voilà la liste de tout la matériel que nous avons acheté pour notre déploiement VoIP avec les prix associés ; cela vous permet de connaître le budget de notre déploiement. J'ai laissé les prix payés lors de l'achat ; certains prix ont donc évolué depuis. Les éléments sur fond gris sont les éléments qui ne sont plus utilisés dans notre architecture actuellement en production.

Mes bookmarks

Voilà un peu en vrac les sites Web actuellement présents dans la catégorie Asterisk / VoIP de mes bookmarks :

• Asterisk.org, le site communautaire du projet Asterisk.
• Asterisk France : site communautaire français sur Asterisk et tout ce qui tourne autour (les téléphones IP notamment). Les forums sont assez actifs. J'en profite pour remercier tous les utilisateurs d'Asterisk France qui ont répondu à mes questions dans les forums !
• Panoramisk : site d'information en français sur Asterisk et la VoIP.
• Thomson ST2030 - page de téléchargement : cette page contient en particulier les nouvelles versions des firmwares des téléphones ST2030.
• Aastra: Support Downloads 6731i : cette page contient notamment les nouvelles versions des firmwares des téléphones Aastra 6731i.
• Voip-info.org : très gros Wiki communautaire qui parle des sujets relatifs à Asterisk et à la VoIP en général et qui donne aussi des infos intéressantes sur les téléphones IP.
• The Asterisk Book : la version actualisée du livre "Practical Asterisk 1.4", qui aborde tous les aspects pratiques de l'installation et du paramétrage d'Asterisk.
• Planet Asterisk : site qui traite de l'actualité d'Asterisk et de la VoIP.
• The Asterisk Guru : site proposant un certain nombre de tutoriels sur Asterisk et ce qui tourne autour.
• Blog Elastix : le blog officiel de la distribution Linux spécialisée Asterisk "Elastix".
• Elastix Connection : forums et tutoriels sur Elastix.
• Déployer la téléphonique FULL IP dans de bonnes conditions : document de 17 pages passant en revue toutes les problématiques techniques d'une solution full IP pour les communications internes et externes.

Retour d'expérience global

Globalement, le déploiement s'est très bien passé. Notre nouvelle installation est :

• stable et fiable : elle tourne en production depuis Août 2007 et elle est au moins aussi fiable que notre installation précédente. En 3 ans d'utilisation de notre PABX Alcatel d'Août 2004 à Août 2007, nous avons eu 3 pannes inexpliquées qui se sont solutionnées par un reboot du PABX ; depuis le déploiement de notre IPBX Asterisk en Août 2007 (bientôt 3 ans à l'heure où j'écris ces lignes), nous avons eu une seule panne inexpliquée qui s'est solutionnée par un reboot (c'était à l'époque où nous utilisions la carte RNIS PCI : elle a soudain refusé de fonctionner, ce qui nous a coupé de l'extérieur jusqu'au reboot de l'IPBX). Nous n'avons jamais rencontré de bug du logiciel Asterisk lui-même lors de son utilisation en production.
• pleinement fonctionnelle : nous avons retrouvé toutes les fonctionnalités de notre PABX Alcatel sans exception et nous pouvons maintenant profiter des fonctionnalités supplémentaires apportées par Asterisk et la VoIP.
• identique à la précédente au niveau de la qualité audio.

Au niveau technique, les 3 choses que je voudrais dire à ceux qui se lanceraient dans le même type de migration sont :

1. Asterisk et la VoIP ne sont pas des technologies simples qui "tombent en marche" tous seuls : il faut s'y intéresser vraiment et s'y plonger à fond pour bien maîtriser tous les paramètres techniques... et ils sont nombreux ! Il faut bien mûrir les choix techniques à faire (ils sont listés ci-dessous) et cela prend du temps.
2. le plus long n'est pas de comprendre et d'écrire les fichiers de configuration d'Asterisk mais ceux des téléphones IP !
3. n'achetez pas de téléphone Thomson ST2030 (ou autre de la même famille) car les firmwares de ces téléphones sont trop buggés... cf détails ci-dessous.

Choix et motivation des choix

Les 3 choix les plus importants, sur lesquels vous devrez concentrer toute votre attention avant le déploiement, sont à mon avis :

• le choix des téléphones IP,
• le choix du "packaging" d'Asterisk,
• le choix du canal de communication avec l'extérieur et de l'opérateur associé.

Téléphones IP

Choix initial : téléphone Thomson ST2030 (que je déconseille fortement aujourd'hui).

Choix actuel : téléphone Aastra 6731i.

Le choix du téléphone IP est très important pour plusieurs raisons :

• il représente la plus grosse partie du budget,
• c'est le paramétrage des téléphones IP qui a pris le plus de temps lors du déploiement initial, et non le paramétrage d'Asterisk,
• c'est ce que verront les utilisateurs de la nouvelle installation,
• il joue un rôle important dans la qualité audio.

Vous allez choisir un téléphone IP professionnel qui utilisera le protocole SIP. Ne cherchez pas sur les sites de vente grand public du type LDLC ou Rue du commerce, vous ne les trouverez pas ou très peu. Il vous faudra plutôt consulter les sites des constructeurs pour avoir les spécifications et les sites de vente spécialisés dans la téléphonie (IP & Go, One Direct, Wildix) pour avoir les prix. Les principaux constructeurs qui proposent des téléphones IP à des prix abordables (i.e. prix unitaires compris entre 80 et 130 euros HT) sont :

• Thomson : téléphones ST2030 et ST2022,
• Grand Stream, notamment le téléphone GXP2000,
• Budget Tone, qui est la marque entrée de gamme de Grand Stream,
• Aastra : la nouvelle génération de téléphones 6730i (sans PoE) et 6731i (avec PoE) ont un très bon rapport qualité/prix ; le téléphone 53i, plus ancien, est également intéressant,
• Snom,
• Siemens, qui fait notamment des téléphones SIP DECT, comme par exemple le téléphone Gigaset C470,
• Linksys, dont la gamme SPA comporte maintenant des téléphones SIP (à chercher dans la catégorie Products / Business / IP Communications / Linksys voice system... sinon vous allez vous retrouver au milieu des téléphones Skype, USB...)

J'exclus Cisco de la liste ; leurs téléphones IP sont très chers et leur support du SIP n'a pas toujours été bon car Cisco essayait d'imposer un autre protocole.

Les critères de choix sont à mon avis, par ordre d'importance :

1. la qualité du rendu et de la captation audio du combiné et du haut parleur éventuel,
2. la qualité physique du combiné et des touches,
3. le niveau de compatibilité avec Asterisk (c'est rare qu'il y ait des problèmes chez les grands constructeurs de téléphones IP),
4. les fonctionnalités du téléphone : codecs supportés, PoE, haut parleur, fonction main-libre, fonction d'interception des appels, le nombre de voyants de supervision de lignes, possibilité d'avoir une "extension standard" qui permet de monitorer un grand nombre de lignes, possibilité d'autoconfiguration des téléphones via des fichiers de configuration partagés en TFTP ou en HTTP.

Les fonctionnalités suivantes sont proposées aujourd'hui par tous les téléphones IP : présentation du numéro, notification des appels en absence et des messages présents sur le répondeur, mise en attente d'un appel, transfert d'appel, possibilité d'avoir un carnet d'adresse.

Pour faire notre choix lors du déploiement initial en 2007, nous avions décidé de faire une pré-sélection en utilisant les informations disponibles sur Internet puis d'acheter un téléphone de chaque modèle pré-sélectionné. Nous avons pré-sélectionné le téléphone Thomson ST2030 et le téléphone Dlink DPH120S. Mon idée était d'avoir un téléphone orienté professionnel dont j'avais entendu du bien à l'époque (le Thomson) et un téléphone d'une marque orientée grand public (le Dlink), en apparence moins cher. Lors de nos tests, nous avons rapidement constaté que le firmware du téléphone Dlink n'était pas maintenu et souffrait de plusieurs bugs mineurs non corrigés. De l'autre côté, le téléphone Thomson donnait globalement satisfaction et avait un firmware qui avait l'air bien maintenu (en tout cas en comparaison du Dlink... la suite de notre expérience nous a prouvé que le firmware du téléphone Thomson était assez buggé), nous l'avons donc retenu pour le déploiement initial.

Le téléphone Thomson ST2030 que nous avons choisi initialement a certaines qualités :

• son de bonne qualité,
• bonne qualité du combiné et des touches (même si on a quand même eu plusieurs pannes de combinés qui se mettaient à grésiller et qu'il a fallu remplacer),
• 10 touches de supervision en standard et possibilité d'ajouter des extensions pour superviser un grand nombre de lignes, ce qui est utile pour le poste qui sert de standard,
• toutes les fonctionnalités que j'ai cité plus haut, qui sont attendues sur un téléphone professionnel, sont bien présentes et fonctionnelles (modulo les bugs, cf ci-dessous),
• pas de problème de compatibilité avec Asterisk.

Ce que je reproche à ce téléphone :

• les firmwares sortis en 2008 et 2009 comportent trop souvent des bugs gênants. Il devient difficile de trouver une version récente de firmware déployable sans bug significatif. A chaque fois que j'ai testé une version récente de firmware ST2030, j'ai trouvé des bugs dans l'heure qui a suivi... donc j'en déduis que Thomson ne fait pas de tests sérieux de qualité logicielle sur leurs firmwares. A titre d'exemple :

  Version de firmware	Descriptif des bugs du firmware
  1.62	bug sur les touches de monitoring des modules d'extension
  1.63	bug sur les touches de monitoring toujours présent
  1.65	petit bug au moment de la réception d'un appel quand on est déjà en communication : le haut-parleur se met à émettre la conversation en cours pendant une demi-seconde sans raison. C'est le firmware qu'on utilise actuellement car c'est celui qui est à mon sens le moins buggé.
  1.66	bug sur les touches de monitoring des modules d'extension réintroduit
  2.67	bug sur le call pick-up et quand on fait un transfert d'appel vers un poste qui ne décroche pas (dans ce cas, quand on appuie sur "Retour", le correspondant ne vous entend plus, et il faut refaire "Transfert" puis "Retour" pour que la conversation repasse dans les 2 sens).
  2.68	bug sur les touches de monitoring 64 à 66 et problème sur le call pick-up (plus de détails ici).
  2.69	selon une personne du forum Asterisk-France, le problème sur le call pick-up présent dans le firmware 2.68 n'a pas disparu (le pickup ne marche pas si on décroche et qu'on appuie ensuite sur la touche de monitoring ; il ne marche que quand on appuie d'abord sur la touche de monitoring et qu'on décroche ensuite).

  Le fait qu'il y ait des bugs dans les firmwares est malheureusement courant de nos jours, mais ce qui n'est pas normal est que les bugs des firmwares ST2030 soient aussi faciles à trouver et concernent des fonctions courantes utilisées dans la plupart des déploiements !

• la mise en place de l'autoconfiguration par fichiers de configuration est laborieuse : il faut bien lire la doc pour ne pas "se faire avoir" par certaines subtilités. On a passé beaucoup de temps à faire du fine tuning des fichiers de configuration.
• un problème récurrent pour raccrocher : régulièrement, quand on raccroche le combiné à la fin d'un appel, le combiné se met dans une position telle que le téléphone ne détecte pas que le combiné est raccroché ; il se met alors à émettre un bruit spécifique qui permet de s'en rendre compte. La solution est alors de soulever légèrement le combiné et de le raccrocher en douceur. Ce problème est une sorte de bug hardware !
• et un point anecdotique : la qualité de la langue anglaise utilisée dans la documentation ne fait pas honneur à Thomson !

Pour permettre aux utilisateurs de downgrader leur téléphone ST2030 pour tenter de trouver une version de firmware sans bug gênant, j'ai rassemblé d'anciennes versions de firmware ST2030 à l'URL suivante : http://people.via.ecp.fr/~alexis/asterisk/st2030/firmware/ J'ai été obligé de prendre cette initiative car malheureusement Thomson ne prend pas la peine de donner accès aux anciens firmwares sur son site (au 16 Juin 2009, seul le firmware 2.67 est disponible sur le site de Thomson, or ce firmware souffre de 2 bugs critiques !).

Après avoir entendu beaucoup de bien des téléphones Aastra et lu à plusieurs reprises que les téléphones Aastra étaient les meilleurs téléphones pour Asterisk, j'ai finalement décidé d'acheter un téléphone Aastra 6731i à des fins d'évaluation. Attention, ce téléphone est livré sans bloc d'alimentation, donc pensez à l'acheter en plus si vous n'avez pas de switch PoE (ou prenez un Aastra 6730i, qui est livré avec un bloc d'alimentation mais ne supporte pas le PoE). Nous sommes très satisfaits de ce téléphone pour les raisons indiquées ci-dessous et tous les téléphones IP que nous achetons désormais sont des Aastra 6731i. Voilà pourquoi :

• très bonne qualité audio,
• nous n'avons trouvé aucun bug firmware pour le moment,
• la configuration centralisée par TFTP est très simple,
• il marche parfaitement bien avec Asterisk et Aastra est un constructeur impliqué dans la communauté Asterisk : Asterisk est officiellement supporté par Aastra (la doc des téléphones Aastra donne des exemples de configuration d'Asterisk !), des ingénieurs Aastra répondent parfois dans les forums Asterisk anglophones, Aastra était le seul constructeur de téléphone IP à être présent au salon AstriEurope 2010 avec une démo utilisant Asterisk, etc...
• son prix est compétitif par rapport au téléphone ST2030 (en gros le prix est le même que celui du ST2030 mais l'Aastra 6731i est livré sans bloc d'alimentation).

Canal de communication avec l'extérieur

Choix initial : conserver les lignes RNIS utilisées dans l'installation précédente pour les appels entrants et sortants.

Choix actuel (depuis Juillet 2010) : utilisation d'un opérateur IP pour les appels entrants et sortants, sur une ligne SDSL dédiée.

Pour la sélection du canal de communication avec l'extérieur, trois choix s'offrent à vous. Leurs avantages et inconvénients respectifs sont résumés ci-dessous. Par la suite, quand je parle d'un lien xDSL, je désigne un lien ADSL ou SDSL.

Nous avons initialement choisi la solution n°1 car c'était la solution la plus simple à mettre en œuvre et qu'elle n'ajoutait aucun délai.

La solution n°3, qui est apparemment souvent adoptée par les entreprises qui migrent vers un IPBX, est un bon compromis.

En ce qui concerne la solution n°2, mon étude des offres disponibles sur le marché français ne m'a pas permis d'identifier un opérateur capable de proposer à la fois le lien ADSL ou SDSL avec ses propres DSLAM et les communications en VoIP via des comptes SIP, IAX, MGCP ou autre (dans le cas d'une interconnexion SIP, on appelle l'offre un trunk SIP). Aujourd'hui, seuls Orange, Free, SFR, Bouygues Telecom et Completel possèdent leurs propres DSLAM dans les NRAs (i.e. les centraux téléphoniques). Parmi ces opérateurs, ceux qui ont une offre pour les PMEs (i.e. tous sauf Free) proposent généralement deux types d'offres :

• une offre en mode "Centrex" : dans ce cas, l'opérateur héberge le serveur qui réalise la fonction d'un IPBX dans sa propre salle serveur, vous fourni les téléphones IPs pré-configurés pour se connecter à son serveur et vous fourni le lien xDSL pour relier votre VLAN dédié à la téléphonie à son réseau. Avec les offres Centrex, l'opérateur s'occupe de l'intégralité de la solution technique. Avantages : l'opérateur peut se porter garant du bon fonctionnement de l'ensemble de la solution puisqu'il en fourni tous les composants ; la PME ne s'occupe de rien. Inconvénient : la PME est extrêmement dépendante de l'opérateur. C'est la raison pour laquelle j'ai exclu dès le début ce type de solution.
• une offre de type "box", parfois appelée "dégroupage de PABX" : dans ces offres, l'opérateur fourni à l'entreprise une box qui intègre un modem xDSL et des ports FXS ou RNIS T0. Cette box fonctionne de la façon suivante dans le cas d'un appel sortant : la box réceptionne le signal sur le port FXS ou RNIS T0, réalise la conversion en VoIP et envoie la communication IP vers le réseau de l'opérateur via le modem xDSL intégré. Elle fait la même chose en sens inverse pour les communications entrantes. Par exemple, chez Orange, il y a 2 offres de ce type : la Livebox Pro v2 qui intègre 2 ports FXS et un modem ADSL, et la BIV (Business Internet Voix) qui intègre plusieurs ports RNIS T0 et un modem SDSL (enfin, ça dépend des modèles). Avec ce type de solution, si l'entreprise possède déjà une installation de VoIP en interne avec un IPBX, elle devra convertir la communication IP en RNIS ou en téléphonie analogique pour se connecter à la box, qui se chargera alors de re-convertir le tout en VoIP... quelle horrible architecture ! J'ai donc également exclu ce type de solution.

Malheureusement, aucun des opérateurs ayant ses propres DSLAM dans les NRAs ne propose, à ma connaissance, une offre de type "trunking" aux PMEs. Dans ce type d'offre, l'IPBX interne à l'entreprise se connecte directement en VoIP aux serveurs de téléphonie de l'opérateur via le lien xDSL de ce même opérateur. Comme l'interconnexion entre l'IPBX de l'entreprise et l'opérateur se fait en VoIP, il faut préciser le protocole et le codec utilisé. Pour le protocole, on utilise en général SIP ou IAX ; comme l'interconnexion via ce protocole doit permettre d'avoir plusieurs communications simultanées dans une même connexion, on parle de trunk SIP ou de trunk IAX. Pour le codec, on a généralement le choix entre G711A et G729 (et parfois d'autres). Aujourd'hui, Free propose dans son offre standard Freebox un compte SIP qui est limité à une seule communication simultanée. Du côté de SFR, il était annoncé une offre en trunking en Novembre 2008, mais elle a apparemment été retirée (info de Mars 2009) et seule l'offre en mode Centrex subsiste.

Pour avoir une offre en mode "trunking", il faut se tourner vers des opérateurs qui ne possèdent pas leurs propres DSLAM dans les NRAs. Ces opérateurs sont moins connus, et doivent être répartis en deux catégories :

• ceux qui ont passé un accord avec un ou plusieurs opérateurs possédant leurs propres DSLAM pour organiser une collecte IP directement entre leurs deux réseaux, sans passer par Internet. Cette collecte permet d'avoir une garantie de qualité de service de bout en bout entre l'IPBX situé sur le LAN de l'entreprise et le serveur SIP ou IAX de l'opérateur.
• ceux qui n'ont pas organisé de collecte avec un opérateur possédant ses propres DSLAM ; dans ce cas, la communication VoIP entre l'IPBX de l'entreprise et le serveur SIP ou IAX de l'opérateur passe par Internet, ce qui ne permet pas de garantir la qualité de service de bout en bout.

Je conseille de ne prendre en considération que les opérateurs de la première catégorie, sauf si vous recherchez l'offre la moins chère possible ou si vous disposez d'une connexion à Internet par fibre optique. Dans le cas où vous seriez amené à considérer un opérateur de la 2ème catégorie, vérifiez la latence entre une machine de votre LAN (par exemple l'IPBX) et le serveur téléphonique de l'opérateur sur une longue période (plusieurs jours au moins) ; cette latence ne doit jamais dépasser 100 millisecondes pour pouvoir assurer une qualité de communication correcte. Pour mesurer la latence, vous pouvez tout simplement faire un ping et regarder le temps affiché ; pour mesurer la latence sur une longue période, utilisez un outil dédié qui va lancer un ping chaque minute, va en extraire le temps de latence et va construire un graph à partir de ces informations. Ce test permettra par la même occasion de vérifier que l'uptime du lien entre votre LAN et l'opérateur est bon. Attention, avoir une bonne latence et un bon uptime n'est pas suffisant, il faut aussi avoir le débit nécessaire ; mais vous aurez du mal à avoir l'information de débit sans faire un test réel avec l'opérateur sur une longue période (plusieurs jours ou plusieurs semaines).

Au niveau des coûts, voilà un tableau qui compare la structure de coût de la solution RNIS de France Télécom avec la solution en trunking sur lien SDSL d'Acropolis Telecom et la même sur lien ADSL. Les prix affichés dans le tableau sont les prix publics hors taxes.

Suite à la mise en concurrence, nous avons pu obtenir des réductions par rapport aux prix publics de la part d'Acropolis Telecom ; nous n'avons obtenu aucune réduction de la part de France Telecom.

Dans notre cas, nous avons remplacé 3 lignes T0 de France Telecom par une ligne SDSL avec un trunk IAX pour 6 communications simultanées en G711 d'Acropolis Telecom. Au niveau du coût fixe mensuel hors SDA, on est passé de 107 € (3 x 35,60) chez France Telecom à 190 € (110 + 6 x 13,34) chez Acropolis Telecom. Pour que l'opération de migration soit bénéfique en terme de coût, il faut donc que le gain sur le coût mensuel des communications soit au minimum de 83 €. Au niveau du coût des communications, en comparant notre facture détaillée de France Telecom (à défaut d'avoir réussi à obtenir la grille tarifaire !) à la grille tarifaire d'Acropolis Telecom, nous avons pu constater que le gain était important au niveau du coût d'appel vers les mobiles en France, vers les mobiles à l'étranger et très important vers les fixes à l'étranger, sauf pour les communications vers le Moyen-Orient. D'après notre simulation, l'économie sur les communications dépasse largement les 83 €, et devrait nous permettre une économie de l'ordre de 20% sur le prix mensuel total.

Mais attention, pour estimer le gain de la migration, il faut tenir compte des frais importants de mise en service de la ligne SDSL. On remarque d'ailleurs que les frais de mise en service sont beaucoup plus élevés pour la solution IP dans le cas d'utilisation d'une ligne SDSL, que pour la solution RNIS. Nous avons choisi un engagement de 24 mois pour réduire de 50% les frais de mise en service de la ligne SDSL. Dans le cas d'une nouvelle installation téléphonique, les frais de mise en service importants de la ligne SDSL seront à comparer aux frais réduits de mise en service des lignes RNIS T0, mais sans oublier d'ajouter pour la solution RNIS le prix non négligeable d'une passerelle SIP/RNIS ou d'une carte PCI RNIS (cf section budget).

Au final, il est difficile de prédire dans l'absolu si la solution la moins chère est la solution IP ou la solution RNIS, car cela dépend de très nombreux paramètres :

• le nombre maximum d'appels simultanés voulu.
• le codec choisi pour les communications IP vers l'extérieur (généralement, les opérateurs donnent le choix entre G711 et G729).
• l'éloignement par rapport au NRA et la qualité du câble téléphonique entre le NRA et l'entreprise, qui influencera le débit disponible en ADSL et donc la nécessité éventuelle de recourrir à un lien SDSL et le nombre de paires de cuivres requise dans le cas d'un lien SDSL.
• le département où l'entreprise est installée, car le prix des liens SDSL d'Orange dépend à la fois du nombre de paires de cuivre requis pour le débit demandé et du département (ne me demandez pas pourquoi !)
• la typologie des appels de l'entreprise : si il y a beaucoup d'appels "chers" i.e. vers les mobiles et vers l'étranger, les prix de communication réduits des opérateurs IP vont avoir un impact plus important dans le coût total.
• la solution de redondance éventuelle.

Mais, en règle générale, le tableau sur la structure de coût montre bien que :

• si, dans votre cas, le nombre maximum d'appels simultanés dont vous avez besoin est supporté par une simple ligne ADSL, le surcoût au niveau des frais fixes mensuels par rapport à une solution RNIS sera faible et donc l'économie réalisée sur le coût des communications téléphoniques devrait le couvrir largement. Par contre, il faut penser à une solution de backup et son coût éventuel, car les lignes ADSL n'ont pas de garantie de temps de rétablissement et il n'est pas rare de voir des liens ADSL down.
• si, dans votre cas, le nombre maximum d'appels simultané dont vous avez besoin oblige à avoir recours à une ligne SDSL, le surcoût au niveau des frais fixes mensuels sera important et, pour que l'économie réalisée sur le coût des communications téléphoniques compense ce surcoût, il faut que le volume de communications soit important et/ou qu'il y ait beaucoup d'appels "chers" vers les mobiles et à l'international. Dans le cas d'un lien SDSL, on peut se passer d'une solution de backup si le lien SDSL est down, car la garantie du temps de rétablissement oblige l'opérateur du lien SDSL à se presser pour rétablir le service.

Dans le cas d'une solution RNIS, on ne prévoit généralement pas de lien de backup en cas de panne du lien RNIS, car les liens RNIS sont très fiables ; en 6 ans d'utilisation de 3 lignes T0, nous n'avons jamais été en dérangement. Il faut aussi penser que, si vous avez plusieurs lignes T0, vos lignes se backupent entre-elles : si une ligne T0 est down (par exemple à cause d'une erreur de câblage entre le NRA et l'entreprise de la part de France Telecom, comme cela nous est arrivé lors de l'installation de la ligne SDSL), votre installation RNIS continue de fonctionner pour les appels entrants et sortants avec seulement 2 appels simultanés maximum en moins.

Par contre, dans le cas d'un lien ADSL, il est plus difficile de trouver des gens qui peuvent témoigner que leur lien ADSL fonctionne sans discontinuer depuis plusieurs années ! Personnellement, j'observe en moyenne une ou deux pannes d'un lien ADSL chaque année. Si votre entreprise tient à avoir une disponibilité maximale de son installation téléphonique, il faut donc songer à une solution de backup en cas de panne du lien ADSL. Dans le cas d'un lien SDSL, l'opérateur s'engage généralement sur une GTR (Garantie de Temps de Rétablissement) de 4h. Attention, cela ne veut pas dire que toute panne sera réparée en moins de 4h ! Cela veut dire que l'opérateur a une pénalité financière pour toute panne qui dure plus de 4h.

Il y a principalement 2 méthodes pour assurer une solution de backup pour un lien ADSL ou SDSL :

• utiliser en backup une ligne RNIS T0. Cela oblige à garder une ligne RNIS T0 chez France Telecom avec un numéro de téléphone associé (numéro qui ne sera pas connu par les correspondants de l'entreprise).
  • Fonctionnement pour les appels entrants : quand votre opérateur IP n'arrive pas à vous joindre par le trunk SIP ou IAX, il transfert l'appel entrant vers le numéro associé à la ligne RNIS de backup.
  • Fonctionnement pour les appels sortants : il faut configurer le dialplan d'Asterisk pour que, quand un appel sortant n'arrive pas à s'établir par le trunk SIP ou IAX, on essaye de le faire passer par la passerelle SIP/RNIS ou la carte RNIS.
  • Coût de cette solution : 35,60 € HT par mois plus une passerelle SIP/RNIS ou une carte PCI RNIS.
  • Nombre maximum d'appels simultanés en fonctionnement dégradé : 2 si vous avez une seule ligne RNIS T0 de backup.
• utiliser en backup le lien ADSL/câble/... dédié à l'accès Internet de l'entreprise.
  • Fonctionnement : tout d'abord, il faut se rappeler que c'est le serveur Asterisk de l'entreprise qui initie la connexion IAX ou SIP vers l'opérateur IP, et non l'inverse. En cas de panne du lien ADSL ou SDSL dédié à la VoIP, il faut donc qu'Asterisk initie une nouvelle connexion IAX ou SIP vers l'opérateur IP en passant par le lien Internet de l'entreprise. Cela se fait assez simplement en mettant en place une surveillance du lien ADSL ou SDSL dédié à la VoIP et, dès qu'on détecte que le lien est down, on modifie la table de routage appropriée pour passer par le lien Internet de l'entreprise. Cela requiert que les serveurs SIP ou IAX de l'opérateur IP soient joignables par Internet et pas seulement par le lien ADSL/SDSL dédié à la VoIP, mais c'est normalement le cas chez tous les opérateurs IP.
  • Coût de cette solution : nul, si l'entreprise a un ou plusieurs liens pour l'accès Internet.
  • Nombre maximum d'appels simultanés en fonctionnement dégradé : dépend du débit du lien Internet et de la répartition de ce débit entre le trafic data et le trafic voix.

Même si nous avons un lien SDSL, nous avons quand même mis en place une solution de backup ; nous avons opté pour la 2ème solution car elle est simple et n'engendre aucun surcoût.

Choix d'un opérateur IP

Choix actuel : Acropolis Telecom.

Si, pour le choix du canal de communication vers l'extérieur, vous êtes tenté par la solution n°2 ou n°3, cette section vous intéressera ; si vous avez choisi la solution n°1, cette partie ne vous intéressera pas.

Pour le choix d'un opérateur IP, nous avons considéré plusieurs opérateurs, qui ont tous une collecte auprès d'Orange et/ou SFR pour assurer une qualité de service entre notre IPBX et le serveur SIP ou IAX de l'opérateur. Tous les opérateurs que nous avons considéré proposent le portage des numéros. Voilà la liste des opérateurs que nous avons consulté :

• Acropolis Telecom, qui propose des offres en trunk SIP ou IAX avec le lien ADSL ou SDSL. Ils achètent leurs liens SDSL à Orange, et ils ont une collecte ATM directement chez Orange, ce qui leur permet de garantir la qualité de service entre le DSLAM et leur réseau. Leur offre semble donc solide d'un point de vue technique.
• OpenIP, qui propose des offres en trunk SIP avec le lien ADSL ou SDSL. Ils achètent leurs liens xDSL chez Orange ou SFR et ont une collecte directement ces opérateurs.
• Azylis, qui propose des offres en trunk SIP ou IAX avec le lien ADSL ou SDSL. Ils achètent leurs liens ADSL ou SDSL chez Orange ou SFR et ils ont une collecte en direct chez ces deux opérateurs. Cet opérateur a l'originalité de proposer aussi ses services sur Asterisk (c'est en fait un intégrateur Asterisk qui a décidé d'ajouter à son activité d'intégrateur celle d'opérateur car il n'était pas satisfait des opérateurs VoIP présents sur le marché français à l'époque où il a pris cette décision !).

Nous avons également interrogé l'opérateur Direct Centrex qui propose des trunks SIP et IAX avec des coûts de communication très compétitifs. Cet opérateur ne propose pas de liens ADSL ni SDSL, et, quand on l'interroge sur la problématique de la qualité de service entre le lien xDSL qu'on aura pris chez un ISP et leur réseau, leur réponse est "ça ne pose généralement pas de problème", ce qui ne nous convenait pas ! En effet, nous ne voulions que des opérateurs de téléphonie IP ayant une collecte directement auprès de l'opérateur assurant la liaison xDSL. De plus, un petit tour par les forums d'Asterisk-France montre que cet opérateur n'a pas bonne réputation (cf de nombreux posts datant du 1er trimestre 2009).

Finalement, nous avons retenu l'offre d'Acropolis Telecom pour les raisons suivantes :

• leur offre était compétitive (les écarts de coût entre les différentes offres étaient faibles),
• nous avions un bon contact commercial,
• nous avons interrogé une PME cliente d'Acropolis Telecom que nous connaissions ; cette entreprise utilise Asterisk et est cliente d'Acropolis depuis plusieurs années et est très satisfaite du service fourni.
• nous n'avons vu aucun client d'Acropolis Telecom mécontent dans les forums d'Asterisk-france.

Il est encore un peu tôt pour donner un avis complet sur le service de trunking d'Acropolis Telecom car le portage des numéros a eu lieu début Juillet 2010. Voilà ce que je peux dire pour le moment :

• Points positifs :
  • la latence entre notre serveur Asterisk et le serveur IAX d'Acropolis Telecom via la ligne SDSL est très faible et très stable : elle varie entre 11 et 13 millisecondes seulement !
  • nos interlocuteurs au support technique d'Acropolis Telecom ont un bon niveau technique et on peut sans problème parler avec précision de certains points techniques.
  • la qualité audio des communications téléphoniques est bonne : nos employés ne se sont aperçu de rien lors du basculement de nos lignes RNIS vers Acropolis Telecom.
  • le contact commercial est bon.
• Points négatifs :
  • le process d'administration des ventes chez Acropolis Telecom n'est pas rigoureux : à deux reprises, j'ai dû renvoyer à mon interlocuteur un scan de mon bon de commande pour pouvoir me justifier quand je lui disais qu'il mettait en place quelque chose qui n'était pas conforme à notre commande !
  • ces imprécisions au niveau de la communication en interne chez Acropolis Telecom ont engendré un autre problème : lors du portage des numéros, l'équipe technique a oublié de mettre en place le fax2mail sur la SDA dédiée au fax, alors même qu'Acropolis Telecom disposait bien de toutes les informations nécessaires. Nous nous en sommes aperçu en réalisant des tests juste après le portage des numéros ; Acropolis Telecom a corrigé son erreur environ 1h après qu'on la leur ait notifiée. Cela nous a privé de fax en réception pendant un peu plus d'une heure ; rien de grave, mais, sans ce loupé, l'opération de portage des numéros aurait été parfaite.
  • lors de la mise en place du trunk IAX, nous n'avons reçu que le minimum d'informations techniques, et nous avons dû poser de nombreuses questions par mail pour en savoir plus sur les détails du fonctionnement (mais nous avons toujours eu les réponses à nos questions). Un petit dossier technique de quelques pages abordant les différents aspects technique de l'architecture réseau, du trunk IAX et des mécanismes de redondance éventuels n'aurait pas été de trop !
  • Acropolis Telecom établit 2 factures par mois : une pour les communications du mois précédent, et une autre pour les abonnements du mois suivant (ligne SDSL, trunk IAX, service mail2fax). Cela double le temps de traitement comptable de des factures de téléphone, c'est dommage ! Je leur ai demandé si il était possible de recevoir une seule facture par mois, mais ils m'ont répondu que ce n'était pas possible pour le moment, mais qu'ils comptaient le faire un jour.

Le codec

Choix réalisé : utilisation du codec G711A partout.

Il existe un très grand nombre de codecs dans le monde de la VoIP : G711A, G711µ, G723, G726, G727, G729, GSM, etc... le choix semble donc très large à premier abord. En réalité, seuls deux codecs sont vraiment répandus et supportés par la quasi-totalité des équipements et des opérateurs IP :

• le G711, codec non compressé, qui est à la VoIP ce que le format WAV est aux fichiers son. Il en existe deux variantes : la version européenne, le G711A, et la version américaine, le G711µ.
• le G729, codec avec compression, qui permet de minimiser la bande passante utilisée. Ce codec est protégé par des brevets dont les propriétaires exigent le paiement de royalties.

Dans le monde de l'audio comme dans celui de la vidéo, les opérations de transcodage (i.e. conversion d'un codec à un autre) ne sont pas anodines car :

• elle ne peuvent pas se faire sans une perte de qualité, toute la difficulté étant que cette perte de qualité passe la plus inaperçue possible ;
• elle sont gourmandes en ressources processeur, même si dans le cas d'un flux voix cela reste très modeste.

Pour garder la meilleure qualité possible, on essayera donc de minimiser le nombre de transcodages entre la source et la destination.

Si on fait de la VoIP uniquement sur un LAN, le choix est facile : étant donné qu'il n'y a normalement pas de problème de débit ni de problème de perte de paquets, on choisira le codec G711.

Le packaging d'Asterisk

Choix initial : Asterisk et drivers compilés à la main sur une Debian stable.

Choix actuel : Asterisk et drivers Zaptel/DAHDI packagés dans notre distribution Linux habituelle (Debian stable).

Si c'était à refaire : Distribution Asterisk (Elastix ou autre).

Tout d'abord, il me faut clarifier ce que j'entends par "packaging" d'Asterisk. Asterisk, comme tous les logiciels libres importants, peut être installé soit via le package de votre distribution Linux habituelle (fichier de package .rpm ou .deb), soit en téléchargeant les sources sur le site Web du projet et en les compilant à la main (via la commande classique ./configure && make && make install).

Mais il ne faut pas seulement considérer le logiciel Asterisk lui-même, mais également les autres composants logiciels utiles au fonctionnement d'un IPBX complet. Au final, voilà l'ensemble des composants logiciels requis ou facultatifs sur un IPBX :

Cette multiplicité de composants logiciels explique l'émergence de distributions Linux spécialisées sur Asterisk... nous en parlons justement ci-dessous.

Il existe en tout 4 solutions pour le packaging d'Asterisk :

1. utiliser le package Asterisk de votre distribution Linux habituelle et les packages des autres composants logiciels requis fournis en standard dans votre distribution. Par exemple, sur une distribution Ubuntu, des packages sont fournis pour Asterisk, DAHDI, IAXmodem et Hylafax, mais pas pour FreePBX.
2. sur votre distribution Linux habituelle, télécharger les sources d'Asterisk sur le site asterisk.org et les compiler "à la main" ainsi que les drivers DAHDI et les autres composants que vous voulez utiliser.
3. acheter Asterisk Business Edition auprès de Digium ou un de ses revendeurs : c'est une version payante d'Asterisk proposée par Digium. Cette version a passé des tests de qualité avant sa release et est accompagnée d'un support technique. L'ordre de grandeur du prix est de 300 euros HT pour 10 communications simultanées, puis environ 170 euros HT par tranche de 10 communications simultanées supplémentaires (tarif dégressif en fonction du nombre de communications simultanées).

4. utiliser une distribution Linux spécialisée Asterisk, i.e. une distribution Linux dont l'objet est de contenir Asterisk et tous les composants logiciels listés dans le tableau précédent, et parfois plus (certaines distributions packagent en plus un webmail, un logiciel de CRM, etc...). Il existe de nombreuses distributions Linux specialisées Asterisk ; elle sont présentées ci-dessous :

   Distribution	Editeur	Interface de management	Fourni Asterisk 1.6 ?	OS	Commentaire
   Trixbox	Fonality, USA	FreePBX	Oui, dans Trixbox 2.8 et supérieurs	CentOS	Distribution Asterisk la plus ancienne. Il existe une version communautaire gratuite et une version "entreprise" payante.
   AsteriskNow	Digium, USA	FreePBX	Seulement en option, cf ce post	CentOS	La version 1.0.0 est sortie en Février 2008. Elle utilisait jusqu'à fin 2008 l'interface Web de configuration AsteriskGUI, mais les développeurs ont finalement décidé de passer à FreePBX.
   Elastix	PaloSanto Solutions, Equateur	FreePBX	A partir d'Elastix 2.0, prochainement en version finale	CentOS	Distribution lancée en 2006. Ce projet a l'air très dynamique et possède une bonne réputation. Communauté espagnole très forte.
   PBX in a Flash	aucun, développement 100% communautaire	FreePBX	Disponible en option dans PBX in a Flash 1.4	CentOS	Projet créé en Novembre 2007 par d'anciens développeurs de Trixbox en réaction à l'orientation de plus en plus propriétaire de Trixbox (explications ici).
   Xivo	Proformatique, France	Xivo	Pas encore. Prévu en roadmap pour Octobre 2010	Debian	Projet initialement non communautaire qui constituait la base des solutions commerciales de la société française ProFormatique ; le projet est devenu communautaire début 2009. C'est la seule distribution Asterisk basée sur Debian. Elle possède son interface de management propre et elle se distingue de ses homologues, d'après ses concepteurs, sur certaines fonctions avancées comme le filtrage Patron-Secrétaire, l'intégration des annuaires téléphoniques propres à chaque modèle de téléphone, etc...

   Note : CentOS est un clone gratuit de RedHat Enterprise Linux, qui est la distribution Linux payante de RedHat pour les serveurs d'entreprise ; le projet CentOS reprend les packets source de RedHat Enterprise Linux et se contente de les recompiler en enlevant les logos RedHat.

Je vais essayer de récapituler les avantages et inconvénients de chaque approche :

Dans notre déploiement initial, nous avons éliminé d'office la première solution car notre distribution habituelle est Debian et les packages Asterisk dans la distribution Debian stable à l'époque de notre déploiement étaient vieux (la Etch contenait Asterisk 1.2.13 et ne proposait pas Asterisk 1.4). Nous avons un peu testé Trixbox, mais nous n'avions aucune expérience des distributions CentOS ce qui ne nous a pas aidé à nous motiver pour explorer plus à fond cette piste.

Nous avons donc initialement décidé de partir sur la 2ème solution en installant une Debian stable avec un noyau Linux compilé à la main et l'ensemble "Zaptel (renommé DAHDI depuis) + libpri + Asterisk" compilé également à la main. Nous avons choisi de ne pas installer d'interface Web d'administration comme par exemple FreePBX, car nous avions déjà passé du temps à lire les docs d'Asterisk qui apprennent à se servir des fichiers de configuration et éditer un fichier de configuration avec notre éditeur de texte préféré ne nous fait pas peur ; c'était en fait une erreur car nous n'avions pas réalisé à l'époque que FreePBX apporte beaucoup plus que le simple fait de ne pas avoir à éditer les fichiers de configuration. En effet, FreePBX apporte de nombreuses fonctionnalités prêtes à l'emploi qu'il implémente en standard dans le dialplan d'Asterisk, comme par exemple le call pick-up, le follow-me, le routage d'appel intelligent, la présentation du numéro adaptée au contexte (appel interne ou vers l'extérieur), etc...

En Juin 2010, nous avons upgradé notre Debian Etch en Lenny, et nous en avons profité pour passer à la solution n°1, à savoir utiliser les packages Asterisk de notre distribution Linux. C'est maintenant possible car Debian Lenny fournit une version pas trop vieille d'Asterisk (1.4.21). Comme nous étions sur le point de passer à un opérateur IP et que cela nous obligeait à faire communiquer notre Asterisk en IP avec l'extérieur, nous voulions avoir les packages Asterisk de Debian et ainsi pouvoir facilement faire les éventuelles mises à jour de sécurité par simple mise à jour des paquets Debian. Ainsi, les composants logiciels Asterisk, libpri, Zaptel et le noyau Linux sont désormais des packages Debian et non des logiciels compilés à la main depuis les sources. On pourrait penser que, comme nous n'utilisons plus aucune carte téléphonique dans notre serveur Asterisk, nous n'avions plus besoin d'installer Zaptel/DAHDI... mais en fait Zaptel/DAHDI reste nécessaire pour faire des conférences téléphoniques avec la fonction MeetMe du dialplan ; en effet, en l'absence de carte téléphonique, MeetMe a besoin du module noyau ztdummy / dahdi_dummy pour avoir une source de timing pour la synchronisation des multiples conversations. D'après ce que j'ai lu sur cette page, l'utilisation de la fonction ConfBridge, fournie en standard dans Asterisk 1.6, permet de faire des conférences téléphoniques avec Asterisk sans avoir besoin de dahdi_dummy. D'après ce que j'ai lu dans les release notes de DAHDI, à partir de la version 2.2.0.2, le module dahdi_dummy n'existe plus et sa fonctionnalité est désormais fournie directement par le module dahdi. J'ai aussi constaté que DAHDI 2.3.0 ne permettait pas de faire fonctionner la fonction MeetMe d'Asterisk 1.4.21 ; l'explication de ce problème est que les deux releases sont incompatibles car Asterisk 1.4.21 a été releasé avant le changement de nom de Zaptel en DAHDI ; en tout cas c'est ce que laisse penser ce billet, quand il dit "Asterisk 1.4 will continue to have support for Zaptel, although it will be enhanced to also transparently support DAHDI instead". Asterisk 1.4.22 est donc a priori la première version d'Asterisk à supporter DAHDI ; en tout cas, c'est la première à avoir un module chan_dahdi et à être livrée avec un fichier Zaptel-to-DAHDI.txt qui explique la problématique de la transition. Plus de détail dans mes posts (mon pseudo est sixela) sur ce fil de discussion.

Si nous devions refaire complètement notre installation, nous ferions le choix des distributions "dédiées Asterisk"... et j'ai d'ailleurs eu l'occasion de mettre en oeuvre cette solution dans un autre déploiement que j'ai réalisé fin 2009 dans une autre entreprise. J'ai choisi Elastix car j'en avais entendu du bien de la part d'une personne très expérimentée sur Asterisk. Je suis très satisfait de ce choix car FreePBX est vraiment une bonne solution pour gagner du temps sur le paramétrage et profiter de certaines fonctions "prêtes à l'emploi". La seule petite difficulté pour moi réside dans le fait qu'Elastix est basé sur CentOS et que je n'ai jamais administré une RedHat de ma vie... mais il n'est jamais trop tard pour s'y mettre !

Serveur

Choix réalisé : Ordinateur Dell Optiplex de bureau.

Si c'était à refaire : j'essayerais un miniPC fanless.

Lors du déploiement initial, nous cherchions un serveur rackable fiable avec 2 slots PCI 32 bit 33 Mhz pour accueillir la carte RNIS et la carte avec le port FXS pour le fax (car c'était l'architecture prévue au tout début) et deux emplacements SATA pour avoir des disques en RAID 1. Malheureusement, la contrainte d'avoir 2 ports PCI 32 bit 33 Mhz impose souvent des serveurs 2U voir 3 ou 4U, ce qui devient assez imposant et coûte généralement un peu cher. Nous avons donc finalement choisi de prendre un de nos ordinateurs de bureau Dell Optiplex GX620, qui a l'avantage d'être peu couteux et facilement remplaçable en cas de panne. Ses caractéristiques techniques sont les suivantes :

• processeur Pentium D 2,8 Ghz
• 1 Go de RAM
• 2 disques SATA, qui seront utilisés en RAID 1 (grâce au RAID logiciel de Linux)
• 2 slots PCI 32 bit 33 Mhz

Cette configuration matérielle est en réalité très surdimensionnée par rapport à notre utilisation. En effet, quand on ne fait pas de transcodage systématique des flux audio (tous nos téléphones utilisent le codec G711A) et qu'on n'utilise l'audioconférence que de façon ponctuelle, les besoins en RAM et en CPU sont modestes.

Si c'était à refaire, et maintenant que nous avons une solution sans carte PCI ce qui enlève une contrainte importante dans le choix, j'essayerais de choisir une machine "no moving parts", c'est à dire un serveur sans ventilateurs et doté d'un disque SSD. J'ai notamment repéré ce modèle, très compact, à base de processeur Atom et complètement fanless, que l'on peut trouver à 249 euros TTC sans disque dur sur Amazon.fr (processeur Atom Z530 1,6 Ghz, 1 Go de RAM, 1 port Giga Ethernet, 1 emplacement pour disque SATA 2,5", 6 W de consommation électrique).

Fax

Choix initial : branchement du fax sur l'IPBX via une carte Digium TDM400P (choix que je déconseille fortement à cause de problèmes techniques).

Choix suivant jusqu'à Juillet 2010 :

• pour la réception de fax : système type fax2mail avec archivage Web basé sur IAXmodem + Hylafax + Avantfax
• pour l'émission de fax : fax "traditionnel" directement connecté à une de nos lignes analogiques France Télécom (et non plus via la carte TDM400P) ou utilisation de l'interface Web d'Avantfax (qui permet d'envoyer un fax à partir d'un document PDF).

Choix actuel :

• pour la réception de fax : notre opérateur IP reçoit le fax sur un de nos SDAs, le converti en PDF et l'envoie sur une de nos adresses mail dédiée.
• pour l'émission de fax : fax "traditionnel" directement connecté à une ligne analogique France Télécom.

Il n'existe pas aujourd'hui de fax IP à la façon d'un téléphone IP ; il en existera peut-être à l'avenir avec l'adoption par les constructeurs de fax de la norme T38.

D'une manière générale, la problématique du fax n'est pas simple dans le monde de la VoIP. Je vous conseille la lecture de cette page pour mieux comprendre les problématiques techniques qui se posent.

Le choix doit donc se faire entre garder son fax traditionnel et mettre en place un système de type fax2mail pour la réception et de print2fax pour l'envoi.

Dans un souci de simplicité pour les utilisateurs et les administrateurs, nous avons choisi de conserver notre fax traditionnel pour l'émission et la réception lors du déploiement initial en utilisant la carte TDM400P.

Malheureusement, nous avons constaté une recrudescence des erreurs à l'émission des faxs (pas de problème par contre pour la réception) : régulièrement, le fax signalait une erreur à l'envoi et, comme on ne peut pas savoir si le fax est passé quand même ou pas, il faut refaire un envoi. J'ai essayé quelques changements de paramètres au niveau de Zaptel (renommé DAHDI depuis), mais sans succès. J'ai fait quelques recherches sur Internet, et je suis tombé sur la section "Zap and Digium cards issues" de la page Asterisk and fax calls, ainsi que cette page.

Je me suis alors rappelé que le numéro de fax de provenance qui est écrit sur l'entête du fax reçu par le destinataire n'est pas le numéro de téléphone depuis lequel est émis le fax mais le numéro de téléphone qui est paramétré dans le fax lui-même. J'ai donc décidé de simplement brancher notre fax sur une de nos lignes analogiques (il ne nous en reste plus qu'une actuellement) pour réaliser l'envoi de fax, et d'installer un système de fax2mail pour la réception des fax avec IAXmodem et Hylafax. A chaque fax reçu, un mail est envoyé vers une adresse mail dédiée avec en pièce jointe un PDF contenant le fax.

Ce système a plusieurs avantages :

• on évite les traditionnelles indisponibilités du fax liées au classique "le rouleau du fax est fini et on a oublié d'en acheter un d'avance",
• on économise le prix des rouleaux et on évite le gaspillage de papier lié au spam par fax.

Ce système avait un petit inconvénient : le mail contenant le fax était adressé à deux personnes chargées de faire la distribution du fax, mais quand ces personnes étaient absentes, le reste du personnel n'avait pas accès aux fax. D'où l'idée d'avoir un archivage Web des fax reçus, qui est une fonctionnalité proposée par Avantfax. Avantfax permet aussi d'envoyer un fax à partir d'une interface Web : il suffit d'indiquer le numéro de téléphone du destinataire et de sélectionner un fichier PDF de son ordinateur (Avantfax propose aussi de générer facilement une page de garde).

Avec le passage à un opérateur IP en Juillet 2010, la question du fax s'est de nouveau posée. Après discussion avec notre nouvel opérateur IP, Acropolis Telecom, nous avons appris qu'ils ne faisaient pas de fax sur IP, pour éviter les problèmes techniques associés. Ils considèrent que le T38 n'est pas encore assez mature et standardisé dans l'industrie pour pouvoir le déployer sereinement avec leurs clients. Ils nous proposaient donc deux solutions pour la réception des fax :

1. soit renvoyer les appels contenant des fax vers une de nos lignes téléphoniques analogiques, sur laquelle un fax traditionnel serait branché. Le coût de cette solution était simplement le coût de la communication téléphonique pour le renvoi.
2. soit réaliser la convertion fax2mail au niveau de leurs serveurs et nous envoyer le fax en PDF sur une de nos adresses mail. Le coût de cette solution était la souscription à une option fax2mail à 5 euros HT par mois.

Nous avons finalement adopté la solution n°2 pour la réception de nos fax. L'émission des fax continue de se faire par un fax classique branché sur une de nos lignes analogiques avec présentation du numéro de notre SDA dédiée à la réception des fax.

Choix des interfaces téléphoniques

Choix initial : carte PCI Digium B410P pour le RNIS et carte PCI Digium TDM400P pour relier le fax.

Choix actuel : nous n'utilisons plus aucune carte téléphonique PCI. Nous avons arrêté d'utiliser la carte Digium TDM400P, cf section précédente. La carte RNIS Digium B410P a été remplacée par une passerelle SIP/RNIS Patton SN4638 en Juin 2009, puis la passerelle Patton a été mise à la retraite quand nous avons migré vers un opérateur IP en Juillet 2010.

Quand nous avons fait notre choix initial, notre motivation était la suivante : en tant qu'auteur principal d'Asterisk et développeur des drivers Linux des cartes, les cartes téléphoniques de Digium devaient sûrement être le meilleur choix pour les interfaces téléphoniques.

Au final, je ne recommande pas ce choix initial pour plusieurs raisons :

• on rencontre parfois des problèmes avec les drivers des cartes (nous en avons rencontré avec les drivers des cartes B410P, même si nous avons finalement trouvé la solution),
• ces cartes font peser des contraintes importantes sur le choix du hardware du serveur Asterisk,
• il y a dans quelques cas des soucis entre les cartes téléphoniques et la carte mère (mauvais partage d'IRQ, incompatibilité entre un chipset de carte mère et une carte téléphonique, etc...). Même si nous n'avons pas été confronté nous-même à ce dernier problème, on voit dans les forums des utilisateurs qui en sont victime.

Je trouve donc qu'il vaut mieux acheter un boitier dédié qu'une carte téléphonique pour remplir la même fonction ; par exemple :

• une carte TDM400P avec un port FXS peut être remplacée par un boitier Linksys PAP2T,
• une carte RNIS B410P peut être remplacée par une passerelle SIP/RNIS, cf ci-dessous.

Avec ces boitiers dédiés :

• suppression du problème des drivers,
• suppression des éventuels problèmes d'IRQ ou d'incompatibilité entre une carte mère et une carte téléphonique,
• suppression de la contrainte des ports PCI sur le choix du hardware du serveur Asterisk (cela peut aussi permettre d'embarquer Asterisk dans une machine virtuelle),
• en cas de panne du boitier, on peut le remplacer sans arrêter le serveur Asterisk ; et, si on investi pour avoir un 2ème boitier identique pour prendre le relai rapidement en cas de panne, il est facile de le pré-paramétrer et de n'avoir plus qu'à déplacer les branchements du boitier en panne vers le boitier de réserve pour prendre le relais.
• suppression de la contrainte sur l'emplacement du serveur Asterisk : plus besoin qu'il soit situé physiquement à proximité des lignes RNIS par exemple.

Si vous faites le choix de prendre des boitiers dédiés, il faut bien sûr faire attention à acheter un produit qui a bonne réputation dans la communauté Asterisk, ce qui vous garantira à la fois sa fiabilité et sa compatibilité Asterisk (je vous conseille de faire une recherche dans les forums d'Asterisk-France avant d'acheter), et qui a une large diffusion (la probabilité d'être le seul à rencontrer un problème donné est plus faible !). En effet, les problèmes de drivers que l'on pouvait rencontrer avec les cartes téléphoniques peuvent être remplacés par des problèmes de firmware buggé qui vient affecter la bonne marche du boitier dédié... pour éviter ces soucis, prenez le temps de bien choisir votre boitier dédié.

Comme je l'explique dans le paragraphe précédent, nous n'utilisons plus la carte TDM400P pour le fax, car le fax est maintenant connecté directement à une de nos lignes analogiques.

Je me suis ensuite posé la question de la redondance de la carte B410P ; en effet, si elle tombe en panne, je n'avais rien sous la main pour la remplacer immédiatement. Je pouvais bien sûr m'acheter une 2ème carte B410P... mais j'ai préféré creuser la possibilité d'utiliser un channel bank Ethernet/RNIS, que je préfère appeler Passerelle SIP/RNIS. Un channel bank Ethernet/RNIS est un boitier qui converti une ligne RNIS en channel SIP. Le gros avantage est que cela évite la contrainte d'installer une carte PCI dans le serveur Asterisk, d'installer les drivers Linux de la carte, etc... Dans cette configuration, le serveur Asterisk se connecte en SIP au boitier channel bank pour envoyer ou recevoir des communications téléphoniques par les lignes RNIS. Ce fil de discussion sur le site d'Asterisk-France parle des différentes marques de channel bank RNIS.

Voilà les modèles de channel bank Ethernet/RNIS que j'ai trouvé :

• Gamme Patton SmartNode : le boitier Smartnode 4634 avec 3 ports T0 (2 ports utilisables simultanément) est à 380 euros HT chez ipandgo (le prix fait le yoyo entre 380 et 500 euros depuis quelques mois chez ipandgo ; il est à 511 euros HT sur cet autre site et à 550 euros sur ce 3ème site) et le boitier Smartnode 4638 avec 5 ports T0 (4 ports utilisables simultanément) est à 490 euros HT chez ipandgo (le prix fait le yoyo entre 490 euros et 650 euros depuis quelques mois chez ipandgo ; il est à 644 euros HT sur cet autre site et à 635 euros sur ce 3ème site). Prix raisonnable, semble assez utilisé dans la communauté Asterisk. Selon ce que j'ai pu lire et entendre, la qualité audio est bonne, c'est fiable, mais la configuration n'est pas facile.
• AudioCodes, modèle MP-402-BRI (1 port T0, 310 euros HT chez ipandgo) ou MP-404-BRI (2 ports T0, 450 euros HT sur le même site) ou MP-408-BRI (4 ports T0, 650 euros HT sur le même site). Info Mai 2009 : ces 2 modèles seraient en fin de vie, et remplacés par d'autres modèles. Selon ce que j'ai pu lire et entendre, la qualité audio est très bonne, la configuration est simple, mais les prix sont plus chers que chez Patton.
• Vega 50 Europa (530£ pour le boitier avec 2 ports RNIS TO et 1060£ pour le modèle avec 4 ports selon ce site). Je n'ai jamais lu ni entendu de retour d'expérience sur cette marque.
• One Access, modèle One Access One100A qui a une option 4 ports RNIS (BRI), mais on ne le trouve pas sur des sites de vente en ligne, et il est donc très peu utilisé dans la communauté Asterisk.

Dans la communauté Asterisk-france.net, on trouve seulement quelques utilisateurs du boitier Patton, cf ce post. Selon ce fil de discussion, la configuration du boitier n'est pas triviale et requière une lecture approfondie de la documentation (ce que confirme mon expérience).

Notre déploiement du boitier Patton s'est très bien passé et nos sommes très contents de la qualité audio et de la fiabilité du produit (aucun problème à signaler depuis son déploiement). Je mets notre fichier de configuration en partage ; vous le trouverez plus bas sur cette même page.

Réseau

Choix initial : garder la VoIP dans le même VLAN que tout le reste, et utiliser de la QoS au niveau IP (DiffServ, et plus précisément le champ DSCP) pour mettre les flux voix en priorité par rapport au trafic data. Pas de PoE.

Choix actuel : Création d'un VLAN dédié à la VoIP pour éviter que les équipements VoIP soient impactés quand on a un problème de multicast dans le VLAN principal. Ajout d'un switch PoE Linksys SRW224G4P pour alimenter certains téléphones, notamment les Aastra et la pieuvre Polycom pour lesquels le bloc d'alimentation est vendu en option.

Si c'était à refaire : idem que la solution actuelle, mais avec un autre switch PoE qui gère mieux les VLANs que le Linksys SRW224G4P ; j'essayerais par exemple le switch HP Procurve 2520-24-POE (ce modèle n'existait pas à l'époque du choix du switch PoE Linksys).

Le choix est très lié à l'architecture réseau existante et au matériel réseau déjà en place. On vous conseillera sûrement de mettre les flux VoIP dans un VLAN dédié. Dans nos locaux, nous manquons de prises réseau dans un certain nombre de bureaux et nous avons donc recours à de petits switchs non administrables au niveau de ces bureaux pour raccorder les différents ordinateurs du bureau et les téléphones IP au reste du réseau. Il y a donc de toute façon une cohabitation des flux data et voix au niveau de ces petits switchs. Ensuite, notre préoccupation n'est pas tant de séparer les flux voix des flux data que de s'assurer que les flux voix ne seront jamais perturbés par le volume des flux data ; par exemple, nous voulions que si un lien entre 2 switchs du réseau est saturé, les flux voix ne soient pas impactés. D'où le recours à la QoS. Nous avons choisi de faire de la QoS au niveau IP plutôt que de la QoS au niveau Ethernet car nos switchs supportent la QoS IP et les téléphones Thomson, Aastra et Polycom sont capables de tagger les flux en QoS IP (et Asterisk également, ainsi que la passerelle Patton), ce qui simplifie la configuration des switchs, qui n'ont alors qu'à se baser sur les tags des paquets IP pour attribuer le niveau de priorité.

Alors qu'initialement nous n'avions pas crée de VLAN dédié à la VoIP, nous en avons finalement crée un, dans lequel se trouvent maintenant le serveur Asterisk ainsi que les téléphones IP, l'interphone IP et la passerelle Patton. Dans notre société, nous utilisons beaucoup le multicast, et nous avons parfois des problèmes de multicast quand nous réalisons certains tests ; une conséquence possible de ces problèmes est que les flux multicast se retrouvent broadcastés dans le VLAN où se trouve(nt) le(s) émétteur(s) de flux multicast, ce qui peut sérieusement perturber le réseau si les flux multicast sont d'un gros débit (par exemple, si la somme des débits des flux multicast qui se retrouvent broadcastés est supérieure à 100 Mb, on arrive à une paralysie de tous les équipements branchés sur des ports Fast Ethernet et/ou ayant des interfaces Fast Ethernet). Nous avons notamment remarqué que les téléphones Aastra ont une qualité audio dégradée quand ils recoivent plusieurs flux multicast de quelques Mbit/s auxquels ils ne sont pas abonnés. Le fait de créer un VLAN dédié à la VoIP nous a permis de ne plus avoir de problème de téléphonie quand on a des problèmes de multicast dans le VLAN principal. Comme nous utilisons des switchs non administrables dans certains bureaux pour connecter des PCs et des téléphones IP, nous avons configuré les téléphones pour qu'ils taggent leurs paquets audio et SIP avec le numéro du VLAN dédié à la VoIP ; cela permet aux switchs administrables situés en aval des switchs non administrables d'aiguiller les paquets issus des téléphones IP vers le VLAN dédié à la VoIP.

Attention, il ne faut pas perdre de vue l'essentiel : si on veut avoir une bonne qualité audio, il faut simplement un réseau où il n'y a aucune perte de paquet. En effet, les flux VoIP sont envoyés en UDP sans algorithme particulier de correction d'erreur ni de renvoi de paquet perdu ; toute perte de paquet, si il s'agit d'un paquet transportant le son d'une conversation VoIP, va donc très certainement entraîner une dégradation ponctuelle de la qualité audio. Cette affirmation est valable quand on utilise le codec G711, mais certains codecs comme le G729 sont conçus pour tolérer un certain niveau de perte de paquet sans dégradation de la qualité audio (j'imagine qu'ils utilisent des techniques de type FEC i.e. Forward Error Correction). Si vous avez du matériel réseau de bonne qualité (j'entends par là des switchs administrables qui tiennent un peu la charge, et pas des hubs non administrables même si ils sont de marque) et que vous ne l'utilisez que pour échanger des fichiers bureautique et des mails (c'est à dire que vous l'utilisez à 1% de ses capacités), alors vous n'aurez même pas besoin de mettre en place de QoS, la VoIP marchera très bien sans cela. Par contre, si vous avez des vieux hubs 10 Mb sur lesquels la diode de collision s'allume régulièrement, il faudra absolument faire quelque chose : mettre en place de la QoS ne vous apportera rien car votre hub n'a certainement pas de files de priorité, mais il faudra plutôt mettre votre vieux hub au placard et le remplacer par un vrai switch administrable qui tient la route.

Dans notre entreprise, nous avons un réseau composé uniquement de switchs administrables de bonne qualité (différents modèles de switchs HP Procurve) mis à part les petits switchs non administrables dans certains bureaux, mais certains trafics de données autres sont susceptibles de saturer des liens entre les switchs, d'où l'idée de mettre en place de la QoS.

La fonctionnalité PoE (Power over Ethernet) permet d'alimenter les téléphones en électricité par le câble réseau plutôt que par un bloc d'alimentation spécifique. Il faut que cette fonctionnalité soit supportée par les téléphones IP (ce qui est le cas des téléphones Thomson ST2030, Aastra 6731i et Polycom IP 6000) et par les switchs sur lesquels ils sont branchés (ce n'est pas une fonctionnalité courante sur les switchs ; il vous faudra probablement acheter de nouveaux switchs dans le but de supporter le PoE). L'avantage du PoE est de n'avoir qu'un seul câble utilisé pour les téléphones IP au lieu de deux, ce qui fait plus propre sur les bureaux !

Nous n'avons pas utilisé la fonctionnalité PoE pour notre déploiement initial, mais nous avons par la suite acheté un switch Linksys SRW224G4P ayant 24 ports PoE et 4 ports Giga non PoE. Ce modèle a été choisi en m'aidant des messages dans ce fil de discussion que j'ai lancé sur le forum Asterisk-France. Ce switch donne globalement satisfaction et est simple à utiliser ; il se configure par une interface Web (il y a aussi une interface telnet qui permet d'accéder à un menu très basique). Il permet, tout comme les switchs HP Procurve, de mettre en priorité les flux ayant un champ DSCP particulier. Ce switch possède néanmoins deux gros défauts :

• la configuration des VLANs est un cauchemar ; elle ne peut se faire que par l'interface Web et elle est extrêmement lente, laborieuse et buggée.
• la quasi-totalité des fonctions se paramètrent seulement par l'interface Web... sauf quelques fonctions qui se paramètrent seulement par l'interface telnet (notamment le VLAN de l'interface d'administration du switch) ; il n'est donc pas possible d'utiliser une seule interface pour la totalité de la configuration.

Au final, si vous ne comptez pas utiliser plusieurs VLANs, le switch Linksys SRW224G4P est à recommander pour une utilisation en PoE ; si vous comptez utiliser plusieurs VLANs, choisissez un autre constructeur de switchs PoE. Par exemple, vous pouvez regarder les nouveaux switchs HP Procurve 2520, notamment le switch 2520-24-POE, qui propose 20 ports Fast Ethernet PoE et 4 ports Giga à 575 euros HT chez Busiboutique.

Fonction standard

Le PABX Alcatel de notre installation précédente proposait une solution intéressante pour la gestion du standard. Nous avions un poste dédié au standard, qui sonne quand on reçoit un appel de l'extérieur sur le numéro de téléphone du standard. En plus de cela, il était possible, sur les autres téléphones Alcatel, d'activer ou non une "fonction standard" par simple pression d'une touche dédiée : quand la fonction standard est activée sur un poste, ce poste sonne en plus du poste dédié au standard quand on reçoit un appel de l'extérieur sur le numéro du standard, et c'est le premier qui décroche qui obtient la communication. Cela permet de ne pas rater des appels au standard quand la standardiste est déjà au téléphone ou quand elle n'est pas à son poste.

Malheureusement, il n'existe pas d'équivalent de cette fonctionnalité prêt à l'emploi avec Asterisk et un téléphone IP. Dans le but de ne pas perdre cette fonctionnalité lors de la migration, ce qui n'aurait pas manqué d'alimenter les critiques des utilisateurs, nous avons développé nous-même cette fonctionnalité grâce à de simples scripts AGI. Malheureusement, nous n'avons pas trouvé le moyen de programmer une touche du téléphone Thomson ou de personnaliser son menu pour reproduire le fonctionnement de la touche dédiée à la fonction standard sur les téléphones Alcatel (il aurait fallu être capable d'afficher l'état d'une variable binaire et de la modifier, via un protocole quelconque). Nous avons donc implémenté le système suivant :

1. pour savoir si son poste est en "mode standard" ou non, l'utilisateur compose un numéro de téléphone qui l'amène à un menu vocal programmé dans Asterisk,
2. ce menu vocal va consulter une variable binaire dans AstDB (Asterisk Database) pour le poste en question. Cette variable binaire a été crée spécialement pour cette fonctionnalité : si elle contient 1 alors la fonctionnalité standard est activée, si elle contient zéro elle est désactivée. Le serveur vocal annonce donc à l'utilisateur si la fonctionnalité est activée pour le poste ou non (via des phrases pré-enregistrées par nos soins).
3. ce menu propose alors d'appuyer sur une touche pour modifier l'état de la variable ou de raccrocher si on ne veut pas la modifier.

Au final, cela donne par exemple une annonce vocale du style "La fonctionnalité standard de votre poste est actuellement désactivée. Si vous voulez activer la fonctionnalité standard, appuyez sur la touche 1, sinon, vous pouvez raccrocher". C'est un peu fastidieux, mais ça marche bien. Quand on reçoit un appel au standard :

1. un script AGI s'exécute et consulte l'état de la variable binaire dédié à la fonction standard pour chaque poste. Ce script retourne la liste des postes pour lesquels la variable est à 1
2. Asterisk fait sonner, en plus du poste dédié au standard, tous les autres postes de la liste renvoyée par le script AGI
3. avec cette configuration, c'est le premier qui décroche qui prend la communication.

Cette solution marche bien mais n'est pas très pratique à l'utilisation. Nous ne l'avons finalement pas retenue et nous avons adopté une solution beaucoup plus radicale :

1. quand on reçoit un appel au standard, le poste dédié au standard sonne pendant 15 secondes ;
2. s'il n'a pas décroché au bout de ce temps là, tous les postes présents dans une liste définie par moi-même se mettent à sonner en plus du standard, pendant 15 secondes supplémentaires ;
3. si toujours aucun poste ne décroche, l'appel est basculé sur le répondeur du standard.

L'avantage de cette solution est qu'il permet de pallier au problème suivant : les utilisateurs avaient tendance à ne pas activer la fonction standard sur leur poste pour ne pas assumer la corvée de prendre des appels du standard quand la standardiste n'est pas disponible pour prendre l'appel. L'inconvénient est qu'il faut faire appel à l'administrateur de l'IPBX quand on veut modifier la liste des postes déclarés "solidaires" du standard après les 15 premières secondes.

Société de service

Pour nous accompagner en cas de besoin pendant le déploiement et pour assurer la maintenance du système dans les cas où nous ne saurions pas résoudre les problèmes techniques nous-même, nous avons choisi de recourir aux prestations d'une société de service. Cela permet aussi de s'entourer de gens expérimentés sur Asterisk et la VoIP et d'avoir une personne qui peut intervenir sur le système quand je suis absent de l'entreprise.

Lors du déploiement initial, nous avons mis en concurrence deux sociétés :

• Proformatique, qui est une société française spécialisée sur les solutions VoIP basées sur Asterisk, et qui fait partie des premiers intégrateurs à avoir fait la promotion d'Asterisk en France. Elle propose soit de vendre une appliance Asterisk, i.e. un IPBX basé sur un PC et des cartes téléphoniques sur lequel tourne Asterisk et dont ils maîtrisent intégralement le logiciel (solution dénommée Xivo); soit d'accompagner leurs clients dans le déploiement d'Asterisk sur leur propre plateforme matérielle et logicielle.
• Morea, société de service informatique pour les petites entreprise, qui a de fortes compétences sur Asterisk. Elle propose soit d'installer leur propre version améliorée de Trixbox, soit d'accompagner leurs clients dans le déploiement d'Asterisk sur leur propre plateforme matérielle et logicielle.

Les deux sociétés sont à mon avis un bon choix. Nous avons finalement choisi la société Morea car nous connaissions un des associés de la société, qui nous avait prouvé son sérieux sur des projets antérieurs. Le choix le plus important consiste à opter pour une solution packagée proposée par la société ou pour une solution déployée sur sa propre plateforme matérielle et logicielle. Ces sociétés vous inciterons à opter pour la première solution, qui est plus sécurisante pour eux car ils connaissent parfaitement l'ensemble des composants matériels et logiciels de l'IPBX puisqu'ils ont déjà eu l'occasion de déployer le système à l'identique chez de nombreux autres clients. La deuxième solution a l'avantage pour nous d'être plus indépendant de la société de service retenue, mais elle nécessite de se plonger beaucoup plus profondément dans les aspects techniques d'un déploiement Asterisk, ce qui prend du temps.

Après notre déploiement initial, nous avons travaillé ponctuellement avec Christophe Jeannerot de la société Azylis pour nous assister dans le déploiement de la passerelle SIP/RNIS Patton. Cette société est également un bon choix et possède de très bonnes compétences sur les solutions Asterisk.

Interphone IP avec ouverture de porte

Choix réalisé : interphone PanTel IP d'ITS Telecom.

Si c'était à refaire : j'essayerais l'interphone 2N Helios IP.

Je me suis mis à la recherche début 2009 d'un interphone IP capable de déclencher l'ouverture d'une porte. Notre vieil interphone analogique n'était pas relié à notre IPBX et cela nous manquait. Après la lecture de cette page et quelques recherches Google, j'ai identifié 3 interphones SIP avec commande d'ouverture de porte :

• Valcom VIP 172 : Page du produit - Datasheet - Prix : 600 $ sur ce site - Constructeur Américain. Supporte le SIP, s'alimente par PoE, interface Web de configuration, NTP ; codecs non précisés. La doc du produit n'est pas disponible en ligne, ni le firmware.
• ITS Telecom Pantel IP : Page du produit - Datasheet - Prix : 390 euros HT chez MPI en France (prix d'Avril 2009) - Constructeur Israëlien. Supporte le SIP avec un nombre impressionnant de codecs (cf datasheet), interface Web de configuration, echo canceler, alimentation en PoE possible (sauf si commande d'une gâche électrique, car la puissance d'alimentation de la gâche est trop importante pour du PoE ; mais dans le cas de la commande par contact sec, l'utilisation du PoE est possible, ce qui est confirmé par notre propre expérience). La doc du produit est disponible sur le site du constructeur (35 pages), mais pas le firmware (il faut le demander à son revendeur).
• 2N Helios IP : Page du produit + Datasheet - Le prix varie en fonction des nombreuses options disponibles ; à titre indicatif (prix relevés chez Wildix en Avril 2010 en ajoutant le prix de la façade 9135331E 2N Helios Surface 1-module roof) :
  • 2N Helios IP 9137131E (3 boutons d'appel) : 568 euros HT
  • 2N Helios IP 9137131CE (3 boutons d'appel + caméra) : 717 euros HT
  • 2N Helios IP 9137160CKDE (6 boutons d'appel + caméra + digicode + écran couleur) : 919 euros HT
  Constructeur Tchèque. Supporte le SIP avec codec G711 A/u-law, alimentation par PoE, configuration par interface Web, NTP. Il dispose de nombreuses options : plusieurs boutons d'appel (jusqu'à 6), caméra IP intégrée, digicode, écran couleur, etc... Le firmware est disponible sur la page du produit ainsi que la documentation (81 pages). Sylvain Boily de ProFormatique m'a indiqué qu'ils utilisaient cet interphone avec Asterisk et qu'il marchait très bien.

Note : il est possible de relier un interphone analogique à un IPBX via un port FXO/FXS, mais ce n'est pas la solution que nous recherchions.

J'ai finalement choisi le Pantel IP d'ITS Telecom.

Nous avons eu la mauvaise surprise de constater assez rapidement après la configuration initiale de l'interphone (qui se fait par interface Web) que, lors d'une communication entre l'interphone et un téléphone ST2030, la personne à l'interphone n'entendait pas la voix de la personne au téléphone. Dans un premier temps, nous avons vérifié le réglage du niveau du haut-parleur côté interphone (réglage soft dans l'interface Web et réglage hard via un potentiomètre présent sur la carte électronique). Ensuite, nous avons testé en remplaçant le ST2030 par un softphone, et, surprise : le problème n'était pas présent avec un softphone ! Après une longue séance de debug au tcpdump/wireshark, une tentative de bidouillage du SIP via un patch sur Asterisk, des essais avec d'autres versions de firmware sur le ST2030, une demande de mise-à-jour du firmware de l'interphone (en fait, nous avions déjà la dernière version), nous nous apprêtions à envoyer un bug report au fournisseur... et l'interphone s'est alors mis à fonctionner comme par miracle ! Nous n'avons depuis jamais rencontré le problème de nouveau... cela reste inexpliqué pour nous !

Nous avons alors décidé de déployer l'interphone IP en gardant en parallèle notre interphone analogique en cas de problème ; ceci était tout à fait possible de part le mécanisme de commande de notre porte d'entrée (contact sec ouvert par défaut). Nous avons fait venir notre installateur habituel de solutions de contrôle d'accès, la société Paris 15 Sécurité, qui a réalisé la pose de l'interphone et le lien avec la commande d'ouverture de porte. Tout s'est bien passé et l'interphone fonctionne parfaitement depuis qu'il a été posé. Nous avons seulement constaté lors du déploiement que l'interphone ne fonctionnait pas avec les quelques téléphones ST2030 qui étaient encore en firmware 1.58 ; nous les avons donc upgradé en firmware 1.65 et tout est rentré dans l'ordre.

Actuellement, l'interphone est configuré pour composer un numéro spécial de notre dialplan qui exécute une fonction qui fait sonner plusieurs téléphones en fonction de l'heure de la journée. La personne qui décroche l'appel de l'interphone est alors immédiatement en conversation avec son interlocuteur à l'interphone et n'a plus qu'à appuyer sur une touche du téléphone pour déclencher l'ouverture de la porte ; en fait, l'interphone reçoit le signal DTMF envoyé par le téléphone lors de l'appui sur la touche et, si il correspond au paramètre Door opening code from extension configuré dans l'interface Web de l'interphone, ferme le contact sec qui déclenche l'ouverture de la porte.

Au final, voilà mon avis sur l'interphone Pantel IP :

• Qualités :
  • pas de problème de fiabilité : il marche très bien depuis que nous l'avons déployé.
  • pas de problème de compatibilité Asterisk.
  • prix intéressant.
• Défauts :
  • problème d'écho pour la personne au téléphone (la personne qui est à l'interphone n'a pas ce problème) : j'ai essayé de jouer sur le niveau du micro de l'interphone (réglable en soft), sur le niveau du haut parleur de l'interphone (réglable en soft et en hardware via un potentiomètre), etc... mais sans succès.
  • l'accès à l'interface Web d'administration de l'interphone n'est pas protégée par login et mot de passe ; cette fonctionnalité, pourtant très basique, n'est tout simplement pas supportée !
  • les nouveaux firmwares ne sont pas librement téléchargeables pour les clients sur le site du constructeur ; pour obtenir les nouveaux firmwares, il faut s'adresser au revendeur, et personne ne nous prévient de la disponibilité de nouveaux firmwares.
  • la procédure de mise à jour du firmware est trop compliquée : la mise à jour du firmware se fait par TFTP (facile !), mais, pour initier la mise à jour au niveau de l'interphone, il faut se connecter à la carte électronique embarquée dans l'interphone par un câble série spécial !
  • il n'existe pas d'option ou de modèle similaire dans la gamme d'ITS Telecom permettant d'avoir plusieurs boutons d'appel sur le même interphone.

Conseils sur l'installation et la configuration des différents composants

Le serveur Asterisk

Comme notre déploiement initial date d'Août 2007, ce qui était expliqué dans cette section sur l'installation d'Asterisk était en grande partie obsolète. J'ai donc supprimé cette partie et je n'ai gardé que les éléments qui pourraient encore être utiles aujourd'hui.

Voici certains de mes fichiers de configuration d'Asterisk, dans l'espoir que cela puisse être utile à d'autres personnes :

• /etc/asterisk/sip.conf : fichier de configuration de SIP pour Asterisk,
• /etc/asterisk/voicemail.conf : fichier de configuration du voicemail d'Asterisk.

Ces fichiers utilisent un encodage UTF-8. Pour qu'ils s'affichent correctement dans votre navigateur, vous aurez peut-être besoin d'aller dans le menu Affichage, Encodage des caractères, Unicode UTF-8 (sous Firefox).

Pour l'installation du fax2mail à l'époque où on recevait les fax sur notre serveur Asterisk, j'ai procédé en deux temps :

1. Installation d'IAXmodem et de Hylafax en suivant ce tutoriel. Pour ceux qui utilisent Debian, les versions d'IAXmodem et de Hylafax présentes dans Debian stable sont suffisamment récentes pour pouvoir être utilisées, pas besoin de prendre les sources des logiciels et de les compiler.
2. Installation d'Avantfax en suivant la doc d'installation (il faut avoir un peu de temps devant soi !)

La passerelle SIP/RNIS Patton SN4683

Nous n'utilisons plus le boitier Patton depuis Juillet 2010, date à laquelle nous avons migré vers un opérateur IP. Je laisse quand même cette section, car elle pourra intéresser les personnes qui déploient des passerelles SIP/RNIS Patton.

Nous avons déployé la passerelle Patton en version de firmware 4.2 (la dernière version du firmware en Juin 2009 était la 5.3), car la personne d'Azylis avec qui nous avons déployé ce boitier nous a dit que les firmwares 5.x avaient intégré une évolution majeure qui permettait au boitier de faire office de serveur SIP simple (ce qui transforme le boitier en mini-IPBX !), et qu'il valait mieux pour le moment utiliser les firmwares antérieurs à cette évolution majeure.

Voici notre fichier de configuration du boitier Patton.

Nous avons réalisé la configuration par l'interface Web. Il est aussi possible d'utiliser la ligne de commande (accès telnet) pour configurer le boitier.

Le port WAN est connecté à notre réseau local ; nous n'utilisons pas le port LAN, mais il est quand même configuré avec un serveur DHCP qui écoute sur ce port ; cela permet, en cas de problème au niveau du réseau local ou de la configuration du port WAN, de venir brancher son ordinateur portable directement sur le port LAN et d'avoir ainsi facilement accès au serveur telnet du boitier.

Je vous conseille de lire au moins le chapitre 2 de la doc qui explique les concepts de configuration et notamment les deux contexts : IP et CS. On retrouve d'ailleurs certains concepts Unix dans la configuration d'une Patton, notamment la nécessité de binder un élément sur un autre : par exemple, dans mon fichier de config, l'interface SIP gw-sip est bindé sur la gateway SIP sip (c'est au niveau de la gateway qu'est configuré le compte SIP d'Asterisk), qui est elle-même bindée sur l'interface WAN (qui porte l'adresse IP). On retrouve aussi la nécessité de binder une interface sur un port physique : toujours dans mon fichier de config, l'interface IP WAN est bindée sur le port Ethernet 0 0 ; le port BRI 0 0 est bindé sur l'interface T0-1, le port BRI 0 1 est bindé sur l'interface T0-2, etc....

Une fois que toutes les interfaces sont configurées et que les différents éléments sont bien bindés, il reste 2 choses importantes à faire, qui se paramètrent dans le context CS :

• router les appels entrants par chacune des interfaces RNIS vers le compte SIP : dans mon fichier de config, ils sont routés vers l'interface SIP gw-sip :

  context cs switch
  
    interface isdn T0-1
      route call dest-interface gw-sip
  
    interface isdn T0-2
      route call dest-interface gw-sip
  
    interface isdn T0-3
      route call dest-interface gw-sip
  

• router les appels entrants par SIP vers les interfaces RNIS : dans mon fichier de config, ils sont routés vers le hunt-group dénommé Group-T0, qui est configuré pour regrouper les 3 interfaces RNIS que nous utilisons :

  context cs switch
  
    interface sip gw-sip
      bind gateway sip
      service default
      route call dest-service Group-T0
  

Mon pense-bête Patton :

• login par défaut : administrator
• mot de passe par défaut : vide !
• upgrade : en mode enable : copy tftp://192.168.1.3/SN4600_H323_SIP_R4.2_2008-09-11.zip flash: puis reload
• TODO : à compléter

Les téléphones Thomson ST2030

Je ne vais pas réexpliquer ici ce qui est expliqué dans la documentation de Thomson, mais plutôt vous faire part de mon expérience dans ce domaine.

Vu que la taille de notre parc (plusieurs dizaines de téléphones), il est hors de question de les configurer un par un via leur interface Web. Nous avons donc opté pour la configuration en provisionning TFTP. Le plus long et fastidieux a été de mettre au point les fichiers de configuration, car il y a énormément de paramètres, qui n'ont pas tous la même importance... Je vous fourni mes fichiers de configuration, en espérant que ça vous fera gagner du temps.

Premier piège à éviter : quand on fait une modification dans un fichier de configuration du téléphone en partage TFTP, si on veut que le téléphone daigne tenir compte de la modification à son prochain reboot, il y a souvent une manipulation supplémentaire à faire, qui est détaillée dans le tableau ci-dessous.

Au niveau de mon serveur TFTP, tous les fichiers ST2030S_MACtelephone.inf sont des liens symboliques vers le même fichier que j'ai appelé ST2030S_all.inf.

J'ai mis en ligne mes fichiers :

• ComConf2030S,
• ST2030S_all.inf,
• ST2030S_MACtelephone.txt,

J'ai mis un maximum de commentaires à l'intérieur des fichiers. Vous êtes libres de les utiliser... j'espère qu'ils vous seront utiles ! Ces fichiers sont en encodage ASCII ou ISO-8859.

Deuxième piège : il faut toujours partir du fichier TelConf fourni par Thomson. Je veux dire qu'à chaque fois que vous voulez mettre à jour vers un nouveau firmware, il ne faut pas garder le fichier TelConf que vous utilisiez avec le firmware précédent (qu'il ait été personnalisé ou non), mais toujours prendre le fichier TelConf fourni avec le nouveau firmware, et le re-personnaliser si besoin. Dans mon cas, la seule modification que j'apporte au fichier TelConf de Thomson est la désactivation de l'auto-détection de la voix (paramètre VAD comme Voice Auto Détection) pour le codec que j'utilise, à savoir le G711A. Dans la section G711A du fichier TelConf, j'ai donc :

set coding 0 vad  off

Truc et astuce : pour rebooter facilement le téléphone, il suffit d'appuyer simultanément sur les touches répertoire, haut-parleur et bis (touche avec une double flèche vers le haut).

Les téléphones Aastra 6731i

La configuration des téléphones Aastra 6731i est beaucoup plus simple celle des téléphones ST2030 : moins de fichiers de configuration, rien de particulier à faire quand on met à jour un fichier de configuration (pas besoin de changer son nom ou de changer un paramètre comme avec les ST2030). Vous trouverez les firmwares et la documentation sur le site d'Aastra dans la rubrique Support / Download Area.

Pour configurer les téléphones de façon centralisée, il suffit de mettre en partage TFTP 4 fichiers, dont le détail est donné ci-dessous. L'IP du serveur TFTP contenant les fichiers de configuration sera donnée au téléphone par le serveur DHCP via l'option tftp-server-name (comme pour les téléphones ST2030).

La pieuvre de conférence Polycom IP 6000

Tout d'abord, armez-vous de patience, car la configuration est au moins aussi compliquée que celle des téléphones Thomson ST2030. De plus, elle n'est pas particulièrement pratique car il faut personnaliser d'énormes fichiers XML de plusieurs centaines de lignes. Justement, une des choses qui m'a fait perdre plusieurs heures est que j'ai commencé à préparer mes fichiers de configuration après avoir lu le Administrator guide... et je n'avais pas encore lu le white paper Configuration File Management on SoundPoint IP Phones. Or ce white paper contient une information importante qui n'est apparemment pas présente dans le guide Administrateur : quand on veut mettre à jour le firmware du téléphone, il faut impérativement repartir des fichiers de configuration livrés avec le firmware sinon on risque d'avoir des problèmes. Or ces fichiers de configuration, en particulier sip.cfg, sont énormes (700 lignes de XML pour sip.cfg). Il faut donc créer soi-même un dérivé du fichier de configuration original qui ne contiendra que les paramètres ayant besoin d'être changés, et indiquer à la fois le fichier original et le fichier dérivé dans le fichier de configuration maître du téléphone, en faisant attention à ce que le nom du fichier dérivé précède celui du fichier original pour que les paramètres définis dans le fichier dérivé overrident ceux du fichier original.

Je mets en partage les fichiers à personnaliser :

• MAC_telephone_polycom.cfg
• sip-custom.cfg
• phone-custom-conf1.cfg

La QoS sur le réseau

Comme je l'ai expliqué dans la section Réseau du chapitre Choix et motivation des choix, nous avons choisi d'utiliser de la QoS au niveau IP, appelée DiffServ, pour mettre le trafic VoIP en priorité par rapport à tous les autres trafics. La méthode retenue a été de tagger les paquets IP avec un champ DSCP particulier et de déclarer au niveau du matériel réseau que les flux ainsi taggés ont une priorité maximale.

Tout d'abord, je vous conseille la lecture de l'article sur DiffServ dans Wikipedia. Pour vérifier que vous avez bien tout compris, voilà une petit résumé : dans l'entête des paquets IP, il y a 8 bits réservés au champ TOS (Type of Service), aussi appelé DiffServ. Les 6 premiers bits du champ TOS constituent le champ DSCP. Par convention, on met ce champ à la valeur 101 110 pour les flux de priorité maximale ; cela s'appelle la classe DSCP Expedited Forwarding (EF). Les 2 derniers bits forment le champ ECN (Explicit Congestion Notification), qui ne nous intéressent pas dans notre cas.

Nous voulons donc que les flux VoIP soient taggés ainsi :

Pour mettre en place la QoS, il faut :

• que les téléphones taggent les flux IP qu'ils envoient, ce qui se configure différemment pour chaque marque de téléphone (les fichiers de configuration que je mets en partage vous donneront la solution pour les téléphones Thomson, Aastra et Polycom ainsi que pour la passerelle Patton),
• qu'Asterisk tagge les flux IP qu'il envoie, ce qui se configure dans le fichier sip.conf (paramètres tos_sip=ef et tos_audio=ef),
• que les switchs donnent la priorité maximale aux flux ainsi taggés... c'est ce qu'il nous reste à faire !

Sur les switchs HP Procurve modèles 2510, 2810, 2824 et 2848 (la fonctionnalité de QoS n'est pas disponible sur les Procurve 2524), cela se configure de la façon suivante. Tout d'abord, il faut activer la gestion de la QoS DiffServ :

switch(config)# qos type-of-service diff-services

Pour vérifier que la fonctionnalité QoS DiffServ a bien été activée :

switch# show qos type-of-service

  Type of Service [Disabled] : Differentiated Services


  Codepoint DSCP Policy | Priority   
  --------- ----------- + -----------
  000000                | No-override
[...]
  101101                | No-override
  101110                | 7          
  101111                | No-override
[...]

Il faut dire au switch que les flux dont le champ DSCP est 101 110 doit être traité en priorité maximale, qui est la priorité 7. En fait, c'est le réglage par défaut, comme on peut le voir ci-dessus.

Pour les switchs Linksys SRW224G4P, cela se configure dans l'interface Web du switch.

Interconnexion avec un opérateur IP

Portage des numéros

Le portage des numéros de téléphone de France Télécom vers le nouvel opérateur IP est une opération qui se fait directement entre les deux opérateurs, sans notre intervention. Après avoir convenu du jour du basculement avec le nouvel opérateur, celui-ci nous confirme la date du portage et l'heure approximative (dans notre cas, on nous avait dit que cela aurait lieu entre 10h et 12h... l'intervalle était plutôt large ! Et pour l'anecdote, la portabilité a eu lieu à 12h20 !). D'après ce que j'ai compris, l'opération de portage est "manuelle" et se fait par téléphone entre des techniciens de France Telecom et des techniciens du nouvel opérateur.

Concrètement, d'après ce que j'ai compris, l'opération consiste en une mise à jour des tables de routage téléphonique du côté de France Télécom ; en effet, les numéros de téléphone continuent d'être associés à France Télécom, et France Télécom met en place une sorte de renvoi d'appel permanent vers le nouvel opérateur. D'après ce que m'a dit Acropolis Telecom, les communications téléphoniques en cours au moment du portage ne sont pas coupées. Je voulais le vérifier à l'occasion du portage de nos numéros, mais l'heure exacte du portage était trop imprécise pour que je le fasse.

Comme quand on change d'opérateur de téléphone mobile avec portage du numéro, la résiliation des lignes chez l'ancien opérateur est automatique, pas besoin d'écrire une lettre de résiliation.

Pour que l'opération de portage soit transparente, il faut préparer plusieurs jours à l'avance le serveur Asterisk :

1. connecter le serveur Asterisk à la ligne SDSL et mettre à jour sa configuration réseau.
2. mettre en place le trunk IAX via la ligne SDSL. Dès que le trunk IAX est "tombé en marche", nous avons modifié le dialplan pour que les appels sortants passent par le trunk IAX ; cela nous a permis de tester le bon fonctionnement du trunk et de la ligne SDSL et de vérifier la qualité audio des communications plusieurs jours avant le portage des numéros. Je conseille de faire cela suffisamment à l'avance par rapport à la date de portage prévue pour pouvoir la repousser si un problème est constaté sur les appels sortants par le trunk ; en effet, notre nouvel opérateur nous avait dit qu'il fallait le prévenir plusieurs jours à l'avance si on souhaitait changer la date de portage des numéros. Il faut aussi tenir compte des instructions données par l'opérateur IP pour :
   • le format des numéros à appeler, à adapter dans extensions.conf ; dans le cas d'Acropolis Telecom, le format est le même que pour les lignes RNIS : pour les appels à destination de la France, il faut présenter le numéro appelé sous le format national, par exemple 0170725015, et pour l'étranger, il faut le présenter sous le format 00+CC+XXXXXXXXX où CC est le code du pays.
   • le format du numéro appelant, à adapter dans sip.conf ; dans le cas d'Acropolis Telecom, les instructions étaient de présenter le numéro sous le format national sans le 0 au début, par exemple 170715015.
3. adapter le dialplan pour le préparer à recevoir les appels par le trunk : dans notre cas, cela a simplement consisté à dupliquer temporairement le code du contexte de réception des appels pour matcher à la fois sur les 4 derniers numéros (fonctionnement avec les lignes RNIS) et sur les numéros complets (fonctionnement avec le trunk). Par exemple :

   ; le code pour la réception d'appel via RNIS
   exten => _3341,1,Macro(dial-voicemail-ext,20)
   
   ; le même code pour la réception d'appel via le trunk IAX
   exten => _0142993341,1,Macro(dial-voicemail-ext,20)
   

Si l'interconnexion avec votre opérateur IP se fait par un trunk IAX, ce sera peut-être la première fois que vous aurez affaire à ce protocole. Je vous conseille de lire cette petite doc qui explique en très résumé (5 petites pages) le fonctionnement d'IAX et les différences avec SIP.

La problématique du fax dans l'opération de basculement vers l'opérateur IP est expliquée dans la section concernant le fax.

Dès que le portage a été effectif, nous avons tout de suite procédé à des tests pour vérifier que tout fonctionnait bien :

• tests de réception d'appel : vérification de la présentation du numéro appelant et du bon établissement de la communication.
• tests de réception de fax. Cela nous a permis de détecter très rapidement qu'Acropolis Telecom avait oublié de mettre en place le service de fax2mail que nous avions demandé, et de leur demander de corriger leur erreur !

Architecture d'interconnexion

Nous avons choisi de relier notre serveur Asterisk directement au modem SDSL, en ajoutant une 2ème carte réseau dans le serveur Asterisk.

Acropolis Telecom nous avait fourni un routeur Zyxel Prestige 334 à installer entre le serveur Asterisk et le modem SDSL. Nous avons demandé à Acropolis Telecom à quoi servait exactement ce routeur. En fait, ce routeur fait du NAT entre son interface WAN qui porte l'IP publique de la ligne SDSL et son interface LAN qui porte une IP privée (il y a aussi un serveur DHCP qui tourne sur l'interface LAN). Ce routeur permet en fait à Acropolis d'être sûr que l'IP publique de la ligne SDSL répond bien au ping, de vérifier la négociation Ethernet (10/100 Mb, half/full duplex) des deux côtés du routeur et d'avoir un NAT pour "protéger" le serveur Asterisk. Nous avons finalement décidé de ne pas utiliser ce routeur Zyxel et de brancher directement le modem SDSL au serveur Asterisk, en faisant porter l'IP publique de la ligne SDSL par le serveur Asterisk, car nous avons préféré ne pas ajouter un équipement non essentiel et susceptible de tomber en panne entre notre serveur Asterisk et le serveur IAX d'Acropolis. Par contre, on a fait attention à ce que notre serveur Asterisk réponde bien aux pings du côté de la ligne SDSL et qu'il soit maintenu à jour au niveau de la sécurité (même si en fait l'IP publique de notre ligne SDSL n'est pas joignable par Internet).

Pour l'anecdote, on n'avait initialement pas réussi à connecter la 2ème interface réseau de notre serveur Asterisk directement au modem SDSL... et on s'est ensuite aperçu que le problème venait du fait qu'on avait utilisé un câble droit au lieu d'un câble croisé ! On a tellement l'habitude aujourd'hui de travailler avec des interfaces Ethernet qui font de l'auto MDI/MDI-X, qu'on en vient à oublier la question des câbles droits ou croisés, or l'interface Ethernet du modem SDSL ne faisait pas d'auto MDI/MDI-X et la vieille carte Ethernet que j'avais ajoutée dans le serveur Asterisk n'en faisait pas non plus !

Pour la solution de backup en cas de panne du lien SDSL, comme expliqué dans la section choix du canal de communication vers l'extérieur, nous avons choisi d'avoir un basculement automatique du trunk IAX vers la connexion Internet de l'entreprise, qui est en fait une connexion ADSL classique.

Pour cela, nous avons développé un script qui est lancé au démarrage du serveur Asterisk et qui tourne en tâche de fond. Ce script fait régulièrement un ping vers le serveur IAX d'Acropolis ; si le ping ne répond pas pendant un certain temps, il en déduit que le lien SDSL est down et il ajoute une route spéciale dans la table de routage du serveur Asterisk pour router le traffic vers le serveur IAX d'Acropolis via l'interface d'Asterisk connectée au LAN de l'entreprise, qui est lui-même relié à Internet par un accès ADSL classique. Après ce basculement vers le lien de backup, le script se met alors à pinguer un autre serveur Acropolis habituellement joignable par la ligne SDSL (en l'occurence un serveur DNS) et, si il se met à répondre, il supprime la route qu'il avait précédemment ajoutée, ce qui a pour conséquence de faire de nouveau passer le trunk IAX par la ligne SDSL.

Les imperfections qu'il reste à corriger

Voilà la liste des points qu'il me reste à résoudre pour être parfaitement satisfait de mon déploiement VoIP avec Asterisk. Cette liste s'est réduite au fur et à mesure et ne comporte plus qu'un seul élément :

• problème de présentation du numéro lors d'un transfert d'appel. Voilà le scénario du problème : le poste A reçoit un appel de l'extérieur et voit le numéro du correspondant qui s'affiche sur son écran ; il décroche puis transfère l'appel vers le poste B ; le poste B est alors en ligne avec le correspondant extérieur mais le numéro qui est présenté sur son écran est celui du poste A.

  J'ai reçu un éclairage de Sylvain Boily de Proformatique sur ce sujet, et il m'indique que ce problème a été résolu tout récemment par un patch qui permet d'activer le p-asserted, que ce patch sera inclus dans une prochaine version d'Asterisk, et qu'il faudra activer la fonction dans sip.conf et dans les téléphones IP. D'après mes recherches complémentaires et le témoignage d'un lecteur qui a réussi à faire marcher le patch sur son serveur Asterisk, cette fonctionnalité est arrivée suite au travail sur le bug 8824 d'Asterisk, et sera inclus dans la version 1.8.0 d'Asterisk (la version 1.8.0-beta1 est sortie le 23 Juillet 2010), cf ce commit. Cela est confirmé par les informations du fichier CHANGES qui mentionne bien au niveau des modifications SIP : The 'sendrpid' parameter has been expanded to include the options 'rpid' and 'pai'. Setting sendrpid to 'rpid' will cause Remote-Party-ID header to be sent (equivalent to setting sendrpid=yes) and setting sendrpid to 'pai' will cause P-Asserted-Identity header to be sent. . Pour faire marcher cette fonctionnalité, il faudra ajouter les paramètres suivants dans sip.conf :

  [general]
  assertedidentity=yes
  needprack=yes
  rpidtype=passerted
  sendrpid=yes
  

  Plus d'infos sur le paramètre sendrpid ici. Il faut aussi activer la fonction adéquate sur les téléphones IP ; sur les téléphones ST2030, cela se fait a priori avec le paramètre CodeDisplayPrior ; sur les téléphones Aastra, cette fonctionnalité est a priori activée par défaut. Si cette fonction est très importante pour vous et que vous ne voulez pas attendre la prochaine version officielle d'Asterisk qui intègrera cette fonctionnalité, vous pouvez appliquer le patch disponible ici sur les sources d'Asterisk et le recompiler.

Si vous avez des informations complémentaires, je serai ravi de recevoir un mail de votre part !

Les commandes de diagnostic

pour les téléphones ST2030

Voici une liste de commandes que j'utilise pour diagnostiquer un problème sur un téléphone ST2030, après m'être connecté en telnet sur le poste :

• Pour voir la version du firmware :

  # version

• Pour voir la version des différents fichiers de configuration, ce qui me permet de vérifier que le téléphone est bien à jour avec la dernière version des fichiers de configuration :

  # autoprovision show

• Après, quand je veux vérifier qu'un certain paramètre du fichier de configuration a bien été pris en compte, je chercher dans le document ST20XXS_Config File Syntax_version.pdf (fourni dans le ZIP du firmware de Thomson) la commande permettant d'afficher la valeur du paramètre et je la tape dans la ligne de commande.

pour Asterisk

En cas de problème avec Asterisk, j'ai le réflexe d'utiliser les commandes suivantes au prompt d'Asterisk ou au prompt du shell du serveur :

• Pour voir les entités SIP :

  asterisk*CLI> sip show peers
  

• Pour voir les entités SIP en communication (très pratique quand on a besoin de faire une opération de maintenance qui va couper Asterisk et qu'on ne veut pas couper une conversation en cours) :

  asterisk*CLI> sip show inuse
  

• Quand je veux voir les échanges SIP entre un téléphone et Asterisk, je suis parfois amené à utiliser tcpdump :

  # tcpdump -n -A -s 65535 host 10.1.2.3 and port 5060

  où 10.1.2.3 est l'IP du téléphone.

pour la passerelle Patton

Voilà les commandes que j'utilise pour diagnostiquer un problème sur la passerelle SIP/RNIS Patton à travers l'interface telnet :

• pour voir la configuration en cours :

  # show running-config
  

• pour voir la configuration de démarrage :

  # show startup-config
  

• pour activer les logs de signalisation RNIS :

  # debug ccisdn error
  # debug ccisdn signaling
  

  Les logs s'affichent alors en direct dans la console. Si on veut encore plus de logs RNIS :

  # debug isdn error
  # debug isdn event 0 0 all
  

  où 0 0 désigne le numéro du port BRI que l'on veut étudier de plus près.

Anciens schémas d'architecture

Schéma d'architecture de Juin 2009 à Juillet 2010

Voilà l'architecture après le déploiement de la passerelle SIP/RNIS et avant l'utilisation d'un opérateur IP :

Schéma d'architecture jusqu'en Juin 2009

Voilà l'architecture avant le déploiement de la passerelle SIP/RNIS, quand on utilisait la carte PCI B410P pour accéder aux lignes RNIS, et après l'utilisation d'une ligne analogique pour l'envoi des fax :

Schéma d'architecture initial

Voilà l'architecture initiale de notre déploiement VoIP avant l'utilisation d'une ligne analogique pour l'envoi des fax et avant le déploiement de la passerelle SIP/RNIS :

XHTML 1.1 et CSS valides