Your voice agent passed every test in the browser. Then a customer called from a parking garage, and it fell apart. Telephony testing is how you catch that gap before the customer does, by checking how your agent behaves on a real phone call rather than a clean WebRTC demo.
TL;DR: Telephony Testing
- The gap: Your voice agent works in a browser demo over wideband WebRTC. Real callers connect over narrowband PSTN from cars, parking garages, and noisy rooms. Telephony testing checks how the agent holds up on that real phone line.
- Method 1: Call simulation: Place automated inbound and outbound calls over a live carrier using scripted personas and multi-turn scenarios.
- Method 2: Audio and codec testing: Test on the 8 kHz narrowband codec your callers actually use rather than the wideband audio from your demo environment.
- Method 3: Latency and turn timing: Measure the full round trip from caller speech to agent reply against the ITU-T G.114 end-to-end ceiling, which your transport and pipeline time must share.
- Method 4: DTMF and IVR: Inject keypad sequences for PINs, account numbers, and transfers, then confirm the agent routed them correctly.
- Method 5: Load and production monitoring: Ramp concurrent calls to find where latency and error rates break, then score live calls continuously after launch.
- Where to start: Call simulation if you're pre-launch. Audio testing if callers connect from noisy or mobile environments. Latency testing if agents are talking over callers.
- Automate it: Cekura runs all five methods over your telephony provider before launch and monitors live calls after, with native integrations for Retell, VAPI, LiveKit, Pipecat, and more.
What Is Telephony Testing?
Telephony testing is the practice of verifying that phone calls connect, stay clear, and let your agent finish its task across real phone networks and protocols like the PSTN and SIP.
It covers the signaling that sets up a call, the audio that travels through it, the keypad input that steers it, and the behavior of whatever answers on the other end.
For years, "whatever" was an IVR menu or a human agent. Now it is an AI voice agent. The phone line did not get simpler, your agent just inherited every quirk of it.
Where Telephony Sits in the Voice AI Stack
A voice agent runs on five layers. The stack moves from speech-to-text to an LLM, then text-to-speech, a telephony provider, and an orchestration platform or framework. The telephony provider is the layer that connects your agent to the outside world through a carrier.
It is also the layer demos skip. A browser demo runs over wideband WebRTC at 16 kHz, in a quiet room, with near-zero network distance.
A real call, however, runs over a carrier, through a narrowband codec, with a stranger in a moving car. It's the same agent, but a completely different set of circumstances.
How Telephony Testing Changed for AI Agents
Classic telephony testing checked scripted paths. Press 1 for sales, press 2 for billing, and confirm the call routed correctly. The agent followed a tree, so the test followed the same tree.
An AI agent has no tree. It improvises a reply to whatever the caller says, which means the failure modes multiply.
Instead of testing a fixed menu, you are testing an open conversation that happens to ride on a phone line, with all the timing and audio constraints that line imposes.
What Telephony Testing Checks
A phone call passes through seven checkpoints before your agent earns a happy customer. Each one breaks in its own way, and each break leaves a different fingerprint.
| Layer | What you test | Failure mode |
|---|---|---|
| Signaling and connectivity | Call setup, SIP registration, inbound, and outbound routing | Calls fail to connect or drop on pickup |
| Audio quality | Codec, jitter, packet loss, MOS | Garbled speech, the agent mishears digits |
| Latency and turn timing | One-way delay, response lag, interruptions | The agent talks over the caller or leaves dead air |
| DTMF and IVR | Keypad input, menu navigation | Wrong branch, PIN entry ignored |
| Call control | Transfers, hold, voicemail detection | The caller dropped during a handoff |
| Concurrency and load | Simultaneous calls, carrier limits | Slowdowns or failures at peak volume |
| Security | Adversarial callers, data extraction, jailbreaks, prompt injection | The agent leaks info or breaks its rules |
Telephony Testing Methods
Five methods take you from a single manual call to thousands running in parallel. Each one catches a category of failure that the others miss.
Most teams start with manual call-throughs and stall there. You can dial your agent, run a few scripts, and ship.
At any real volume, you review 1% to 2% of live calls by hand, so 99 out of 100 failures reach a customer before you do. The methods that follow replace that ceiling with automation.
1. Automated Call Simulation Over Real Numbers
What it is: Placing programmatic inbound and outbound calls to your agent over a live carrier, using scripted personas and multi-turn scenarios.
How it works: A test runner dials your agent through a telephony API, plays synthesized speech, records the response, and scores the transcript against expected behavior.
You bring your own Twilio or Plivo numbers, or point the runner at a SIP-based agent, and the calls travel the same path your customers use.
Real example: A healthcare receptionist who booked appointments cleanly in staging started losing callers in production. Automated calls over a real number found the cause. The agent handled the WebRTC test audio fine and choked on the carrier's narrowband audio.
2. Audio-Quality and Codec Testing
What it is: Measuring how the call's audio path affects what your agent hears, with attention to the codec, jitter, and packet loss.
How it works: PSTN calls ride on a narrowband G.711 codec that samples at 8 kHz and passes only 300 to 3400 Hz.
Your wideband demo captured detail that this codec throws away. Narrowband PSTN audio is well documented to lower speech-recognition accuracy, especially on digit strings like account IDs and PINs.
Test on the band your callers use, then read our voice quality testing and VoIP testing guides for the perceptual and network layers underneath.
Real example: An agent confirmed "1-5-1-3" as "1-9-1-3" once the call dropped to narrowband. Clean audio hid it, but the phone line exposed it on the first digit-heavy call.
3. Latency and Turn-Timing Testing
What it is: Measuring the delay between caller speech and agent reply, plus how the agent handles interruptions and pauses.
How it works: The ITU-T G.114 recommendation puts the preferred ceiling for one-way, mouth-to-ear delay at 150 ms, which is a budget your network transport and your STT, LLM, and TTS processing all have to share. Between 150 and 400 ms, quality degrades, and past 400 ms, a conversation falls apart.
Your speech-to-text, LLM, and text-to-speech time draws from that same mouth-to-ear budget, so the agent's "thinking" eats into a window the network has already spent.
Get this wrong, and the agent talks over the caller or sits in silence long enough to be read as a dropped call. Our guide to endpointing covers the signals that decide when the agent should speak.
Real example: A debt-collection agent averaged an acceptable 600 ms reply in the lab. Over a mobile carrier, though, transport added 200 ms each way, and the agent began stepping on callers mid-sentence.
4. DTMF and IVR Navigation Testing
What it is: Testing keypad input, menu navigation, and any flow that asks the caller to press a button.
How it works: DTMF is the tone a phone sends when you press a key. Your agent has to send it, receive it, or both, depending on whether it navigates a menu or collects a number.
You test this by injecting digit sequences at the right moment, then confirming the agent routed or recorded them correctly. Account numbers, PINs, transfer-to-human requests, and star codes all run through DTMF.
Real example: An agent asked a caller to enter a 9-digit member ID. It captured the speech fine and ignored the keypad tones, so every caller who typed instead of speaking hit a dead end.
5. Load, Concurrency, and Production Monitoring
What it is: Testing how the agent holds up under many simultaneous calls, then watching live traffic once it launches.
How it works: Carrier limits and infrastructure bottlenecks stay hidden until concurrent calls hit them. You ramp from a baseline toward a peak in steps, watching where latency and error rates climb.
After launch, you score live calls continuously and feed the failures back into your suite. Our outbound voice AI QA guide covers campaign-scale volume, and conversation monitoring metrics cover what to watch once you go live.
Real example: An agent that handled 5 test calls cleanly degraded badly at 25 concurrent calls, when a provider rate limit started queuing responses, and latency tripled.
Which Telephony Tests to Run First
You do not need all five on day one. Where you start depends on your stack and your biggest blind spot right now.
| If this describes you | Start here |
|---|---|
| Preparing a first launch with no automated coverage history | Call simulation |
| Agent runs over the PSTN; callers connect from cars, mobile networks, or noisy rooms | Audio and codec testing |
| Callers report the agent interrupting them or going quiet at the wrong moment | Latency testing |
| Your flow asks callers to enter account numbers, PINs, or menu selections | DTMF testing |
| A product launch or seasonal peak is about to raise your concurrent call volume | Load testing |
Telephony Testing Tools
Telephony testing tools fall into three categories. Picking the wrong one leaves a layer of the call untested.
Network and QoS VoIP Testers
These tools measure the network path. They report jitter, packet loss, MOS, and round-trip delay, which matters because callers' communications break down near 250 ms of one-way latency. They tell you the line is healthy, but they say nothing about whether your AI agent understood the caller.
Legacy IVR and Load-Test Harnesses
These tools place calls and drive scripted menus at volume. They were built for fixed IVR trees, so they shine at "press 1, expect billing." An open-ended AI conversation has no script for them to follow, which leaves the behavior of the agent itself outside their reach.
AI Voice Agent Testing Platforms
These tools place real calls, hold a multi-turn conversation, and score the agent's behavior across audio, timing, DTMF, and intent. Cekura belongs in this category, as it runs simulated calls over your telephony provider before launch and monitors live calls after.
It covers the network layer, the QoS tools watch, and the conversation layer that the legacy harnesses cannot reach.
Telephony Testing Best Practices
Seven practices separate a suite that catches real failures from one that hands you false confidence.
- Test on the codec your callers will use. Run audio checks over an 8 kHz narrowband leg, since that is what the PSTN delivers. A suite that only runs on a wideband browser audio hides your worst transcription errors.
- Budget latency end-to-end. Measure the full round trip, from caller speech to agent reply, against the 150 ms end-to-end ceiling, which your transport and STT/LLM/TTS time must share.
- Cover DTMF and transfers as first-class flows. Keypad entry and human handoffs fail silently, so script them with the same care you give the happy path.
- Ramp concurrency from a baseline. Climb from normal load toward peak in steps, and watch where latency and error rates break.
- Turn every dropped call into a regression test. Feed live failures back into your suite so the same break cannot ship twice. Our CI/CD pipeline guide shows how to wire this into every release.
- Keep evaluation off the agent's own stack. Score calls on a separate infrastructure, so a telephony outage cannot hide itself.
- Red team over the phone line. Adversarial callers behave differently on audio than in chat. Attack success climbs from 19.5% at two turns to 92.7% at eight turns, so probe jailbreaks and data extraction across a full multi-turn call, not a single prompt.
How Cekura Makes Telephony Testing Easier
Running all five methods by hand takes more engineering time than most launch deadlines allow.
Cekura sits on top of your existing stack and handles the testing infrastructure, so your team scores the phone line instead of building the harness for it. It serves 100+ voice and chat AI teams with a 16-person engineering team behind the product.
Pre-production:
- Automated inbound and outbound calls: Bring your own Twilio or Plivo numbers, or test SIP-based agents directly, then run scripted scenarios over a live line.
- DTMF and IVR navigation: Send keypad sequences with a structured tag for account numbers, PINs, transfers, and star codes, then confirm the agent routed correctly.
Infrastructure:
- Infrastructure Suite: Add 18+ pre-built scenarios covering latency, packet loss, interruptions, and hold handling across LiveKit, Pipecat, VAPI, Retell, and custom stacks.
- Load testing: Drive concurrent calls to find the volume where latency and error rates start to climb.
Observability:
- Production monitoring: Score every live call on latency, interruptions, and task completion, with alerts when quality drops.
Native integrations work out of the box for Retell, VAPI, ElevenLabs, LiveKit, Pipecat, Bland, and more. You don't rebuild anything. You add a testing and monitoring layer on top of what you already have.
It's SOC 2-, HIPAA-, and GDPR-compliant for transcript redaction, role-based access, and audit trails.
Book a demo to see how Cekura tests your agent over a real phone line before your customers call.
Frequently Asked Questions
What is telephony testing?
Telephony testing is the practice of checking that phone calls connect, stay clear, and let your voice agent finish its task across real networks and protocols like the PSTN and SIP. It covers signaling, audio quality, latency, DTMF, call transfers, and behavior under concurrent load.
What is the difference between telephony testing and VoIP testing?
The main difference between telephony testing and VoIP testing is scope. VoIP testing focuses on network call quality, such as jitter, packet loss, and MOS.
Telephony testing includes the audio layer and adds signaling, DTMF, and IVR navigation, call control, and how your AI agent behaves on the line.
How do you test an AI voice agent over the phone?
You test an AI voice agent over the phone by placing automated calls to a real number, then scoring the recording and transcript against expected behavior.
Cover narrowband audio, interruptions, DTMF entry, and transfers, then run the same scenarios at concurrent volume before launch. Platforms like Cekura place the calls and score them for you.
Can telephony testing be automated?
Yes, telephony testing can be automated by using a telephony API or platform to place programmatic calls, inject DTMF, transcribe the response, and assert against expected results. Automated runs replace slow manual call-throughs and cover hundreds of scenarios on every release.