Promouvoir et soutenir le logiciel libre

Expérience de déploiements Asterisk dans des entreprises françaises

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...

Introduction

A propos de l'auteur

Dans le cadre de mon activité professionnelle, je propose mes services de déploiement et d'expertise sur les solutions Asterisk. Je propose par exemple de réaliser des installations d'IPBX Asterisk et de téléphones IP dans des PMEs pour un prix forfaitaire. Si vous êtes intéressé, n'hésitez pas à me contacter par mail à l'adresse qui figure au début de ce document.

Par ailleurs, je suis l'auteur du connecteur Asterisk-OpenERP (OpenERP est un ERP en logiciel libre). Ce module est sous licence AGPL, la même licence qu'OpenERP, et il est hébergé sur Launchpad, comme l'ensemble du projet OpenERP. Une documentation complète est disponible en anglais. Ce module a 3 fonctionnalités :

Je suis membre de la sympatique association Asterisk France ; mon nom sur le forum est sixela.

Dans la même série, j'ai publié en Octobre 2012 un document intitulé Expérience de déploiements OpenERP dans des entreprises françaises.

Historique du document

Date Changement
2008-01-13 Version initiale
2008-01-27 Relecture et ajout du diagramme (vive OpenClipart !)
2008-02-01 C'est bon, j'ai réussi à faire marcher le call pick-up sur les ST2030, cf l'explication dans ce fil de discussion sur le forum d'Asterisk France. Nouveau fichier Common Config de ST2030 mis en partage.
2008-04-27 Mise à jour concernant l'émission de fax. Mise en partage d'un certain nombre de mes fichiers de configuration d'Asterisk.
2008-06-03 Ajout sur les channel bank Ethernet/RNIS comme alternative à une carte RNIS PCI.
2008-08-12 Selon ce message dans le forum Asterisk France, le firmware 1.62.3 des téléphones ST2030 permettrait d'utiliser le call pick-up avec les touches de fonction sans patcher Asterisk... il va falloir que je teste ça !
2008-09-06 J'ai trouvé un bug dans les firmwares 1.62 des téléphones ST2030 quand ils sont utilisés avec le module d'extension. Le firmware 1.63 est a priori également affecté. Tous les détails sont sur ce fil de discussion dans le forum Asterisk France. Du coup j'ai downgradé mes deux téléphones qui ont le module d'extension en firmware 1.58 et tout marche bien.
2008-10-28 Thomson a releasé un firmware 1.64, qui, selon les release notes de Thomson et ce message dans le forum Asterisk France corrige le bug que j'avais trouvé dans les firmwares précédent et qui affectait les téléphones ST2030 dotés d'une extension. Je n'ai pas encore eu le temps d'essayer ce nouveau firmware.
2008-11-16 Quelques ajouts sur les channel bank RNIS, suite à une recherche sur le sujet.
2009-01-04 Baisse de prix des channel bank RNIS Patton... je vais peut-être finir par en acheter un quand j'aurai le temps de le déployer !
2009-03-01 Remontée brutale des prix des channel bank RNIS Patton chez IP and Go, ce qui ramène ces boitiers à leurs prix antérieurs. Début de mes recherches sur les interphones SIP avec commande d'ouverture de porte. Mise à jour des URLs vers Asterisk-France.net. Info intéressante : les drivers mISDN font maintenant partie du kernel 2.6.27, comme expliqué ici.
2009-03-22 MAJ au niveau des channel bank RNIS et sur les opérateurs VoIP (suite à mes nouvelles recherches sur le sujet).
2009-04-08 J'ai reçu aujourd'hui au bureau l'interphone SIP (modèle PanTel IP d'ITS Telecom). 1ère surprise : le bouton "Call" n'est pas vraiment un bouton ! En fait, il n'y a pas réellement de bouton sur le boitier mais seulement une marque noire qui délimite l'emplacement du bouton sur le boitier. Apparemment, il s'agit d'un bouton Piezzo-électrique qui détecte la pression sur le métal du boitier à ce endroit. Le seul souci est que ça ne donne pas du tout l'impression que c'est un vrai bouton sur lequel il faut appuyer pour appeler ! J'espère pouvoir jouer avec cet interphone et donner mes premières impressions très bientôt.
2009-04-10 L'interphone SIP PanTel IP fonctionne... à un détail près : on entend la personne qui parle dans l'interphone, mais la personne à l'interphone n'entend pas son interlocuteur. J'ai essayé d'ajuster le niveau sonore du haut parleur de l'interphone, mais sans succès. D'après le support, je suis en dernière version de firmware. Il va donc falloir que je creuse le sujet...
2009-04-11 J'ai testé il y a quelques semaines le firmware 2.67 des téléphones ST2030, mais j'ai découvert un bug : le call pickup avec les touches de monitoring ne fonctionne plus ! J'ai remonté le problème dans ce fil de discussion du forum Asterisk-France, et d'autres utilisateurs ont confirmé le bug et en ont trouvé d'autres. Décidément, il devient difficile de trouver un firmware ST2030 récent qui fonctionne correctement, et on est obligé de déployer différentes versions de firmware sur nos téléphones en fonction de l'utilisation qui en est faite et de la présence ou non d'un module d'extension. Je ne suis pas le seul à faire ce constat : dans le même fil de discussion, l'utilisateur yold en a également marre. Après réflexion, j'ai donc décidé de modifier mes commentaires sur le téléphone ST2030 pour souligner la mauvaise qualité des firmwares Thomson, jusqu'à ce que Thomson se décide à sortir des firmwares moins buggés. Même si l'audience de cette page Web reste modeste, elle est quand même en bonne position dans Google quand on recherche "ST2030 asterisk", et j'espère que cela réveillera certaines personnes en charge du développement produit chez Thomson !
2009-06-08 Nous avons déployé notre interphone SIP Pantel IP avec succès. Le problème de communication où on entend la personne qui parle dans l'interphone mais pas l'inverse a disparu comme par enchantement. Tout marche bien, y compris la commande d'ouverture de porte : pendant la communication avec l'interphone, on appuie sur une touche et le signal DTMF est interprété par l'interphone pour déclencher l'ouverture de la porte. La commande d'ouverture de notre porte est faite par un contact sec ouvert par défaut i.e. il faut que le contact soit fermé pour que la porte s'ouvre. Il est aussi possible d'avoir un contact sec fermé par défaut, mais aussi de commander une gache électrique en mode "ouvert si alimenté" ou en mode "fermé si alimenté". Il reste encore à résoudre le problème d'écho entre les téléphones ST2030 et l'interphone, qui est probablement causé par un écho acoustique... à creuser.
2009-06-14 Nous avons déployé cette semaine un Channel bank RNIS/Ethernet, modèle Patton SN4638. Pourquoi ? Parce qu'on avait des problèmes d'écho sur certaines conversations téléphoniques (cela restait très rare), et que nous avions de toute façon besoin d'avoir une redondance sur notre accès RNIS. Notre Patton SN4683 est donc en production depuis 3 jours maintenant et tout se passe bien. En cas de panne du Patton, nous rebasculerons sur la B410P en changeant le branchement des câbles qui vont aux lignes RNIS et en adaptant le dialplan dans Asterisk. Nous avons fait cette migration avec Christophe Jeannot de la société Azylis, société qui fait notamment de l'intégration Asterisk et qui est aussi opérateur VoIP. En relisant nos fichiers de configuration mISDN avec Christophe, nous nous sommes aperçus que nous avions désactivé l'anti-écho de la B410P dans le fichier /etc/asterisk/misdn.conf, car nous avions suivi une documentation qui s'appliquait à une carte RNIS 4 ports de Beronet possédant le même chipset et le même driver... mais qui n'était pas pour autant identique à la B410P de Digium car elle ne possède pas d'anti-écho hardware ! J'ai donc mis à jour mon fichier de configuration mISDN d'exemple.
2009-06-16 Mise en place d'un partage d'anciens firmwares ST2030, pour permettre aux utilisateurs de downgrader pour tenter de trouver des firmwares sans bug critique : http://people.via.ecp.fr/~alexis/asterisk/st2030/firmware/ J'ai pris cette initiative car actuellement seule la dernière version de firmware est disponible sur le site de Thomson... et ce n'est pas la moins buggée de toutes !
2009-07-10 Beaucoup de nouvelles choses en perspective : nous avons reçu un téléphone Aastra 6731i, un pont de conférence Polycom IP 6000 et un switch Linksys SRW224G4P qui permet de faire du PoE. Je suis entrain de m'amuser à configurer tout ça... plus d'infos très bientôt.
2009-07-11 J'ai configuré notre téléphone Aastra 6731i, et ça s'est très bien passé. La configuration est beaucoup plus simple qu'avec les ST2030 : nombre de fichiers de configuration réduit (1 fichier commun à tous les téléphones, 1 fichier spécifique au téléphone), pas besoin de penser à changer le nom du fichier ou à mettre un jour un certain paramètre pour que le téléphone tienne compte des modifications du fichier de configuration (une aberration des ST2030 !). J'ai réussi à faire marcher tout ce que je voulais : monitoring de ligne, call pickup, MWI, transfert d'appel, conférence, tag diffserv des packets IP émis, etc... J'ai ajouté une section Déploiement et configuration des téléphones Aastra 6731i où je mets en partage mes fichiers de configuration pour ceux que ça intéresse. Si tout se passe bien dans les prochaines semaines, je compte acheter des téléphones Aastra plutôt que des ST2030 pour mes prochaines extensions de parc.
2009-07-19 J'ai configuré notre pieuvre de conférence IP 6000. Je n'ai testé que le fonctionnement de base, mais ça a l'air de bien marcher. J'ai ajouté une section Déploiement et configuration d'une pieuvre de conférence Polycom IP 6000. J'ai reçu un mail m'indiquant une solution concernant une des imperfections que j'avais relevé sur notre installation. J'ai donc mis à jour la section sur les imperfections avec les informations que j'ai reçu et mes recherches complémentaires. J'en profite pour remercier la personne qui m'a donné la solution !
2009-07-26 Le téléphone Aastra 6731i que nous testons depuis 2 semaines fonctionne parfaitement, et c'est donc maintenant notre nouveau téléphone de référence. Les prochains téléphones que nous achèterons seront donc des Aastra 6731i. J'ai mis à jour la section choix des téléphones IP en conséquence.
2009-08-31 J'ai passé les téléphones ST2030 de notre parc en firmware 1.65, qui est le seul firmware récent sans bug trop gênant, en tout cas pour l'utilisation qu'on en fait !
2009-09-14 J'ai mis en partage mes fichiers de configuration des téléphones ST2030 pour le firmware 1.65, à télécharger ici !
2009-10-04 Je suis entrain de faire mon 2ème déploiement, dans une petite entreprise française. Pour ce déploiement, j'ai choisi les téléphones Aastra 31i, une passerelle SIP/RNIS Patton, et un serveur Elastix. Je n'ai pas encore réussi à tout faire marcher, car il faut que j'apprenne FreePBX, mais j'espère y arriver rapidement !
2009-10-18 Ma deuxième installation est maintenant en production. Il reste encore quelques détails à améliorer, mais ça fonctionne. Je suis globalement assez content de FreePBX, même si j'ai l'impression que c'est pas très bien documenté (mais je n'ai peut-être pas trouvé la bonne doc...). J'ai ajouté un tableau récapitulatif des différentes distributions Asterisk, et ajouté Xivo à la liste des distributions Asterisk.
2009-12-06 Le firmware 2.69 pour les téléphones ST2030 est sorti ; le bug sur le call pickup du firmware 2.68 est apparemment toujours présent. Je remarque d'ailleurs, et c'est la première fois, que les membres du form Asterisk-france ne sont plus motivés pour tester les nouveaux firmwares Thomson, comme si ils avaient perdu l'espoir que Thomson sorte un jour un firmware sans bug gênant ! De mon côté, j'utilise toujours le firmware 1.65, qui ne souffre que d'un seul petit bug (cf détail des bugs par version de firmware dans cette section).
2010-04-24 Ajout de précisions sur mon avis concernant les téléphones ST2030, l'interphone Pantel IP et le switch Linksys PoE. Mise à jour de la partie réseau, car nous utilisons maintenant un VLAN dédié à la VoIP, ce qui n'était pas le cas initialement. Partout où il est écrit Zaptel, je rappelle que le nouveau nom est DAHDI. Ajout d'un tableau récapitulatif des composants logiciels d'un IPBX dans la section choix du packaging Asterisk. Revue complète de la section choix des interfaces téléphoniques (anciennement appelée "choix des cartes téléphoniques). Ajout d'une section Annexes avec les anciens schémas d'architecture. Passage au correcteur orthographique. Correction des liens morts.
2010-04-27 Ajout d'éléments dans le tableau récapitulatif des avantages et des inconvénients des différentes solutions pour le packaging d'Asterisk.
2010-04-29 Un élément de plus dans les défauts de l'interphone Pantel.
2010-05-03 Ajout de précisions concernant les switchs PoE et un exemple de PC fanless.
2010-05-07 Ajout d'une colonne sur Asterisk 1.6 dans le tableau de comparaison des distributions Asterisk.
2010-05-31 Ajout des commandes de diagnostic Patton que j'utilise.
2010-06-03 Etape importante dans l'évolution de notre déploiement Asterisk : nous avons choisi un nouvel opérateur de téléphonie fixe et c'est un opérateur IP : Acropolis Telecom. Nous allons donc passer de nos accès Numéris France Telecom à un accès SDSL avec une interconnexion en trunk IAX entre notre serveur Asterisk et les équipements d'Acropolis Telecom. Nos numéros de téléphone fixe actuels seront portés chez Acropolis. Cette page va donc évoluer dans les prochaines semaines pour vous faire part de notre retour d'expérience une fois que le nouvel accès sera mis en place, c'est à dire d'ici fin Juin.
2010-06-10 Mise à jour de notre serveur Asterisk de Debian Etch à Lenny. Utilisation des paquets Debian pour Asterisk, en remplacement de notre ancien Asterisk compilé à la main. J'ai mis à jour le tableau regroupant les versions des composants logiciels utilisés ainsi que la section concernant le choix du packaging d'Asterisk.
2010-06-11 Petit souci concernant les conférences téléphoniques : la combinaison de DAHDI 2.3.0 avec Asterisk 1.4.21 ne marche pas. Par contre, Asterisk 1.4.21 marche bien avec Zaptel 1.4.11. D'après mes recherches, la première version d'Asterisk 1.4 qui supporte DAHDI est Asterisk 1.4.22.
2010-06-24 Nous avons mis en place le trunk IAX avec Acropolis Telecom, notre nouvel opérateur de téléphonie fixe, via la liaison SDSL dédiée. Nous l'utilisons pour les appels sortants et cela marche bien... mais c'est encore trop tôt pour porter un réel jugement. Nous continuons de recevoir les appels par nos lignes Numéris et notre passerelle SIP/RNIS Patton jusqu'au portage de nos numéros chez Acropolis, qui aura lieu la semaine prochaine. Je mettrai alors à jour le schéma avec la nouvelle architecture.
2010-07-03 Le portage des numéros a été réalisé avant-hier ; ça s'est globalement bien passé, même si ça n'a malheureusement pas été parfait. Je donnerai plus de détails très prochainement ; il faut aussi que je m'attaque à la mise à jour du schéma d'architecture suite à cette migration.
2010-07-09 Mise à jour du schéma d'architecture suite au basculement vers notre nouvel opérateur IP ; l'ancien schéma d'architecture a été déplacé à la fin du document. Mise à jour de la section sur les fax, de la section choix du canal de communication avec l'extérieur et création d'une section choix d'un opérateur IP, qui devra encore être complétée.
2010-07-23 Relecture complète. Suppression de tout ce qui était obsolète dans la partie sur l'installation du serveur Asterisk. Suppression de toutes les références à mISDN, car on m'a dit que les cartes RNIS PCI B410P étaient maintenant bien supportées par DAHDI ; comme je ne sais pas si il vaut mieux utiliser mISDN ou DAHDI, je préfère ne rien dire et ne pas inciter à choisir mISDN. Amélioration du schéma d'architecture. Ajout d'une colonne "Produit que je recommande ?" dans le tableau du budget. Beaucoup d'ajouts aux sections choix de l'opérateur IP et choix du canal de communication avec l'extérieur avec notamment une comparaison des coûts entre la solution RNIS et la solution d'un opérateur IP. Ajout d'une section sur le choix du codec, qui demande encore à être complétée. Nouvelle section Interconnexion avec un opérateur IP.
2010-08-10 Ajout d'un point supplémentaire (négatif) sur notre expérience avec Acropolis Telecom.
2010-09-12 Ajout d'une section sur le call pickup, et en particulier la distinction entre le directed pickup et le group pickup... une subtilité que j'ai compris seulement récemment !
2010-09-23 Annonce de mon module de click2dial Asterisk pour OpenERP, un ERP en logiciel libre. Ce module est sous licence AGPL, la même licence qu'OpenERP.
2010-10-20 Petite mise-à-jour pendant la conférence Asterisk au salon IP Convergence !
2010-11-02 J'ai déjà trouvé un bug dans le firmware 2.72 des téléphones ST2030 (le tableau qui résume les bugs par version a été mis-à-jour), et c'est confirmé par les témoignages sur le forum Asterisk-France. Thomson est donc fidèle à sa tradition de firmwares buggés... alors que, sur les téléphones Aastra, je n'ai pour l'instant jamais trouvé le moindre bug !
2010-11-12 Mise à jour de la partie sur le choix du hardware.
2010-12-06 Depuis Décembre 2010, Acropolis Telecom émet une seule facture par mois (au lieu de 2)... un point négatif en moins pour Acropolis !
2010-12-29 Mise à jour du descriptif concernant le module asterisk_click2dial pour OpenERP que j'ai développé, pour mentionner la nouvelle fonctionnalité de présentation du nom du correspondant sur un appel entrant. Voilà le lien vers l'annonce de cette nouvelle fonctionnalité.
2011-02-18 Grosse mise à jour : mes déconvenues avec Acropolis Telecom qui m'ont fait changer ma recommandation concernant les canaux de communications avec l'extérieur et les opérateurs IP. Ma troisième expérience de déploiement Asterisk, cette fois-ci avec Xivo, qui est une très bonne distribution Asterisk que je recommande comme choix de packaging Asterisk.
2011-03-21 Ajout du problème de fiabilité des combinés des téléphones ST2030, que nous ne sommes apparemment pas les seuls à constater.
2011-05-12 Une remarque en plus sur le téléphone ST2030 : défauts du port "PC".
2011-10-26 J'ai complété la partie choix du serveur avec l'expérience de mon 4ème déploiement Asterisk où j'ai choisi un serveur no moving parts c'est à dire un serveur fanless avec un SSD.
2011-11-29 J'ai pu faire marcher la fonctionnalité p-asserted avec Asterisk 1.8, ce qui permet d'avoir la mise à jour de la présentation du numéro lors d'un transfert d'appel, cf cette section. Ma section liste des imperfections qu'il reste à corriger est donc maintenant vide !
2011-12-29 Suite à ce que j'ai appris sur mes déploiements récents, j'ai ajouté une partie sur le choix des téléphones sans-fil et j'ai complété l'information sur les opérateurs IP avec la nouvelle offre de trunk SIP d'OVH.
2012-04-09 Ajout d'infos sur Xivo 1.2 ainsi que sur l'offre SIP trunk + connexion dédiée d'OVH. Un downtime ajouté au tableau de suivi de nos downtimes Acropolis Telecom.
2012-07-15 Mise à jour des schémas d'architecture recommandé. Ajout du Shuttle XS35v2 dans la section Serveur. Mise à jour de mon avis sur Xivo (suite à mes premiers déploiements de Xivo 1.2)
2012-11-02 Passage du titre au pluriel, vu que ce document se base maintenant sur plusieurs déploiements que j'ai réalisé, et adaptation du texte en conséquence. Ajout de mon avis sur Yealink, depuis que j'ai commencé à utiliser ce modèle de téléphone SIP.
2012-12-28 Suite de l'adaptation pour rendre compte de mes multiples déploiements. Explications sur les offres d'OVH dans la partie choix d'un opérateur IP. Ajout d'infos sur le codec G722 dans la section choix du codec. Ré-écriture complète de la partie sur le réseau et de la partie fonction standard. Sur les diagrammes, l'image du PC est maintenant celle d'un XS35v2. Mention de la gamme Gigaset N720 dans la partie téléphones IP sans fil. Nombreuses petites modifications et mises-à-jour à plein d'endroits.
2013-03-08 Mise à jour de la partie choix des téléphones IP filaires suite à mon premier déploiement en prod de téléphones Yealink.
2013-04-05 Ajout d'un tableau sur les downtime d'OVH depuis le 1er Janvier 2013 dans la partie choix d'un opérateur IP.
2013-04-19 MAJ du tableau des downtime d'OVH suite à une nouvelle panne.
2013-08-09 MAJ du diagramme d'architecture OVH avec l'introduction du firewall pfSense. Ajout de la solution DECT de Yealink dans la section téléphones IP sans fil. Ajout d'une nouvelle section Le firewall et la QoS. Ajout d'une table des matières (enfin !).
2013-08-31 MAJ de la section choix du hardware pour pfSense avec les specs de la prochaine version de la carte mère du boitier Alix avec ports Giga.
2013-10-04 Quelques précisions sur la remontée de fiche avec Xivo. Ajout d'un nouveau hardware conseillé pour le serveur Asterisk dans la section choix serveur.
2014-01-17 Mise à jour des tableaux de panne d'OVH et Acropolis.
2014-01-19 Ajout du prix des offres de Stella en RNIS et OpenIP en trunk SIP.
2014-04-21 Grosse mise à jour : nouveaux schémas d'architecture avec les patton RNIS+FXS pour le fax, mise à jour de la section sur les téléphones fixes avec la nouvelle gamme Yealink, mise à jour de la section sur le Serveur avec le Intel NUC Celeron, mise à jour du hardware pour pfSense (APU dispo), ré-écriture de la partie sur le fax. Suppresion de parties obsolètes sur le ST2030 et la config Patton (les explications étaient pour de très vieux firmwares).
2014-05-26 MAJ du tableau des pannes d'OVH avec la panne de Vendredi dernier. Avertissement sur un probable pb d'autonomie des DECT Yealink. Ajout du NUC fanless dans la section sur choix serveur.
2014-06-23 MAJ avec plus d'infos sur le NUC Atom fanless dans la section choix serveur et la semaine horrible d'OVH.
2014-12-09 MAJ avec mes mauvaises expériences avec le NUC Atom fanless (pb de boot sans écran) et des infos sur les alternatives au NUC chez Gigabyte dans la section choix serveur. Un mot également sur les nouveaux firmwares des téléphones DECT Yealink dans la section choix téléphone IP sans fil.
2015-04-18 MAJ avec ma recommandation du Brix de Gigabyte dans la section choix serveur. MAJ des diagrammes avec l'image du Brix.
2015-08-07 Petites modifications et mises-à-jour mineures à plusieurs endroits.
2015-10-24 Mise-à-jour de la partie sur les qualités et défauts de Xivo.

A propos du document

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 les architectures possibles, les choix techniques à faire et les motivations de ces choix, les erreurs à éviter. 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.

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

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 !

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 l'installation VoIP de l'entreprise où je travaillais à l'époque, des ajouts de matériel, des mises à jour logicielles, etc...

Après ce premier déploiement réussi dans mon entreprise, j'ai réalisé plusieurs autres déploiements Asterisk et je continue d'en réaliser à l'heure actuelle. Je fais de mon mieux pour mettre à jour ce document au fur et à mesure de l'expérience de j'acquiers sur les différents déploiements que je fais.

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 :

Installation VoIP avec Asterisk

Schémas d'architecture

Je recommande deux architectures, à choisir en fonction de vos priorités :

Architecture avec lignes RNIS : priorité à la qualité et à la disponibilité

La partie du schéma sur fond jaune représente ce qui est interne à l'entreprise.

diagramme d'architecture avec lignes RNIS

Architecture avec l'opérateur IP OVH : le moins cher

diagramme d'architecture l'opérateur IP OVH

Matériel utilisé et budget

pour un déploiement avec un opérateur IP

Voilà la liste typique du matériel que j'utilise actuellement pour un déploiement avec un opérateur IP (donc sans recours à des lignes Numéris) :

Composant Produit retenu Commentaire Acheté chez Prix unitaire HT
Serveur Gigabyte Brix GB-BXBT-2807 + 2 ou 4 Go de RAM + petit SSD boutique en ligne 200 €
Switch PoE D-Link DES-1210 (fast) ou DGS-1210 (giga) PoE Choix du modèle exact en fonction du nombre de ports requis boutique en ligne 137 € pour le modèle 8 ports
Téléphone Yealink T42G Prise casque. 6 touches programmables. Non compatible avec l'extension standard. IT-logiq ou IP and Go ou OfficeEasy ou Opcom moins de 100 €
Base DECT sans roaming Yealink W52P Gère 5 combinés max. 4 communications simultannées. 1 combiné inclus. IT-logiq ou IP and Go ou OfficeEasy ou Opcom 80 €
Combiné DECT Yealink W52P Combiné supplémentaire pour la base W52P IT-logiq ou IP and Go ou OfficeEasy ou Opcom 50 €
Firewall pfSense PC Engines APU 3 ports Giga, 2 Go de RAM, SSD mSATA 16 Go Gooze 120 €

pour un déploiement avec des lignes RNIS

Dans le cas d'un déploiement avec des lignes RNIS, par rapport au tableau ci-dessus, je n'ai pas besoin du firewall pfSense, mais je dois ajouter une passerelle Patton, à choisir parmi les différents modèles possibles en fonction du nombre de ports RNIS et du besoin de ports analogiques (FXS) pour le fax ou non :

Composant Produit retenu Commentaire Acheté chez Prix unitaire HT
Passerelle SIP/RNIS SN4661/2BIS4JS8V/EUI 2 ports RNIS, 4 ports FXS (pour le fax) Opcom ou IT-logiq 650 € environ
Passerelle SIP/RNIS SN4661/4BIS4JS12V/EUI 4 ports RNIS, 4 ports FXS (pour le fax) Opcom ou IT-logiq 850 € environ
Passerelle SIP/RNIS SN4120/1BIS2V/EUI 1 port RNIS Opcom ou IP and Go 205 €
Passerelle SIP/RNIS SN4120/2BIS4V/EUI 2 ports RNIS Opcom ou IP and Go 310 €
Passerelle SIP/RNIS SN4638/5BIS/EUI 4 ports RNIS (plus un port non utile) Opcom ou IP and Go 560 €

Mes bookmarks

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

Retour d'expérience global

Globalement, tous mes déploiements Asterisk se sont bien passés. Pour mon premier déploiement, quand je compare au PABX Alcatel antérieur, je peux dire que la nouvelle installation est :

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 Technicolor/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 :

Téléphones IP filaires

Choix actuel : téléphone Yealink (modèles T21P, T41P, T42G ou T46G).

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

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, OfficeEasy) pour avoir les prix. Les principaux constructeurs qui proposent des téléphones IP à des prix abordables (i.e. prix unitaires compris entre 50 et 130 euros HT) sont :

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, le SCCP.

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.

Je ne parle plus dans cette partie des téléphones Thomson/Technicolor ST2030, qui ont eu leur heure de gloire en 2007-2008, mais qui avaient des firmwares trop buggés. Voilà le tableau des bugs que j'avais dressé quand j'essayais de choisir un firmware pour déployer des ST2030... cela me permet d'insister sur l'importance du critère présence de bug dans les firmwares quand on choisit un téléphone SIP :

Version de firmware Descriptif des bugs du firmware
1.62bug sur les touches de monitoring des modules d'extension
1.63bug sur les touches de monitoring toujours présent
1.65petit 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.66bug sur les touches de monitoring des modules d'extension réintroduit
2.67bug sur le directed 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.68bug sur les touches de monitoring 64 à 66 et problème sur le directed call pick-up (plus de détails ici).
2.69selon une personne du forum Asterisk-France, le problème sur le directed 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).
2.72bug sur le directed call pickup via les touches de monitoring : il faut d'abord appuyer sur la touche de monitoring et ensuite décrocher le combiné ; l'inverse ne marche pas. Il y a aussi un secret de configuration à connaître (que je n'ai trouvé nulle part dans la doc) : il faut ajouter un "X" à la fin du champ CallPkupSC. Plus de détails ici.

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 acheté mes premiers téléphones Aastra 6731i en 2009 et je les ai utilisés pour tous mes déploiements sans exception jusqu'à début 2013 (modèles 6731i, 6753i ou 6755i). Attention, le téléphone 6731i 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). Je suis très satisfait du téléphone 6731i pour les raisons indiquées ci-dessous :

Ce modèle a cependant quelques défauts :

Ces 3 "défauts" obligent souvent à choisir des téléphones de la gamme 5xi (53i, 55i et 57i), qui ont tous une prise casque et sont compatibles avec l'extension standard. Mais les prix de ces modèles sont plus élevés et dépassent les 100 € HT.

La gamme du constructeur Yealink vient pallier ce problème. Les téléphones Yealink proposent un maximum de fonctionnalités à un prix très compétitif, ce qui explique leur grand succès depuis 2012-2013. En 2013, ce sont les téléphones T22P et T26P qui ont connu un gros succès. Le T26P possède les mêmes qualités que l'Aastra 31i, sans ses défauts. En effet, il est compatible PoE (et livré avec bloc d'alimentation), possède 10 touches de fonction avec diode, 2 ports Fast Ethernet, une prise casque, un grand écran et il est compatible avec l'extension standard... le tout pour 80 € HT. Il y a également d'autres modèles plus entrée de gamme : le T18P qui n'a pas d'écran LCD a coûte moins de 40 € HT ; le T20P qui a un petit écran de 2 lignes, et le T22P qui a le même écran que le T26P mais pas les 10 touches de fonction avec diode.

J'ai déployé pour la première fois des téléphones Yealink T26P en production en Mars 2013 et ils donnent satisfaction ; je n'ai pas découvert de bug firmware particulier pour le moment. Depuis ce premier déploiement, je n'utilise plus que des téléphones fixes Yealink pour mes déploiements.

Depuis fin 2013, une nouvelle gamme de téléphones Yealink a fait son apparition : les téléphones T21P, T41P, T42G, T46G et T48G, complétée début 2015 par le T23P et T23G. La dernière lettre indique la vitesse des ports réseau : P ou Fast Ethernet, G pour Gigabit. Voilà les principales différences par rapport à l'ancienne gamme :

Les prix de cette nouvelle gamme sont toujours très compétitifs et les firmwares sont bons (j'ai eu l'occasion de déployer des T41P, T42G et T46G en production et je n'ai trouvé aucun bug firmware). Le succès de Yealink n'est pas prêt de s'arrêter...

Téléphones IP sans-fil

Choix actuel pour une solution sans roaming : borne DECT Yealink W52P et le combiné W52H associé.

Concernant les téléphones IP sans-fil, il faut tout d'abord choisir une technologie : WiFi ou DECT. Sur ce point, les choses sont claires aujourd'hui : DECT a gagné et la question ne se pose plus. En voici les raisons :

Ensuite, il nous faut choisir une infrastructure DECT (bornes, repeaters, ...) avec une sortie SIP et des téléphones DECT. La première question qui se pose est : doit-on prendre une infrastructure DECT et des téléphones DECT chez le même constructeur ? En théorie, la réponse est non, grâce à la norme GAP, qui assure une compatibilité entre tous les téléphones et les bornes DECT qui respectent cette norme. La quasi-totalité des téléphones et des bornes DECT actuellement commercialisés respectent cette norme. Mais cette norme se limite à la partie voix, et ne couvre pas les "à côtés", tels que le journal d'appel (sur les téléphones Siemens Gigaset par exemple, le journal d'appel est stocké sur la borne apparemment), l'envoi de messages texte, la notification de messages sur le répondeur, etc... autant de petites fonctions qui ne sont pas vitales mais dont l'absence peut agacer. Si on veut profiter de ces "à côtés", il est donc conseillé de prendre des téléphones DECT et une infrastructure DECT chez le même constructeur.

Il nous faut maintenant choisir le constructeur et la gamme. D'après mes recherches, il faut distinguer deux catégories :

Je vous propose un petit zoom sur les solutions DECT de Polycom, la gamme N510 IP Pro de Siemens et la gamme W52P de Yealink.

La gamme Siemens Gigaset Pro

Chez Siemens, les solutions DECT-SIP ont longtemps été cantonnées aux produits C470IP et à ses successeurs C590IP, C610IP et A510IP. Ces produits sont composés d'un combiné et d'une borne qui a les caractéristiques suivantes :

Le coût est de 75 € HT environ pour l'ensemble borne + 1 combiné. Le combiné supplémentaire avec sa base de charge coûte environ 45 € HT (référence C610H ou autres).

Siemens a annoncé en Février 2011 un nouveau produit dans sa gamme Gigaset Pro : la borne N510 IP Pro. Le produit a d'abord été commercialisé en Allemagne, et il est arrivé en France en Octobre 2011. C'est une borne DECT-SIP qui présente les caractéristiques suivantes :

Son prix est de 100 € HT environ. Il faut ensuite acheter des combinés, en choisissant de préférence des combinés "certifiés" pour un bon fonctionnement avec la borne N510. Pour avoir la liste des combinés "certifiés", il faut compiler les informations disponibles dans la datasheet, dans le manuel et dans les release notes ; au final, on obtient une liste d'une petite dizaine de combinés, ce qui donne un grand choix en terme de caractéristiques (encombrement, autonomie, taille de l'écran, vibreur, bluetooth, résistance aux chocs et aux projections d'eau), et de prix (de 30 à 90 € HT).

Les bornes Siemens DECT-SIP (tous les modèles a priori) peuvent être utilisées avec des repeaters qui permettent d'étendre la couverture radio. Le repeater est en lien radio avec la base ; il n'est pas relié en IP. Attention, chez Siemens, le repeater doit être en lien radio avec la base ; il ne peut pas être en lien radio avec un autre repeater (contrairement à Polycom par exemple). Une base peut avoir jusqu'à 6 repeaters. Le handover fonctionne entre la base et ses repeaters. Le repeater peut déporter jusqu'à 2 communications simultanées. Le Siemens Gigaset repeater coûte 140 € HT environ.

Cette solution DECT de Siemens est fiable et compétitive et offre un large choix de combinés. Elle a quand même un gros défaut : il n'est pas possible de faire du provisionning via TFTP ou HTTP pour la borne N510IP (il existe apparemment des solutions de provisionning pour les opérateurs, mais la doc n'est pas publique et la solution est lourde et compliquée à mettre en oeuvre).

La gamme Yealink

Chez Yealink, la borne W52P a les caractéristiques suivantes :

Yealink ne propose qu'un seul modèle de combiné : le W52H (un combiné est fourni avec la borne). Le choix est donc vite fait !

Cette solution DECT de Yealink est très compétitive. Mis à par le prix, elle a un gros avantage : on peut provisionner la borne via TFTP / HTTP comme n'importe quel téléphone SIP. Il existe même un plugin de provisionning pour la distribution Asterisk Xivo. Et, cerise sur le gateau, la borne Yealink supporte le PAI, qui est la norme qui permet de mettre à jour le numéro présenté sur l'écran du téléphone lors d'un transfert d'appel (la borne Siemens Gigaset ne le permet pas).

Par contre, il semble que l'autonomie du combiné soit mauvaise. Je ne sais pas encore si le problème ne concerne que quelques unités ou si c'est un problème généralisé ; en tout cas, un de mes utilisateurs m'a remonté ce problème et certaines personnes s'en plaignent dans les forums comme ici ou . Le firmware 25.73.0.20 couplé au firmware combiné 26.73.0.10 prétent, selon les release notes, avoir amélioré l'autonomie en veille du combiné. Je n'ai pas fait de mesure sur l'autonomie des combinés DECT Yealink, mais par contre il est certain que cette nouvelle version améliore très nettement la vitesse d'utilisation du répertoire du combiné. De plus, un problème d'ergonomie que j'avais remonté dans le forum a été corrigé dans le firmware suivant (26.73.0.11) ; un bel exemple de prise en compte du retour des utilisateurs de la part des développeurs de Yealink !

La gamme Polycom

Chez Polycom (ex Kirk), il existe deux gammes pour la partie infrastructure :

La borne KWS 300 a les caractéristiques suivantes :

Cette borne coûte 290 € HT environ. Pour le repeater, un modèle pour une infra mono-cellule (le KWS 300 est une infra mono-cellule i.e. mono borne DECT) qui peut déporter jusqu'à 4 communications simultanées (référence 0233 4600) coûte 230 € HT environ.

Dans le domaine des infra multi-cellules, Polycom propose la solution KWS 6000 qui est composée de plusieurs éléments :

La solution KWS 6000 avec ses multiples éléments permet d'avoir jusqu'à 4096 téléphones DECT et 1024 communications simultanées en G711 ! Elle est donc très scalable. Elle supporte le roaming et le handover d'une borne à une autre.

Avec la solution KWS 6000, pour une infrastructure jusqu'à 32 appels simultanés en G711, il faut donc prévoir :

Dernier élément à prendre en compte au niveau de la solution Polycom : les téléphones. Les prix vont de 90 à 300 euros HT. On vous déconseillera peut-être le téléphone d'entrée de gamme modèle 2010 à 90 € HT car il ne s'agit pas d'un téléphone développé par Kirk mais d'un téléphone OEMisé chez un constructeur chinois... le "vrai" téléphone Kirk d'entrée de gamme est donc en réalité le modèle 4020 à 200 € HT. Mais, pour ce prix, on vous vantera une qualité et une solidité sans commune mesure avec un téléphone Siemens...

Avec ce zoom sur la gamme N510 IP Pro de Siemens et la gamme de Polycom, j'espère avoir pu vous éclairer sur la différence entre une infrastructure DECT "simplifiée" (Siemens N510) et une infrastructure DECT "complète" (Polycom), à la fois en terme de capacité (nombre de combinés, nombre de communications simultanées), de fonctionnalité (roaming/handover), de prix et de complexité.

Canal de communication avec l'extérieur

Choix pour mon premier déploiement : au départ, les lignes RNIS utilisées dans l'installation précédente ont été conservées pour les appels entrants et sortants. En Juillet 2010, début de l'utilisation d'un opérateur IP pour les appels entrants et sortants, sur une ligne SDSL dédiée.

Choix actuel : si vous n'avez pas d'accès fibre optique et que vous recherchez la qualité et la disponibilité maximale, je vous conseille de conserver vos lignes RNIS existantes pour les appels entrants et sortants. Si vous recherchez d'abord le meilleur prix, je vous conseillerai l'offre de SIP trunk + connexion dédiée d'OVH.

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.

Numéro Communications entrantes Communications sortantes Avantages Inconvénients
1 RNIS RNIS
  • Rien à changer à l'installation existante
  • Je n'ai jamais vu une ligne RNIS en dérangement (sauf en cas de facture France Telecom impayée !) ; qui peut dire la même chose d'un lien ADSL ?
  • Conservation de la dépendance vis-à-vis de France Telecom pour le lien RNIS
  • Nécessite l'achat et le déploiement d'une passerelle SIP/RNIS (ou carte PCI RNIS)
2 VoIP sur xDSL ou fibre optique VoIP sur xDSL ou fibre optique
  • Vous pouvez bénéficier des tarifs agressifs sur les communications de certains opérateurs VoIP (mais attention, la réalité est parfois moins idyllique que la grille tarifaire).
  • Vous évitez l'achat et le déploiement d'une passerelle SIP/RNIS. Cela simplifie l'architecture technique et évite d'avoir à s'intéresser à la technologie RNIS, peu connue des administrateurs réseau.
  • Si vous choisissez un lien SDSL avec une GTR (Garantie de Temps de Rétablissement) de 4h, ne négligez pas son coût. Si vous choisissez un lien ADSL, il faut prévoir une solution de secours quand le lien est down !
  • Si votre opérateur VoIP n'est pas le même que l'ISP qui vous fourni le lien xDSL ou fibre optique, il faut s'assurer que l'opérateur VoIP a une collecte IP spéciale chez l'ISP (i.e. ils ont un lien direct entre leurs deux réseaux sans passer par Internet), sinon vos flux VoIP passeront par Internet, or il n'y a pas de garantie de qualité de service sur Internet, donc pas de garantie sur la qualité audio de vos communications vers ou depuis l'extérieur.
  • Il faut réaliser le portage des numéros de téléphones existants vers votre opérateur VoIP ; cela se passe généralement bien quand l'ancien opérateur et le nouveau sont sérieux.
3 RNIS VoIP sur xDSL ou fibre optique
  • Vous bénéficiez de la fiabilité parfaite du lien RNIS pour les appels entrants.
  • Pas de portage des numéros de téléphone à réaliser.
  • Votre lien RNIS sert aussi de lien de backup pour les appels sortants.
  • Vous pouvez bénéficier des tarifs agressifs sur les communications de certains opérateurs VoIP.
  • Il faut payer à la fois l'abonnement pour le lien RNIS et l'abonnement pour le lien ADSL ou SDSL.
  • Nécessite l'achat et le déploiement d'une passerelle SIP/RNIS (ou carte PCI RNIS)
  • Il faut que l'opérateur IP accepte de présenter un numéro qui ne lui "appartient" pas. Certains refusent, car, si vous présentez les numéros de vos lignes RNIS lors de vos appels sortants via votre opérateur IP, vos appels entrants vont tous arriver sur les lignes RNIS et l'opérateur IP ne pourra jamais facturer des frais de terminaison d'appel à des opérateurs tiers. (les frais de terminaison d'appel sont des frais que votre opérateur facture à l'opérateur de votre correspondant quand on vous appelle)

Pour mon premier déploiement, 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.

En ce qui concerne la solution n°2, mon étude des offres disponibles sur le marché français ne m'a permis d'identifier qu'un seul 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) : OVH. Mais OVH n'a pour l'instant dégroupé qu'une grosse centaine de NRA dans quelques grandes villes et leur proche banlieue (liste complète des NRAs dégroupés par OVH disponible ici). Aujourd'hui, seuls Orange, Free, SFR, Bouygues Telecom, Completel et OVH 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 :

Malheureusement, à part OVH, 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 le SIP ; comme l'interconnexion via ce protocole doit permettre d'avoir plusieurs communications simultanées dans une même connexion, on parle de trunk SIP. Pour le codec, on a généralement le choix entre G711A et G729 (et parfois le codec haute-définition G722). 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.

En dehors d'OVH, pour avoir une offre en mode "trunking", il faut s'adresser à 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 :

Pour ces opérateurs sans DSLAM en propre, 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. Pour réaliser ce test, l'outil smokeping (packagé dans Debian/Ubuntu) semble bien adapté. 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 des offres de plusieurs opérateurs, en RNIS ou en trunking sur lien xDSL. Les prix affichés dans le tableau sont les prix publics hors taxes. Pour rappel, une ligne RNIS T0 permet de faire passer 2 communications simultannées.

France Telecom - RNIS Stella Telecom - RNIS Acropolis Telecom - trunk sur ligne xDSL OpenIP - trunk sur ligne xDSL OVH - trunk SIP sur ligne xDSL
Prix mensuel du lien 38,00 € par T0 25,00 € par T0 sans communications incluses.
35,00 € par T0 avec illimité vers les fixes.
49,00 € par T0 avec illimité fixes et mobiles.
SDSL : le prix varie très fortement en fonction de votre département et de votre éloignement par rapport au NRA. Exemple : prix d'Anevia : 110 € pour une ligne SDSL 600 kbit/s garantis GTR 4h (département 94, 4 km du NRA)
ADSL : 39 €
SDSL : 99 € à 499 € selon le débit et le nombre de paires de cuivre avec GTR 4h.
ADSL : 39 € via SFR, 49 € via Orange en dégroupage total
inclus dans le prix de l'interconnexion
Prix mensuel de l'interconnexion 0 0 13,34 € par communication simultanée maximum dans le trunk 3 € par communication simultanée sans communication incluse
13 € par communication simultanée avec illimité vers les fixes
27 € par communication simultanée avec illimité vers les fixes et les mobiles
Pour chaque communication simultannée, une communication entrante supplémentaire est offerte.
20 € par communication simultanée (2 minimum)
Prix mensuel des SDAs 0,91 € par SDA 0,90 € par SDA 8 € par tranche de 10 SDAs consécutifs 0,30 € par SDA 1 € par SDA (gratuit pour les SDA pré-existants portés chez OVH)
Prix des communications Prix de mise en relation, puis facturation à la minute. Si offre sans communications incluses : tarification à la seconde depuis la première seconde.
Pour les offres avec communications illimités, cela inclus également les appels vers les fixes de 68 pays ; attention à la clause de fair-use : limite de 200 numéros appelés différents par ligne T0 par mois et 60 minutes maximum par appel. Au delà de ces limites, se référer aux prix en hors-forfait.
Illimité vers les fixes en France métropolitaine. Autres destinations : selon une grille très précise par pays et par opérateur. Les forfaits illimités incluent aussi les fixes de 50 pays. Illimité vers les fixes en France métropolitaine et dans 40 pays, ainsi que vers les mobiles en France. Attention à la clause de fair-use : 60 minutes maximum par appel, 99 numéros différents par ligne simultanée et par mois pour les fixes et même limite pour les mobiles (limite mutualisable ; si vous avez 3 lignes simultanées, la limite est de 3x99 numéros différents par mois). Au delà de ces limites, se référer à la grille tarifaire par destination.
Hors forfait vers les fixes 0,105 € de mise en relation, puis 0,021 € / minute 0,02 € / min 0,012 € / min 0,01 € / min
Hors forfait vers les mobiles 0,134 € de mise en relation, puis 0,134 € / minute 0,08 € / min 0,079 € / min 0,08 € / min
Prix mensuel du service fax2mail - - 5 € 5 € à 10 € selon les options 1 € (offre EcoFax Pro)
Frais de mise en service 55 € de frais de déplacement du technicien
45 € par ligne T0 [TODO vérifier]
99 € pour une création de ligne avec engagement de 12 mois.
19 € pour une reprise de ligne RNIS existante avec engagement de 12 mois.
700 € pour la ligne SDSL (-50% si engagement 24 mois, -100% si engagement 36 mois), varie en fonction de votre département et de votre éloignement par rapport au NRA
30 € par communication simultanée maximum dans le trunk IAX
30 € pour le service fax2mail
650 € pour une SDSL 1 paire
140 € pour une ligne ADSL
250 €
Frais de portage des numéros ? 0 50 € par tranche de 10 numéros 50 € ou 80 € par tranche de 10 numéros aucun
Durée d'engagement ? 12 mois minimum 12 mois minimum 12 mois pour le lien SDSL 12 mois
Lien de backup à prévoir ? Non Non SDSL : Conseillé
ADSL : Oui
SDSL : Conseillé
ADSL : Oui
Conseillé

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.

Pour mon premier déploiement, nous avons remplacé en Juillet 2010 3 lignes T0 de France Telecom par une ligne SDSL avec un trunk 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 :

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

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. Dans l'entreprise de mon premier déploiement, 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 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 :

Pour mon premier déploiement, 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 pour mon premier déploiement : Acropolis Telecom.

Choix actuel : pour les entreprises à la recherche de la meilleure qualité et disponibilité possible, j'éviterai d'utiliser un opérateur IP et j'utiliserai des lignes RNIS, en choisissant une offre VGA d'un opérateur alternatif tel que Stella Telecom. Pour les entreprises à la recherche de la solution la plus compétitive, je suggère de choisir l'offre de trunk SIP d'OVH.

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, dans l'hypothèse où vous êtes éligible à l'ADSL et pas à la fibre optique, je conseille de choisir :

Sinon, je conseille de mettre en concurrence les opérateurs qui ont une collecte auprès d'Orange et/ou SFR pour assurer une qualité de service entre l'IPBX et le serveur SIP de l'opérateur ; les opérateurs sont recommandables :

Les offres de trunk SIP d'OVH comportent quelques subtilités, que je vais décrypter ci-dessous. Ces offres ont l'avantage d'avoir des tarifs affichés publiquement (pas besoin de passer par un commercial pour obtenir les tarifs !) et il est possible de souscrire directement en ligne. OVH est un des rares opérateurs de trunk SIP a avoir complètement industrialisé son offre de trunk SIP, avec la possibilité de souscrire en ligne, puis de paramétrer son trunk SIP en ligne. Ainsi, une fois la souscription réalisée, depuis son compte client en ligne, on peut :

Ils existes en réalité 3 offres de trunk SIP chez OVH :

Ligne SIP Entreprise SIP trunk SIP trunk + connexion dédiée
Ligne xDSL incluse non non oui
Engagement 1 mois 1 mois 12 mois
Illimité vers les fixes en France et dans 40 pays oui (clause de fair-use ; au-delà, 1 cts HT/min) oui (clause de fair-use ; au-delà, 1 cts HT/min) oui (clause de fair-use ; au-delà, 1 cts HT/min)
Illimité vers les mobiles en France non (8 cts HT/min) oui (clause de fair-use ; au-delà, 8 cts HT/min) oui (clause de fair-use ; au-delà, 8 cts HT/min)
Tarif 5 € HT pour 2 communications simultannées, puis 1 € HT / communication simultannée supplémentaire 20 € HT par communication simultannée 20 € HT par communication simultannée (2 minimum)

Mon expérience avec Acropolis Telecom

Pour mon premier déploiement Asterisk, j'ai choisi l'offre d'Acropolis Telecom pour les raisons suivantes :

Après quelques mois d'utilisation du service de trunking d'Acropolis Telecom, le bilan est globalement positif sur les aspects techniques, mais globalement négatif sur le process d'administration des ventes et sur l'aspect commercial :

Voici un tableau récapitulatif des downtimes que nous avons eu depuis le début :

Date Durée Symptôme
à retrouver 30 minutes Trunk IAX down
22/06/2011 6h (5h30 à 11h30) Toute l'infra Acropolis était down, à cause d'un acte de vandalisme sur une fibre optique
28/03/2012 0h45 (10h48 à 11h32) Problème sur le serveur Asterisk d'Acropolis. Résolu 15 min après l'appel du support technique (reload d'IAX)
16/01/2014 9h (15h à minuit) Panne totale des appels entrants, à cause d'une rupture d'une fibre optique d'Orange.

Au final, l'arnaque dont nous avons été victime concernant la présentation du numéro à l'étranger m'oblige à déconseiller Acropolis Telecom. J'ai eu des discussions intéressantes avec d'autres professionnels de la téléphonie sur IP à qui j'ai raconté mes mesaventures et qui n'ont pas été surpris par ce que je leur ai raconté. Ils m'ont décrit les dessous du business des minutes, où plein d'entreprises au nom inconnu s'improvisent opérateur télécom et proposent des minutes de communication téléphonique à prix cassé vers certaines destinations à d'autres opérateurs qui ont pignon sur rue. Pour casser les prix, ces opérateurs super-low-cost utilisent des interconnexions "non officielles" avec les opérateurs locaux à l'étranger. Par exemple, ils ouvrent des lignes téléphoniques comme un client lambda auprès de l'opérateur local à l'étranger et renvoient leurs communications IP entrantes sur ces lignes téléphoniques où ils payent le coût d'une communication locale. Evidemment, avec ce genre d'interconnexion "non officielle", ces opérateurs super-low-cost ne peuvent pas assurer la présentation du numéro, car l'opérateur local à l'étranger n'acceptera pas, via la ligne téléphonique classique ouverte par l'opérateur, de relayer un appel avec pour numéro présenté un numéro qui n'est pas celui de la ligne téléphonique.

Mon expérience avec OVH

Depuis fin 2011 et le lancement des offres SIP trunk et SIP trunk + connexion dédiée d'OVH avec l'illimité vers les mobiles, la majorité de mes déploiements Asterisk ont été faits avec l'opérateur OVH sur une de ces deux offres.

Mon premier déploiement Asterisk avec l'opérateur OVH est passé en production fin Décembre 2011 ; l'entreprise a fait le choix de l'offre de SIP trunk + connexion dédiée d'OVH avec 3 communications simultannées (3x20 € HT / mois). La ligne téléphonique du site avait une longueur d'un peu plus de 4 km et le NRA n'était pas dégroupé par OVH ; OVH a installé un lien ADSL en passant par les DSLAM de SFR. La latence entre le serveur Asterisk et le serveur SIP d'OVH est stable à 50 ms (ce qui est un peu élevé, mais quand même acceptable). Après plusieurs mois d'utilisation en production, un seul incident est à déplorer : à cause d'une erreur de comptabilité côté OVH, les appels sortants ont été suspendus pour cause de facture impayée ; la facture avait en réalité bien été payée par prélèvement automatique ! OVH a confirmé son erreur et a rétabli les appels sortants dès le lendemain. Les appels entrants n'ont pas été impactés. Le NRA a ensuite été dégroupé par OVH en Mars 2012, et la ligne a été basculée sur le DSLAM OVH quelques mois plus tard. Le basculement s'est bien passé et OVH a correctement communiqué avec son client à ce sujet ; la coupure résultant de ce basculement n'a pas duré plus longtemps que ce qui avait été annoncé. Suite à ce basculement, la latence a diminué ; elle est maintenant de 32 ms.

J'ai maintenant 4 déploiements avec l'opérateur OVH en production :

Voilà un tableau récapitulatif des downtimes d'OVH impactant l'ensemble du service téléphonique (i.e. tous les abonnés privés de service en même temps) depuis le début de l'année 2013 :

Date Durée Symptôme Lien vers la tâche travaux
02/01/2013 de 18h30 à 18h50 20 minutes Serveur SIP d'OVH down. Ticket 7837
10/01/2013 à partir de 17h toute la soirée Rupture de fibre optique entre Paris et Roubaix, qui perturbe le backbone d'OVH et provoque une augmentation de la latence et des problèmes de fiabilité sur la réception et l'émission d'appels, ainsi que sur l'accès Internet. Ticket 7874
22/01/2013 de 12h40 à 13h10 30 minutes Serveur SIP d'OVH down. Ticket 7939
07/03/2013 de 9h28 à 09h40 10 minutes Serveur SIP d'OVH down. Pas de tâche travaux créé
19/03/2013 de 6h50 à 07h35 45 minutes Serveur SIP d'OVH down (panne hardware). Ticket 8495
13/10/2013 de 2h15 à 11h 8h45 Problème sur le serveur SIP... heureusement un Dimanche matin, mais ça n'excuse rien ! Pas de tâche travaux créé
13/01/2014 de 15h15 à 16h (?) 30/45 minutes Problème hardware sur un équipement réseau. Ticket 9999
23/05/2014 de 12h à 13h45 1h45 Problème sur le serveur SIP. Ticket 10832
12/06/2014 au 18/06/2014 une semaine Une semaine de "débuggage à ciel ouvert" sur les serveurs de production, avec de gros changement dans l'infra en urgence. Pas mal de perturbations pendant toute la semaine. Ticket 10957

Comme vous pouvez le voir dans ce tableau, le mois de Janvier 2013 a été très mauvais. Même si je ne tenais pas de statistiques en 2012, mes souvenirs me font dire qu'il y avait eu très peu de pannes au court du 2ème semestre 2012.

Il faut souligner le fait qu'OVH a une politique de transparence totale en ce qui concerne les pannes techniques, ce qui est très rare chez les opérateurs télécoms. Le site travaux.ovh.net recense toutes les pannes (une seule n'a pas été référencée en 2013) presque en direct : le ticket est ouvert généralement dans les minutes qui suivent la détection de l'incident et des commentaires sont ajoutés au fur et à mesure du diagnostic jusqu'à la résolution de l'incident par OVH. Cette transparence totale est très rassurante quand une panne survient, car on peut ainsi avoir confirmation que le problème est bien du côté d'OVH, on connaît l'étendue de la panne et on est tenu au courant de l'avancement dans la résolution de l'incident.

Conclusion

Au final, mon conseil est le suivant :

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, G722 (codec "HD"), 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 :

G711A G729
Compression Non Oui
Débit du flux audio 64 kbps 8 kbps
Débit IP avec signalisation SIP 82 kbps 24 kbps
Tolérance à la perte de paquets Non Oui
Brevets avec royalties Non Oui

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 :

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.

On parle de plus en plus souvent du codec Haute Définition G722 (lien Wikipedia), qui est la référence des codecs à large bande (wideband codec). Ce codec a la particularité de coder la voix sur une bande de fréquence beaucoup plus large que les codecs classiques : 50 à 7000 Hz pour le G722 contre 300 à 3400 Hz pour les codecs classiques et la téléphonie analogique. Cela permet d'avoir une meilleure qualité audio ; l'interlocuteur pourra entendre certaines subtilités dans le son qu'il ne pouvait pas entendre avec un codec classique. Le G722 est un codec compressé, ce qui lui permet d'avoir un débit identiqué au G711 malgré la largeur deux fois plus importante de sa bande de fréquence. L'utilisation de ce codec n'est pas soumis au paiement de royalties. Ce codec est aujourd'hui supporté par la quasi-totalité des matériels de ToIP ; il a donc tout pour plaire ! Mais il faut bien comprendre qu'utiliser un codec à large-bande n'a d'intérêt que quand il est utilisé de bout en bout. En effet, si un élément entre l'émetteur et le récepteur ne supporte pas les codecs à large bande, il y aura un transcodage vers un codec classique (type G711) et tout le gain en qualité audio apporté par l'aspect "large-bande" sera perdu. Or, peu d'opérateurs téléphoniques supportent le G722 (par exemple, chez OVH, le codec G722 est supporté en BETA) et, même si certains opérateurs ont franchi le pas, les interconnexions entre opérateurs sont encore très majoritairement réalisées en largeur de bande classique. Concrètement, aujourd'hui, cela signifie que vous allez pouvoir téléphoner en "large bande" sur votre réseau interne, mais que, quand vous appellerez vers l'extérieur, vous serez en réalité en largeur de bande classique.

Le packaging d'Asterisk

Choix pour mon premier déploiement : Asterisk et drivers Zaptel/DAHDI packagés dans la distribution Linux habituellement utilisée par l'entreprise (Debian stable).

Choix actuel : Distribution Asterisk Xivo.

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 procédure 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 :

Nom du composant Fonction Obligatoire ?
Distribution Linux Il faut bien un système d'exploitation ! Requis
DAHDI Drivers des cartes téléphoniques et création de devices virtuels nécessaires au bon fonctionnement d'Asterisk Requis, même si on n'utilise aucune carte téléphonique (sauf si on utilise Asterisk 1.6 avec la fonction ConfBridge au lieu de MeetMe pour les conférences téléphoniques)
Asterisk et ses librairies Le cœur du système ! Requis
FreePBX ou Xivo Interface Web de management. Permet de réaliser l'ensemble de la configuration de l'IPBX dans une interface Web simple et intuitive. Fournit des fonctions "prêtes à l'emploi" pour le fonctionnement de l'IPBX. Dépend d'un serveur Web et d'une base SQL. Facultatif, mais très pratique !
IAXmodem + Hylafax Outils de traitement des fax. Permet notamment de convertir un fax en PDF. Requis si vous voulez faire du fax2mail ou autre conversion de ce type
Serveur de mail Permet l'envoi de mails Requis si vous voulez faire du fax2mail
Stats d'appel (cdr-stats ou autre) Consultation des logs d'appel et génération de statistiques sur les appels. Nécessite qu'Asterisk soit configuré pour envoyer ses logs d'appel dans une base SQL (MySQL, PostgreSQL ou autre). Facultatif
Logiciel de billing Gère la refacturation des communications téléphoniques aux utilisateurs Facultatif

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 OS Commentaire
    AsteriskNow Digium, USA FreePBX 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 par défaut.
    Elastix PaloSanto Solutions, Equateur FreePBX 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 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 Avencall (anciennement Proformatique), France Xivo Debian Projet initialement non communautaire qui constituait la base des solutions commerciales de la société française Avencall ; le projet est devenu communautaire début 2009. C'est la seule distribution Asterisk basée sur Debian. C'est la seule distribution à ne pas utiliser FreePBX : Xivo possède sa propre interface Web de configuration. Elle a aussi beaucoup d'autres qualités, cf mon retour d'expérience ci-dessous.

    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.

    Note 2 : j'ai supprimé Tribox de la liste, car la version communautaire de Tribox, Trixbox CE, n'existe plus, cf la FAQ à ce sujet.

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

Numéro Choix Avantages Inconvénients
1 Asterisk packagé dans votre distribution Linux habituelle
  • Vous avez déjà l'habitude de l'administration de cette distribution que vous connaissez bien
  • En cas de faille de sécurité, n'avez qu'à mettre à jour votre distribution selon la procédure habituelle (style apt-get update && apt-get upgrade sous Debian/Ubuntu)
  • Ce n'est pas la solution la plus courante, donc ce n'est pas celle sur laquelle vous pourrez trouver de l'aide le plus facilement
  • Les paquets Asterisk sont parfois vieux et pas toujours très bien maintenus (ça dépend des distribs)
  • Vous aurez probablement envie d'utiliser la dernière version officielle des drivers des cartes téléphoniques, or les packages de votre distrib contenant les drivers sont parfois anciens
  • Certains composants logiciels que vous comptez utiliser risquent de ne pas être packagés dans votre distribution (par exemple, FreePBX n'est packagé ni dans Debian ni dans Ubuntu)
2 Asterisk compilé à la main sur sa distribution Linux habituelle
  • Vous avez déjà l'habitude de l'administration de cette distribution que vous connaissez bien
  • Vous choisissez vous-même les versions d'Asterisk, des librairies et des drivers des cartes téléphoniques
  • C'est la solution qui est documentée dans la doc officielle d'Asterisk et dans la plupart des docs sur Asterisk
  • Requiert un minimum d'expérience de la compilation d'un logiciel libre et d'un driver Linux (rien de très compliqué !)
  • Il faut vous occuper vous-même des mises à jour de sécurité : recevoir les mails d'annonce des failles de sécurité, télécharger les versions corrigées si nécessaire, recompiler, etc...
  • Choisir soi-même les versions des différents composants logiciels n'est pas chose facile pour un débutant. Si votre combinaison de version des différents composants logiciels marche parfaitement, tout va bien... mais dans le cas contraire, vous serez probablement peu nombreux à avoir choisi la même combinaison et donc à être confronté aux mêmes problèmes.
3 Asterisk Business Edition
  • Inclus un support professionnel fourni par Digium pendant 1 an
  • Tests de qualité logicielle effectués par Digium sur chaque release
  • Cette offre introduit un coût de licence, en sachant que ce coût augmentera si le nombre de postes téléphoniques augmente
  • On sort un peu du domaine du logiciel libre, puisque cette version est sous une licence propriétaire et non sous licence GPL
  • Asterisk n'est pas le seul composant logiciel qui entre en jeu dans la construction d'un IPBX... et donc avoir une garantie de qualité sur un seul composant ne garanti pas la bonne marche de l'ensemble
4 Distribution Linux spécialisée Asterisk (AsteriskNow, Elastix, PBX in a Flash, Xivo)
  • Vous êtes normalement assuré d'avoir une combinaison "noyau + drivers de cartes téléphoniques + librairies + Asterisk + interface de management" qui marche bien ; et si c'est n'est pas le cas, vous serez probablement nombreux à remonter le problème !
  • Mises à jour de sécurité simplifiées
  • Dans le cas de AsteriskNow, Elastix et Xivo, je sais que ce sont des solutions répandues sur lesquelles vous trouverez du support de la communauté
  • Ces distributions proposent par défaut une interface Web d'administration (FreePBX ou Xivo) qui permet de gagner du temps et de profiter de certaines fonctions prêtes-à-l'emploi
  • Ces distributions packagent systématiquement les outils de fax (fax2mail notamment) et souvent des applications de billing, de statistiques sur l'utilisation des lignes, etc...
  • Fonctionnalités annexes fournies en plus. Par exemple, dans le cas de Xivo : Xivo client à installer sur son PC, serveur de provisionning pour les téléphones IP, intégration des annuaires téléphoniques des différentes marques de téléphones IP.
  • Il vous faudra peut-être apprendre à administrer une nouvelle distribution Linux (Debian pour Xivo, CentOS pour toutes les autres)
  • Vous êtes dépendant du support matériel de la version de la distribution Linux sur laquelle repose la distribution spécialisée Asterisk. Debian et CentOS sont très "conservateurs" au niveau des versions de noyau... si vous comptez utiliser pour votre IPBX un hardware récent avec un chipset de carte réseau récent, vérifiez au préalable qu'il est supporté en standard par la version de CentOS ou Debian sur laquelle repose votre distribution spécialisée Asterisk.
  • Vous n'avez pas la maîtrise complète des versions d'Asterisk, des librairies, des drivers, etc... mais pour les utilisateurs débutants, c'est un gros souci en moins, et donc plutôt un avantage !

Pour mon premier déploiement, pour réaliser l'installation initiale, 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 (c'était avant l'arrêt de la version communautaire), 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. Xivo n'était pas encore OpenSource à l'époque.

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 ou Xivo apportent de nombreuses fonctionnalités prêtes à l'emploi qu'ils implémentent 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 c'est la solution que j'ai choisi pour tous mes déploiements ultérieurs. Pour mon 2ème déploiement, réalisé fin 2009, j'ai choisi Elastix car j'en avais entendu du bien de la part d'une personne très expérimentée sur Asterisk. J'ai été satisfait d'Elastix 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ésidait 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 !

Pour mon 3ème déploiement réalisé fin 2010 et pour tous les déploiements que j'ai réalisé depuis cette date, j'ai choisi Xivo et c'est maintenant la solution que je recommande. Voilà mon retour d'expérience sur Xivo :