Table des matières

1. Introduction
   • A propos de l'auteur
   • Historique du document
   • A propos du document
2. Installation VoIP avec Asterisk
   • Schémas d'architecture
   • Matériel utilisé et budget
3. Mes bookmarks
4. Retour d'expérience global
5. Choix et motivation des choix
   • Téléphones IP filaires
   • Téléphones IP sans-fil
   • Canal de communication avec l'extérieur
   • Choix d'un opérateur IP
   • Le codec
   • Le packaging d'Asterisk
   • Serveur
   • Fax
   • Choix des interfaces téléphoniques
   • Le réseau local
   • Le firewall et la QoS
   • Fonction standard
   • Société de service
   • Interphone IP avec ouverture de porte
6. Quelques points techniques en vrac
   • La QoS sur le réseau
   • Le call pickup : group ou directed ?
   • Présentation du numéro et transfert d'appel
   • Les commandes de diagnostic
7. Annexes - Anciens schémas d'architecture

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

Auteur : Alexis de Lattre <alexis _chez_ miluni.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 https://alexis.miluni.fr/asterisk/

Mes fiches de paramétrages et mes documents de travail se trouvent sous forme de Google Docs dans ce répertoire partagé.

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

Par ailleurs, je suis l'auteur du connecteur Odoo-Asterisk (Odoo est un ERP en logiciel libre). Ce module est sous licence AGPL et il fait partie des projets de l'Odoo Community Association (OCA). Il est disponible sur le projet Github connector-telephony. Une documentation complète est disponible en anglais. Ce module a 3 fonctionnalités :

• il ajoute un bouton Dial en face des champs contenant un numéro de téléphone dans Odoo ; quand l'utilisateur clique sur ce bouton, Odoo envoie une requête à Asterisk ; le téléphone de l'utilisateur sonne, et, quand il décroche, Asterisk compose le numéro de téléphone du correspondant à la place de l'utilisateur. Simple et pratique !
• à la réception d'un appel, le dialplan d'Asterisk exécute un script AGI, qui va interroger Odoo pour savoir si le numéro qui est présenté est renseigné dans la base de contact d'Odoo ; si oui, il obtient alors le nom de la personne et met à jour le CallerID en ajoutant le nom. Ainsi, la personne qui reçoit l'appel verra le nom de son correspondant s'afficher sur l'écran de son téléphone IP, et pas seulement son numéro de téléphone. Idem sur les appels sortants, pour afficher sur l'écran du téléphone le nom de l'interlocteur.
• à la réception d'un appel entrant, la fiche de l'interlocuteur s'ouvre dans Odoo (ouverture automatique ou via un clic sur un bouton) ; cette fonctionalité est couramment appelée la remontée de fiche.

Dans la même série, j'ai publié un document intitulé Expérience de déploiements Odoo 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. 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-10-04	Je suis entrain de faire mon 2ème déploiement, dans une petite entreprise française. Pour ce déploiement, j'ai choisi les téléphones Aastra 31i, une passerelle SIP/RNIS Patton, et un serveur Elastix. Je n'ai pas encore réussi à tout faire marcher, car il faut que j'apprenne FreePBX, mais j'espère y arriver rapidement !
2009-10-18	Ma deuxième installation est maintenant en production. Il reste encore quelques détails à améliorer, mais ça fonctionne. Je suis globalement assez content de FreePBX, même si j'ai l'impression que c'est pas très bien documenté (mais je n'ai peut-être pas trouvé la bonne doc...). J'ai ajouté un tableau récapitulatif des différentes distributions Asterisk, et ajouté Xivo à la liste des distributions Asterisk.
2009-12-06	Le firmware 2.69 pour les téléphones ST2030 est sorti ; le bug sur le call pickup du firmware 2.68 est apparemment toujours présent. Je remarque d'ailleurs, et c'est la première fois, que les membres du form Asterisk-france ne sont plus motivés pour tester les nouveaux firmwares Thomson, comme si ils avaient perdu l'espoir que Thomson sorte un jour un firmware sans bug gênant ! De mon côté, j'utilise toujours le firmware 1.65, qui ne souffre que d'un seul petit bug (cf détail des bugs par version de firmware dans cette section).
2010-04-24	Ajout de précisions sur mon avis concernant les téléphones ST2030, l'interphone Pantel IP et le switch Linksys PoE. Mise à jour de la partie réseau, car nous utilisons maintenant un VLAN dédié à la VoIP, ce qui n'était pas le cas initialement. Partout où il est écrit Zaptel, je rappelle que le nouveau nom est DAHDI. Ajout d'un tableau récapitulatif des composants logiciels d'un IPBX dans la section choix du packaging Asterisk. Revue complète de la section choix des interfaces téléphoniques (anciennement appelée "choix des cartes téléphoniques). Ajout d'une section Annexes avec les anciens schémas d'architecture. Passage au correcteur orthographique. Correction des liens morts.
2010-04-27	Ajout d'éléments dans le tableau récapitulatif des avantages et des inconvénients des différentes solutions pour le packaging d'Asterisk.
2010-04-29	Un élément de plus dans les défauts de l'interphone Pantel.
2010-05-03	Ajout de précisions concernant les switchs PoE et un exemple de PC fanless.
2010-05-07	Ajout d'une colonne sur Asterisk 1.6 dans le tableau de comparaison des distributions Asterisk.
2010-05-31	Ajout des commandes de diagnostic Patton que j'utilise.
2010-06-03	Etape importante dans l'évolution de notre déploiement Asterisk : nous avons choisi un nouvel opérateur de téléphonie fixe et c'est un opérateur IP : Acropolis Telecom. Nous allons donc passer de nos accès Numéris France Telecom à un accès SDSL avec une interconnexion en trunk IAX entre notre serveur Asterisk et les équipements d'Acropolis Telecom. Nos numéros de téléphone fixe actuels seront portés chez Acropolis. Cette page va donc évoluer dans les prochaines semaines pour vous faire part de notre retour d'expérience une fois que le nouvel accès sera mis en place, c'est à dire d'ici fin Juin.
2010-06-10	Mise à jour de notre serveur Asterisk de Debian Etch à Lenny. Utilisation des paquets Debian pour Asterisk, en remplacement de notre ancien Asterisk compilé à la main. J'ai mis à jour le tableau regroupant les versions des composants logiciels utilisés ainsi que la section concernant le choix du packaging d'Asterisk.
2010-06-11	Petit souci concernant les conférences téléphoniques : la combinaison de DAHDI 2.3.0 avec Asterisk 1.4.21 ne marche pas. Par contre, Asterisk 1.4.21 marche bien avec Zaptel 1.4.11. D'après mes recherches, la première version d'Asterisk 1.4 qui supporte DAHDI est Asterisk 1.4.22.
2010-06-24	Nous avons mis en place le trunk IAX avec Acropolis Telecom, notre nouvel opérateur de téléphonie fixe, via la liaison SDSL dédiée. Nous l'utilisons pour les appels sortants et cela marche bien... mais c'est encore trop tôt pour porter un réel jugement. Nous continuons de recevoir les appels par nos lignes Numéris et notre passerelle SIP/RNIS Patton jusqu'au portage de nos numéros chez Acropolis, qui aura lieu la semaine prochaine. Je mettrai alors à jour le schéma avec la nouvelle architecture.
2010-07-03	Le portage des numéros a été réalisé avant-hier ; ça s'est globalement bien passé, même si ça n'a malheureusement pas été parfait. Je donnerai plus de détails très prochainement ; il faut aussi que je m'attaque à la mise à jour du schéma d'architecture suite à cette migration.
2010-07-09	Mise à jour du schéma d'architecture suite au basculement vers notre nouvel opérateur IP ; l'ancien schéma d'architecture a été déplacé à la fin du document. Mise à jour de la section sur les fax, de la section choix du canal de communication avec l'extérieur et création d'une section choix d'un opérateur IP, qui devra encore être complétée.
2010-07-23	Relecture complète. Suppression de tout ce qui était obsolète dans la partie sur l'installation du serveur Asterisk. Suppression de toutes les références à mISDN, car on m'a dit que les cartes RNIS PCI B410P étaient maintenant bien supportées par DAHDI ; comme je ne sais pas si il vaut mieux utiliser mISDN ou DAHDI, je préfère ne rien dire et ne pas inciter à choisir mISDN. Amélioration du schéma d'architecture. Ajout d'une colonne "Produit que je recommande ?" dans le tableau du budget. Beaucoup d'ajouts aux sections choix de l'opérateur IP et choix du canal de communication avec l'extérieur avec notamment une comparaison des coûts entre la solution RNIS et la solution d'un opérateur IP. Ajout d'une section sur le choix du codec, qui demande encore à être complétée. Nouvelle section Interconnexion avec un opérateur IP.
2010-08-10	Ajout d'un point supplémentaire (négatif) sur notre expérience avec Acropolis Telecom.
2010-09-12	Ajout d'une section sur le call pickup, et en particulier la distinction entre le directed pickup et le group pickup... une subtilité que j'ai compris seulement récemment !
2010-09-23	Annonce de mon module de click2dial Asterisk pour OpenERP, un ERP en logiciel libre. Ce module est sous licence AGPL, la même licence qu'OpenERP.
2010-10-20	Petite mise-à-jour pendant la conférence Asterisk au salon IP Convergence !
2010-11-02	J'ai déjà trouvé un bug dans le firmware 2.72 des téléphones ST2030 (le tableau qui résume les bugs par version a été mis-à-jour), et c'est confirmé par les témoignages sur le forum Asterisk-France. Thomson est donc fidèle à sa tradition de firmwares buggés... alors que, sur les téléphones Aastra, je n'ai pour l'instant jamais trouvé le moindre bug !
2010-11-12	Mise à jour de la partie sur le choix du hardware.
2010-12-06	Depuis Décembre 2010, Acropolis Telecom émet une seule facture par mois (au lieu de 2)... un point négatif en moins pour Acropolis !
2010-12-29	Mise à jour du descriptif concernant le module asterisk_click2dial pour OpenERP que j'ai développé, pour mentionner la nouvelle fonctionnalité de présentation du nom du correspondant sur un appel entrant. Voilà le lien vers l'annonce de cette nouvelle fonctionnalité.
2011-02-18	Grosse mise à jour : mes déconvenues avec Acropolis Telecom qui m'ont fait changer ma recommandation concernant les canaux de communications avec l'extérieur et les opérateurs IP. Ma troisième expérience de déploiement Asterisk, cette fois-ci avec Xivo, qui est une très bonne distribution Asterisk que je recommande comme choix de packaging Asterisk.
2011-03-21	Ajout du problème de fiabilité des combinés des téléphones ST2030, que nous ne sommes apparemment pas les seuls à constater.
2011-05-12	Une remarque en plus sur le téléphone ST2030 : défauts du port "PC".
2011-10-26	J'ai complété la partie choix du serveur avec l'expérience de mon 4ème déploiement Asterisk où j'ai choisi un serveur no moving parts c'est à dire un serveur fanless avec un SSD.
2011-11-29	J'ai pu faire marcher la fonctionnalité p-asserted avec Asterisk 1.8, ce qui permet d'avoir la mise à jour de la présentation du numéro lors d'un transfert d'appel, cf cette section. Ma section liste des imperfections qu'il reste à corriger est donc maintenant vide !
2011-12-29	Suite à ce que j'ai appris sur mes déploiements récents, j'ai ajouté une partie sur le choix des téléphones sans-fil et j'ai complété l'information sur les opérateurs IP avec la nouvelle offre de trunk SIP d'OVH.
2012-04-09	Ajout d'infos sur Xivo 1.2 ainsi que sur l'offre SIP trunk + connexion dédiée d'OVH. Un downtime ajouté au tableau de suivi de nos downtimes Acropolis Telecom.
2012-07-15	Mise à jour des schémas d'architecture recommandé. Ajout du Shuttle XS35v2 dans la section Serveur. Mise à jour de mon avis sur Xivo (suite à mes premiers déploiements de Xivo 1.2)
2012-11-02	Passage du titre au pluriel, vu que ce document se base maintenant sur plusieurs déploiements que j'ai réalisé, et adaptation du texte en conséquence. Ajout de mon avis sur Yealink, depuis que j'ai commencé à utiliser ce modèle de téléphone SIP.
2012-12-28	Suite de l'adaptation pour rendre compte de mes multiples déploiements. Explications sur les offres d'OVH dans la partie choix d'un opérateur IP. Ajout d'infos sur le codec G722 dans la section choix du codec. Ré-écriture complète de la partie sur le réseau et de la partie fonction standard. Sur les diagrammes, l'image du PC est maintenant celle d'un XS35v2. Mention de la gamme Gigaset N720 dans la partie téléphones IP sans fil. Nombreuses petites modifications et mises-à-jour à plein d'endroits.
2013-03-08	Mise à jour de la partie choix des téléphones IP filaires suite à mon premier déploiement en prod de téléphones Yealink.
2013-04-05	Ajout d'un tableau sur les downtime d'OVH depuis le 1er Janvier 2013 dans la partie choix d'un opérateur IP.
2013-04-19	MAJ du tableau des downtime d'OVH suite à une nouvelle panne.
2013-08-09	MAJ du diagramme d'architecture OVH avec l'introduction du firewall pfSense. Ajout de la solution DECT de Yealink dans la section téléphones IP sans fil. Ajout d'une nouvelle section Le firewall et la QoS. Ajout d'une table des matières (enfin !).
2013-08-31	MAJ de la section choix du hardware pour pfSense avec les specs de la prochaine version de la carte mère du boitier Alix avec ports Giga.
2013-10-04	Quelques précisions sur la remontée de fiche avec Xivo. Ajout d'un nouveau hardware conseillé pour le serveur Asterisk dans la section choix serveur.
2014-01-17	Mise à jour des tableaux de panne d'OVH et Acropolis.
2014-01-19	Ajout du prix des offres de Stella en RNIS et OpenIP en trunk SIP.
2014-04-21	Grosse mise à jour : nouveaux schémas d'architecture avec les patton RNIS+FXS pour le fax, mise à jour de la section sur les téléphones fixes avec la nouvelle gamme Yealink, mise à jour de la section sur le Serveur avec le Intel NUC Celeron, mise à jour du hardware pour pfSense (APU dispo), ré-écriture de la partie sur le fax. Suppresion de parties obsolètes sur le ST2030 et la config Patton (les explications étaient pour de très vieux firmwares).
2014-05-26	MAJ du tableau des pannes d'OVH avec la panne de Vendredi dernier. Avertissement sur un probable pb d'autonomie des DECT Yealink. Ajout du NUC fanless dans la section sur choix serveur.
2014-06-23	MAJ avec plus d'infos sur le NUC Atom fanless dans la section choix serveur et la semaine horrible d'OVH.
2014-12-09	MAJ avec mes mauvaises expériences avec le NUC Atom fanless (pb de boot sans écran) et des infos sur les alternatives au NUC chez Gigabyte dans la section choix serveur. Un mot également sur les nouveaux firmwares des téléphones DECT Yealink dans la section choix téléphone IP sans fil.
2015-04-18	MAJ avec ma recommandation du Brix de Gigabyte dans la section choix serveur. MAJ des diagrammes avec l'image du Brix.
2015-08-07	Petites modifications et mises-à-jour mineures à plusieurs endroits.
2015-10-24	Mise-à-jour de la partie sur les qualités et défauts de Xivo.
2017-03-04	Mise-à-jour avec l'arrivée de la distribution Wazo, le fork de Xivo et avec mon expérience avec l'interphone IP 2N.
2018-12-26	Publication de mes fiches de paramétrage. Mise-à-jour de la section intégrateur, des distributions Asterisk, du matériel DECT.
2020-04-29	Mise-à-jour de la section interphone (Fanvil) et des distributions Asterisk (Issabel, Wazo Platform).
2024-12-25	Mise en ligne sur une nouvelle URL alexis.miluni.fr/asterisk

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.

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 :

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

Ce PABX était relié à 3 lignes RNIS T0 de France Telecom. Rappel : une ligne T0 permet d'avoir 2 conversations téléphoniques simultanées. Ce PABX ne convenait plus à nos besoins car, avec la croissance des effectifs de l'entreprise, il n'y avait plus de ports libres pour brancher des téléphones supplémentaires !

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 :

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

Installation VoIP avec Asterisk

Schémas d'architecture

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

• si votre priorité est la qualité audio et la disponibilité de la connexion téléphonique vers l'extérieur, je recommande de conserver les lignes RNIS, cf mon premier schéma d'architecture ;
• si votre priorité d'avoir la solution la moins chère, je recommande l'opérateur IP OVH, cf mon deuxième schéma d'architecture.

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.

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

Matériel utilisé et budget

pour un déploiement avec un opérateur IP

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

Composant	Produit retenu	Commentaire	Acheté chez	Prix unitaire HT
Serveur	Gigabyte Brix + 2 ou 4 Go de RAM + petit SSD		boutique en ligne	200 €
Switch PoE	D-Link DES-1210 (fast) ou DGS-1210 (giga) PoE	Choix du modèle exact en fonction du nombre de ports requis	boutique en ligne	137 € pour le modèle 8 ports
Téléphone	Yealink T42G	Prise casque. 6 touches programmables. Non compatible avec l'extension standard.	IT-logiq ou IP and Go ou OfficeEasy ou Opcom	moins de 100 €
Base DECT sans roaming	Yealink W60B	Gère 8 combinés max. 8 communications simultannées.	IT-logiq ou IP and Go ou OfficeEasy ou Opcom	80 €
Combiné DECT	Yealink W56H ou W53H	Combiné supplémentaire pour la base W60B	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	PC-engines	130 €

pour un déploiement avec des lignes RNIS

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

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

Mes bookmarks

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

• Asterisk.org, le site communautaire du projet Asterisk.
• le Wiki d'Asterisk, qui contient toute la documentation officielle d'Asterisk.
• Asterisk France : site de l'ancienne association Asterisk-France (dissoute en 2019), qui hébergeait notamment le principal forum communautaire français sur Asterisk. Le forum est encore accessible en lecture seule, pour archives.
• Voip-info.org : très gros Wiki communautaire qui parle des sujets relatifs à Asterisk et à la VoIP, mais la plupart des infos sont très anciennes et donc il faut éviter de l'utiliser aujourd'hui.
• The Asterisk Guru : site proposant un certain nombre de tutoriels sur Asterisk et ce qui tourne autour.

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 :

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

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

1. Asterisk et la VoIP ne sont pas des technologies simples qui "tombent en marche" tous seuls : il faut s'y intéresser vraiment et s'y plonger à fond pour bien maîtriser tous les paramètres techniques... et ils sont nombreux ! Il faut bien mûrir les choix techniques à faire (ils sont listés ci-dessous) et cela prend du temps.
2. le plus long n'est pas de comprendre et d'écrire les fichiers de configuration d'Asterisk mais ceux des téléphones IP !
3. si vous faites le choix d'un opérateur IP, faites très attention à la problématique de qualité de service et ne prenez cette option que si à l'endroit où vous êtes implanté vous avez des accès Internet de qualité (fibre optique ou ADSL avec longueur de ligne raisonnable).

Choix et motivation des choix

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

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

Téléphones IP filaires

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

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

• il représente la plus grosse partie du budget (sauf si vous avez moins de 5 téléphones).
• il faut du temps pour se familiariser avec la configuration d'un téléphone IP : chaque constructeur a sa propre méthode pour le provisionning et la mise-à-jour des firmwares ainsi que des petits secrets à découvrir... il est donc difficile de bien connaître plusieurs marques.
• c'est ce que verront les utilisateurs de la nouvelle installation.
• il joue un rôle important dans la qualité audio.

Vous allez choisir un téléphone IP professionnel qui utilisera le protocole SIP. Ne cherchez pas sur les sites de vente grand public du type LDLC ou Rue du commerce, vous ne les trouverez pas ou très peu. Il vous faudra plutôt consulter les sites des constructeurs pour avoir les spécifications et les sites de vente spécialisés dans la téléphonie (IP & Go, One Direct, 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 :

• Grand Stream,
• Mitel (ex-Aastra),
• Snom,
• Yealink, constructeur chinois,
• Cisco Small Business (ex-Linksys), dont la gamme SPA propose des téléphones SIP.

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.62	bug sur les touches de monitoring des modules d'extension
1.63	bug sur les touches de monitoring toujours présent
1.65	petit bug au moment de la réception d'un appel quand on est déjà en communication : le haut-parleur se met à émettre la conversation en cours pendant une demi-seconde sans raison. C'est le firmware qu'on utilise actuellement car c'est celui qui est à mon sens le moins buggé.
1.66	bug sur les touches de monitoring des modules d'extension réintroduit
2.67	bug sur le 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.68	bug sur les touches de monitoring 64 à 66 et problème sur le directed call pick-up (plus de détails ici).
2.69	selon 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.72	bug 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 (maintenant Mitel suite au rachat d'Aastra par Mitel) 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). Le téléphone 6731i a été pendant plus années mon choix de référence pour plusieurs raisons :

• très bonne qualité audio,
• firmware de très bonne qualité,
• la configuration centralisée par TFTP est très simple,
• il marche parfaitement bien avec Asterisk et Aastra est un constructeur impliqué dans la communauté Asterisk : Asterisk est officiellement supporté par Aastra (la doc des téléphones Aastra donne des exemples de configuration d'Asterisk !), des ingénieurs Aastra répondent parfois dans les forums Asterisk anglophones, Aastra est membre de l'association Asterisk-France, etc...
• son prix est compétitif (moins de 80 € HT).

Ce modèle avait cependant quelques défauts :

• un défaut majeur : il n'a pas de prise casque,
• deux défauts mineurs :
  • l'écran est petit,
  • il n'est pas compatible avec l'extension standard (module 536M alias M670i).

Ces 3 "défauts" obligaient 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 étaient plus élevés et dépassaient 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.

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. Depuis ce premier déploiement, je n'utilise plus que des téléphones fixes Yealink pour mes déploiements.

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

• l'apparition de ports gigabit sur certains modèles (T23G, T42G, T46G et T48G).
• l'apparition d'un écran couleur sur certains modèles (T46G et T48G).
• l'apparition d'un port USB sur certains modèles (T46G et T48G), ce qui permet de brancher un dongle USB Bluetooth et d'utiliser des casques Bluetooth. Les casque Bluetooth sont beaucoup moins onéreux (car beaucoup plus démocratisés) que les casques professionnels DECT, ce qui permet de s'équiper d'un casque sans fil à un coût raisonnable.
• des téléphones paperless (les touches de fonctions sont situées sur les côtés de l'écran et leur libellé est indiqué sur le LCD ; il n'y a donc plus besoin d'utiliser un morceau de papier pour indiquer le libellé des touches)
• le fait qu'ils sont livrés sans bloc d'alimentation.

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 T21P, T41P, T42G et T46G en production et je n'ai trouvé aucun bug firmware). Le succès de Yealink n'est pas prêt de s'arrêter...

Téléphones IP sans-fil

Choix actuel pour une solution sans roaming : borne DECT Yealink W60B et le combiné W53H ou W56H 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 :

• le WiFi n'a pas été conçu pour le transport de données en temps réel ; quand le réseau WiFi est un peu chargé, la latence peut augmenter significativement, ce qui est mauvais en ToIP.
• le WiFi est plus consommateur en énergie pour le terminal que le DECT ; les téléphones WiFi ont donc une autonomie plus faible.
• les téléphones WiFi sont beaucoup plus chers, moins fiables et l'offre est réduite (on peut probablement dire que c'est à la fois une cause et une conséquence du succès du DECT).
• le roaming (basculement transparent d'une borne à une autre quand le téléphone se déplace) a été prévu dès le départ dans la norme DECT, mais pas en WiFi.

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 :

• les constructeurs/gammes qui fournissent une vraie infrastructure DECT, c'est à dire capables de faire fonctionner des bornes en réseau avec du "vrai" roaming et handover. Dans cette catégorie, on trouve :
  • Kirk, qui a été racheté par Polycom (la gamme affiche maintenant le nom Polycom, mais beaucoup de gens continuent de l'appeler Kirk),
  • Aastra,
  • la gamme Gigaset N720 de Siemens (sortie en Février 2012, cf le communiqué de presse).
• les constructeurs/gammes qui ne fournissent qu'une infrastructure DECT limitée, sans roaming ni handover entre plusieurs bornes. Dans cette catégorie, on trouve :
  • la gamme "Gigaset Pro" de Siemens, avec la borne Gigaset N510 IP Pro,
  • Yealink, avec la borne W52P.

Je vous propose un petit zoom sur les solutions DECT de Polycom, la gamme N510 IP Pro de Siemens et la gamme W52/W53/W56 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 :

• un port Ethernet et un port pour une ligne analogique,
• jusqu'à 6 combinés, soit 6 comptes SIP,
• jusqu'à 2 communications simultanées en SIP (plus une communication simultanée en analogique),
• la base est alimentée via un bloc d'alimentation fourni ; elle ne peut pas être alimentée en PoE.

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 :

• un port Ethernet (pas de port analogique),
• jusqu'à 6 combinés, soit 6 comptes SIP,
• jusqu'à 4 communications simultanées,
• la base peut être alimentée en PoE ou via un bloc d'alimentation fourni.

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 W60B a les caractéristiques suivantes :

• jusqu'à 8 combinés, soit 8 comptes SIP,
• jusqu'à 8 communications simultanées,
• jusqu'à 6 repeaters simultanés (modèle Yealink RT30 ; un repeater peut permettre de déporter jusqu'à 2 communications simultanées),
• alimentable en PoE ou via un bloc d'alimentation fourni.

Yealink propose 3 modèles de combiné : le W52H, qui est le combiné historique, et le W56H, qui a été lancé en 2016 et le W53H qui a été lancé fin 2018. Le W56H coûte une douzaine d'euros de plus que le W52H (prix grossiste) et propose une autonomie 3 fois plus importante, un écran plus grand, un clavier rétro-éclairé, un design plus fin et soigné... mais sa hauteur est tellement importante (17,6 cm pour le W56H vs 14,4 cm pour le W52H) que cela peut être un critère bloquant pour certains. Ce problème est résolu avec le W53H, qui a une taille plus raisonnable et une bonne autonomie sans être aussi énorme que le W56H.

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

Le firmware de la base et du combiné Yealink a mis plusieurs années à être vraiment mature, mais je pense qu'on peut dire qu'ils le sont devenus aujourd'hui. Par exemple, l'autonomie en veille et la vitesse de naviation dans le répertoire ont été améliorés par des mises-à-jour firmware. De plus, un problème d'ergonomie que j'avais remonté dans le forum a été corrigé dans le firmware suivant (26.73.0.11) ; un bel exemple de prise en compte du retour des utilisateurs de la part des développeurs de Yealink ! Quand vous déployez une borne et un combiné DECT Yealink, commencez par upgrader à la fois la borne et le combiné vers la dernière version de firmware disponible pour profiter des nombreuses améliorations et corrections.

La gamme Polycom

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

• la solution mono-cellule KWS (Kirk Wireless Server) 300, qui utilise une seule borne,
• la solution multi-cellules KWS 6000, qui est constituée de plusieurs bornes ainsi que d'autres composants.

La borne KWS 300 a les caractéristiques suivantes :

• jusqu'à 12 combinés, soit 12 comptes SIP,
• jusqu'à 4 communications simultanées,
• jusqu'à 6 repeaters simultanés,
• alimentation en PoE.

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 :

• le KWS 6000 lui-même, qui est le chef d'orchestre de l'infrastructure DECT : c'est lui qui assure la connection SIP avec le serveur Asterisk, mais il ne fait pas office de borne DECT. Ce matériel coûte 680 € HT environ. Si vous dépassez les 30 téléphones DECT, il faut ajouter des licences logicielles : vous avez le choix entre la licence 150 utilisateurs i.e. 150 téléphones DECT (750 € HT environ), 500 utilisateurs (1650 € HT environ), 1500 utilisateurs (3000 € HT environ) ou 4096 utilisateurs (4600 € HT environ).
• les Kirk Media Ressources (1170 € HT environ), qui assurent la conversion de media (convertion de codec ?). Chaque Media Ressource gère jusqu'à 32 communications simultanées en G711 (il en gère 24 en G729 avec le "Codec Module"). Le KWS 6000 intègre une Media Ressource en interne.
• les Kirk IP Base stations (540 € HT environ), qui sont des bornes radio DECT alimentées en PoE, et qui assurent chacune jusqu'à 11 appels simultanés,
• les éventuels repeaters, en sachant qu'un Kirk IP Base station peut avoir jusqu'à 6 repeaters. Il existe plusieurs modèles pour une infra multi-cellules ; il y a notamment le modèle 0233 4601 qui peut déporter jusqu'à 4 communications simultanées et coûte 240 € HT environ.

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 :

• un KWS 6000
• une licence pour le KWS 6000 si vous dépassez 30 téléphones DECT,
• suffisamment de bornes IP Base station pour assurer une bonne couverture de la zone, en gardant en tête qu'une borne peut gérer jusqu'à 11 appels simultanés,
• pour les zones à couvrir dépourvues de prise réseau, il faut prévoir des repeaters,
• ne pas oublier le switch PoE, nécessaire pour l'alimentation des Base stations.

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 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 En 10 ans d'expérience avec de nombreux déploiements, je n'ai eu qu'une seule fois une ligne RNIS en dérangement ; en ce qui concerne les liens ADSL, j'ai arrêté de compter depuis longtemps !	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 :

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

Malheureusement, à 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 :

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

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 :

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

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

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

Dans le cas d'une solution RNIS, on ne prévoit généralement pas de lien de backup en cas de panne du lien RNIS, car les liens RNIS sont très fiables. 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 :

• utiliser en backup une ligne RNIS T0. Cela oblige à garder une ligne RNIS T0 chez France Telecom avec un numéro de téléphone associé (numéro qui ne sera pas connu par les correspondants de l'entreprise).
  • Fonctionnement pour les appels entrants : quand votre opérateur IP n'arrive pas à vous joindre par le trunk SIP, il transfert l'appel entrant vers le numéro associé à la ligne RNIS de backup.
  • Fonctionnement pour les appels sortants : il faut configurer le dialplan d'Asterisk pour que, quand un appel sortant n'arrive pas à s'établir par le trunk SIP, on fait passer la communication par le lien RNIS.
  • Coût de cette solution : 35,60 € HT par mois pour une ligne RNIS T0, plus le coût d'une passerelle SIP/RNIS ou d'une carte PCI RNIS.
  • Nombre maximum d'appels simultanés en fonctionnement dégradé : 2 si vous avez une seule ligne RNIS T0 de backup.
• utiliser en backup le lien ADSL/câble/... dédié à l'accès Internet de l'entreprise.
  • Fonctionnement : tout d'abord, il faut se rappeler que c'est le serveur Asterisk de l'entreprise qui initie la connexion SIP vers l'opérateur IP, et non l'inverse. En cas de panne du lien ADSL ou SDSL dédié à la VoIP, il faut donc qu'Asterisk initie une nouvelle connexion SIP vers l'opérateur IP en passant par le lien Internet de l'entreprise. Cela se fait assez simplement en mettant en place une surveillance du lien ADSL ou SDSL dédié à la VoIP et, dès qu'on détecte que le lien est down, on modifie la table de routage appropriée pour passer par le lien Internet de l'entreprise. Cela requiert que les serveurs SIP de l'opérateur IP soient joignables par Internet et pas seulement par le lien ADSL/SDSL dédié à la VoIP, mais c'est normalement le cas chez tous les opérateurs IP.
  • Coût de cette solution : nul, si l'entreprise a un ou plusieurs liens pour l'accès Internet.
  • Nombre maximum d'appels simultanés en fonctionnement dégradé : dépend du débit du lien Internet et de la répartition de ce débit entre le trafic data et le trafic voix.
  • Inconvénient : quand le lien dédié à la VoIP est down et que le trunk SIP utilise le lien xDSL dédié à l'accès Internet de l'entreprise, le trafic VoIP se retrouve en concurrence avec le trafic data, ce qui peut occasionner des paquets VoIP perdus en cas de saturation du lien, et donc une dégradation de la qualité audio des communications téléphoniques. La solution à ce problème est de mettre en place des règles de QoS sur le firewall du lien dédié à l'accès Internet, mais les petits firewalls que l'on trouve dans les PMEs ont rarement cette fonctionnalités (dans les TPEs, c'est souvent la box de l'opérateur Internet qui fait juste un partage de connexion).

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

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

Pour le choix d'un opérateur IP, dans l'hypothèse où vous êtes éligible à l'ADSL et pas à la fibre optique, je conseille de choisir :

• l'opérateur OVH, si celui-ci a dégroupé le NRA sur lequel vous êtes raccordé

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 suivants sont recommandables :

• Acropolis Telecom, qui propose des offres en trunk SIP ou IAX avec le lien ADSL ou SDSL. Ils achètent leurs liens SDSL à Orange, et ils ont une collecte ATM directement chez Orange, ce qui leur permet de garantir la qualité de service entre le DSLAM et leur réseau.
• OpenIP, qui propose des offres en trunk SIP avec le lien ADSL ou SDSL. Ils achètent leurs liens xDSL chez Orange ou SFR et ont une collecte directement ces opérateurs.
• OVH, qui propose des offres en trunk SIP avec un lien xDSL chez SFR ou Orange. OVH est connu pour ses tarifs très compétitifs, avec la possibilité d'avoir de l'illimité vers les fixes et les modules (modulo la clause de fair-use).

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 :

• gérer ses coordonnées dans l'annuaire universel,
• changer son mot de passe SIP,
• restreindre l'accès à son compte SIP depuis une ou plusieurs IPs,
• sélectionner le ou les codecs utilisés,
• configurer une redirection d'appel si le client SIP n'est pas enregistré sur le serveur SIP d'OVH.

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 :

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

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 :

• Points positifs :
  • la latence entre notre serveur Asterisk et le serveur IAX d'Acropolis Telecom via la ligne SDSL est très faible et très stable : elle varie entre 11 et 13 millisecondes seulement !
  • nos interlocuteurs au support technique d'Acropolis Telecom ont un bon niveau technique et on peut sans problème parler avec précision de certains points techniques.
  • la qualité audio des communications téléphoniques est bonne : nos employés ne se sont aperçu de rien lors du basculement de nos lignes RNIS vers Acropolis Telecom.
• Points négatifs :
  • nous avons été victime d'un mensonge par omission de la part d'Acropolis Telecom. Dès le début de nos discussions avec Acropolis Telecom, nous avions mentionné que nous avions beaucoup de clients à l'étranger et donc beaucoup d'appels internationaux. Nous avions insisté sur le fait que nous ne voulions pas avoir de dégradation au niveau de la qualité des communications par rapport à nos lignes RNIS France Télécom. Acropolis Telecom nous a proposé une grille tarifaire très compétitive au niveau des communications internationales par rapport aux tarifs de France Telecom. Après la mise en production, nous avons été satisfait de la qualité audio des communications à l'international, mais certains de nos employés basés à l'étranger nous ont informé que, lors qu'ils recevaient un appel émis depuis nos bureaux, la présentation du numéro ne fonctionnait pas. Pourtant, la présentation du numéro continuait de bien fonctionner lors de mes tests vers des téléphones portables et fixes français... mais je n'avais pas la possibilité de tester moi-même la présentation du numéro vers des téléphones étrangers. Je pensais qu'il s'agissait d'un problème de configuration, et comme je ne trouvais pas la solution tout seul, j'ai ouvert un ticket chez Acropolis Telecom. Quelle ne fut pas ma surprise quand j'ai reçu la réponse : on m'a alors informé que la présentation du numéro n'était pas garantie sur les appels vers l'étranger, mais qu'il était possible de basculer sur une autre "sortie" pour les appels internationaux où la présentation du numéro est garantie... sachant que cette "autre sortie" correspond à une autre grille tarifaire ! Acropolis Telecom ne m'avait jamais parlé de cela jusqu'à présent ! Avant de me fâcher tout rouge, j'ai donc demandé la grille tarifaire correspondant à cette "autre sortie" où la présentation du numéro fonctionne. J'ai reçu en retour une nouvelle grille tarifaire avec un nom de fichier évocateur : Grille FT.pdf. Tiens, les initiales "FT", ça me rappelle notre ancien opérateur ! J'ai alors comparé les deux grilles tarifaires, ce qui m'a permis de m'apercevoir que la "grille FT" était très significativement plus chère sur quasiement toutes les destinations, cf mon tableau de comparaison. Je me suis alors fâché tout rouge, en envoyant ce mail à mes interlocuteurs chez Acropolis Telecom et je n'ai jamais eu de réponse. Je suis malheureusement engagé pour une durée totale de 2 ans (ce qui m'a permis d'avoir des frais de mise en réduits pour la SDSL), ce qui réduit ma marge de manoeuvre.
  • le process d'administration des ventes chez Acropolis Telecom n'est pas rigoureux : à deux reprises, j'ai dû renvoyer à mon interlocuteur un scan de mon bon de commande pour pouvoir me justifier quand je lui disais qu'il mettait en place quelque chose qui n'était pas conforme à notre commande !
  • ces imprécisions au niveau de la communication en interne chez Acropolis Telecom ont engendré un autre problème : lors du portage des numéros, l'équipe technique a oublié de mettre en place le fax2mail sur la SDA dédiée au fax, alors même qu'Acropolis Telecom disposait bien de toutes les informations nécessaires. Nous nous en sommes aperçu en réalisant des tests juste après le portage des numéros ; Acropolis Telecom a corrigé son erreur environ 1h après qu'on la leur ait notifiée. Cela nous a privé de fax en réception pendant un peu plus d'une heure ; rien de grave, mais, sans ce loupé, l'opération de portage des numéros aurait été parfaite.
  • autre problème, toujours lié a priori au process de traitement des commandes : la grille tarifaire qui nous avait été appliquée n'était pas celle que nous avions négocié avec notre commercial ! Quand j'ai procédé à la vérification de notre facture détaillée, je me suis aperçu que le tarif qui nous était appliqué était supérieur au tarif que notre commercial nous avait proposé... la situation a été régularisée après notification du problème.
  • lors de la mise en place du trunk IAX, nous n'avons reçu que le minimum d'informations techniques, et nous avons dû poser de nombreuses questions par mail pour en savoir plus sur les détails du fonctionnement (mais nous avons toujours eu les réponses à nos questions). Un petit dossier technique de quelques pages abordant les différents aspects technique de l'architecture réseau, du trunk IAX et des mécanismes de redondance éventuels n'aurait pas été de trop !

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 de très nombreux 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 :

• intéressez-vous aux opérateurs IP (OVH, OpenIP, etc...) si vous êtes à la recherche du meilleur prix ; si vous appelez vers l'étranger, interrogez l'opérateur pour savoir si il gère correctement la présentation du numéro.
• restez en RNIS en utilisant un opérateur alternatif (offres dites "VGA") si vous cherchez la meilleure qualité et disponibilité possible pour vos communications.

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 :

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

	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 :

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

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

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

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, ce codec est supporté par OVH, mais seulement pour les appels entre 2 correspondants chez OVH. Cela montre que, 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 actuel : Distribution Asterisk FreePBX Distro.

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 Wazo	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
   FreePBX distro	Sangoma (ex-Digium), USA	FreePBX	CentOS	Anciennement AsteriskNow. C'est la distribution Asterisk de référence. Releases régulières, à chaque nouvelle version de FreePBX. Modulaire. Attention à faire le tri dans les nombreux modules. Certains modules sont opensource, d'autres sont propriétaires gratuits, d'autres encore sont propriétaires et payant. De façon surprenante, certains modules payants sont installés par défaut : ils ont leur entrée dans le menu, mais la fonctionnalité n'est pas disponible tant qu'on n'a pas payé. Il existe un module opensource de provisionning OSS End Point Manager, mais il n'est pas réellement maintenu. Seul le module propriétaire payant (150$) EndPoint Manager de Sangoma fourni une réelle solution de provisionning clé en main.
   Issabel	Issabel.com, Mexique	FreePBX	CentOS	Issabel est un fork d'Elastix, après son rachat par 3CX. Comme Elastix à l'époque, il fourni non seulement un IPBX basé sur Asterisk, mais aussi une solution de messagerie et de CRM. Le module de provisionning est opensource et fourni en standard. Issabel utilisé un fork de FreePBX basé sur FreePBX 2.11 (qui date de 2013) et qui est maintenu par l'équipe d'Issabel dans ce repo Github. Je trouve vraiment dommage qu'Issabel ait forké FreePBX ; les nouvelles fonctionnalités et les améliorations de FreePBX ne sont pas disponibles sur Issabel. Le projet est dépourvu de documentation ; ce n'est pas trop un problème pour la partie FreePBX, mais cela est gênant pour comprendre le paramétrage avancé du provisionning. Communauté essentiellement hispanophone.
   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.
   Wazo Platform	Wazo Communication Inc., la société de Sylvain Boily au Canada	Non activée par défaut. API/webservices uniquement	Debian	Wazo est un fork de Xivo lancé fin 2016 par l'équipe R&D de Xivo, qui était basée au Québec sous la direction de Sylvain Boily. Etant donné que toute l'équipe R&D de Xivo est maintenant derrière Wazo et qu'elle est toujours dirigée par Sylvain Boily, on peut dire d'une certaine façon que Wazo est simplement la suite de Xivo (étant donné que la marque Xivo appartient à la société Avencall, il était nécessaire de changer de nom). En Octobre 2019, le projet se ré-oriente et devient Wazo Platform (cf news LinuxFR). L'ancienne interface Web est abandonnée. La nouvelle distribution n'a plus d'interface Web par défaut ; elle est conçue pour être pilotée par API/webservices. Il est possible d'activer une nouvelle interface Web pour certaines fonctionnalités. Basculement vers un business model "opencore", avec une interface Web hébergée par l'éditeur dénommée Wazo Enterprise Unified Communications qui peut piloter plusieurs serveurs Wazo via API/Webservices.

   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 : Le cimetière des distributions Asterisk est bien rempli : Tribox (la version communautaire de Tribox, Trixbox CE, n'existe plus, cf la FAQ à ce sujet), Elastix (qui existe toujours mais utilise 3CX depuis fin 2016) et PBX in a Flash (qui existe toujours mais utilise aussi 3CX depuis Octobre 2016).

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 (Freebox, PBX in a Flash, Wazo)	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 Freepbx et Wazo, 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 Wazo/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 Wazo : Wazo 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 Wazo/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 Wazo 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é jusqu'à Octobre 2019 et la sortie de Wazo Platform, j'ai choisi Wazo/Xivo. Voilà mon retour d'expérience sur Wazo/Xivo :

• Qualités :
  • Le client Wazo, qu'on peut installer sur son PC sous Windows, Linux ou Mac OS X. Il permet notamment :
    • de configurer son compte téléphonique. Par exemple, vous travaillez momentanément dans un autre bureau et vous souhaitez faire un transfert d'appel vers le téléphone de cet autre bureau : plutôt que de retourner à votre bureau pour configurer le renvoi d'appel sur votre téléphone, vous utilisez le client Wazo pour activer le renvoi d'appel sans vous déplacer ! Super pratique !
    • vous pouvez lancer la numérotation d'un appel depuis le client Wazo. Par exemple, vous souhaitez appeler le numéro de téléphone qui s'affiche sur la page Web que vous êtes entrain de consulter. Plutôt que de composer manuellement ce numéro, vous faites un copier-coller du numéro dans votre client Wazo et d'un clic vous lancez la numérotation : votre téléphone sonne, vous décrochez, et Wazo compose alors automatiquement le numéro pour vous.
    • de superviser toutes les lignes téléphoniques que vous voulez, sans être limité par le nombre de touches de fonction de votre téléphone.
    • d'envoyer des faxs à partir d'un fichier PDF.
    • si votre application de gestion (ERP, CRM, ...) possède une interface Web, de mettre en place facilement une remontée de fiche : en effet, il est possible de configurer le client Wazo pour que, lors de la réception d'un appel, il ouvre un nouvel onglet dans le navigateur Web de l'utilisateur (ou, si le navigateur Web n'est pas lancé sur le PC, qu'il lance le navigateur Web) avec une URL qui intégre le numéro de téléphone de l'appelant dans l'URL. Je l'ai déjà déployé pour faire de la remontée de fiche avec Salesforce par exemple.
    • et bien d'autres fonctionnalités encore... cf cette page (notamment les pages spécifiques à chaque Xlet).
  • Fonctionnalités avancées et très pratiques pour le provisionning des téléphones IP :
    • Le fait de confier à Wazo le provisionning de ses téléphones IP évite beaucoup de duplication d'information : par exemple, pas besoin de dupliquer le login SIP, le mot de passe SIP et le numéro de téléphone entre la configuration d'Asterisk et le fichier de configuration du téléphone.
    • Wazo permet également de rattacher très facilement un nouveau téléphone à un compte SIP : pas besoin de noter l'adresse MAC du téléphone et d'aller bidouiller les fichiers de configuration du serveur TFTP pour mettre le bon fichier de configuration pour l'adresse MAC en question. Par défaut, un téléphone sorti du carton est configuré en mode "auto-provisionning". Il suffit alors de composer le code d'approvisionnement que Wazo a attribué au compte SIP sur le téléphone, et le téléphone redémarre et obtient du serveur de provisionning de Wazo la bonne configuration. Très pratique !
    • les fichiers de configuration générés par Wazo sont adaptés pour un usage courant ; pas besoin de se plonger dans les centaines de pages de la doc administrateur du téléphone pour arriver à avoir une première configuration qui marche.
    • Wazo intègre la gestion avancée des touches de fonction. Par exemple, on peut facilement configurer une touche de fonction pour activer/désactiver le DND (Do Not Disturb = bascule directement sur le répondeur) et la touche de fonction correspondante reste allumée tant que le DND est activé, ce qui aide l'utilisateur à se souvenir qu'il doit désactiver la fonction DND quand il revient à son poste. J'ai aussi profité de cette fonctionnalité pour les renvois d'appel : j'ai configuré une touche de fonction pour activer/désactiver un renvoi d'appel, et la touche de fonction reste allumée tant que le renvoi d'appel est activé.
  • L'intégration des annuaires téléphoniques des différents modèles de téléphone. Les téléphones IP ont généralement dans leur menu une fonction d'annuaire téléphonique, qui permet d'accéder à un ou plusieurs annuaires téléphoniques disponibles côté serveur. Le protocole entre le téléphone IP et l'annuaire côté serveur est spécifique à chaque constructeur. Wazo a implémenté le protocole des principaux constructeurs de téléphone IP, et permet ainsi de mettre en place un annuaire téléphonique qui sera alors accessible depuis tous les téléphones IP même si vous avez un parc hétérogène. Par défaut, Wazo propose un annuaire téléphonique commun à tous les utilisateurs et un annuaire téléphonique spécifique à chaque poste. L'accès à l'annuaire est également possible depuis le client Wazo. Encore une fonctionnalité très pratique !
• Défauts :
  • L'interface Web d'administration de Wazo reste très orientée vers l'ingénieur système ayant des compétences Asterisk ; son utilisation n'est pas adaptée pour les utilisateurs sans compétences techniques.
  • L'interface Web d'administration est vieillotte et fait penser aux sites Web d'il y a 15 ans. Elle mériterait une bonne cure de jouvence ! Son ergonomie laisse à désirer.
  • Beaucoup de fonctionnalités demandées classiquement dans un déploiement d'entreprise ne sont pas disponibles en standard dans l'interface Web d'administration (exemple : en cas de non réponse, je veux un comportement A dans le cas d'un appel interne et un comportement B dans le cas d'un appel externe) ; il faut passer par les sous-routines de pré-traitement, c'est à dire coder des morceaux de Dialplan Asterisk à la main.
  • Il n'est pas possible de ré-injecter facilement sur un serveur Wazo une configuration sauvegardée préalablement (une procédure est disponible, mais elle est fastidieuse à mettre en oeuvre)

Avec la sortie de Wazo Platform en Octobre 2019 et le nouveau business model "opencore", j'ai arrêté d'utiliser Wazo. Je conseille maintenant FreePBX Distro, dont le seul point noir concerne le provisionning, plus précisement l'absence d'un module opensource de provisionning correctement maintenu.

Serveur

Choix actuel : mini-PC fanless Gigabyte Brix avec SSD.

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.

Après avoir utilisé des LinuTop puis des shuttle XS35v2, j'ai ensuite adopté les NUC d'Intel dès leur apparition sur le marché. Mais une très mauvaise expérience avec les NUC Atom DE3815TYKHE (impossibilité de démarrer le PC sans écran branché sur certaines modèles, cf mon post sur le forum d'Intel), j'ai cherché des alternatives chez d'autres constructeurs. Entre temps, d'autres constructeurs s'étaient intéressés à ce segment à la suite d'Intel, et notamment Gigabyte avec la gamme Brix, cf cette annonce sur hardware.fr. Le modèle entrée de gamme de Brix, le GB-BXBT-2807, est fanless et coûte 96 € HT (cf LDLC-pro), auquel il faut ajouter la RAM et le SSD 2,5". Il est vraiment parfait pour faire un serveur Asterisk ; la carte réseau Realtek est supportée via le driver r8169 et il est équipé d'un processeur Celeron Dual-core (détails) avec un PDT de moins de 5W (il chauffe effectivement très peu). Je mets en partage la sortie de lspci, lspci -nv, dmesg et lsmod. Par rapport au NUC Celeron d'Intel, il a l'avantage d'être fanless et d'avoir non seulement un port HDMI mais aussi un port VGA. Il a bien une option dans le BIOS qui permet de redémarrer automatiquement après une coupure de courant.

Fax

Choix actuel :

• dans le cas d'un opérateur IP :
  • pour la réception de fax : l'opérateur IP reçoit les fax sur un des SDAs, les convertit en PDF et les envoie sur une adresse mail dédiée.
  • pour l'émission de fax : utilisation de la solution proposée par l'opérateur IP pour envoyer un fax (ou utilisation d'un fax "traditionnel" directement connecté à une ligne analogique).
• dans le cas de lignes RNIS :
  • si le numéro du fax est associé aux lignes RNIS : utilisation d'une Patton SN4661 qui intègre des ports FXS permettant de brancher le fax.
  • si le numéro de fax est associé à une ligne analogique : on ne change rien et on garde la ligne analogique.

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 :

• dans le cas où on utilise un opérateur IP, on va lui demander de mettre en place une solution de fax2mail pour les faxs entrant sur la SDA dédiée au fax. On lui demandera également quelles sont les solutions qu'il propose pour l'envoi de fax sous forme de fichier. Tous les opérateurs IP avec lesquels j'ai été amené à travailler proposent de telles solutions, souvent sous forme d'options (attention à bien intégrer ce coût dans les comparaisons de prix entre opérateurs).
• dans le cas où on utilise des lignes RNIS, on peut utiliser les fonctions de fax2mail sur le serveur Asterisk (cette fonction est native dans Wazo ; sinon, je recommande l'utilisation d'Hylafax). Dans ce cas, le fax arrive sur la Patton, est envoyé en SIP vers le serveur Asterisk et est converti en PDF sur le serveur Asterisk. Certes, le fax transite sur IP entre la passerelle Patton et le serveur Asterisk, mais si le réseau local est parfait sans aucune perte de paquet, mon expérience m'a montré que cela ne devrait pas poser de problème en réception de fax.

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

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

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

• dans le cas où on utilise un opérateur IP, on peut ouvrir ou ré-utiliser une ligne téléphonique analogique qui sera dédiée au fax, et porter le numéro de fax vers cette ligne (il est possible de porter un numéro qui appartient à un bloc).
• dans le cas où on utilise des lignes RNIS, je recommande d'utiliser une passerelle Patton SN4661 avec des ports FXS, et de la configurer pour que les appels entrants sur la SDA dédiée au fax soient renvoyés vers le port FXS du fax, et que les faxs sortants partent directement sur les lignes RNIS. Ainsi, les faxs ne sont pas transmis sur IP et ne passent pas par Asterisk.

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 :

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

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

• une carte TDM400P avec un port FXS peut être remplacée par un boitier de type PAP2T comme par exemple le Cisco SPA112,
• une carte RNIS B410P peut être remplacée par une passerelle SIP/RNIS, cf ci-dessous.

Avec ces boitiers dédiés :

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

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

• Gamme Patton SmartNode :
  • pour 1 ligne RNIS T0 : modèle SN4120/1BIS2V/EUI à 210 euros HT chez ipandgo,
  • pour 2 lignes RNIS T0 : modèle SN4120/2BIS2V/EUI à 325 euros HT chez ipandgo. Il y a aussi le modèle SN4634 : il est plus cher (440 euros HT) et les fonctions supplémentaires qu'il propose - le port supplémentaire de passthrough et le support non seulement du mode TE (Terminal Equipment i.e. le port est connecté à des lignes RNIS) mais aussi du mode NT (Network Termination, i.e. le port est connecté aux ports RNIS d'un PABX ou un téléphone RNIS) - ne sont pas vraiment utiles.
  • pour 4 lignes RNIS T0 : modèle SN4638 à 540 euros HT chez ipandgo.
  Le prix des passerelles SIP/RNIS de la gamme Patton SmartNode est très raisonnable ; de plus, ces boitiers sont très fiables et leurs firmwares ont une bonne réputation. Tout cela explique leur succès dans la communauté Asterisk. Leur seul défaut est qu'ils sont difficiles à configurer ; mon avis sur ce point est confirmé par ce fil de discussion dans le forum Asterisk-France.
• AudioCodes :
  • pour 1 ligne RNIS T0 : modèle Mediant 800 1-BRI à 470 € HT chez ipandgo,
  • pour 2 lignes RNIS T0 : modèle Mediant 800 2-BRI à 560 € HT chez ipandgo,
  • pour 4 lignes RNIS T0 : modèle Mediant 800 4-BRI à 700 € HT chez ipandgo.
  Selon ce que j'ai pu lire et entendre, la qualité audio est très bonne et la configuration est simple. Mais les prix sont un peu plus chers que chez Patton et surtout il manque un modèle pour 2 lignes RNIS, ce qui explique que les passerelles Audiocodes soient peu utilisées dans la communauté Asterisk.
• Vega 50 (530£ pour le boitier avec 2 ports RNIS T0 et 1060£ pour le modèle avec 4 ports selon ce site). Je n'ai jamais lu ni entendu de retour d'expérience sur cette marque.
• One Access, modèle One Access One100D/M qui a une option 4 ports RNIS (BRI), mais on ne le trouve pas sur des sites de vente en ligne, et il est donc très peu utilisé dans la communauté Asterisk.

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

• Avantages :
  • le téléphone IP n'a qu'un seul câble (le câble réseau) au lieu de deux (le câble réseau + le câble d'alimentation)... comme au bon vieux temps de la téléphonie traditionnelle ! Cela fait plus propre sur les bureaux et évite la prolifération des multi-prises !
  • si le switch PoE et le serveur Asterisk (ainsi que la passerelle SIP/RNIS ou le modem xDSL) sont branchés sur un onduleur, cela permet d'avoir une installation téléphonique qui continue de fonctionner en cas de coupure d'électricité. J'ai déployé une solution Asterisk dans un club de sport, et cet argument a été le déclancheur du choix du PoE car, si un client fait un malaise dans une salle de sport pendant une coupure d'électricité, le téléphone doit continuer de fonctionner pour appeler les secours et coordonner la prise en charge.
  • certains équipements PoE sont vendus avec un bloc d'alimentation en option, et cette option est parfois un peu chère, ce qui rentabilise le surcoût du switch PoE. C'est par exemple le cas des pieuvres de conférence Polycom (modèle IP 5000 et IP 6000 par exemple), qui supportent le PoE et dont le bloc d'alimentation est proposé en option pour la modique somme de 70 euros HT (vu le prix, il revient moins cher d'acheter un injecteur PoE) !
• Inconvénients :
  • le switch PoE devient un single point of failure. En effet, si tous les téléphones sont alimentés par un switch PoE, en cas de panne de celui-ci, tous les téléphones s'éteignent. Il faut alors pouvoir rapidement remplacer le switch PoE par un autre (ce qui implique généralement d'avoir un switch PoE de spare) ou avoir en stock quelque part les blocs d'alimentation des téléphones...
  • les switchs PoE sont plus chers que les switchs non PoE. Par exemple, le switch non PoE Dlink DES-1210-28 (24 ports FastEthernet, 4 ports Giga, support des VLANs) coûte 116 € HT (cf LDLC) alors que son équivalent PoE, le modèle DES-1210-28P coûte 224 € HT (cf LDLC).

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 :

• le Dlink DES-1210-xxP où xx est le nombre de ports total en comptant les ports Giga non PoE (existe en 8 ou 24 ports PoE). A noter : il supporte l'arrêt de l'alimentation électrique des ports PoE à certaines heures, ce qui permet par exemple d'éteindre les téléphones la nuit pour économiser l'électricité.
• le Cisco Small Business SF300-xxP où xx est le nombre de ports PoE (existe en 24 ou 48 ports PoE).

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 :

• sans aucune perte de paquet. En effet, les flux VoIP sont envoyés en UDP sans algorithme particulier de correction d'erreur ni de renvoi de paquet perdu ; toute perte de paquet, si il s'agit d'un paquet transportant le son d'une conversation VoIP, va donc très certainement entraîner une dégradation ponctuelle de la qualité audio. Cette affirmation est valable quand on utilise le codec G711, mais certains codecs comme le G729 sont conçus pour tolérer un certain niveau de perte de paquet sans dégradation de la qualité audio (j'imagine qu'ils utilisent des techniques de type FEC i.e. Forward Error Correction).
• avec une latence faible et relativement constante dans le temps.

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 :

• VLAN 2 pour la data i.e. la bureautique avec accès Internet,
• VLAN 3 pour la téléphonie, qui contient le serveur Asterisk, les téléphones IP et tous les autres équipements de ToIP, y compris l'accès au lien xDSL dédié au trunk SIP éventuel.

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

• le système téléphonique ne sera pas impacté par un éventuel problème de flooding dans le VLAN data. Par exemple, si un PC appartenant au VLAN data se met à envoyer une grosse quantité de trafic broadcast ou multicast, le VLAN dédié à la ToIP ne sera pas impacté (en simplifiant un peu !). Par exemple, mon premier déploiement Asterisk a été réalisé dans une société spécialisée en IPTV, qui est une technologie qui utilise beaucoup le multicast. Lors du déploiement initial dans cette société, la ToIP n'était pas isolée dans un VLAN dédié : les flux ToIP étaient simplement mis en priorité sur le réseau via les fonctions de QoS des switchs et l'utilisation du champ DSCP. Or, lors de certains tests techniques, nous rencontrions parfois des problèmes de multicast, et une des conséquences possibles de ces problèmes est que les flux multicast se retrouvent broadcastés, ce qui peut sérieusement perturber le réseau si les flux multicast sont d'un gros débit (par exemple, si la somme des débits des flux multicast qui se retrouvent broadcastés est supérieure à 100 Mb, on arrive à une paralysie de tous les équipements branchés sur des ports Fast Ethernet et/ou ayant des interfaces Fast Ethernet). On avait d'ailleurs remarqué que les téléphones Aastra ont une qualité audio dégradée quand ils recoivent plusieurs flux multicast de quelques Mbit/s auxquels ils ne sont pas abonnés. Le fait de créer un VLAN dédié à la VoIP a permis de ne plus avoir de problème de téléphonie quand il y avait des problèmes de multicast dans le VLAN principal.
• il est parfois recommandé que le serveur Asterisk assure la fonction de serveur DHCP, pour un bon fonctionnement du système de provisionning des téléphones. C'est par exemple le cas de la distribution Asterisk Wazo quand on utilise sa fonctionnalité super-pratique d'auto-provisionning des téléphones IP. Mais il existe probablement déjà un serveur DHCP en fonctionnement dans l'entreprise avec ses contraintes propres. Si on crée un VLAN dédié à la ToIP, alors Asterisk pourra être le serveur DHCP du VLAN ToIP alors que le serveur DHCP de l'entreprise sera le serveur DHCP du VLAN data.

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

• si vous comptez utiliser le port "PC" des téléphones IP (que j'appelle habituellement le port de rebond), faire en sorte que ce port soit dans le VLAN data,
• si vous comptez mettre en place certaines interactions entre votre serveur Asterisk et le reste de votre système informatique (via l'installation du client Wazo sur les PCs, ou via le connecteur Odoo-Asterisk si vous utilisez Odoo par exemple), il faudra que le serveur Asterisk soit joignable depuis le VLAN data,
• si votre accès au réseau téléphonique externe se fait via un trunk SIP sur un lien xDSL dédié, il serait bien d'avoir la possibilité de faire passer le trunk SIP par le lien xDSL normal de l'entreprise en cas de panne du lien xDSL dédié à la ToIP.

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 :

• vous n'y comprennez rien aux VLANs,
• votre matériel réseau actuel ne supporte pas les VLANs et vous ne souhaitez pas en changer pour le moment.

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

• au LAN (si la VoIP est dans un VLAN dédié, le firewall aura en plus une interface virtuelle dans ce VLAN),
• au modem xDSL de la connexion "Internet" (connexion WAN1),
• au modem xDSL de la connexion dédiée à la VoIP (connexion WAN2).

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 :

• le trafic Internet est routé par défaut sur l'interface WAN1 ; en cas de panne de WAN1, il est alors routé temporairement par WAN2 avec une priorité inférieure à celle du trafic VoIP ;
• le trafic VoIP est routé par défaut sur WAN2 ; en cas de panne de WAN2, il est alors routé temporairement par WAN1 avec une priorité supérieure au trafic Internet.

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 :

• un téléchargement HTTP (donc en TCP) depuis un serveur rapide qui dispose d'une bonne bande-passante Internet,
• une conversation téléphonique en SIP/RTP (donc en UDP).

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

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. La solution la moins chère pour acheter un APU est de l'acheter directement chez le constructeur PC Engines (basé en Suisse).

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 :

• le standard correspond à un téléphone particulier, et les autres postes peuvent faire une interception sur les appels du standard,
• lors d'un appel au standard, le poste appelé "standard" sonne pendant 15 secondes, puis, si l'appel n'a pas été pris, un groupe de postes incluant le poste standard sonne pendant les 15 secondes suivantes, puis, si l'appel n'est toujours pas pris, un autre groupe de postes plus large se met à sonner.
• les appels au standard sont pris en charge par une queue d'appel doté d'une jolie musique d'attente avec une annonce de la position dans la file d'attente. La prise en charge des appels en attente dans la queue par les postes est très configurable.

En plus de cela, on peut avoir :

• un fixe horaire : en dehors des heures/jours d'ouverture de l'entreprise, un message rappelle les horaires/jours d'ouverture et redirige l'appel vers un répondeur,
• une ouverture/fermeture manuelle du standard via l'action d'une touche de fonction d'un téléphone : quand le standard est "fermé", l'appel est redirigé vers un répondeur,
• un renvoi conditionnel vers un numéro extérieur qui peut être changé facilement par les utilisateurs.

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 :

• avoir la triple expertise Linux + réseau + téléphonie ou prendre le temps de l'acquérir,
• faire les bons choix techniques (ce document devrait vous y aider !) et choisir le bon opérateur (et la bonne offre chez cet opérateur !),
• apprendre non seulement l'installation et le paramétrage d'Asterisk, mais aussi des nombreux composants logiciels qui gravitent autour,
• apprendre le paramétrage des autres équipements : téléphone IP, borne DECT, passerelle SIP/RNIS, etc...

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 :

• Les intégrateurs Wazo, dont vous trouverez une liste sur le site de Wazo,
• Prestaclic, un intégrateur Asterisk/Wazo basé en région parisienne avec qui je travaille régulièrement depuis de nombreuses années,
• Ceyla, un intégrateur Asterisk/Wazo basé à Nantes,
• Eyepea, un intégrateur Asterisk/Wazo basé à Bruxelles,

Et, comme expliqué au début de cette page, je propose mes services de déploiement d'IPBX Asterisk.

Interphone IP avec ouverture de porte

Choix actuel : interphone Fanvil i10V.

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. A l'époque, j'avais retenu le modèle Pantel IP d'ITS Telecom. ITS Telecom est un constructeur israélien. C'est un interphone SIP avec alimentation en PoE possible (sauf si commande d'une gâche électrique, car la puissance d'alimentation de la gâche est trop importante pour du PoE ; mais dans le cas de la commande par contact sec, l'utilisation du PoE est possible, ce qui est confirmé par notre propre expérience).

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.

L'interphone était configuré pour composer un numéro spécial du dialplan qui exécutait une fonction qui faisait sonner plusieurs téléphones en fonction de l'heure de la journée. La personne qui décrochait l'appel de l'interphone était alors immédiatement en conversation avec son interlocuteur à l'interphone et n'avait 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.

Mais je déconseille l'interphone PanTel IP, car nous avons été confronté à certains défauts :

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

J'ai déployé en Avril 2016 un interphone 2N Helios IP Vario chez un de mes clients. Tout a parfaitement marché à la fois au niveau matériel et au niveau logiciel. L'interface Web d'administration est bien faite et propose toutes les fonctionnalités attendues. Le firmware est stable et fiable. Plus récemment, 2N a sorti un interphone IP Uni, qui est un modèle d'entrée de gamme aux alentours de 300 euros (il faut ajouter 62 euros pour le boitier alu si montage en saillie !). Cet interphone est deux fois moins cher que le modèle IP Vario, ce qui est très appréciable.

Mais, en 2019, la nouveauté est l'arrivée du constructeur chinois Fanvil (distribué en France par Distri-Fanvil), avec sa gamme d'interphones SIP PoE low-cost. Pour mon dernier déploiement, j'ai installé un interphone Fanvil i10V, qui est trois fois moins cher que le 2N IP Uni... et équipé d'une caméra ! Un interphone SIP PoE simple et abordable, qui fonctionne bien. Il est certifié IP54 et prévu pour une plage de température de -20 à 50°C. Certains sites le classent dans la catégorie indoor, d'autres dans la catégorie outdoor. Certes, les modèles pur-outdoor sont généralement en alu (alors que le i10V est en plastique) et certifiés IP65. J'ai déployé mon i10V en extérieur, accessible depuis la rue, en Avril 2020. Pour l'instant, j'en suis très satisfait... on verra si il tient bien dans la durée !

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 :

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

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

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

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

switch# show qos type-of-service

  Type of Service [Disabled] : Differentiated Services


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

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

Pour les 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 :

• le directed call pickup. L'utilisateur qui fait un directed call pickup va intercepter un appel précis en composant une combinaison de touches correspondant au poste qui sonne ou en appuyant sur une touche de fonction de son téléphone configurée pour monitorer le poste qui sonne.

  Par exemple : le poste 12 sonne. L'utilisateur du poste 42 va pouvoir prendre la communication en composant sur son téléphone **12. En outre, si l'utilisateur du poste 42 a un téléphone avec des touches de fonction et qu'une de ces touches de fonction a été configurée pour monitorer le poste 12, alors la touche en question va se mettre à clignoter quand le poste 12 sonne, et l'utilisateur va pouvoir prendre la communication en appuyant sur la touche qui clignote sur son poste.

• le group call pickup. Dans ce mode, les téléphones appartiennent à un ou plusieurs groupes (vous pouvez ne faire qu'un seul groupe pour tous les téléphones si vous voulez) et ont des droits pour faire des group call pickup vers certains groupes de téléphones. L'utilisateur qui fait un group call pickup va taper une combinaison de touches générique (ou appuyer sur une touche programmable de son téléphone dédiée à cette fonction) pour intercepter un appel destiné à un des téléphones appartenant aux groupes sur lesquels il a les droits pour faire des group call pickup. Attention : si, au moment où l'utilisateur fait un group call pickup, il y a plusieurs appels en attente d'être décrochés vers des postes appartenant aux groupes sur lesquels l'utilisateur a les droits, on ne peut pas prédire lequel des appels il interceptera.

  Par exemple : une petite entreprise a 5 téléphones et souhaite pouvoir faire du group call pickup depuis n'importe quel téléphone vers n'importe quel téléphone. L'administrateur va donc mettre tous les téléphones dans le groupe n°1 et il décide que la combinaison de touches pour le group call pickup est *8. Un des 5 postes sonne ; l'utilisateur qui souhaite intercepter l'appel va composer sur son poste *8. En outre, si l'utilisateur a un téléphone avec des touches de fonction et qu'une de ces touches de fonction a été programmée pour composer *8, il lui suffira d'appuyer sur cette touche quand il veut faire un group call pickup (mais la touche ne clignotera pas quand un poste sonne).

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.

• Dans le cas d'un appel interne, c'est facile, car l'extension par laquelle passe l'appel est normalement égale au numéro du poste qui sonne. En effet, pour faire sonner le poste 12, je compose 12 et je vais donc matcher dans le dialplan sur exten => 12. Pour faire un directed pickup sur un appel interne, je vais donc utiliser le code suivant dans le dialplan :

  exten => _**.,1,Pickup(${EXTEN:2})
  

• Dans le cas d'un appel venant de l'extérieur par une ligne directe par exemple, c'est plus difficile, car l'extension par laquelle passe l'appel est le numéro de la ligne directe (ou les 4 derniers chiffres de la ligne directe en RNIS), et pas le numéro du poste qui sonne. Pour pouvoir faire un directed pickup sur un appel venant de l'extérieur avec la même combinaison de touches, il va donc falloir ruser !

  D'abord, je suppose que vous avez défini une macro spéciale pour les appels entrants via les lignes directes, que l'on appellera reception-appel-ext et qui prend en argument le numéro du poste interne correspondant à la ligne directe. Par exemple, pour un appel entrant par la ligne 0141981142 qui correspond au poste 12, on aura dans le contexte de reception des appels venant de l'extérieur (que l'on appellera reception) :

  [reception]
  exten => _0141981142,1,Macro(reception-appel-ext,12)
  

  Dans la définition de la macro reception-appel-ext qui s'exécute lors de la réception d'un appel venant de l'extérieur, on va ajouter le code suivant au début de la macro :

  [macro-reception-appel-ext]
  exten => s,1,Set(GLOBAL(PICKUPEXT_${ARG1})=${MACRO_EXTEN})
  [...]
  

  Ce code va mettre dans la variable globale PICKUPEXT_12 le numéro de la ligne directe 0141981142 du poste 12.

  On va alors pouvoir faire un directed pickup en passant la variable globale en argument de la fonction Pickup :

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

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 voir les entités SIP :

  asterisk*CLI> sip show peers
  

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

  asterisk*CLI> sip show inuse
  

• Quand on utilise un trunk SIP, pour vérifier qu'Asterisk est bien enregistré auprès du serveur SIP :

  asterisk*CLI> sip show registry
  

• Pour contrôler qu'il n'y a pas de perte de paquets RTP sur les communications en cours :

  asterisk*CLI> sip show channelstats
  

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

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

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

• Pour afficher l'aide au sujet d'une fonction du dialplan, par exemple pour la fonction Goto :

  asterisk*CLI> core show application Goto
  

pour la passerelle Patton

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

• pour voir la configuration en cours :

  # show running-config
  

• pour voir la configuration de démarrage :

  # show startup-config
  

• pour activer les logs de signalisation RNIS :

  # debug ccisdn error
  # debug ccisdn signaling
  

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

  # debug isdn error
  # debug isdn event 0 0 all
  

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

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.

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 :

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 :

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 :

XHTML 1.1 et CSS valides. Lien vers sites partenaires : Appartement Miluni