Phone Number Testing for Live Lines and Voice Agents

Phone number testing covers three separate jobs that share one name: confirming a number is well formed, confirming it reaches a live endpoint, and confirming that whatever answers behaves correctly. Most guides cover one of the three. This guide covers all three, and says which test numbers are safe to use and what a connected call actually proves.

What phone number testing actually means

One group of results for this term offers validation tools that parse a number and tell you the country and carrier. A second group offers numbers you can dial to hear a tone or an echo. A third group sells enterprise services that dial your toll free numbers from real devices in other countries. None of them is wrong. They are answering three different questions.

Those three questions are worth separating before you write a single test, because each one fails differently and each one needs a different check:

1. Format. Is this string a number at all, in a form the network and your code both accept?
2. Reachability. Does dialling it reach a live endpoint, from where your callers actually are?
3. Behaviour. Does the thing that answers do the right thing?

A test suite that only answers the first question passes on numbers that no longer connect. A suite that answers the first two passes on a line that connects to the wrong department. Most of the tooling you will find addresses the first question. The failures a caller notices live in the third.

Job one: is the number well formed?

Start with format, because it is cheap and because a format bug corrupts every test downstream.

The reference point is the international form. RFC 3966, which defines the tel URI, is direct about it: "Globally unique numbers are identified by the leading '+' character." The same section requires global numbers to be composed of the country code and the national number as specified in E.123 and E.164. It adds a rule worth adopting as a storage policy: "All phone numbers MUST use the global form unless they cannot be represented as such."

When a number cannot be represented that way, the specification does not let it float free. Local numbers, it says, "MUST have a 'phone-context' parameter that identifies the scope of their validity," so that the context plus the local number is globally unique again. A seven digit string in a database column with no country attached is not a phone number. It is a fragment, and it will pass your format test and fail in production.

The practical rule is to store and test in E.164 form, and to treat any number that cannot be canonicalised as a data defect rather than an edge case.

Valid is not the same as possible, and neither means reachable

The standard tool here is Google's libphonenumber, which distinguishes a number that is the right shape from a number in a range that carriers can actually assign. Its FAQ defines validity narrowly: "A valid number range is one from which numbers can be freely assigned by carriers to users."

That is a statement about the range, not about the number. The same FAQ closes the gap most test suites leave open, and the wording is unambiguous: "Do not rely on libphonenumber to determine whether numbers are currently assigned to a specific user and reachable." The library's own position is that answering that question needs a verification step, an SMS or an automated call, and that it "is not technically feasible without such a verification step given the complicated international world we live in, with varying standardization practices in different regions."

The trap: a call that connects does not prove the number is right

The library documents this explicitly. Asked whether a dialled number that connected must therefore be valid, the FAQ answers: "Not necessarily."

Two of its reasons matter for anyone writing tests. In some countries extra digits at the end of a number are ignored, so dialling 1800 MICROSOFT in the US connects to +1 (800) MIC-ROSO. And during a renumbering transition, when a region adds a digit, "some operators will 'fix' old numbers long after they're no longer working for the majority."

Read that second one again as a test result. Your call connects. Your assertion passes. A large share of real callers on other operators are already failing, and the suite reports green until someone complains. A connection is evidence, not proof, and a test that asserts only "the call connected" is weaker than it looks.

Job two: does the number reach anything?

Reachability cannot be checked by parsing; libphonenumber's FAQ is explicit that it needs a verification step. It needs a real attempt, and the attempt has to come from somewhere realistic.

Four variables decide whether that attempt reflects what your callers experience:

• Origin. A number that answers from your office may be unroutable from another country or another carrier. This is the main reason the enterprise number testing market exists: in-country test calls placed from the networks your callers actually use.
• Number type. Mobile, fixed line, and VoIP ranges route differently and carry different costs and restrictions, and libphonenumber exposes the type through getNumberType. Its FAQ is candid that the answer is not always available: where a country's mobile and fixed line ranges overlap, or are too granular to separate, accurate identification may be impossible, and it names Argentina and Mexico as those cases. Treat the type as a hint and let a real call settle it.
• Answer time. A number that connects after a long silence is failing from the caller's side even though the record says answered. Measure the gap between dialling and ringback, set a threshold on it, and alert when it moves. Our guide to post-dial delay covers where that silence comes from.
• Time. Numbers get reassigned, ported, and reclaimed. A reachability result has a shelf life, which is why this belongs in a scheduled monitor rather than in a one time launch checklist.

The honest summary is that reachability is a sampled measurement, not a property you can look up. You are estimating a rate from a set of attempts, and the value of the estimate depends entirely on whether the attempts resemble real calls.

Test numbers that are safe to use, and the ones that are not

Once you accept that testing means placing real attempts, the next question is what to dial. There are three categories with published, stable answers, and one that this guide deliberately does not list.

Provider sandbox numbers, for testing your code

If your telephony runs on a provider, the provider usually gives you numbers that exercise failure paths without touching the network. Twilio's test credentials work this way. Authenticating with them means, in Twilio's words, that Twilio "doesn't charge your account, update the state of your account, or connect to real phone numbers."

The magic values are fixed strings with defined outcomes. +15005550006 is "Phone number is valid and available," with no error. +15005550001 returns "Phone number is invalid" as error 21421 on a purchase attempt, and +15005550000 returns "Phone number is unavailable" as error 21422. On the voice side, +15005550002 stands in for a number Twilio "can't route to," and +15005550004 for a number "blocked for your account."

Know exactly what these prove. They prove your code handles a routing failure, a blocked number, and an invalid number without crashing or double charging. They prove nothing about audio, latency, or whether a call completes, because no call is placed. That is a useful boundary, not a shortcoming.

Reserved fictitious ranges, for fixtures and screenshots

The second category is numbers that are guaranteed never to belong to anyone. Ofcom publishes a set of ranges for drama use in the UK, including 020 7946 0000 to 020 7946 0999 for London, 07700 900000 to 900999 for mobile, and 08081 570000 to 570999 for freephone. For any area code not on its list, Ofcom points to 01632 960000 to 960999, which carries no area code at all.

Ofcom's reasoning is the same reason they suit a test fixture: "Telephone numbers recommended for drama purposes cannot be allocated to communications providers for their customers because of the potential influx of calls that customers might receive should their telephone numbers be shown in a drama." Using a number from these ranges, Ofcom notes, does not imply it has been allocated to anyone.

Use them in seed data, documentation, screenshots, and anywhere a realistic looking number might escape into a real dialler. They will pass a format check and reach nobody, which is precisely the behaviour you want from test data.

An echo test line you control

Carriers operate test lines that play a tone back, announce the calling number, or echo your audio, and that is what most people searching this term are looking for. The lists of them circulating online are carrier specific, undocumented outside the operator, and subject to change without notice, and several point at third party lines whose owners never volunteered them. A test that depends on somebody else's line is a test that will fail for reasons you cannot fix.

The better answer is to run one. Asterisk's Echo() dialplan application, in the project's own documentation, "Echos back any media or DTMF frames read from the calling channel back to itself," and exits when it detects a #. Point a spare extension at it, preceded by an answer step, and you have a loopback line whose uptime, codec, and route you own.

Dial that extension from the origins your callers use and one call gives you a reachability check and a two way audio check at once, with nobody else's line in the loop. For the numbers your own carrier operates, ask them directly rather than trusting a list.

Job three: does what answers actually work?

The first two jobs end the moment the call is answered. Everything that matters to a caller starts there.

This is where phone number testing stops being a telecoms task and becomes an application testing task. The checks that belong here are behavioural: does the call route to the intended queue or agent, do DTMF digits register, does the greeting play in full, does the caller ID arrive as configured, and does the system behave the same on the fiftieth concurrent call as on the first.

For a traditional IVR the answers are deterministic, so the tests can be scripted. An AI voice agent answers correctly in different words every time, so the assertion has to be on outcome and behaviour rather than on a string, and the failure modes that matter are talking over the caller, mishearing a digit, calling a tool with the wrong argument, or hanging up early. Our guide to telephony testing covers the layers underneath the agent, and how to test voice AI agents covers the behavioural layer in more depth.

Cekura tests this layer by placing real calls to the number under test and scoring the conversation that results, rather than asserting on a transcript string.

How phone number testing changes for AI voice agents

The reason to test the number rather than the agent in isolation is that a measurable share of calls fail for infrastructure reasons rather than agent reasons, and some never connect at all.

Cekura's voice AI benchmarks are a frozen matched study of eight voice agent configurations, each run against the same 82 caller scenarios with three retained repeats, for 246 calls per configuration. One of the metrics it publishes for each configuration is infrastructure reliability, defined as the share of calls that completed without a provider side or connection issue, with a call counting as clean only when the infrastructure evaluator scores it 5 out of 5.

The spread on that metric is wide. Two configurations, ElevenLabs and Telnyx, were infrastructure clean on every retained call at 100%. The lowest, Gemini Live, sat at 72.36%. On one configuration, 41 of its 246 calls did not connect at all, and those calls remain visible in the metric rather than being dropped from it. The methodology is explicit that "calls that did not connect or produced no transcript stay in the denominator."

Two caveats travel with those numbers and should travel with any quotation of them. Infrastructure reliability counts all 246 retained calls per configuration, while task completion counts only the calls that produced outcome evidence, so the two metrics do not sit on the same base and cannot be multiplied together. And the providers chose the configurations that were tested, against a shared brief, so these are results for specific stacks rather than verdicts on the platforms.

The lesson for testing generalises past any one leaderboard. If you evaluate an agent only on the calls that connected, you have measured the agent and thrown away the failure rate of everything in front of it. Cekura's benchmark keeps non connecting calls in the denominator for that reason, and any number you report about your own agent should say which base it uses.

A phone number testing checklist

Run these in order. Each step assumes the one above it passed, which is what makes a failure informative.

1. Canonicalise. Parse every number to E.164 and fail the build on anything that will not canonicalise.
2. Validate the range. Check the number sits in an assignable range, and record that this is a statement about the range, not the subscriber.
3. Exercise the error paths. Use your provider's sandbox numbers to confirm your code survives invalid, unroutable, and blocked numbers.
4. Place a real call. From the origins your callers actually use, not only from your office.
5. Assert on more than connection. Check answer time, audio in both directions, DTMF, and caller ID, because a connected call is not a working one.
6. Score the conversation. For an AI agent, evaluate what was said and done, not whether a string matched.
7. Re run on a schedule. Reachability decays. Treat it as a monitor, not a launch gate.

Steps 1 through 3 are free and fast. Step 4 onward costs real calls, which is the point at which teams usually automate. Cekura runs steps 4 through 7 as scheduled scenario suites against your live numbers, and scores infrastructure issues as a metric of their own rather than folding them into the task outcome. That metric flags when the agent fails to respond within a configured timeout, 10 seconds by default, after the caller finishes a turn, so a connectivity failure is not counted as a reasoning failure. If you would rather have this checklist running against your own numbers on a schedule than by hand, Cekura's team will set up the scenario suite for your line.

Frequently asked questions

What is phone number testing?

Phone number testing is the practice of confirming that a telephone number is correctly formatted, reaches a live endpoint from where callers dial, and connects to a system that behaves as intended. The three checks are independent, and a number can pass the first two while failing the third.

What number can I call to test my phone line?

Ask your carrier or telephony provider for their test line numbers, which typically include an echo test, a tone, and a number announcement. Public lists exist but point at carrier specific lines that change without notice and are often operated by third parties who did not publish them for general use. If you run Asterisk or a similar PBX, point a spare extension at its echo application and dial that instead: it is the one test line whose availability you control.

Is a valid phone number always reachable?

No. Validity describes the number range, not the individual number. Google's libphonenumber states directly that it should not be relied on to determine whether a number is currently assigned to a specific user and reachable, and that answering that needs a verification step such as an SMS or an automated call.

What is a good test phone number for a staging environment?

Use a reserved fictitious range so the number can never reach a real person. Ofcom reserves ranges for drama use in the UK, such as 020 7946 0000 to 020 7946 0999, and they are held back from allocation. For provider API testing, use your provider's documented sandbox values, such as Twilio's +15005550006.

How do you do phone line testing for an AI voice agent?

Place real calls to the live number and score the resulting conversation rather than asserting on exact wording. Cekura runs scenario suites as actual calls through the production path, so routing, carrier, and agent behaviour are tested together. When you report the results, keep the calls that never connected in the denominator, as Cekura's published benchmark does, so the connection failure rate stays visible.

Why did my test pass when callers report failures?

The most common cause is that the test asserted only that the call connected. A connection can succeed while the number is wrong, because some countries ignore extra trailing digits, and during a renumbering transition some operators keep old numbers working after they have stopped working for most callers.