To test a SIP trunk or VoIP route, place a set of test calls to real numbers in the destination, check that calls connect, that audio is clean both ways, that the caller ID arrives as promised and that billing starts only when the call is answered, then send a small share of live traffic before moving volume.
Agree the test before you start
A test is only useful if both sides know what is being measured. Before the first call, write down with the carrier:
- the destination and breakouts covered (for example mobile only, or a single operator), as listed in the rate deck;
- the CLI type promised (CLI, local CLI or non-CLI) and the codecs offered;
- the traffic type you will send, since a route built for conversational calls may block dialer traffic;
- the IPs, prefix (tech prefix) and number of channels and CPS allowed during the test;
- who pays for test minutes and how long the test window lasts.
Step 1: manual test calls
Start with 10 to 30 calls to numbers you control or to a test-call platform with numbers in the destination. Use a mix of operators if the route covers more than one. For each call, note:
- Connection: did it ring and connect, and what SIP response came back when it did not?
- Post-dial delay: the seconds between your INVITE and the first ringback. Long delays usually mean extra hops (see post-dial delay causes).
- Audio: speak in both directions for at least 30 seconds. Listen for echo, clipping, robotic voice and one-way audio.
- Caller ID: what number appeared on the handset, and in which format. The method is covered in how to check CLI delivery.
- Answer timing: compare when the phone was really picked up with the answer time (200 OK) in your logs.
Step 2: check for false answer and short calls
Call numbers that will not answer, numbers that are busy and numbers that are switched off. None of these calls should be billed. If your switch logs a 200 OK while the handset is still ringing, or a busy number returns an answered call with a recording, the route may be using false answer supervision. Also check that a call you hang up after 5 seconds is billed for 5 seconds under the agreed billing increment, not rounded up beyond it.
Step 3: a small share of live traffic
Manual calls show whether the route works; live traffic shows whether it works at scale. Send 5 to 10% of your traffic for the destination, or a fixed daily number of calls, for a few days. Compare the new route with your current one on the same metrics:
| Metric | What to compare |
|---|---|
| ASR and NER | Share of calls answered and share that completed at network level |
| ACD | Average call length; a sudden drop can mean dropped calls or poor audio |
| PDD | Average and worst case setup time |
| Short calls | Share of answered calls under a few seconds |
| Cost per minute | Billed minutes from the carrier against your own CDRs |
The metrics are defined in ASR, ACD, PDD and NER explained. Compare like with like: same hours, same number lists, same traffic type. A route can look worse simply because it received the hardest numbers.
Step 4: reconcile and decide
At the end of the test, match your CDRs with the carrier's invoice or usage report. Differences above 1 to 2% in billed minutes need an explanation. If quality holds and the numbers match, increase volume in steps rather than all at once, and keep monitoring as described in monitoring route quality with CDRs. Routes often change after the test period, so a route that tested well is not a route you can stop watching.
Common mistakes
- Testing with a handful of calls to the same number, which a grey route can easily handle well.
- Testing only at night, when routes are less congested.
- Sending a different traffic type in the test than in production.
- Not keeping the SIP traces of failed calls, which you will need if you raise a ticket.
VoIPMatcher sources wholesale VoIP termination from its carriers and manages the route between you and the supplier. If you need a route for a destination and want to test it with your own traffic, request a VoIP route.
Frequently asked questions
What is a VoIP test call?
A VoIP test call is a call placed through a new route to a number you control or to a test-call platform in the destination. It checks that the call connects, how long it takes to ring, whether audio works both ways, which caller ID arrives and whether billing starts only on answer. Several calls across operators are needed.
How do I test VoIP call quality?
Speak in both directions for at least 30 seconds on each test call and listen for echo, clipping, robotic voice and one-way audio. For figures, use RTCP reports from your switch for jitter and packet loss, test-call platforms that score audio end to end, and watch ACD and short calls once live traffic starts.
Is there a VoIP test number I can call?
Many carriers and test-call platforms provide numbers or handsets in destination countries for this purpose, and your own phones, colleagues or partners abroad also work. A single public echo number only tells you the trunk is up; it does not show how the route performs to real mobile and fixed numbers in the destination.
How many test calls are enough?
Start with 10 to 30 manual calls across the operators the route covers, spread over different hours, then send 5 to 10% of real traffic for a few days. A handful of calls to the same number proves little, because even a grey route can handle a few calls well before volume arrives.
Do carriers charge for test calls?
Some do and some give a small test credit; there is no standard. Agree before the first call who pays for test minutes, how long the test window lasts, which channels and CPS are allowed and which breakouts are covered, so both sides judge the result on the same terms.
Need a route?
Send the destination, route type and target rate. We reply with what we can deliver.