Vijf teams, vijf verschillende redenen om een spraaknetwerk te testen.

U voert verkeer af via een dozijn peeringpartners. Eén van hen houdt vol dat hun kant in orde is; uw klanten zeggen van niet. Geen van beiden kan de andere helft van het gesprek zien.

Post-mortem debugging op basis van alleen CDR’s kan een codec-hernegotiatie niet onderscheiden van een transcoding-artefact of echte packet loss. Tegen de tijd dat een pcap handmatig is vastgelegd, is de storing meestal al verdwenen.

1. 01Voer continu een geplande campagne uit tegen elke peeringroute, vanaf een agent node op uw eigen netwerk.
2. 02Beoordeel elk gesprek op beantwoording, PDD en of er audio in beide richtingen liep, met oordeelbeleid per responscode, zodat een 486 bij een busy-tone-test als geslaagd telt en een 404 niet.
3. 03Wanneer een route verslechtert, zijn de SIP ladder en de capture van precies het mislukte gesprek al beschikbaar.

Een nieuwe SBC, een nieuwe carrier of een UCaaS-cutover. De configuratie ziet er goed uit en een handvol handmatige testgesprekken slaagt.

Handmatige tests oefenen het happy path uit vanaf één toestel. Ze oefenen niet de tweede codec in het aanbod, de re-INVITE bij hold, de PRACK die de nieuwe SBC nu vereist, of wat er gebeurt bij 200 gelijktijdige gesprekken in plaats van twee.

1. 01Plaats functionele gesprekken vanuit de Test Console en lees de volledige SIP ladder — elke transactie, met timings, inclusief de auth-challenge en re-INVITE.
2. 02Draai een load-run op de gelijktijdigheid die de locatie daadwerkelijk bereikt, met oplopend aantal gesprekken per seconde, en bekijk het breekpunt in plaats van het te raden.
3. 03Laat een geplande campagne doorlopen tijdens het cutover-venster, zodat een regressie zichzelf meldt.

U bouwt een PBX, een SBC, een gateway of een softphone. Elke release moet blijven werken met de codecs, transporten en call flows waarvan uw klanten al afhankelijk zijn.

Regressietests met de hand, of met scripts die maar één engineer begrijpt, dekken de flows die iemand zich herinnerde te bellen. De tweede codec over TLS, of het antwoord op een header die niet goed gevormd is, blijft meestal onbeproefd.

1. 01Beschrijf de gesprekstests als een YAML-suite met een codec- en transportmatrix, en bewaar die in versiebeheer naast het product.
2. 02Draai de suite vanuit CI bij elke build en maak de release afhankelijk van het JUnit-resultaat, zoals bij een unit test.
3. 03Gebruik de Signalling Lab voor de negatieve gevallen: met de hand geschreven en opzettelijk misvormde SIP, om te zien hoe de nieuwe build erop antwoordt.

De audiokwaliteit van uitgaande gesprekken is het grootste deel van de dag prima. Klachten concentreren zich in de middag en niemand kan ze reproduceren.

Onregelmatige degradatie is onzichtbaar voor monitoring die alleen kijkt of de trunk bereikbaar is. Een gesprek kan met een 200 OK worden afgerond en toch onbruikbaar zijn — jitter die in pieken optreedt, audio in slechts één richting, een codec die is teruggevallen op iets smalbandigs.

1. 01Voer volgens een schema synthetische gesprekken uit over de routes die ertoe doen, de klok rond, en controleer elk gesprek op tweerichtingsaudio en de onderhandelde codec, naast de beantwoording.
2. 02Als klachten zich op een route concentreren, voer dan een spraakkwaliteitstest uit: bekende audio wordt verstuurd en wat aankomt wordt ermee vergeleken, zodat schade zichtbaar wordt, ook als de pakketstatistieken er schoon uitzien.
3. 03Gebruik het jitter-histogram en de drill-down per frame om burst loss te onderscheiden van een constante verstoring.

U beheert spraak voor een portfolio van klanten. Elk wil weten of het netwerk gezond is, en elk vraagt dat in een ander formaat.

Rapportage wordt met de hand samengesteld uit losse tools, en is daardoor hooguit maandelijks haalbaar — en maandelijkse rapportage is een samenvatting van problemen die uw klant al heeft meegemaakt.

1. 01Isoleer elke klant als eigen tenant, met eigen accounts, agent nodes en teams.
2. 02Bouw een rapport één keer op basis van gespreksrecords, SLA-resultaten en load-runs, en plan het in zodat het zichzelf verstuurt.
3. 03Stuur het geheel aan via de API als een klant het in zijn eigen tooling wil, met JUnit-uitvoer voor wie CI draait.

Een geplande test is vannacht mislukt. De engineer met bereikbaarheidsdienst heeft een gespreksrecord, een responscode en een wachtende klant, en het lezen van de SIP ladder, de SDP en de mediaresultaten kost tijd die hij niet heeft.

Een responscode benoemt een symptoom, geen oorzaak. Dezelfde 488 kan een codec-mismatch zijn, een SRTP-aanbod dat de andere kant weigert, of een beleidsregel op de SBC, en het bewijs is verspreid over meerdere schermen.

1. 01Druk op Ask AI bij het gespreksrecord, of vraag de assistent waarom het gesprek mislukte.
2. 02De assistent leest het gesprek, de SIP ladder en de mediaresultaten uit de eigen records van VoiceLab en legt de respons uit in de context van dat gesprek.
3. 03Elke bewering is gemarkeerd als Observed, Likely of Unknown, zodat wat de data laten zien gescheiden blijft van wat de assistent vermoedt.
4. 04Vraag hem de twee betrokken accounts te vergelijken, of het SLA-incident te onderzoeken tegen dezelfde uren van de vorige week.

Een nieuwe trunk heeft dezelfde controles nodig als de andere: een account registreren, een nummer bellen met een bepaalde codec, de audio bevestigen en dat elke nacht herhalen.

Elk daarvan is een formulier met een dozijn velden over meerdere pagina’s, en een typefout in een codecnaam of nummer kost een mislukte run en een verwarrend resultaat.

1. 01Beschrijf het: “bel 6002 vanaf 6001 via PCMA en controleer de audio”.
2. 02De assistent vindt de accounts op exact nummer, stelt de test op en controleert hem tegen dezelfde regels die de API toepast.
3. 03U bekijkt het voorstel, precies wat er wordt verstuurd of gewijzigd, en drukt op Confirm. Daarvoor draait er niets.
4. 04Het resultaat verschijnt in Call Records zoals elke andere test, en de assistent legt de uitkomst uit.