L’IP, il y en a partout, les PABX IP sont désormais la norme dans bien des domaines et on ne se pose plus vraiment la question de la fiabilité ou de la qualité des communications sur IP (attention, je n’ai pas dit sur Internet, mais bien sur IP). Alors pourquoi est-il si difficile de faire se comprendre deux PABX du marché ? C’est ce que je supporte en ce moment sur un gros projet de téléphonie pour lequel une entité d’étude technique essaye de faire fonctionner un PABX Alcatel et un de chez Avaya. Pourtant deux marques très présentes sur leurs marchés respectifs, reconnues et pas tout à fait des startups dans le domaine, mais pourtant ça ne suffit pas. Il manque une licence par ci, un bout de code par là, une option spéciale à débloquer ou encore des incompatibilités. Tout ceci est assez incompréhensible et encore plus pour les utilisateurs d’Asterisk qui ne se posent par définition par la question de la compatibilité des téléphones et autres équipements SIP lorsqu’ils en ont besoin.

Mais ici, nous sommes dans la cours des grands où l’argent est important et les clients se doivent d’être captifs. Pas question d’envisager d’interconnecter sa solution technique qui fonctionne de façon autonome avec une autre solution d’un constructeur tiers et probablement concurrent d’ailleurs. Le téléphone n’utilise pas vraiment SIP pour communiquer avec la plate-forme, mais c’est de l’IP. Il pourrait être compatible avec SIP, mais en fait pas vraiment ou alors il manque tellement de fonctionnalité qu’il en devient inutilisable et surtout hors de prix pour les fonctions rendues. Utiliser un produit tiers totalement compatible SIP n’est pas non plus simple, il faut s’acquitter de licence et en plus souvent beaucoup de fonctionnalités sont perdues en route (appel par le nom, annuaire, rappel, conférence…).

Bref, il y a encore de belles années pour tous ces constructeurs de spécifique et de propriétaire, mais nous savons tous pertinemment que cette époque finira par être révolue, l’exemple de l’informatique propriétaire et mono marque nous l’a démontré et je suis convaincu qu’il ne peut en être autrement pour la téléphonie d’entreprise. Si on pouvait accélérer le temps sur ce thème je le ferais volontiers pour sortir de cette situation bien peu favorable au consommateur et bien triste technologiquement.

Il était auparavant possible de positionner un maximum de paramètres dans la section générale du fichier sip.conf, mais la gestion des exceptions n’était pas simple et imposait une rigueur importante.

L’utilisation des modèles SIP s’effectue en deux temps : définition puis utilisation.

Définition des modèles

Le principe est simple, on définit un contexte suivi par une inclusion optionnelle d’autres modèles :

[internal-codec](!)
        disallow=all
        allow=alaw

[internal-sip](!)
        type=friend
        host=dynamic
        qualify=150
        context=internal

Là j’ai défini une section avec les codecs qui seront utilisés sur les postes internes internal-codec et un modèle pour les postes de mon réseau internal-sip. La syntaxe (!) permet de spécifier que ce contexte est un modèle et éventuellement les inclusions d’autres modèles séparés par une ,.

Utilisation des modèles pour les extensions

Au niveau de la définition des extensions, on ajoute (modèles) derrière le nom du contexte pour appliquer le ou les modèles spécifiés et séparés par des ,.

[100](internal-sip,internal-codec)
callerid=Lab 1 <100>

[101](internal-sip)
callerid=Lab 2 <101>

[102](internal-sip)
callerid=Lab 3 <102>

Simple, rapide et vraiment pratique. Voilà un argument intéressant en faveur de la 1.6, même si cela peut sembler un détail, mais lorsque l’on écrit les configurations à la main pour plus de précision c’est important en terme d’efficacité et de lisibilité.

Certes on peut transporter de la voix sur IP et depuis bien longtemps d’ailleurs, la numérisation des réseaux de téléphonie à débuté dans les années 60 et utiliser des réseaux de paquet ne complexifie pas énormément le processus. Un peu de gestion de gigue et de réordonnancement des trames et le tour est joué. Avant les années 2000 des produits étaient en production chez les opérarteurs data pour transporter de la voix, souvent sur FrameRelay à l’époque mais le principe est exactement le même.

Mais de là à transporter de la voix dans un réseau IP qui lui même est transporté sur un réseau de mobile est loin d’être une solution technique élégante. En particulier on mettra en lumière les problèmes de bande passante sur la voix montante et de délai. Pour la bande passante on utilise en général 80Kbps pour transporter un appel en G.711, skype utilise un codec large bande pour donner plus de qualité et on peut descendre la consommation en utilisant des codecs plus agressifs mais nécessitant plus de CPU (G729 par exemple) ou tout simplement le codec GSM (le comble du paradoxe non ?). La bande passante peut varier en fonction de l’usage sur la partie données, donc dans une zone de population dense, il sera préférable de passer par le réseau voix traditionnel.
Pour ce qui est du délai, en fonction du niveau de signal on peut avoir des délais de transit autour de 200ms alors que l’on considère un appel de bonne qualité en dessous de 150ms et la plupart des utilisateurs commencent à ressentir le délai à partir de 90ms.

Tout ceci va s’améliorer avec les nouvelles technologies de transmission notamment le HSDPA (High Speed Downlink Packet Access), mais ce n’est pas pour tout de suite sur l’ensemble du réseau.

Nous avons été habitués avec la téléphonie à un niveau de qualité assez élevé et nous devrions tenter d’avoir encore mieux plutôt que de niveler par le bas. Dans la téléphonie sur IP nous avons beaucoup de travail pour éduquer nos clients sur le fait que la qualité peut être bien meilleure que dans la téléphonie traditionnelle, si on s’en donne la peine. Dommage que des services comme ceux-là sortent trop tôt par rapport à la capacité des réseaux des opérateurs à l’absorber, la qualité va être faible et on va assimiler VoIP avec mauvaise qualité.

Messieurs les opérateurs, la balle est désormais dans votre camp pour migrer rapidement vos réseaux en IP, augmenter la bande passante et nous offrir des solutions SIP homogènes et ouvertes.

« Pour beaucoup de clients, la qualité audio n’est pas encore satisfaisante », explique Pascal Richard, directeur technique chez Resophone.

Quel est le rapport entre le trunk SIP et la qualité audio ressentie par les utilisateurs ? S’il on fait bien les choses, ce que je me tue à dire lors des cours que je donne, on peut avoir une qualité au moins aussi bonne, voir meilleure avec l’utilisation de codec à large bande. SIP est un protocole de signalisation pas de gestion de la qualité de service. Dès lors que l’on utilise un réseau asynchrone pour transporter des données temps réel, il est important de mettre en place des méthodes et outils pour atteindre le niveau de qualité demandé par les utilisateurs. On ne met pas en place un code G.729 pour le plaisir, mais bien comme un compromis entre qualité d’écoute plus faible et consommation de bande passante réduite.

Le passage en SIP nécessite principalement des équipements dans les entreprises et c’est ici à mon avis que cela coince aujourd’hui. Les installateurs préfèrent pousser pour un passage sur du T0/T2 qui est simple, fonctionnel et efficace. L’opérateur historique ne va pas dire le contraire puisque tirant des revenus important de cette activité déjà largement amortie. D’ailleurs il suffit de questionner un chargé d’affaire de la marque pour avoir des informations sur leur interconnexion Trunk SIP pour s’en convaincre.
D’autre part, les constructeurs ayant un retard fou sur la mise en place de pile SIP dans leurs machines historiquement H.323, n’y vont que petit à petit. Autant la connexion des postes utilisateurs en IP propriétaire est facile à vendre, autant il est difficile de faire pression pour l’utilisation d’un protocole maison dès lors que l’on se connecte à l’extérieur avec des opérateurs multiples.

SIP ne sera par tiré par les utilisateurs d’Asterisk ou de FreePBX, j’en doute fort, ni par les petits opérateurs allant chercher principalement de la TPE et du particulier en SIP. Tant que les opérateurs de premier ordre ne pousseront pas les clients vers les nouveaux réseaux IP en présentant la valeur ajoutée plutôt que la réduction de coût (erreur stratégique à mon sens), les choses n’avanceront que lentement.

Le trunk SIP c’est l’avenir, aucun doute là dessus à cette heure. Il ne reste plus qu’à y aller en faisant attention à l’installation afin que les clients ne soient pas déçus : gestion de priorité IP, redondance si besoin, intégration des flux de données et hybrides (fax par exemple), utilisation des téléphones SIP et des bornes DECT/SIP en provenance des constructeurs compétents, sécurité bien sûr…

On trouve donc du PlcmSpIp dans les tentatives d’accès SSH, étonnant non ? Cela signifie qu’il y a une probabilité non nulle que des téléphones IP soient directement connectés à l’Internet, ce qui n’est pas bien prudent vous en conviendrez.

Au minimum, on met en place un filtrage, idéalement un VPN, mais encore mieux un Asterisk, un SER ou équivalent en guise de SBC.

Enfin, moi ce que j’en dis…

Il est clair que la migration sur IP de la voix est importante aujourd’hui et inéluctable. Bien ou pas ce n’est pas le débat ici. Tant que l’on mettra IP en avant, des solutions ouvertes feront leur apparition et l’interopérabilité deviendra la maître mot, permettant aux clients de faire leur marché sans rester attaché à un constructeur ou une solution propriétaire.

Dès qu’il est question de mobilité et donc principalement en entreprise où les distances à couvrir sont plus importantes que chez les particuliers, on quitte un monde qui était dominé par le DECT pour un nouveau monde. Longtemps, l’offre IP des constructeurs historiques de téléphonie avait délaissé la partie mobile pour reprendre simplement la partie DECT numérique existante au catalogue. On a donc vu apparaître des solutions chez les pro-IP qui, ne pouvant pas être basées sur DECT, se sont rabattues sur un moyen de transport existant et peu coûteux : Wi-Fi (IEEE 802.11 pour être exact).

On l’a déjà dit ici Wi-Fi n’est pas fait pour transporter un flux temps réel et la voix en est un. L’acquittement positif de toutes les trames de données, les délais d’attentes pour la prise de parole, la nature half-duplex du média radio utilisé avec la méthode d’accès CSMA/CA font de ce protocole un excellent moyen économique de pousser des trames IP, mais sans aucun contrôle sur le délai un très mauvais candidat pour la téléphonie. Pour connecter mon micro c’est parfait, fabriquer un hot-spot c’est idéal, jouer à Mario Kart sur la Wii c’est super, mais pour le transport de la voix dans un environnement professionnel c’est plus discutable.

Afin de s’en sortir, il y a eu longtemps l’approche quantitative : la bande passante disponible sur un point d’accès Wi-Fi peut aller jusqu’à 25Mbps environ en 802.11g, donc pour faire passer une communication téléphonique à 80Kbps environ c’est très largement suffisant. On peut même se permettre de mettre plusieurs communications simultanées et de la donnée en plus. Le soucis vient un peu plus tard, lorsque la partie données du réseau commence à être utilisée plus largement, alors le réseau ne tient plus face à des besoins de temps réel, une fois de plus il n’a pas été conçu pour cela. Il faudra donc multiplier les points d’accès pour espérer répartir les terminaux associés à chacun.

Autre soucis du Wi-Fi, la mobilité et non l’itinérance comme sa conception le suppose. Bien souvent, les terminaux Wi-Fi ne cherchent une nouvelle source de réseau (un point d’accès) que lorsque celle sur laquelle ils sont associés propose un niveau de signal faible (SNR). Alors débute une traque qui consiste à analyser chaque canal radio (nous en disposons de 14 en France) à l’écoute d’une trame de balise qui est émise par défaut toutes les 100ms. Le temps de recalibrer une radio sur un terminal à faible coût prend tout simplement du temps. Donc on arrive à un délai de passage d’un point d’accès à un autre qui peut facilement atteindre la seconde, soit 20 fois plus long que ce qui est communément admis dans l’industrie de la voix. Ce délai pourrait largement être réduit mais avec des coûts d’électronique plus importants. Une nouvelle norme fait donc son apparition, mais à partir de quand sera-t-elle disponible dans les équipements utilisés en entreprise et notamment en PME ?

L’autre approche consiste donc à faire du qualitatif : on met en place de nouvelles normes faisant évoluer le Wi-Fi dans une optique de qualité de service. L’approche bande passante que l’on a pu voir dans 802.11n ne s’applique pas aux entreprises pour des raisons évidentes de radio, nous laisserons donc cela pour les particuliers et leur TV HD. Dans le qualitatif on nous promet donc une capacité de roaming et un traitement de la QoS avec le respect de classes de service. Cette approche est excellente, mais va à l’encontre des économies annoncées pour un passage en ToIP puisque celui-ci s’appuie sur une infrastructure IP existante. Or pour faire de la mobilité en ToIP sur du Wi-Fi il sera nécessaire de mettre en place une infrastructure lourde Wi-Fi qui sera probablement mono constructeur (point d’accès et téléphone) dans un premier temps.

Alors, quitte à mettre en place une infrastructure spécifique, pourquoi ne pas aller vers du DECT. Ce protocole existe et a fait ses preuves. La couverture radio est plus simple à définir en raison de la bande de fréquence utilisée et de la portée des communications. Les bornes DECT aujourd’hui parlent en SIP avec l’infrastructure de téléphonie. Mais surtout le confort d’écoute est de très haute qualité puisque le réseau est dédié à cet usage d’une part et que la QoS est gérée de façon intrinsèque. Enfin, la densité est plus importante au regard de la bande passante utilisée.

Aujourd’hui que le marché est mature en terme d’offre DECT sur SIP et en attendant plus de maturité au niveau du Wi-Fi adapté à la voix, je continuerai donc à proposer à mes clients, ayant des besoins importants de mobilité en voix, de regarder sérieusement les solutions DECT. Bien sûr à contrario, lorsque l’infrastructure Wi-Fi existe dans l’entreprise et que l’on ne souhaite pas avoir un usage industriel de la partie téléphonie mobile, quelques terminaux Wi-Fi SIP et le tour est joué.

Et vous, Wi-Fi ou DECT sur votre Asterisk ?

• if_inbound: permet de définir la carte réseau de votre réseau interne, Là où le téléphone se trouve (eth0 par exemple)
• if_outbound: permet de définir la carte réseau externe. Dans mon cas, il s’agit de l’interface virtuelle montée par mon VPN (tap0 par exemple)
• hosts_allow_reg: la liste des machines/réseaux qui auront le droit d’utiliser le proxy pour s’enregistrer sur un serveur SIP.

Vous avez à présent un proxy sip fonctionnel. L’ajout de log de debug (paramètre silence_log) peut être utilisé pour diagnostiquer les éventuels problèmes.

Finalement il manque juste à cet outils un portage sous Windows…

La page du projet est ici: siproxd

Ainsi, l’objectif d’Astitray est le suivant:

• Une application simple
• Intégrée au poste de travail
• Permettant de générer des appels sur son téléphone
• Avec un annuaire central

Bien évidement, il est impensable d’ouvrir un accès manager pour chaque poste de travail. De même partager un accès commun amène inévitablement à des « débordements » (déclenchement d’un appel chez son voisin principalement…).

Aussi astitray est livré avec un serveur XMLRPC écrit en PHP. Celui-ci gère le contrôle d’accès et permet l’appel aux différents services. L’autre objectif de ce serveur est aussi de réaliser un couche d’abstraction pour la communication avec le PBX. Ainsi il est possible, via l’écriture d’un « driver », de réaliser les mêmes opérations sur un autre PBX qu’Asterisk.

Néanmoins, suivant le nombre de poste de travail, le serveur XMLRPC ne peut être utilisé en direct sur le manager d’Asterisk et l’emploi d’un proxy est indispensable. Astitray utilise Ajam pour communiquer avec Asterisk. Pour le moment aucun Proxy de manager Asterisk ne supporte ce nouveau protocole. Aussi l’écriture d’un driver supportant le protocole natif d’Asterisk est donc une prochaine étape pour le projet !

La page du projet est : Astitray.

Plus d’information ici.

Il est assez fréquent en ce moment de voir des systèmes de gestion des appels ou ACD fonctionner assez mal lorsqu’il est question de passer l’appel sur un agent. Ces derniers jours, j’ai eu l’occasion de contacter mon FAI préféré pour des soucis de qualité et de mise à disposition de ligne DSL, mais également ce matin ma caisse de sécurité sociale, avec des attentes interminables mais surtout avec des lignes qui sont raccrochées lorsque l’agent semble prendre l’appel. Je doute que ce soit les agents qui raccrochent l’appel de façon volontaire, même si dans certains cas la manipulation des postes téléphonique n’est pas ergonomique et peut entraîner ce genre de désagrément. Je pense plutôt qu’il s’agit de réel problème de tenu à la charge des ACD et d’une mauvaise ingénierie.

Les systèmes de téléphonies étant de plus en plus complexes et l’attente des utilisateurs de plus en plus grande il est urgent que les gestionnaires de système de téléphonie s’occupent sérieusement de ce problème de qualité. Un bon suivi des causes d’arrêt des appels doit permettre d’améliorer les fonctionnements internes de l’ACD et ainsi la qualité des services client, car finalement avoir un appel en attente dans une file si celui-ci n’aboutit pas sur un agent qui va résoudre le problème ou donner la bonne information coûte très cher, en image mais également d’un point de vue de l’infrastructure.

Et vous, que faites vous sur votre système pour vous collecter les informations de qualité ?