Cinq équipes, cinq raisons différentes de tester un réseau voix.

Vous acheminez du trafic via une douzaine de partenaires de peering. L’un d’eux affirme que son côté est irréprochable ; vos clients disent le contraire. Ni l’un ni l’autre ne voit l’autre moitié de l’appel.

Le débogage a posteriori à partir des seuls CDR ne permet pas de distinguer une renégociation de codec, un artefact de transcodage et une véritable packet loss. Quand un pcap est capturé à la main, le problème a généralement disparu.

1. 01Exécutez en continu une campagne planifiée sur chaque route de peering, depuis un nœud agent situé sur votre propre réseau.
2. 02Évaluez chaque appel selon la réponse, le PDD et la circulation de l’audio dans les deux sens, avec des politiques de verdict par code, de sorte qu’un 486 lors d’un test de tonalité d’occupation soit un succès et qu’un 404 n’en soit pas un.
3. 03Quand une route se dégrade, le ladder SIP et la capture de paquets de l’appel en échec sont déjà disponibles.

Un nouveau SBC, un nouvel opérateur ou une bascule UCaaS. La configuration semble correcte et quelques appels de test manuels aboutissent.

Les tests manuels n’exercent que le scénario nominal depuis un seul poste. Ils ne couvrent ni le second codec de l’offre, ni le re-INVITE lors d’une mise en attente, ni le PRACK que le nouveau SBC exige désormais, ni ce qui se passe avec 200 appels simultanés au lieu de deux.

1. 01Passez des appels fonctionnels depuis la Test Console et lisez le ladder SIP complet : chaque transaction, avec ses temps, y compris le challenge d’authentification et le re-INVITE.
2. 02Lancez un test de charge à la concurrence réellement atteinte par le site, en augmentant progressivement le nombre d’appels par seconde, et observez le point de rupture au lieu de le deviner.
3. 03Maintenez une campagne planifiée pendant toute la fenêtre de bascule afin qu’une régression se signale d’elle-même.

Vous développez un PBX, un SBC, une passerelle ou un softphone. Chaque version doit continuer à fonctionner avec les codecs, les transports et les call flows dont dépendent déjà vos clients.

Les tests de régression manuels, ou à base de scripts que seul un ingénieur comprend, ne couvrent que les flux que quelqu’un a pensé à composer. Le second codec sur TLS, ou la réponse à un en-tête mal formé, est souvent la partie qui n’est pas testée.

1. 01Décrivez les tests d’appel sous forme de suite YAML avec une matrice de codecs et de transports, et conservez-la sous gestion de versions à côté du produit.
2. 02Exécutez la suite depuis la CI à chaque build et conditionnez la version au résultat JUnit, comme pour un test unitaire.
3. 03Utilisez le Signalling Lab pour les cas négatifs : du SIP écrit à la main et volontairement mal formé, afin de voir comment le nouveau build y répond.

La qualité audio des appels sortants est correcte la plupart de la journée. Les plaintes se concentrent l’après-midi, et personne ne parvient à les reproduire.

Une dégradation intermittente échappe à une supervision qui se contente de vérifier que le trunk est actif. Un appel peut aboutir avec un 200 OK et rester inutilisable : jitter par rafales, audio dans un seul sens, codec qui a basculé vers une version bande étroite.

1. 01Exécutez des appels synthétiques planifiés sur les routes importantes, 24 h/24, chacun étant vérifié pour l’audio bidirectionnel et le codec négocié, en plus de la réponse.
2. 02Lorsque les plaintes se concentrent sur une route, lancez-y un test de qualité vocale : un audio connu est envoyé et ce qui arrive lui est comparé, de sorte que la dégradation apparaît même lorsque les statistiques de paquets semblent saines.
3. 03Utilisez l’histogramme de jitter et l’analyse détaillée trame par trame pour distinguer une perte par rafales d’une dégradation constante.

Vous gérez la voix pour un portefeuille de clients. Chacun veut savoir si son réseau est en bonne santé, et chacun le demande dans un format différent.

Les rapports sont assemblés à la main à partir d’outils distincts, ce qui est si lent qu’ils sont au mieux mensuels, et un rapport mensuel résume des problèmes que votre client a déjà subis.

1. 01Isolez chaque client dans son propre tenant, avec ses propres comptes, nœuds agent et équipes.
2. 02Construisez un rapport une seule fois à partir des enregistrements d’appels, des résultats SLA et des tests de charge, puis planifiez son envoi automatique.
3. 03Pilotez l’ensemble par l’API lorsqu’un client le souhaite dans ses propres outils, avec une sortie JUnit pour ceux qui utilisent la CI.

Un test planifié a échoué pendant la nuit. L’ingénieur d’astreinte dispose d’un enregistrement d’appel, d’un code de réponse et d’un client qui attend, et lire le ladder SIP, le SDP et les résultats média prend un temps qu’il n’a pas.

Un code de réponse désigne un symptôme, pas une cause. Un même 488 peut venir d’une incompatibilité de codec, d’une offre SRTP que l’autre extrémité refuse ou d’une politique du SBC, et les éléments de preuve sont répartis sur plusieurs écrans.

1. 01Cliquez sur Ask AI dans l’enregistrement d’appel, ou demandez à l’assistant pourquoi l’appel a échoué.
2. 02L’assistant lit l’appel, son ladder SIP et ses résultats média dans les enregistrements propres à VoiceLab, et explique la réponse dans le contexte de cet appel.
3. 03Chaque affirmation est marquée Observed, Likely ou Unknown, afin que ce que montrent les données reste distinct de ce que l’assistant soupçonne.
4. 04Demandez-lui de comparer les deux comptes concernés, ou d’analyser l’incident SLA par rapport aux mêmes heures de la semaine précédente.

Un nouveau trunk demande les mêmes vérifications que les autres : enregistrer un compte, appeler un numéro avec un codec donné, confirmer l’audio, et répéter l’opération chaque nuit.

Chacune de ces vérifications correspond à un formulaire d’une douzaine de champs répartis sur plusieurs pages, et une faute de frappe dans un nom de codec ou un numéro coûte une exécution en échec et un résultat déroutant.

1. 01Décrivez-le : « appelle le 6002 depuis le 6001 en PCMA et vérifie l’audio ».
2. 02L’assistant retrouve les comptes par leur numéro exact, prépare le test et le valide selon les mêmes règles que celles de l’API.
3. 03Vous examinez la proposition, c’est-à-dire exactement ce qui sera envoyé ou modifié, puis vous cliquez sur Confirm. Rien ne s’exécute avant.
4. 04Le résultat apparaît dans Call Records comme pour tout autre test, et l’assistant en explique l’issue.