Route testing methods: test calls, passive monitoring and recording review

Every route you buy is a promise: this vendor will connect calls to that destination with a certain quality, caller-ID behaviour and price. Route testing is how you check the promise before you depend on it, and keep checking afterwards. This lesson compares the three main approaches — test calls, passive monitoring and recording review — and shows how to combine them into a routine.

Why test at all?

• A new vendor’s route is unknown until it carries real calls.
• Routes change silently: a vendor may move your traffic to a different path without notice.
• Problems such as false answering or CLI replacement are invisible in basic CDR totals.
• Evidence from testing makes disputes and quality discussions faster.

Method 1 – Test calls

A test call is a call you place deliberately through a specific route to a number whose behaviour you know.

What test calls are good for

• Checking a route that has no live traffic yet.
• Verifying caller ID delivery on CLI routes.
• Confirming that ringback is real and the call is answered only when someone picks up.
• Checking audio in both directions and DTMF tones.

Types of test destination

• Handsets you control in the destination country: the most reliable way to check CLI and answer behaviour.
• Known announcement or IVR numbers: useful for audio checks.
• Numbers that should not answer (for example, unallocated numbers): if the route “answers” them, that is a strong FAS signal.

Keep test calls under control

Test calls cost money and can look like suspicious traffic to the destination network. Good practice:

• Let an operator start tests deliberately rather than dialling automatically around the clock.
• Cap the number of calls per test run.
• Use a dedicated test account so costs are visible and separated from customer traffic.
• Record each test: route, time, number dialled (masked in reports), result and evidence.

Method 2 – Passive monitoring

Passive monitoring observes the real calls your customers already send. Nothing extra is dialled, so it costs nothing per call and reflects exactly what customers experience.

What passive monitoring gives you

• Live ASR, ACD, PDD, packet loss and MOS per route and destination (see Lesson 6).
• Per-call analysis for FAS signs and CLI changes.
• Trends and alerts when a route changes behaviour.

Limits

• It only works on routes that carry traffic. New or backup routes still need test calls.
• It cannot tell what the recipient’s phone displayed; for CLI, combine with handset tests.
• It must be designed carefully so that it does not load the softswitch; heavy processing belongs on a separate server.

Method 3 – Recording review

Listening to calls (or analysing their audio automatically) answers questions that numbers cannot: was there a real person, was there ringback after answer, was the audio one-way or choppy?

• Record a sample of calls on routes under investigation rather than everything, to limit storage and privacy exposure.
• Make sure recordings can be decoded for the codecs you use, such as G.711 and G.729.
• Follow the legal requirements for call recording in the countries involved, and restrict who can listen.
• Delete recordings according to a defined retention period.

Comparing the methods

A practical testing routine

1. Before go-live: a small set of operator-run test calls per new route and destination: answer behaviour, audio both ways, CLI.
2. First days of traffic: flag the route as new and watch its live KPIs and FAS verdicts closely.
3. Ongoing: give every route carrying traffic a status such as PASS, WATCH or FAIL based on its KPIs and FAS results.
4. On alerts: review recordings and SIP traces for example calls, then run targeted test calls if needed.
5. Periodically: re-test backup routes that rarely carry traffic, so they work when you need them.

VoxInspector follows this model: passive live monitoring, automatic PASS / WATCH / FAIL cards for routes with traffic, and operator-controlled manual test calls capped per click.

Examples in this course use invented names (Vendor X, Customer Y, Country Z) and documentation IP ranges. Menu names and options differ between softswitch versions; always check your own system and vendor documentation.