Five teams, five different reasons to test a voice network.

You carry traffic across a dozen peering partners. One of them insists their side is clean; your customers say otherwise. Neither of you can see the other half of the call.

Post-mortem debugging from CDRs alone cannot separate a codec renegotiation from a transcoding artefact from genuine packet loss. By the time a pcap is captured by hand, the condition has usually cleared.

1. 01Run a scheduled campaign against every peering route, continuously, from an agent node on your own network.
2. 02Judge each call on answer, PDD and whether audio flowed in both directions, with per-code verdict policies so a 486 on a busy-tone test counts as success and a 404 does not.
3. 03When a route degrades, the SIP ladder and packet capture for the exact failing call are already there.

A new SBC, a new carrier, or a UCaaS cutover. The configuration looks right and a handful of manual test calls succeed.

Manual tests exercise the happy path from one handset. They do not exercise the second codec in the offer, the re-INVITE on hold, the PRACK the new SBC now requires, or what happens at 200 concurrent calls instead of two.

1. 01Place functional calls from the Test Console and read the full SIP ladder — every transaction, with timings, including the auth challenge and re-INVITE.
2. 02Drive a load run at the concurrency the site actually reaches, ramping calls per second, and watch the failure point rather than guessing it.
3. 03Keep a scheduled campaign running through the cutover window so a regression announces itself.

You build a PBX, an SBC, a gateway or a softphone. Each release has to keep working with the codecs, transports and call flows your customers already depend on.

Regression by hand, or with scripts only one engineer understands, covers the flows somebody remembered to dial. The second codec over TLS, or the response to a header that is not well-formed, tends to be the part that goes untested.

1. 01Describe the call tests as a YAML suite with a codec and transport matrix, and keep it in version control next to the product.
2. 02Run the suite from CI on every build and gate the release on the JUnit result, the way a unit test would.
3. 03Use the Signalling Lab for the negative cases: hand-written and deliberately malformed SIP, to see how the new build answers it.

Audio quality on outbound calls is fine most of the day. Complaints cluster in the afternoon, and nobody can reproduce them.

Intermittent degradation is invisible to monitoring that only watches whether the trunk is up. A call can complete with a 200 OK and still be unusable — jitter that arrives in bursts, audio in one direction only, a codec that fell back to something narrowband.

1. 01Run synthetic calls on a schedule across the routes that matter, around the clock, each one checked for two-way audio and the negotiated codec as well as for an answer.
2. 02When complaints cluster on a route, run a voice-quality test on it: known audio is sent and what arrives is compared with it, so damage shows even when the packet statistics look clean.
3. 03Use the jitter histogram and per-frame drill-down to tell burst loss apart from a steady impairment.

You manage voice for a portfolio of clients. Each wants to know their network is healthy, and each asks in a different format.

Reporting is assembled by hand from separate tools, which is slow enough that it happens monthly at best — and monthly reporting is a summary of problems your client already lived through.

1. 01Isolate each client as their own tenant, with their own accounts, agent nodes and teams.
2. 02Build a report once from call records, SLA results and load runs, then schedule it to send itself.
3. 03Drive the whole thing from the API where a client wants it in their own tooling, with JUnit output for the ones running CI.

A scheduled test failed overnight. The engineer on call has a call record, a response code and a customer waiting, and reading the SIP ladder, the SDP and the media results takes time they do not have.

A response code names a symptom, not a cause. The same 488 can be a codec mismatch, an SRTP offer the far end refuses or a policy on the SBC, and the evidence is spread over several screens.

1. 01Press Ask AI on the call record, or ask the assistant why the call failed.
2. 02The assistant reads the call, its SIP ladder and its media results from VoiceLab’s own records, and explains the response in the context of that call.
3. 03Every claim is marked Observed, Likely or Unknown, so what the data shows stays separate from what the assistant suspects.
4. 04Ask it to compare the two accounts involved, or to investigate the SLA incident against the same hours of the previous week.

A new trunk needs the same checks as the others: register an account, call a number over a given codec, confirm the audio, and repeat it every night.

Each of those is a form with a dozen fields across several pages, and a typo in a codec name or a number costs a failed run and a confusing result.

1. 01Describe it: “call 6002 from 6001 over PCMA and check the audio”.
2. 02The assistant finds the accounts by exact number, drafts the test and checks it against the same rules the API applies.
3. 03You review the proposal, exactly what will be sent or changed, and press Confirm. Nothing runs before that.
4. 04The result lands in Call Records like any other test, and the assistant explains the outcome.