Tester une ligne VoIP avant
de la vendre

Ce qu'on mesure avant de brancher une ligne

Comment nous testons

Trois niveaux, du plus simple au plus révélateur : un appel de test vers une annonce, un appel de test vers un répondeur qui mesure l'écho et le décalage, puis une capture en situation réelle sur le réseau du client, aux heures de pointe. C'est le troisième niveau qui trouve les problèmes, le WiFi d'un établissement à midi ne ressemble pas à celui de huit heures du matin.

Le MOS, ce chiffre qu'on vous vend sans l'expliquer

Quand un fournisseur annonce « une qualité MOS de 4,2 », il avance un nombre que presque personne ne sait interpréter. Il vaut la peine de l'expliquer, parce que c'est la seule mesure qui parle à la fois aux techniciens et aux directions.

Le MOS (Mean Opinion Score) vient de l'ITU-T, recommandation P.800 : c'est, à l'origine, la note moyenne qu'un panel d'auditeurs donnait à un appel, de 1 (inutilisable) à 5 (parfait). Autrement dit, une mesure d'oreille humaine, pas une mesure réseau. Tout le reste n'est qu'une façon de l'approcher.

On l'obtient de deux manières, et la confusion entre les deux est la principale source de malentendus :

• Par écoute instrumentale on injecte un signal de référence dans la ligne et on compare ce qui ressort. PESQ (ITU-T P.862) pour la bande étroite, POLQA (P.863) pour la bande large. C'est une mesure intrusive : elle demande d'interrompre le trafic, mais elle entend vraiment.
• Par prédiction on ne fait pas écouter la voix : on calcule. Le modèle E (recommandation G.107) part des métriques réellement observées, codec, perte de paquets, gigue, délai, et en déduit un facteur R de 0 à 100, converti ensuite en note de 1 à 5. C'est ce que fait Wireshark quand il affiche une colonne MOS sur une capture RTP.

Ce que valent les chiffres, en pratique :

Le codec fixe le plafond, le réseau décide de ce qu'on en garde. Un G.711 parfait plafonne autour de 4,4 ; le même G.711 avec 2 % de pertes tombe vers 3,5 et le client le sent immédiatement. Une gigue mal absorbée par la mémoire tampon fait chuter la note avant même que la perte n'apparaisse.

Et voici le piège, celui qu'il faut dire à un client : un MOS calculé sur une capture de vingt secondes à onze heures du matin ne dit rien de votre lundi à quatorze heures. Un MOS prédictif sur un réseau calme est un bon chiffre et une mauvaise preuve. C'est pourquoi nous ne livrons jamais un MOS seul : il est accompagné de la capture, de l'heure et de la charge du lien au moment du test.

Dernière limite, et elle est importante : le MOS ne mesure pas l'intelligibilité pour une voix donnée, un accent, une langue. Deux personnes peuvent obtenir 4,2 et se faire répéter trois fois. La mesure instrumentale ne remplace pas une écoute réelle, elle la guide.

Comment on teste un appel SIP, message par message

Un appel téléphonique n'est pas « une connexion » : c'est une conversation de messages texte, puis un flux audio séparé. Savoir laquelle des deux parties échoue est tout le travail. Voici la séquence, et ce que nous vérifions à chaque étape.

1. 1
   L'enregistrement. REGISTER Le poste s'annonce au serveur. Réponse attendue : un défi d'authentification (401 ou 407), puis un second REGISTER muni du condensé, et un 200 OK. Si l'on s'arrête là, le problème est un mot de passe, une heure système décalée, ou un accès sortant bloqué.
2. 2
   L'invitation. INVITE et SDP L'appelant propose sa liste de codecs, ses adresses et ses ports. C'est là que se jouent les échecs les plus silencieux : un SDP qui annonce une adresse privée, un port RTP fermé au pare-feu, ou un codec que l'autre côté refuse (réponse 488 ou 415).
3. 3
   Les réponses provisoires 100 Trying (j'ai reçu), 180 Ringing (ça sonne chez le destinataire), 183 Session Progress (une annonce ou une tonalité arrive avant la réponse). Un 180 sans 200 qui suit indique où ça bloque : poste non enregistré, renvoi cassé, ou décroché impossible.
4. 4
   La réponse : 200 OK, puis ACK Le destinataire accepte et renvoie son propre SDP : codec retenu, adresse et port RTP. L'ACK de l'appelant ouvre la conversation. À partir d'ici, tout ce qui compte se passe en UDP, hors de la signalisation.
5. 5
   L'audio. RTP dans les deux sens Des paquets de 20 ms en général, sur une paire de ports UDP. On vérifie qu'il en arrive dans les deux sens, avec des numéros de séquence continus et des horodatages réguliers : c'est de là qu'on tire perte, gigue et, par le modèle E, le MOS.
6. 6
   Les touches. DTMF Un standard qui demande « tapez 1 » teste en réalité la négociation du DTMF. En RFC 4733 (événements RTP), les touches passent même si la voix est compressée ; en inband, un codec qui compresse trop les fait disparaître. Un client qui « n'arrive jamais à joindre le service commercial » a souvent ce problème-là.
7. 7
   La fin. BYE Le 200 OK qui répond au BYE confirme que la session se ferme proprement. Une session qui reste ouverte côté serveur est une fuite de licence et, à terme, un refus d'appel.

Les outils, ensuite, sont simples et tous libres : sngrep pour lire la conversation sous forme d'échelle, sipp pour rejouer cent appels et mesurer le taux de décrochage et le délai de prise d'appel, tcpdump et tshark pour capturer, et l'analyse RTP de Wireshark pour extraire perte, gigue et MOS d'une capture réelle.

Les cinq pannes que ce protocole de test attrape, et qu'aucun « test de sonnerie » ne montre :

Ce qu'une sonde publique ne mesure pas

Notre page État des services vérifie la téléphonie en HTTPS, pas en SIP : depuis un hébergement mutualisé, le port 5060 ne sort pas. La page l'écrit noir sur blanc, plutôt que d'afficher une carte verte qui ne prouverait rien.

Le vrai contrôle SIP se fait depuis le réseau du client, ou depuis un équipement interne autorisé par le pare-feu. C'est ce que nous installons quand un client veut une preuve continue, pas seulement un relevé.

Les trois causes d'échec que nous rencontrons le plus

• Le pare-feu ports SIP filtrés en entrée comme en sortie, ou alg qui réécrit les entêtes et casse la signalisation.
• Le réseau voix et données sur le même VLAN sans priorisation : le premier téléchargement dégrade les appels.
• Le dernier kilomètre un lien Internet saturé en émission, et la voix devient hachée dans un seul sens, ce qui est le plus difficile à faire admettre.

Un audit téléphonique sérieux ne consiste pas à vérifier que « ça sonne ». Il consiste à mesurer ce qui se passe quand ça ne sonne pas.