Lors d’un déploiement de VoIP, il arrive parfois que la qualité de la voix soit médiocre voir même inaudible. Il est alors intéressant de vérifier plusieurs points qui peuvent être source de disfonctionnement des équipements et des protocoles réseaux associés.

La première partie à vérifier se situe au niveau du LAN, et plus particulièrement du câblage. Il ne faut surtout pas outrepasser ce point, le câblage étant souvent mis en défaut sur ce genre de problèmes. Les câbles utilisés en ToIP doivent être au minimum de catégorie 5E.

Ensuite, il convient de vérifier au niveau des switches le paramétrage des ports sur lesquels sont branchés les téléphones. Le paramètre à prendre en compte est essentiellement la vitesse du port (10/100/1000) et le duplex (half / full). L’autonégociation des équipements peut parfois être défaillante et aboutir à des paramètres incorrects, surtout dans le cas où les équipements entre lesquels elle a lieu sont de constructeurs différents.

En téléphonie IP, on peut choisir d’utiliser l’injection POE ou une alimentation électrique classique. Dans le premier cas, il faut vérifier que la tension injectée sur chaque port du switch est correct et respecte le minimum attendu par le poste (il faut pour cela vérifier la doc constructeur). Il peut-être intéressant aussi de vérifier que la capacité POE totale du switch sur lesquels sont raccordés les téléphones permet de brancher le nombre de téléphone souhaité.

Si le LAN est paramétré pour faire de la qualité de service, il faut s’assurer que les flux de voix et de signalisation sont bien prioritaires. Il faut aussi s’assurer que les téléphones effectuent un marquage correct de niveau 2 au niveau du tag 802.1p et que ce tag est correctement pris en compte dans les politiques de QoS LAN.

Une fois la partie LAN vérifiée, il faut alors s’attarder sur la partie WAN. Le plus important sur celle-ci reste la QoS, qu’il est nécessaire de ne pas négliger. Les flux de voix, comme tout flux dit “temps réel”, doivent être les plus prioritaires. L’approche généralement utilisée au niveau des routeurs WAN est DiffServ, avec la gestion des champs DSCP des entêtes IP des paquets.

 Habituellement, le routeur WAN va donc matcher les paquets entrants via des access list et écrire le marquage DSCP dans la nouvelle entête avant d’émettre le paquet sur le WAN. Ce marquage DSCP permet d’indiquer aux routeurs intermédiaires la manière de traiter le paquet. En règle générale, la bande passante totale du lien WAN est divisée en plusieurs classes de services, avec pour chacune d’entre elle une bande passante fixe attribuée (avec tout de même des autorisations de burst dans certaines conditions).

Sur un lien à 1 024 Kbps, on pourra allouer par exemple 256 Kbps pour la voix, 256 Kbps pour une classe moins prioritaire (typiquement SAP, Peoplesoft …) etc … Par conséquence, il peut être intéressant de vérifier l’utilisation de chaque classe de service du WAN, et de vérifier que les paquets qui arrivent sur les interfaces du routeur sont marqués comme il faut. Le marquage est fait à deux endroits distincts : au niveau de la signalisation et au niveau de la communication (pour les paquets RTP).  Les paquets de voix purs doivent être impérativement en EF (IP Precedence = 5) tandis que la signalisation peut se contenter d’un IP Precedence = 3.

Pour vérifier ce point là, il faut donc pouvoir sniffer le traffic qui transite entre le LAN et le routeur WAN, en faisait généralement un port mirroring avec comme source le port où est branché le routeur et comme destination le port où sera branchée la machine qui sniffe. Si les valeurs de DSCP ainsi récupérées s’avèrent être nulles, il faut alors se tourner vers l’opérateur qui peut ne pas prendre en compte les valeurs des paquets qu’il reçoit et écraser lui même cette valeur par la sienne.

Une communication sur IP utilise différents codecs pour communiquer avec les passerelles ou les autres terminaux IP. Les plus connus sont G729ab, G711µ, G711a, GSM et iLBC. Les différences entre ces codecs résident dans leur degré de compression et donc la qualité de restitution du son ainsi que la consommation de bande passante. Ce point peut être très problématique dans la qualité des communications, car un communication en G729 aura une qualité bien moindre qu’une en G711 étant donné que le G729 utilise de la compression. Le G711 sera donc plus régulièrement utilisé sur un LAN tandis que le G729 sera utilisé pour le WAN, la bande passante étant plus coûteuse.

La différence entre le G711a et le G711µ est que ce sont deux standards utilisés respectivement en France et aux USA (il s’agit a priori de l’utilisation d’un bit qui est différentes dans les deux versions). Si vous utilisez le protocole SIP, c’est le protocole SDP qui s’occupe de la négociation du codec lors de la phase d’initialisation de la communication. En capturant des traces il est alors possible de voir le codec employé et de vérifier que tout est conforme à la configuration initiale.

La gigue est un paramètre qu’il est impératif de vérifier lors d’une telle investigation. Il s’agit en fait de la variation des délais lors de la réception des différents paquets d’un flux. Lorsque ce délai est trop important (> 30 ms), la qualité de la voix s’en fait particulièrement ressentir. Ce phénomène peut être maitrîser en adoptant une politique de QoS plus précise et plus adaptée aux flux qui transitent sur le réseau.

Une fois ces informations vérifiées, il reste encore quelques astuces à utiliser pour trouver la source de tels problèmes. En outre, il existe deux mécanismes qui agissent directement sur la voix et qui sont en règle générale à modifier au niveau du téléphone IP. Le premier est l’annulation d’écho accoustique (AEC pour Accoustic Echo Canceller). Généralement, l’écho s’accroît avec les délais de latence observés sur le réseau. Par conséquent, il peut être intéressant de l’activer pour des temps de réponse > à 100 ms, sinon, le désactiver. Ensuite, les téléphones possèdent un système de suppression de silence (VAD pour Voice Activity Detection). Celui-ci permet de détecter la présence de voix et de stopper l’envoi de paquets RTP pendant la durée d’un silence.

Il arrive parfois que la réactivité de ce système soit aléatoire, et que, sur certaines communications, ce mode amplifie les défauts de la communication. Il est alors conseillé de le désactiver. Par ailleurs, ce mode doit être impérativement inactif lorsque des FAX ou des MODEM sont configurés derrière une passerelle analogique. En revanche, sa désactivation entraîne une légère augmentation de bande passante (qui reste relativement infime).

Pour conclure, je dirais qu’il existe bon noms de paramètres à vérifier lorsque de tels problèmes sont rencontrés. La méthode la plus efficace pour le diagnostic reste le sniffer qui analyse le traffic qui circule au niveau du routeur WAN. Je vous conseille d’ailleurs l’utilisation de Wireshark, qui n’est que la nouvelle mouture de Ethereal et qui présente l’avantage d’intégrer le décodage des flux VoIP en natif (SIP, H323 …). De plus, il est possible de reconstituer la synoptique des flux SIP capturés, d’obtenir des statistiques sur la gigue pour les paquets RTP, ou encore vérifier que le marquage DSCP est correct.