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

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

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

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

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

A propos de l'auteur

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

Par ailleurs, j'ai publié en Septembre 2010 un module de click2dial Asterisk pour OpenERP, un ERP en logiciel libre. Ce module est sous licence AGPL, la même licence qu'OpenERP. Il est hébergé sur Launchpad.net, avec les autres modules OpenERP de la section extra-addons. Une documentation complète est disponible en anglais. Ce module a 2 fonctionnalités :

• il ajoute un bouton Dial en face des champs contenant un numéro de téléphone dans OpenERP ; quand l'utilisateur clique sur ce bouton, OpenERP 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 entrant, le dialplan d'Asterisk exécute un script AGI, qui va interroger OpenERP pour savoir si le numéro qui est présenté est renseigné dans la base de contact d'OpenERP ; 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.

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

Historique

Introduction

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

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

Depuis ce premier déploiement, j'ai réalisé deux autres déploiements Asterisk :

• à l'automne 2009, j'ai réalisé mon deuxième déploiement Asterisk dans une petite entreprise : 5 téléphones IP, 1 ligne Numéris T0. Pour ce déploiement, il n'y avait aucune installation téléphonique pré-existante.
• à l'hiver 2010, j'ai réalisé mon troisième déploiement Asterisk dans une petite entreprise : 8 téléphones IP, 2 lignes Numéris T0. Le système Asterisk a remplacé un PABX Matra qui était en location chez France Telecom.

Les choix de matériel et d'architecture que j'ai fait pour ces deux autres déploiements sont inspirés des réussites et des erreurs que j'ai fait lors de mon premier déploiement. Je parlerai donc également à certains moments de ces deux autres déploiements dans ce document.

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

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

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

Installation précédente

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

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

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

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

Installation VoIP avec Asterisk

Schéma d'architecture

Architecture actuelle de mon premier déploiement

Voilà l'architecture de mon premier déploiement ; le schéma correspond à la solution en place depuis l'arrêt de l'utilisation de nos lignes RNIS et le passage vers l'opérateur IP Acropolis Telecom en Juillet 2010 (une architecture que je ne recommande plus, sauf dans certains cas) :

Architecture que je recommande

Voilà l'architecture que je recommande, et qui est à peu de choses près l'architecture que j'ai retenu pour mon 3ème déploiement :

Les principales différences par rapport à l'architecture actuellement utilisée dans mon premier déploiement sont les suivantes :

• on garde les lignes RNIS ; on ne bascule pas vers un opérateur IP,
• choix de la distribution Asterisk Xivo,
• utilisation de téléphones Aastra uniquement (pas de téléphones Technicolor).

Version des composants logiciels actuellement utilisés

Pour mon premier déploiement

Ce que je recommande

Matériel utilisé et budget

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

Mes bookmarks

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

• Asterisk.org, le site communautaire du projet Asterisk.
• Asterisk France : site de l'association Asterisk-France, qui héberge notamment le principal forum communautaire français sur Asterisk et tout ce qui tourne autour (les téléphones IP notamment). Le forum est assez actif. J'en profite pour remercier tous les utilisateurs d'Asterisk France qui ont répondu à mes questions dans le forum ! Note : le forum était initialement hébergé par le site Asterisk-France.NET ; quand l'association Asterisk-France s'est crée début 2010, elle a acquis le nom de domaine Asterisk-France.ORG et la communauté s'est rassemblée sur le nouveau forum de l'association. Par contre, le site Asterisk-France.NET est toujours disponible et permet de consulter les archives de l'ancien forum.
• Panoramisk : site d'information en français sur Asterisk et la VoIP.
• Technicolor (ex-Thomson) ST2030 - page de téléchargement : cette page contient en particulier les nouvelles versions des firmwares des téléphones ST2030.
• Aastra: Support Downloads 6731i : cette page contient notamment les nouvelles versions des firmwares des téléphones Aastra 6731i.
• Voip-info.org : très gros Wiki communautaire qui parle des sujets relatifs à Asterisk et à la VoIP en général et qui donne aussi des infos intéressantes sur les téléphones IP.
• The Asterisk Book : la version actualisée du livre "Practical Asterisk 1.4", qui aborde tous les aspects pratiques de l'installation et du paramétrage d'Asterisk.
• Planet Asterisk : site qui traite de l'actualité d'Asterisk et de la VoIP.
• The Asterisk Guru : site proposant un certain nombre de tutoriels sur Asterisk et ce qui tourne autour.
• Blog Elastix : le blog officiel de la distribution Linux spécialisée Asterisk "Elastix".
• Elastix Connection : forums et tutoriels sur Elastix.
• Déployer la téléphonique FULL IP dans de bonnes conditions : document de 17 pages passant en revue toutes les problématiques techniques d'une solution full IP pour les communications internes et externes.
• Les annonces de Xivo, une distribution Asterisk faite par la société française Avencall.

Retour d'expérience global

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

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

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

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

Choix et motivation des choix

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

• 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 initial : téléphone Technicolor/Thomson ST2030 (que je déconseille fortement aujourd'hui).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Version de firmware	Descriptif des bugs du firmware
  1.62	bug sur les touches de monitoring des modules d'extension
  1.63	bug sur les touches de monitoring toujours présent
  1.65	petit bug au moment de la réception d'un appel quand on est déjà en communication : le haut-parleur se met à émettre la conversation en cours pendant une demi-seconde sans raison. C'est le firmware qu'on utilise actuellement car c'est celui qui est à mon sens le moins buggé.
  1.66	bug sur les touches de monitoring des modules d'extension réintroduit
  2.67	bug sur le 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.

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

• la mise en place de l'autoconfiguration par fichiers de configuration est laborieuse : il faut bien lire la doc pour ne pas "se faire avoir" par certaines subtilités. On a passé beaucoup de temps à faire du fine tuning des fichiers de configuration.
• un problème récurrent pour raccrocher : régulièrement, quand on raccroche le combiné à la fin d'un appel, le combiné se met dans une position telle que le téléphone ne détecte pas que le combiné est raccroché ; il se met alors à émettre un bruit spécifique qui permet de s'en rendre compte. La solution est alors de soulever légèrement le combiné et de le raccrocher en douceur. Ce problème est une sorte de bug hardware !
• un problème de fiabilité au niveau du combiné : sur la quarantaine de téléphones ST2030 que nous avons déployé, nous avons eu, au fil des années, 6 combinés hors-service. Malheureusement, je n'ai pas trouvé comment acheter un combiné seul, ce qui veut dire qu'à chaque fois qu'un combiné tombe en panne, on perd un téléphone !
• le port "PC" ne supporte pas bien les déconnexions/reconnexions ; régulièrement, quand on branche un ordinateur sur le port PC, la connexion réseau ne s'établit pas, et il faut rebooter le téléphone pour que le port PC fonctionne !
• et un point anecdotique : la qualité de la langue anglaise utilisée dans la documentation ne fait pas honneur à Technicolor !

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

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

• très bonne qualité audio,
• nous n'avons trouvé aucun bug firmware pour le moment,
• la configuration centralisée par TFTP est très simple,
• il marche parfaitement bien avec Asterisk et Aastra est un constructeur impliqué dans la communauté Asterisk : Asterisk est officiellement supporté par Aastra (la doc des téléphones Aastra donne des exemples de configuration d'Asterisk !), des ingénieurs Aastra répondent parfois dans les forums Asterisk anglophones, Aastra est membre de l'association Asterisk-France, etc...
• son prix est compétitif par rapport au téléphone ST2030 (en gros le prix est le même que celui du ST2030 mais l'Aastra 6731i est livré sans bloc d'alimentation) ; son seul "manque" par rapport au ST2030 est l'absence d'une prise casque dédiée (seuls les téléphones Aastra de la gamme 5xi ont une prise casque).

Si vous avez besoin d'une "extension standard" pour avoir de nombreuses touches de monitoring, orientez-vous vers les modèles 53i, 55i ou 57i d'Aastra avec le module d'extension 536M (M670i).

Téléphones IP sans-fil

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, comme expliqué dans cet article ; 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. D'après mes recherches, il faut distinguer deux catégories :

• les constructeurs capables de proposer 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.
• les constructeurs qui ne proposent qu'une infrastructure DECT limitée, sans roaming ni handover entre plusieurs bornes. Sur ce créneau, Siemens règne en maître avec ses gammes Gigaset et Gigaset pro et propose des prix très compétitifs.

Je vous propose un petit zoom sur les solutions DECT de Polycom et de Siemens.

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.

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 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) 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 initial : conserver les lignes RNIS utilisées dans l'installation précédente pour les appels entrants et sortants.

Choix actuel (depuis Juillet 2010) : utilisation d'un opérateur IP pour les appels entrants et sortants, sur une ligne SDSL dédiée. Au vu de notre expérience, c'est un choix que je déconseille, sauf dans certains cas particuliers.

Choix recommandé : 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.

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

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

En ce qui concerne la solution n°2, mon étude des offres disponibles sur le marché français ne m'a 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 centaine de NRA dans quelques grandes villes (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 SIP ou IAX ; comme l'interconnexion via ce protocole doit permettre d'avoir plusieurs communications simultanées dans une même connexion, on parle de trunk SIP ou de trunk IAX. Pour le codec, on a généralement le choix entre G711A et G729 (et parfois d'autres). Aujourd'hui, Free propose dans son offre standard Freebox un compte SIP qui est limité à une seule communication simultanée. Du côté de SFR, il était annoncé une offre en trunking en Novembre 2008, mais elle a apparemment été retirée (info de Mars 2009) et seule l'offre en mode Centrex subsiste.

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

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

Je conseille de ne prendre en considération que les opérateurs de la première catégorie, sauf si vous recherchez l'offre la moins chère possible ou si vous disposez d'une connexion à Internet par fibre optique. Dans le cas où vous seriez amené à considérer un opérateur de la 2ème catégorie, vérifiez la latence entre une machine de votre LAN (par exemple l'IPBX) et le serveur téléphonique de l'opérateur sur une longue période (plusieurs jours au moins) ; cette latence ne doit jamais dépasser 100 millisecondes pour pouvoir assurer une qualité de communication correcte. Pour mesurer la latence, vous pouvez tout simplement faire un ping et regarder le temps affiché ; pour mesurer la latence sur une longue période, utilisez un outil dédié qui va lancer un ping chaque minute, va en extraire le temps de latence et va construire un graph à partir de ces informations. Ce test permettra par la même occasion de vérifier que l'uptime du lien entre votre LAN et l'opérateur est bon. 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 de la solution RNIS de France Télécom avec la solution en trunking sur lien SDSL d'Acropolis Telecom et la même sur lien ADSL. Les prix affichés dans le tableau sont les prix publics hors taxes.

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

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

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

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

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

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

• si 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 ; en 6 ans d'utilisation de 3 lignes T0, nous n'avons jamais été en dérangement. Il faut aussi penser que, si vous avez plusieurs lignes T0, vos lignes se backupent entre-elles : si une ligne T0 est down (par exemple à cause d'une erreur de câblage entre le NRA et l'entreprise de la part de France Telecom, comme cela nous est arrivé lors de l'installation de la ligne SDSL), votre installation RNIS continue de fonctionner pour les appels entrants et sortants avec seulement 2 appels simultanés maximum en moins.

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

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

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

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

Choix d'un opérateur IP

Choix actuel : Acropolis Telecom.

Si c'était à refaire : pour les entreprises à la recherche de la meilleure qualité et disponibilité possible, j'éviterai d'utiliser un opérateur IP et je resterai chez France Telecom sur des lignes RNIS. Pour les entreprises à la recherche de la solution la plus compétitive, je suggère de choisir l'offre de trunk SIP d'OVH.

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

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

• Acropolis Telecom, qui propose des offres en trunk SIP ou IAX avec le lien ADSL ou SDSL. Ils achètent leurs liens SDSL à Orange, et ils ont une collecte ATM directement chez Orange, ce qui leur permet de garantir la qualité de service entre le DSLAM et leur réseau. Leur offre semble donc solide d'un point de vue technique.
• OpenIP, qui propose des offres en trunk SIP avec le lien ADSL ou SDSL. Ils achètent leurs liens xDSL chez Orange ou SFR et ont une collecte directement ces opérateurs.

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

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

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

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 :

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.

Sur un autre de mes déploiements Asterisk qui 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.

Mon conseil est donc le suivant :

• intéressez-vous aux opérateurs IP (OVH, Acropolis Telecom, 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 chez France Telecom en RNIS 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.

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

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

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

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

Le packaging d'Asterisk

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

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

Choix recommandé : Distribution Asterisk Xivo (c'est la solution que je retiens maintenant pour tous mes déploiements).

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 :

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

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

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

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

   Distribution	Editeur	Interface de management	Fourni Asterisk 1.6 ou 1.8 ?	OS	Commentaire
   Trixbox	Fonality, USA	FreePBX	Asterisk 1.6 est fourni dans Trixbox 2.8 et supérieurs	CentOS	Distribution Asterisk la plus ancienne. Il existe une version communautaire gratuite et une version "entreprise" payante.
   AsteriskNow	Digium, USA	FreePBX	Asterisk 1.6 est fourni.	CentOS	La version 1.0.0 est sortie en Février 2008. Elle utilisait jusqu'à fin 2008 l'interface Web de configuration AsteriskGUI, mais les développeurs ont finalement décidé de passer à FreePBX par défaut.
   Elastix	PaloSanto Solutions, Equateur	FreePBX	Oui, dans Elastix 2.0	CentOS	Distribution lancée en 2006. Ce projet a l'air très dynamique et possède une bonne réputation. Communauté espagnole très forte.
   PBX in a Flash	aucun, développement 100% communautaire	FreePBX	Donne le choix d'utiliser Asterisk 1.4, 1.6 ou 1.8 lors de l'installation	CentOS	Projet créé en Novembre 2007 par d'anciens développeurs de Trixbox en réaction à l'orientation de plus en plus propriétaire de Trixbox (explications ici).
   Xivo	Avencall (anciennement Proformatique), France	Xivo	Xivo 1.2.x utilise Asterisk 1.8 (Xivo 1.1.x utilisait Asterisk 1.4).	Debian	Projet initialement non communautaire qui constituait la base des solutions commerciales de la société française Avencall ; le projet est devenu communautaire début 2009. C'est la seule distribution Asterisk basée sur Debian. C'est la seule distribution à ne pas utiliser FreePBX : Xivo possède sa propre interface Web de configuration. Elle a aussi beaucoup d'autres qualités, cf mon retour d'expérience ci-dessous.

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

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

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

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

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

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

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

• Qualités :
  • Bonne interface Web d'administration : toutes les fonctionnalités dont j'avais besoin étaient proposées en standard par l'interface d'administration. Je n'ai pas eu à ajouter des fonctions à la main dans le dialplan.
  • Le client Xivo, qu'on peut installer sur son PC sous Windows, Linux ou Mac OS X, voir même sur son smartphone Android, ou qu'on peut utiliser via une interface Web. 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 Xivo pour activer le renvoi d'appel sans vous déplacer ! Super pratique !
    • vous pouvez lancer la numérotation d'un appel depuis le client Xivo. 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 Xivo et d'un clic vous lancez la numérotation : votre téléphone sonne, vous décrochez, et Xivo 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.
    • et bien d'autres fonctionnalités encore... cf cette page.
  • Fonctionnalités avancées et très pratiques pour le provisionning des téléphones IP :
    • Le fait de confier à Xivo 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.
    • Xivo 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 "guest". Il suffit alors de composer le code d'approvisionnement que Xivo a attribué au compte SIP sur le téléphone, et le téléphone redémarre et obtient du serveur de provisionning de Xivo la bonne configuration. Très pratique !
    • les fichiers de configuration générés par Xivo 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.
    • Xivo 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. Xivo 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, Xivo 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 Xivo. Encore une fonctionnalité très pratique !
• Défauts :
  • La documentation disponible dans le Wiki est relativement limitée. Mais comme c'est un Wiki, chacun peut donner un coup de main pour l'améliorer ! Je n'aurai pas pu faire mes premiers déploiements en me contentant de la doc disponible en ligne, j'ai dû demander de l'aide sur l'IRC (chan #xivo sur Freenode), et j'ai été très gentillement aidé par des employés d'Avencall très sympatiques (merci à guillaumeb et kaou !)
  • Le site de Xivo a encore beaucoup de parties en français uniquement, ce qui a tendance à réduire la communauté Xivo aux utilisateurs francophones. C'est dommage car ça empêche Xivo de prendre toute l'ampleur qu'il mérite.
  • La mise en production de ma 3ème installation a été difficile car nous avons été impacté par 2 bugs, le premier était un bug critique et le deuxième un bug majeur :
    • notre installation initiale était un Xivo 1.1.9, qui s'est révélé être impacté par un bug critique qui faisait planter l'IPBX au bout de 11 jours car il atteignait après ce laps de temps le nombre maximum de fichiers ouverts. Les détails de la cause du problème sont expliquées ici. Ce problème a été corrigé dans Asterisk 1.1.10, mais cela a fait planter toute l'installation téléphonique à deux reprises... le temps de comprendre la cause du problème et que la mise à jour soit disponible côté Xivo.
    • dans Xivo 1.1.10, il y avait un bug sur les blind transfert : lors d'un transfert d'appel où on n'attend pas que la personne à qui on passe l'appel décroche avant de valider le transfert, la communication était coupée. Ce bug a été corrigé dans Xivo 1.1.11.
    Heureusement, cette mauvaise expérience du début n'a pas perduré et on a simplement joué de malchance avec ces 2 bugs lors de mon premier déploiement Xivo !

Xivo 1.2 apporte de très nombreuses améliorations :

• le support d'Asterisk 1.8 (Xivo 1.1 embarquait Asterisk 1.4). Avec Asterisk 1.8, on peut profiter d'un vrai support du T.38, du support de nouveaux codecs, de la mise à jour du numéro présenté lors d'un transfert d'appel, etc...
• la correction d'un certain nombre de problèmes d'ergonomie de l'interface Web de Xivo 1.1, et notamment celui-ci : quand on modifiait la configuration d'un élement, par exemple un poste téléphonique, et que la configuration de cet élément était réparti dans plusieurs onglets, on ne savait plus quel élément on était entrain d'éditer quand on quittait l'onglet principal.
• il n'y a plus besoin de penser à faire un reload de la configuration quand on change un paramètre dans l'interface Web ; les changements sont immédiatement pris en compte (auparavant, il fallait systématiquement penser à cliquer sur le bouton Recharger Asterisk en bas à gauche de l'interface Web... il m'est déjà arrivé de l'oublier et cela m'a joué des tours).
• la disponibilité des prompts Xivo en anglais (dans Xivo 1.1, ils n'étaient disponibles qu'en français).
• un "vrai" reboot à distance des téléphones par Xivo via la commande SIP Notify (dans Xivo 1.1, la commande de reboot à distance des téléphones était propre à chaque modèle de téléphone et souvent ne fonctionnait que si on gardait le mot de passe d'administration par défaut du téléphone, ce qui n'est pas recommandé).

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

Serveur

Choix initial : récupération d'un ordinateur Dell Optiplex de bureau.

Choix lors de mes derniers déploiements : mini-PC fanless Linutop 4 avec SSD.

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

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

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

Pour mes déploiements suivants, maintenant que nous avons une solution sans carte PCI ce qui enlève une contrainte importante dans le choix, je me suis intéressé aux serveurs "no moving parts", c'est à dire un serveur sans ventilateurs et doté d'un disque SSD. 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.

Lors de mon 4ème déploiement qui a été mis en production en Octobre 2011, j'ai choisi un serveur Linutop 4 dont voici les caractéristiques :

• processeur Intel Atom N270 1,6 Ghz
• 1 Go de RAM
• 1 interface Giga Ethernet Realtek (driver r8169)
• SSD Intel 320 series 40 Go SATA 2,5", qui a remplacé la mémoire flash de 2 Go livrée en standard (en fait une DOM sur port USB interne)

Pour les gens intéressés par le Linutop 4, je donne ici les détails techniques qu'on ne trouve malheureusement pas sur le site du constructeur : cpuinfo, dmesg, lspci et lspci -nv. Cette machine est bien supportée par Debian Lenny 5.0, qui est la distribution sur laquelle se base la branche 1.1 de Xivo. Le prix public du Linutop 4 est de 380 euros HT, ce qui est assez cher vu les caractériques techniques (on paye la rareté des offres de PC fanless !), mais le constructeurs propose des réductions pour les intégrateurs. Tout compris avec le SSD Intel, la configuration a coûté un peu moins de 400 euros HT. Pour ce déploiement, nous avons fait le choix d'acheter deux Linutop 4, pour avoir une redondance du matériel sur place.

Comme ce déploiement est assez récent, je ne peux pas encore faire un bilan sur le long terme de la fiabilité de cette configuration. Par contre, je peux déjà donner un premier avis :

• c'est une configuration économique en électricité : 14 W de consommation selon le constructeur (je n'avais pas de quoi vérifier sur place), soit 14 euros d'électricité par an environ,
• la puissance modeste du Linutop 4 est tout à fait suffisante pour ce déploiement. Ce déploiement comporte une trentaine de téléphones SIP, un trunk SIP avec 6 communications simultanées maximum, tout est en G711 donc pas de transcodage, pas d'utilisation du client Xivo pour le moment. Selon les graphs de monitoring Xivo, l'utilisation CPU plafonne à 20%, le load est à 0.15 avec des pics à 0.3, la quantité de RAM utilisée est inférieure à 200 Mo après soustraction de la RAM utilisée par les buffers et le cache.
• c'est une configuration totalement silencieuse : la seule façon de savoir si le serveur est bien allumé est de regarder la diode en facade ! Cela donne l'idée que cette boite "n'est pas un PC", et donc que l'on n'est pas dans le domaine de l'informatique, mais bien dans un autre domaine... la téléphonie justement !
• cette machine n'est pas prévue pour être rackée dans un rack 19" (si vous comptez l'installer dans une baie, il faut prévoir un plateau pour la poser),
• il nous a fallu faire un petit bricolage pour pouvoir brancher le connecteur d'alimentation du SSD... si je commande de nouveau la machine, je demanderai au constructeur qu'il me fournisse ce qu'il faut pour pouvoir installer un disque SATA 2,5" sans bricolage.

Fax

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

Choix suivant jusqu'à Juillet 2010 :

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

Choix actuel :

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

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

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

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

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

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

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

Ce système a plusieurs avantages :

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

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

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

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

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

Choix des interfaces téléphoniques

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

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

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

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

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

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

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

Avec ces boitiers dédiés :

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

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

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

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

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

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

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

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

Réseau

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

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

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

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

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

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

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

La fonctionnalité PoE (Power over Ethernet) permet d'alimenter les téléphones en électricité par le câble réseau plutôt que par un bloc d'alimentation spécifique. Il faut que cette fonctionnalité soit supportée par les téléphones IP (ce qui est le cas des téléphones 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). L'avantage du PoE est de n'avoir qu'un seul câble utilisé pour les téléphones IP au lieu de deux, ce qui fait plus propre sur les bureaux !

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

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

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

Fonction standard

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

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

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

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

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

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

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

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

Société de service

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

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

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

Les deux sociétés sont à mon avis un bon choix, mais Avencall a l'avantage d'être focalisé sur la téléphonie sur IP et d'être un acteur majeur de l'écosystème Asterisk. Nous avons finalement choisi la société Morea car nous connaissions un des associés de la société, qui nous avait prouvé son sérieux sur des projets antérieurs.

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

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

• Ceyla, basé à Nantes,
• Infimo, basé à Corbeil-Essonnes.

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

Interphone IP avec ouverture de porte

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

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

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

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

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

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

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

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

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

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

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

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

Le serveur Asterisk

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

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

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

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

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

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

La passerelle SIP/RNIS Patton SN4683

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

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

Voici notre fichier de configuration du boitier Patton.

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

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

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

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

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

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

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

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

Mon pense-bête Patton :

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

Les téléphones Technicolor/Thomson ST2030

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

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

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

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

J'ai mis en ligne mes fichiers :

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

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

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

set coding 0 vad  off

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

Les téléphones Aastra 6731i

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

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

La pieuvre de conférence Polycom IP 6000

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

Je mets en partage les fichiers à personnaliser :

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

La QoS sur le réseau

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

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

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

Pour mettre en place la QoS, il faut :

• que les téléphones taggent les flux IP qu'ils envoient, ce qui se configure différemment pour chaque marque de téléphone (les fichiers de configuration que je mets en partage vous donneront la solution pour les téléphones 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 switchs Linksys SRW224G4P, cela se configure 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 en attente de décroché qui faisait sonner un téléphone qui n'était pas le sien. 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 du déploiement initial, 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.

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, si vous avez du mal à choisir entre faire du directed pickup ou du group pickup, sachez que rien n'empêche de mettre en place les deux !

Interconnexion avec un opérateur IP

Portage des numéros

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

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

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

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

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

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

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

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

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

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

Architecture d'interconnexion

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

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

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

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

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

Les imperfections qu'il reste à corriger

Ce paragraphe contenait la liste des points qu'il me restait à résoudre pour être parfaitement satisfait de mon déploiement VoIP avec Asterisk. Cette liste s'est réduite au fur et à mesure et ne comporte actuellement plus aucun élément !

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

Lors de mon déploiement initial, 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 les téléphones ST2030

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

• Pour voir la version du firmware :

  # version

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

  # autoprovision show

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

pour Asterisk

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

• Pour voir les entités SIP :

  asterisk*CLI> sip show peers
  

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

  asterisk*CLI> sip show inuse
  

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

  asterisk*CLI> sip show registry
  

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

Anciens schémas d'architecture

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

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

Schéma d'architecture jusqu'en Juin 2009

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

Schéma d'architecture initial

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

XHTML 1.1 et CSS valides