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.

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 Shuttle XS35V2 + 2 Go de RAM + petit SSD boutique en ligne 240 €
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 600 € environ
Passerelle SIP/RNIS SN4661/4BIS4JS12V/EUI 4 ports RNIS, 4 ports FXS (pour le fax) Opcom ou IT-logiq 800 € 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 305 €
Passerelle SIP/RNIS SN4638/5BIS/EUI 4 ports RNIS (plus un port non utile) Opcom ou IP and Go 540 €

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 ou T42G).

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

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 je resterai chez France Telecom sur des lignes RNIS. 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 :

Xivo 1.2 (maintenant numérotée année.version, soit 13.14 pour l'année 2013 version 14) apporte de très nombreuses améliorations, ce qui prouve le dynamisme du projet et sa capacité d'innovation :

Par contre, Xivo 1.2 a abandonné 2 fonctionnalités intéressantes de Xivo 1.1 : le client Xivo Web et le client Xivo Android.

D'une façon générale, installer Xivo permet de se doter d'un vrai IPBX très complet, avec plein de fonctionnalités pratiques qui sont appréciées des utilisateurs.

Serveur

Choix actuel : mini-PC fanless Shuttle XS35v2 avec SSD 2,5" ou Intel NUC Celeon ou Atom.

Le premier élément à considérer est : est-ce que j'ai besoin de slots PCI pour mettre une carte téléphonique ? Si oui, quels types de ports (PCI 32bit 33 Mhz, PCIe, etc...) ? Depuis que j'ai pris l'habitude de déployer des passerelles Patton, je n'ai plus la contrainte des ports PCI, ce qui m'a permis de m'intéresser aux mini PC fanless (sans ventilateur) et no moving parts, c'est à dire sans composant qui bouge (i.e. pas de disque dur classique ; on met un SSD à la place). Sur le wiki dédié à l'auto-hébergement, maintenu par mon ami Tanguy Ortolo, vous trouverez une liste de PCs basse consommation, dont certains sont fanless, sur la page choisir son serveur. Attention, vérifiez que l'architecture du processeur (certains sont des processeurs ARM !) est bien supportée par la distribution que vous envisagez d'installer.

Pour deux déploiements réalisés en 2011, j'ai choisi un serveur Linutop 4 (Atom N270, 1 Go de RAM, 1 interface Giga), que j'ai couplé à un SSD Intel 40 Go 2,5" (qui a remplacé la mémoire flash de 2 Go livrée en standard, en fait une DOM sur port USB interne). Cette machine est parfaitement supportée sur Debian 5.0 et suivants (détails techniques : cpuinfo, dmesg, lspci et lspci -nv), mais son prix est à mon avis trop élevé au vu de ses caractéristiques techniques. A part son prix, le Linutop 4 m'a donné satisfaction (aucune panne à déplorer sur mes deux installations, configuration totalement fanless, économe en électricité), sauf sur un point : il m'a fallu faire un petit bricolage pour pouvoir brancher le connecteur d'alimentation du SSD... clairement, le Linutop n'est pas adapté pour l'installation d'un SSD 2,5".

Sur mes déploiements récents, j'ai opté pour une autre configuration fanless qui est deux fois moins chère que le Linutop 4 et qui accepte les disques 2.5" (SSD ou disque classique à plateau) sans problème : le Shuttle XS35v2.

Ce qu'il faut savoir sur le Shuttle XS35v2 :

Si vous avez besoin d'informations complémentaires sur le Shuttle XS35V2, n'hésitez pas à me demander, car j'en ai un à la maison et je peux donc facilement faire des tests, récolter des informations sur le hardware ou prendre des mesures.

Sur une installation plus grosse (65 téléphones) et qui était amenée à grossir à l'avenir où il était prévu une large utilisation du client Xivo, j'ai estimé que le XS35v2 avec son processeur Atom pouvait être un peu juste à terme et j'ai voulu choisir un hardware avec un peu plus de puissance. J'ai opté pour le NUC d'Intel. Plus précisement, j'ai acheté le NUC DC3217IYE dont voici les caractéristiques :

Début 2014, la gamme Intel NUC a été complétée par un modèle entrée de gamme basé sur un processeur Celeron 847 ayant la référence BOXDCCP847DYE. Ce NUC Celeron est vendu à 125 euros HT (exemple : ici) ; il faut simplement lui ajouter une barette de RAM DDR3 SO-DIMM, un SSD mSATA et un cordon secteur en trèfle (en effet, l'adaptateur secteur est fourni, mais pas le cordon d'alimentation, qui comprend la prise électrique et qui est spécifique à chaque pays). C'est la configuration que j'ai retenu pour remplacer le hardware vieillissant (qui devenait instable) du serveur Xivo/Asterisk de mon entreprise ; le prix de la configuration complète avec 2 Go de RAM et un SSD mSATA de 30 Go nous a coûté 175 € HT.

En Mai 2014, Intel a sorti un NUC fanless à base de processeur Atom sous la référence DE3815TYKHE. Ce NUC est livré sans OS ni RAM ni disque dur, mais il contient 4 Go de mémoire Flash, ce qui est suffisant pour une petite installation Asterisk sans enregistrement des appels. Il est vendu à 105 € HT sur LDLC par exemple. Pour en savoir plus sur ce NUC fanless, lisez cet article très détaillé. Ce NUC Atom fanless est bien supporté sous Debian 7, que ce soit la carte réseau (une carte Realtek Gigabit... Intel se fait des infidélités !) ou l'accès aux 4 Go de mémoire flash (il faut juste connaitre le petit secret expliqué sur le site de support d'Intel). Je mets en partage la sortie de lspci, lspci -nv, dmesg et cat /proc/cpuinfo.

Fax

Choix actuel :

Il n'existe pas aujourd'hui de fax IP à la façon d'un téléphone IP ; malgré l'existence de la norme T.38, aucun constructeur ne propose de fax avec une prise Ethernet.

D'une manière générale, la problématique du fax n'est pas simple dans le monde de la VoIP. Il est impératif de bien étudier la problématique du fax lors d'un déploiement de VoIP, sous peine de se retrouver avec un système de fax inopérant ou non fiable. Je vous conseille la lecture de cette page et de ce document pour mieux comprendre les problématiques techniques liées aux Fax en VoIP.

Si il y a un fax existant dans la société, la première question à se poser est la suivante : est-il possible de dématérialiser le fax ? Est-il possible d'adapter l'organisation interne pour reçevoir les fax par e-mail et envoyer les fax sous forme de fichier ?

Si la dématérialisation est possible :

La dématérialisation du fax a plusieurs avantages :

Si la dématérialisation n'est pas possible :

Choix des interfaces téléphoniques

Choix actuel : utilisation de passerelles SIP/RNIS Patton.

Quand j'ai fait le choix pour mon premier déploiement, ma 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 :

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 :

Avec ces boitiers dédiés :

L'option "boitier" a donc de nombreux avantages... à condition que le boitier ait été bien choisi ! En effet, le problème des drivers inhérent aux cartes téléphoniques PCI peut rapidement laisser la place à des prises de tête avec les firmwares instables/buggés des boitiers. Pour éviter de problème, il faut faire attention à acheter un boitier 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 !).

Pour remplacer la carte PCI B410P (4 ports RNIS), la solution consiste à 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 ou plusieurs 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é :

J'ai choisi le boitier Patton pour tous les déploiements où l'accès vers l'extérieur se fait via des lignes RNIS T0. J'ai actuellement six boitiers Patton déployés en production ; les utilisateurs sont satisfaits de la qualité audio et je n'ai jamais eu aucun problème de fiabilité (je n'ai jamais eu besoin de rebooter une Patton par exemple) ni aucune panne matérielle. Certes, la configuration est compliquée, mais une fois qu'on sait la faire, cela n'est plus un problème.

Le réseau local

Choix actuel pour tous mes déploiements : création d'un VLAN dédié à la VoIP. Selon le choix de l'entreprise, utilisation ou non du PoE.

PoE or not PoE

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

Quel switch PoE choisir ? Si vous avez besoin d'un switch PoE avec le support des VLANs, je peux recommander deux modèles que j'ai déployé en production en mode multi-VLAN sans prise de tête :

Par contre, je déconseille fortement le switch Linksys/Cisco Small Business SRW224G4P (24 ports PoE et 4 ports Giga non PoE) si vous comptez utiliser plusieurs VLANs, car 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.

VLAN or not VLAN

Tout d'abord, il ne faut pas perdre de vue l'essentiel : si on veut avoir une bonne qualité audio en téléphonie sur IP, il faut que les flux IP liés à la téléphonie soient transmis et reçus :

Si, sur le LAN de votre entreprise, 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), vous ne devriez pas avoir de perte de paquets et la latence devrait être très faible (1 ou 2 millisecondes), alors vous n'aurez même pas besoin de mettre en place de QoS ou des VLANs, 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 ou des VLANs ne vous apportera rien car votre hub n'a certainement pas de files de priorité et il ne sait pas séparer les VLANs, mais il faudra plutôt mettre votre vieux hub au placard et le remplacer par un vrai switch administrable qui tient la route.

Le conseil qui est généralement donné est d'isoler la téléphonie sur IP dans un VLAN dédié. Si vous suivez ce conseil, vous aurez par exemple sur votre LAN :

Pourquoi créer un VLAN dédié à la ToIP ?

Dans cet environnement multi-VLAN, il faudra penser aux problématiques suivantes :

Ces problématiques ont toutes une ou plusieurs solutions, et le choix de la solution dépendra de l'architecture réseau et du matériel existant. Je disais justement dans l'introduction de ce document qu'il était conseillé d'avoir de solides compétences réseau pour réussir un déploiement de ToIP... en voilà l'illustration !

Au contraire, les raisons qui peuvent vous pousser à ne pas mettre en place un VLAN dédié à la ToIP sont :

Le firewall et la QoS

Cette partie ne concerne que les personnes qui envisagent d'utiliser un opérateur IP. En effet, quand on utilise des lignes RNIS, le trafic VoIP va rester sur le LAN et ne va donc jamais traverser le firewall.

Choix actuel : firewall pfSense.

La problématique

Je suppose donc que vous avez fait le choix d'un opérateur IP. Comme vous voulez mettre toutes les chances de votre côté pour réussir votre déploiement, vous avez décidé de prendre une ligne xDSL dédiée à la VoIP, commandée chez le même opérateur que celui qui vous fourni le trunk SIP. Votre flux VoIP transitera sur le lien xDSL dédié puis sur le réseau de votre opérateur jusqu'au serveur SIP et ne passera donc pas par Internet ; votre opérateur doit être capable de vous garantir de la qualité de service depuis vos locaux jusqu'à son serveur SIP. Ce lien xDSL dédié à la VoIP se rajoutera au lien xDSL "Internet" déjà existant dans votre entreprise. Vous avez évidemment vérifié que le débit de votre lien xDSL en upload et en download allait permettre de supporter le nombre de communications simultannées maximum de votre trunk SIP. Etant donné que vous avez fait le choix d'un lien xDSL dédié à la VoIP, il n'est pas nécessaire de mettre en place de la QoS sur ce lien. D'ailleurs, le routeur/NAT fourni par votre opérateur n'a pas l'air de proposer cette fonctionnalité. Il n'y a donc a priori pas besoin de se casser la tête...

Mais que va-t-il se passer si le lien xDSL dédié à la voix sur IP est en panne ? Vous n'aurez plus de téléphone... dommage ! Pendant ce temps, votre lien xDSL "Internet", qui est a priori chez un autre opérateur, continue de fonctionner... ce serait vraiment dommage de ne pas l'utiliser ! Vous allez donc l'utiliser, mais le trafic de données (Web, mail, FTP, etc...) va cohabiter avec le trafic VoIP sur le même lien, ce qui risque de poser des problèmes de qualité. En effet, il suffit qu'il y ait par exemple un téléchargement ou un upload HTTP vers un serveur avec une bonne bande passante pour que ce trafic HTTP prenne toute la place et fasse perdre des paquets à la connexion téléphonique SIP/RTP. Or, la connexion téléphonique étant en UDP, les paquets perdus ne sont pas retransmis (ce qui est normal pour une application temps-réel par nature) et donc tout paquet RTP perdu va se traduire par une hachure dans la conversation téléphonique. De la même façon, si votre lien xDSL dédié à la téléphonie fonctionne mais que votre lien xDSL "Internet" est down, vous aurez certainement envie d'utiliser votre lien xDSL dédié à la VoIP pour l'accès Internet de l'entreprise, ce qui pose encore le problème de la cohabitation de la VoIP et de la data.

La solution

La solution à ce problème est de se doter d'un firewall qui gère le multi-WAN avec failover et la QoS. Concrètement, ce firewall va être connecté :

Comme le firewall a deux interfaces vers l'extérieur WAN1 et WAN2, on dit qu'il est multi-WAN. Si le firewall est réellement multi-WAN, alors il sait très certainement gérer le failover entre les multiples interfaces WAN. Attention, chez les constructeurs de routeurs/firewall, aucun firewall entrée de gamme ne gère le multi-WAN... il faut généralement monter en gamme et chercher quels sont les modèles qui proposent cette fonctionnalité.

L'objectif est donc de configurer le firewall de la façon suivante :

La QoS sur le lien xDSL

Dans cette section, je vais expliquer certains concepts de base pour bien comprendre comment on fait de la QoS sur un lien xDSL (ou câble ou fibre optique !). Ces concepts de base s'appliquent quel que soit le modèle de firewall, puisqu'ils ont trait au principe de fonctionnement de la QoS sur un accès Internet.

Quand une connexion entre 2 machines passe par plusieurs liens successifs, le débit maximum atteignable par la connexion sera celui du lien ayant le débit le plus faible. Par exemple, si un PC est connecté sur un port 100 Mbit/s d'un switch et qu'un serveur est connecté sur un port 1 Gbit/s du même switch, alors le débit maximum entre les deux ne pourra pas dépasser 100 Mbit/s. Le lien qui a le débit le plus faible est celui qui limite le débit de la connexion... et c'est donc aussi lui qui contrôle le débit d'une certaine façon ! En effet, si le débit de ce lien augmente temporairement, alors le débit de la connexion augmentera temporairement ; si le débit de ce lien diminue temporairairement, alors le débit de la connexion diminuera temporairairement.

Quand on veut faire de la QoS sur un lien xDSL, la première chose à faire est de mesurer le débit de ce lien (en upload et en download), puis de configurer le firewall pour que l'interface WAN reliée à ce lien ait un débit légèrement inférieur à celui du lien (-5% par exemple). Ainsi, le firewall va devenir le goulot d'étrangement de la connexion car le débit de son interface WAN associée sera inférieur au débit de la connexion... et c'est ainsi que le firewall sera le maitre du débit ! Maintenant que le firewall est devenu le maître du débit, on va pouvoir le configurer pour qu'il alloue ce débit intelligemment en mettant en priorité le trafic qu'on lui a demandé de mettre en priorité, etc...

Le deuxième concept à comprendre quand on veut faire de la QoS sur un lien xDSL est le suivant : on maîtrise ce qu'on envoie, mais on ne maîtrise pas ce qu'on reçoit. Si on regarde plus précisement ce qui se passe pour le trafic entrant (le download), on se dit à première vue que le firewall n'a pas réellement le pouvoir de contrôler le download, car le trafic qu'il reçoit sur son interface WAN est déjà entré dans le tuyau que constitue le lien xDSL et, si le download est saturé par plusieurs connexions concurrentes, le DSLAM a déjà constitué un premier goulot d'étranglement et a pu trasher des paquets qui étaient potentiellement des paquets VoIP. Quand les paquets "download" arrivent au firewall, même si ce dernier est configuré avec un débit légèrement inférieur et constitue à ce titre le plus petit goulot d'étranglement, le mal est déjà fait car des paquets ont déjà été trashé par le DSLAM, et on ne maîtrise pas les règles de priorité qui s'appliquent sur le DSLAM. On peut donc se dire à première vue que ça ne sert à rien de faire de la QoS sur le trafic entrant... En réalité, cela a quand même un intérêt, et je vais expliquer pourquoi. Imaginons que le trafic entrant est constitué de 2 connexions :

Quand les paquets de ces deux connexions arrivent au DSLAM, celui-ci doit gérer l'entrée dans le tuyau au débit limité que constitue le lien xDSL. Si la somme du débit des 2 connexions est supérieur au débit du lien xDSL, il va trasher des paquets indifféremment sur la connexion TCP ou la connexion UDP. Ensuite, le trafic arrive sur le firewall, qui est le vrai goulot d'étranglement de la connexion car l'interface WAN du firewall connectée à ce lien xDSL est configurée avec un débit de 5% inférieur au débit en download de la connexion. Les règles de QoS du firewall spécifient que la connexion téléphonique en UDP est prioritaire par rapport à la connexion HTTP/TCP. Le firewall ne va donc trasher aucun paquet de la connexion UDP mais uniquement des paquets de la connexion HTTP/TCP. Or, comme le firewall a trashé des paquets de la connexion HTTP/TCP, le serveur HTTP ne va pas recevoir de ACK de la part du client pour les paquets qui auront été trashés par le firewall, et va donc ralentir le débit de sa connexion TCP vers ce client. Comme le débit de la connexion TCP ralentit, la somme du débit des 2 connexions ne va plus dépasser le débit de la connexion xDSL et le DSLAM n'aura plus besoin de trasher des paquets. En conclusion, on peut dire que la QoS sur le trafic entrant a un intérêt à condition que le trafic soit majoritairement constitué de connexions TCP. C'est normalement le cas, car tout le trafic Web, mail et FTP est constitué de connexions TCP.

Il est facile de vérifier l'efficacité du fonctionnement de la QoS sur votre firewall. Pour cela, mettez votre installation téléphonique et un PC sur le même lien xDSL. Vérifiez que le PC n'a pas de téléchargements en tâche de fond et suivez les étapes suivantes :

  1. désactivez la QoS sur le firewall,
  2. lancez un appel téléphonique : la qualité audio doit être bonne. Gardez votre correspondant en ligne.
  3. lancez un ou plusieurs download et/ou upload de fichier sur Internet : la qualité audio devrait se dégrader au bout de quelques secondes (micro-coupures, hachures dans le son).
  4. arrêtez les transferts de fichier : la qualité audio doit revenir bonne immédiatement.
  5. raccrochez.

Puis, re-faites le même test avec les règles de QoS activées sur le firewall. La qualité audio de la conversation téléphonique doit rester bonne même pendant les transferts de fichiers. Si c'est le cas, alors vous pouvez en déduire que vos règles de QoS fonctionnent bien.

Le choix de pfSense

En tant que partisan du logiciel libre, pour mon choix de routeur/firewall avec support du multi-WAN et de la QoS, je préfère choisir un routeur/firewall basé sur du logiciel libre plutôt que de choisir un routeur/firewall de type Cisco, ZyXEL ou Fortigate. J'ai d'abord cherché dans le monde Linux. J'ai déjà mis en place du multi-WAN sous Linux en ligne de commande, et j'ai pu constater que c'était très complexe à configurer et je n'ai pas pu éviter d'écrire mes propres scripts (qui servaient notamment à tester périodiquement les connexions xDSL et à changer les règles de routage quand une des connexions était down). La mise en place de la QoS en ligne de commande sous Linux est moins compliquée, même si il faut prendre le temps de bien se documenter. A part cette expérience de multi-WAN et QoS en ligne de commande, je n'ai pas pu trouver une solution basée sur Linux où on pourrait configurer le multi-WAN et la QoS via une interface Web sans avoir recours à la ligne de commande (si vous en connaissez une, écrivez-moi un mail !).

Après avoir entendu plusieurs personnes dire du bien de pfSense, je me suis décidé à m'y intéresser malgré le fait que pfSense soit basé sur FreeBSD et que je n'ai aucune expérience de FreeBSD. Les systèmes BSD ont une solide réputation pour tout ce qui touche au routage et au firewalling. Le système de firewall de BSD s'appelle pf (comme Paquet Filter) et n'a rien à voir avec le système de firewall de Linux qui se nomme iptables.

pfSense est une distribution routeur/firewall basée sur FreeBSD. Comme toute distribution, elle est livrée avec ses images pour graver des CDs bootables et faire des clé USB bootables (pour Intel 32bit et 64bit entre autre). pfSense est entièrement configurable par une interface Web, y compris les fonctionnalités avancées de multi-WAN, de QoS et de VPN. Il est possible d'étendre les fonctionnalités natives de pfSense par l'installation de paquets supplémentaires (il existe même des paquets qui fournissent Asterisk !).

L'interface Web est vraiment bien faite, même si il faut compter un petit temps d'apprentissage. Pour cela, je conseille l'achat du livre pfSense, the definitive guide to the OpenSource Firewall and Router Distribution (lien Amazon), même si le livre est basé sur pfSense 1.2 alors que la version stable actuelle est la version 2.0.

Le choix du hardware pour pfSense

Il est possible d'installer pfSense sur n'importe quel PC ayant des cartes réseau supportées par FreeBSD (donc a priori toutes les cartes réseau pas trop exotiques) et possédant 256 Mo de RAM minimum. Attention, la QoS de pfSense utilise ALTQ (ALTernate Queueing framework), qui est un des frameworks de QoS de BSD, et pour que cela fonctionne, il faut que le driver de la carte réseau supporte ALTQ. La liste des drivers de cartes réseaux qui supportent ALTQ est disponible dans la page de man d'ALTQ, dans la section Supported Devices.

Ensuite, il faut trouver un hardware qui ait suffisamment d'interfaces réseau. Dans notre cas, on a besoin de 3 interfaces réseau (LAN, WAN1 et WAN2). En réalité, trouver une carte mère de PC qui intègre 2 interfaces Ethernet est déjà difficile (ça se trouve, mais le choix est assez restreint), mais en trouver une qui intègre 3 interfaces... Il y a bien sûr la possibilité d'ajouter des cartes PCI ou PCIe supplémentaires. Une autre possibilité, que je préfère et que j'ai déjà déployé, consiste à choisir une carte mère avec 2 interfaces Giga (une pour LAN et une pour WAN), de relier les 2 interfaces à un switch administrable et de créer une interface WAN1 virtuelle basée sur l'interface WAN physique et taggée dans un VLAN particulier, ainsi qu'une interface WAN2 virtuelle basée sur l'interface WAN physique et taggée dans un autre VLAN. Ainsi, on peut avoir un nombre illimité d'interfaces LAN et WAN, tout en ayant une carte mère standard avec 2 interfaces Ethernet.

Aujourd'hui, mon choix de hardware pour pfSense est la plateforme APU de PC Engines. Elle utilise une carte mère dotée de 3 interfaces Gigabit et d'un processeur AMD T40E 1 Ghz 64bit et d'un slot mSATA. Cette configuration est assez puissante pour servir de firewall sur un lien fibre optique. Cette plateforme est vendue en France par Gooze : avec 2 Go de RAM, un SSD de 16 Go avec pfSense pré-installé, le prix est de 140 € HT environ.

Fonction standard

Il existe de nombreuses façons de faire fonctionner le "standard" avec Asterisk. Si on est prêt à écrire quelques lignes de code, les possibilités sont sans limite graĉe à l'extrême flexibilité d'Asterisk. Voilà un exemple de modes de fonctionnement du standard utilisés lors de mes différents déploiements :

En plus de cela, on peut avoir :

Dans ce domaine, tout est possible ! Certaines fonctions se feront par un simple paramétrage ; d'autres nécessiteront d'écrire un petit morceau de dialplan dans Asterisk et peut-être de développer un petit script AGI qui sera appelé par le dialplan d'Asterisk.

Société de service

Pour mon premier déploiement Asterisk dans la société qui m'employait à cette époque, quand j'étais encore débutant sur Asterisk et dans le domaine de la ToIP en général, j'ai choisi une société de service experte sur Asterisk pour être accompagné lors du déploiement initial et pour avoir accès à un expert en cas de problème une fois le système en production (ou pour qu'une personne extérieure puisse intervenir si j'étais absent de l'entreprise et injoignable).

Bien sûr, il est possible de tout faire tout seul sans avoir recours à un prestataire extérieur, et c'est un des gros avantages du logiciel libre ! Mais attention, dans le cas de la téléphonie sur IP avec Asterisk, si vous souhaitez réaliser le déploiement tout seul, il faut :

Si vous avez des personnes techniquement compétentes dans votre entreprise, la meilleure méthode est probablement de choisir un prestataire spécialisé, et de faire le déploiement avec lui (et non de le laisser faire le déploiement tout seul) pour en profiter pour monter soi-même en compétence et être capable de réaliser seul un certain nombre de changements de paramétrage et les premiers diagnostics en cas de panne. Cela doit vous permettre d'acquérir un certain niveau d'autonomie dans le paramétrage de votre IPBX Asterisk et de résoudre seul les pannes simples. Si vous avez fait le choix d'un opérateur IP, l'idéal est d'avoir le niveau requis pour être capable de savoir si la panne vient de l'opérateur ou de l'installation de ToIP interne et, si la panne vient de l'opérateur, d'être capable de lui en apporter la preuve. En effet, les opérateurs IP ont tous la facheuse tendance à affirmer que le problème ne vient pas de chez eux tant qu'on ne leur a pas apporté la preuve technique... mais il faut être conscient que le niveau technique requis pour cela est assez élevé et ne s'acquiert pas en un jour !

Grâce à mes rencontres au sein de l'association Asterisk-France, je peux recommander un certain nombre d'intégrateurs dont je sais qu'ils ont le sérieux et les compétences requises pour un déploiement Asterisk :

Et, comme expliqué au début de cette page, je propose, dans le cadre de ma nouvelle activité professionnelle, mes services de déploiement d'IPBX Asterisk, en utilisant la distribution Xivo.

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.

Pour l'entreprise dans laquelle j'ai réalisé mon premier déploiement Asterisk, je me suis mis à la recherche début 2009 d'un interphone IP capable de déclencher l'ouverture d'une porte. Le vieil interphone analogique n'était pas relié à l'IPBX et cela n'était pas pratique. Après la lecture de cette page et quelques recherches Google, j'ai identifié 3 interphones SIP avec commande d'ouverture de porte :

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.

L'interphone IP a été déployé en gardant en parallèle l'interphone analogique en cas de problème ; ceci était tout à fait possible de part le mécanisme de commande de la porte d'entrée (contact sec ouvert par défaut). C'est 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é. J'ai 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 ; ils ont été upgradés en firmware 1.65 et tout est rentré dans l'ordre.

Actuellement, l'interphone est configuré pour composer un numéro spécial du 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 :

En conclusion, je déconseille l'interphone PanTel IP et, si c'était à refaire, j'essayerai l'interphone 2N Helios IP.

Quelques points techniques en vrac

La QoS sur le réseau

Comme je l'ai expliqué dans la section Réseau du chapitre Choix et motivation des choix, j'avais décidé au début de mon premier déploiement d'utiliser de la QoS au niveau IP, appelée DiffServ, pour mettre le trafic VoIP en priorité par rapport à tous les autres trafics. Cette solution avait été retenue au début, avant qu'un VLAN dédié à la ToIP soit crée. 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 :

Champ Binaire Hexadecimal Décimal
DSCP 101 110
TOS/DiffServ 101 110 00 0xB8 46

Pour mettre en place la QoS, il faut :

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 autres modèles de switch administrables supportant la QoS, cela se configure habituellement dans l'interface Web du switch.

Le call pickup : group ou directed ?

Le call pickup est une fonctionnalité d'une installation téléphonique qui permet à un utilisateur d'intercepter un appel qui n'est pas pour lui. L'exemple typique est le suivant : un bureau est partagé par deux personnes ayant chacun leur téléphone. Un des deux poste sonne, mais la personne n'est pas à son bureau et ne peut donc pas décrocher ; son collègue fait alors un call pickup depuis son propre poste et prend la communication. Cela lui évite de se lever et d'aller décocher le téléphone sur le bureau de son collègue.

J'ai fini par comprendre certaines subtilités du call pickup que je n'avais pas compris lors de mon premier déploiement Asterisk, et comme je n'ai pas trouvé sur Internet d'explication claire et précise sur les subtilités en question, je profite de cette page pour vous les révéler.

La principale subtilité à bien comprendre, c'est qu'il existe deux types de call pickup différents :

Si mon explication sur les deux types de call pickup n'est pas assez claire, vous pouvez lire celle de voip-info.org.

Directed call pickup Group call pickup
Fichier extensions.conf Utiliser la fonction Pickup (ou DPickup si vous avez le patch bristuff, comme c'est le cas de la version d'Asterisk fournie par Debian Lenny). Si vous voulez associer des touches de fonction du téléphone au monitoring de certains postes, ajoutez les hint nécessaires. Aucun paramétrage à faire
Fichier features.conf Aucun paramétrage à faire Définir la séquence de touches qui va déclencher le group pickup via le paramètre pickupexten. Dans mon exemple : pickupexten=*8
Fichier sip.conf Aucun paramétrage à faire pour la fonction de directed pickup. Si on veut faire du monitoring de postes par les touches de fonction des téléphones, il faut mettre dans la section [general] les paramètres notifyringing=yes et notifyhold=yes. Pour chaque poste, définir les groupes de pickup auxquels le poste appartient via le paramètre callgroup et les groupes sur lesquels le poste peut faire un group pickup via le paramètre pickupgroup.
Configuration des téléphones IP Facultatif. Si vous voulez éviter à vos utilisateurs d'avoir à taper la séquence de touches nécessaire pour faire un directed pickup, dans mon exemple **<numéro du poste qui sonne> (la séquence exacte depend de ce qui a été configuré dans extensions.conf), vous pouvez configurer des touches de fonction pour monitorer et faire des pickups sur les postes que vous avez choisi (une touche par poste) ; ainsi, quand un des postes monitorés sonne, la touche de fonction correspondante se met à clignoter et vous pouvez faire un directed pickup sur ce poste en appuyant sur la touche qui clignote. Facultatif. Si vous voulez éviter à vos utilisateurs d'avoir à taper la séquence de touches du group pickup que vous avez défini au niveau du paramètre pickupexten du fichier features.conf, vous pouvez configurer une touche de fonction du téléphone pour faire en sorte que l'appui sur cette touche déclenche la composition de la séquence de touches du group pickup, soit *8 dans mon exemple.
Avantages
  • On sait exactement sur quel poste cible on fait l'interception d'appel.
  • Possibilité d'associer des touches de fonction du téléphone au monitoring de certains postes (une touche par poste) et ainsi d'avoir la touche qui clignote quand le téléphone monitoré sonne et pouvoir intercepter l'appel par simple pression sur la touche qui clignote.
  • Très facile à configurer.
  • On peut facilement mettre en place des "droits d'accès" sur l'interception d'appel, pour contrôler qui a le droit de faire une interception d'appel sur qui.
Inconvénients
  • Pas facile à configurer si on écrit son fichier extensions.conf soi-même, notamment si on veut faire de l'interception sur les appels provenant de l'intérieur ET de l'extérieur et/ou si on veut mettre en place des "droits d'accès" sur l'interception d'appel.
  • Combinaison de touches pour faire l'interception d'appel plus longue à taper (et il faut la taper rapidement, avant que le téléphone cible n'arrête de sonner !). Si on passe par les touches de fonction du téléphone, on est alors limité par le nombre de touches de fonction disponibles.
  • Si on fait un group pickup alors que deux téléphones sont entrain de sonner dans les groupes sur lesquels on a le droit de faire cette interception d'appel, alors on ne peut pas prévoir laquelle des deux communications va nous être transmise.
  • A ma connaissance, on ne peut pas faire clignoter une touche de fonction du téléphone quand un poste sonne dans un groupe et l'associer à la combinaison de touches du group pickup.

Vous trouverez ci-dessous un exemple de configuration du dialplan (extensions.conf) pour faire du directed pickup :

Tout d'abord, il faut comprendre que la fonction Pickup prend en argument l'extension par laquelle passe l'appel, et non le numéro du poste qui sonne.

Au final, comme on veut généralement faire du directed pickup sur les appels venant de l'intérieur ET de l'extérieur en composant **<numéro du poste qui sonne>, on va enchainer les deux appels à la fonction Pickup, dans le contexte où se trouvent les téléphones IP (contexte appelé interne dans cet exemple) :

[interne]
exten => _**.,1,Pickup(${EXTEN:2})
exten => _**.,n,Pickup(${PICKUPEXT_${EXTEN:2}}@reception)
exten => _**.,n,Hangup()

Note : n'oubliez pas de remplacer la fonction Pickup par DPickup si vous utilisez le patch bristuff, en sachant que les paquets Debian Lenny utilisent ce patch.

En conclusion, je conseille d'utiliser le group pickup, qui est beaucoup plus simple à mettre en oeuvre et très facile pour les utilisateurs. J'utilise maintenant du group pickup pour tous mes déploiements !

Présentation du numéro et transfert d'appel

Lors de mon premier déploiement, j'ai rencontré un 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 Avencall sur ce sujet, et il m'indique que ce problème a été résolu par un commit qui ajoute le support du p-asserted et qu'il faut activer la fonction dans sip.conf et dans les téléphones IP. D'après mes recherches complémentaires, cette fonctionnalité est arrivée suite au travail sur le bug 8824 d'Asterisk, et est inclus dans la version 1.8.0 d'Asterisk, qui est sortie le 21 Octobre 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. . 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 activée par défaut.

J'ai pu faire marcher cette fonctionnalité avec un Asterisk 1.8.4 et un téléphone Aastra : le numéro du correspondant est bien mis à jour à l'issue du transfert d'appel. Pour cela, j'ai juste eu à ajouter le paramètre suivant dans sip.conf :

[general]
sendrpid=pai

Par contre, je n'ai pas pu faire marcher cette fonctionnalité avec un téléphone DECT Gigaset Siemens... ce qui montre bien que le support dans cette fonctionnalité doit être présent à la fois dans Asterisk et dans le téléphone IP pour que cela marche bien.

Les commandes de diagnostic

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 la passerelle Patton

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

Annexes - Anciens schémas d'architecture

Mon premier déploiement : schéma d'architecture de Juillet 2010 à aujourd'hui

Voilà l'architecture actuelle de mon premier déploiement ; le schéma correspond à la solution en place depuis l'arrêt de l'utilisation des lignes RNIS et le passage vers l'opérateur IP Acropolis Telecom en Juillet 2010.

diagramme d'architecture VoIP après le passage à un opérateur IP

Mon premier déploiement : 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 :

diagramme d'architecture VoIP après déploiement de la passerelle Patton

Mon premier déploiement : schéma d'architecture jusqu'en Juin 2009

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

diagramme d'architecture VoIP avant le déploiement de la passerelle Patton

Mon premier déploiement : schéma d'architecture initial

Voilà l'architecture initiale de mon premier 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 :

diagramme d'architecture VoIP avant l'utilisation d'une ligne analogique pour l'envoi des fax

XHTML 1.1 et CSS valides. Lien vers sites partenaires : Relecture Révision Correction - Les Tropes de Charlotte.