Why Voice AI Load Tests Must Follow the Real Call Path

If your contact center platform answers every call first and then transfers callers to a voice AI agent, a load test that dials the AI directly tells you very little. It proves the AI can take a lot of calls. It does not prove that your carrier, your call-control platform, the transfer into the agent, and the transfer back out all hold up at peak volume. Most failures in this kind of deployment happen at the joins between systems, and the joins only carry traffic when calls follow the production route.

For the general method (ramping concurrency, latency percentiles, regression suites), see our guide to voice agent load testing. This article covers deployments where a UCaaS or CCaaS platform holds call control.

Why doesn't a direct SIP or API load test prove the deployment works?

Because it skips every hop your callers pass through. A direct test sends calls straight to the AI provider's SIP endpoint or API. A production call takes a longer route: it arrives from the carrier, lands on your contact center or UCaaS platform, runs through your IVR or routing logic, gets blind-transferred to the voice AI entry point, and then either ends there or gets transferred back to a human queue.

Each hop has its own capacity limit, SIP behavior, and configuration owner. A direct test exercises none of them. Three examples from Retell's documentation:

• Capacity is set in more than one place. Retell's concurrency limit applies per workspace (Pay-As-You-Go workspaces start at 20 concurrent calls). Retell's Five9 guide notes that Five9 applies its own trunk capacity limits, and its Avaya guide says to confirm the administered SIP trunk count covers your expected concurrent calls. A test that bypasses the platform never touches its limit.
• The connection method changes what the AI can do. Retell supports elastic SIP trunking (the recommended method) and dialing a SIP URI. With the SIP URI method, Retell's built-in transfer feature is not available, so transfers and hang-ups have to be handled by your own logic. A direct test would never show that gap.
• Transfers depend on the far side. Retell's cold transfer uses SIP INVITE by default, or SIP REFER if your telephony provider supports it. Whether REFER works, and whether custom headers survive it, depends on your provider, not on the AI.

What does the real call path look like when a contact center platform holds call control?

It is a chain of five hops, and every test call should pass through all five.

Two details from Retell's docs matter here. With the SIP URI method, each call needs a Register Phone Call request first, and the call must reach that URI within 5 minutes or it ends with registered_call_timeout, so your registration service has to keep up under load too. On the exit side, Retell's Genesys Cloud guide notes that calls Genesys transfers onward pick a trunk from the Site's number plans and outbound routes: platform configuration a direct test never reaches.

Where do path-only failures show up at peak volume?

Where two systems meet, usually once one of them starts queueing. Watch these during the ramp:

1. The tightest capacity limit wins. If your platform's trunk allows fewer simultaneous calls than your AI workspace, callers stall in the platform, and the AI dashboard looks healthy. Size the carrier, the platform trunk, and the AI concurrency limit together.
2. Inbound queueing at the AI. When inbound calls hit Retell's concurrency limit, Retell holds new calls for about 40 seconds. If no slot opens, it transfers the caller to a configured fallback_number, or ends the call with concurrency_limit_reached if none is set. Decide in advance where that fallback should go (often back into your platform's human queue) and test that it works under load.
3. Outbound traffic crowding out inbound. All voice calls in a workspace share one concurrency pool. If the same workspace also runs outbound campaigns, reserved inbound concurrency can hold slots for transferred-in calls.
4. Call setup rate. Retell sets calls per second per telephony path, and its docs note that Custom Telephony CPS scales with your concurrency. A burst of transfers at the top of the hour can hit a rate limit before it hits a concurrency limit.
5. Network and media settings. Retell publishes several IP blocks to allowlist (some apply only to certain US traffic), its transports (TCP recommended, UDP, TLS, mTLS), and its codecs (PCMU, PCMA, G.722). An allowlist that covers only some of those blocks can pass a small test and fail at volume.
6. Mid-call SIP changes. Platforms can send re-INVITEs to refresh a session, move media, or hold a call. Retell answers in-dialog re-INVITEs for session refreshes, media re-anchoring, codec changes, SRTP re-keys, and hold or unhold; confirm your platform's re-INVITEs behave the same way at volume.

How do you generate test traffic through the real path?

Originate test calls outside your network and dial the same public numbers your callers use. That is the only way every hop carries load.

• Pick a call generator that dials your public number. Retell's batch calling places outbound calls from Retell, and Retell's simulation testing runs text-based conversations, so neither one reproduces an inbound call that your platform transfers in. Some testing partners place real calls; Hamming, for example, describes its voice agents calling yours. Ask any test vendor whether its calls enter over the public phone network or connect straight to the agent.
• Tag every test call. Have your platform add a custom X- SIP header (a test run ID, for example) on the transfer. Retell extracts inbound X- headers into the call's custom_sip_headers field and into dynamic variables, so you can tie each AI call back to the platform's record.
• Ramp in steps. Start below your expected peak, step up past it, then let traffic drop and confirm the system returns to idle.
• Book every owner. Carrier, platform admin, and voice AI vendor should all join. Retell's Five9 guide runs the final integration test as a joint session.
• Raise limits before the test, not during it. Check your AI concurrency and CPS limits on the Limits page (the built-in calculator suggests values from your busy-hour traffic) and confirm the platform's trunk capacity matches.

Which SIP signals should you watch during the test?

Watch every call's signaling from first INVITE to final BYE, on both sides of the transfer. Retell's call details can include a Packet Capture tab with the call's SIP signaling, and its PCAP debugging guide walks through reading it in Wireshark. If you run your own trunk, Retell's docs recommend capturing on the server or gateway that terminates SIP, which is usually your SBC.

Look for:

• A clean setup on the transfer leg: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK.
• Error responses: 403 (allowlist or permission), 404 (wrong SIP URI or routing), 408 or 477 (unreachable endpoint or transport error), 486 (busy), 503 (service unavailable).
• The transfer back out: a REFER or a new INVITE, depending on the transfer method, and whether your X- headers survived. Retell's docs warn that custom headers can be stripped when a transfer goes to a PSTN number instead of a SIP endpoint.
• Who sent the BYE, and when: every call should end with a BYE from the party you expect.

Retell's webhook events (call_started, call_ended, and the transfer_* events) give you a per-call timeline to line up against the captures.

What should count as a pass?

A pass means the numbers reconcile across every system, not just that the AI stayed up. Use this checklist:

• Call counts match across carrier records, platform reports, and the AI call log for the test window.
• Every AI call ended with an expected disconnection reason (user_hangup, agent_hangup, call_transfer), and there were no concurrency_limit_reached or error_* reasons.
• Every transfer back to a human reached the right queue, with the expected caller ID and headers.
• No SIP 4xx or 5xx responses on the transfer legs, other than ones you triggered on purpose.
• Audio flowed in both directions on sampled calls.
• Peak concurrency stayed under every limit in the chain, with headroom.
• After traffic stopped, concurrency returned to zero on the AI side and the platform showed no lingering sessions.

That last check deserves its own test plan, since calls that never fully close after a transfer can eat concurrency at peak. We cover call closure in a separate guide.

What should you ask your voice AI vendor before the test?

Ask questions that make the vendor show the path, not just the AI:

1. Which connection method do you recommend for our platform, and what does it change about transfers and hang-ups?
2. Which SIP transfer methods do you support (INVITE, REFER), and what does each require from our platform?
3. How do we pass and read custom SIP headers in both directions?
4. Where are your concurrency and calls-per-second limits set, what happens to the call at the limit, and can we raise them for the test?
5. Can we see per-call SIP signaling and disconnection reasons, and will your telephony team review captures with us?

Retell's docs include setup guides for Genesys Cloud, Five9, Avaya, and Amazon Connect, a general custom telephony guide, and a concurrency guide covering each limit. For transfers out of the agent, see call transfer and how AI-to-human handoffs work.

If your platform owns call control and you need a voice AI agent that fits behind it, see Retell's enterprise conversational AI platform and talk to the team about planning a load test on your real call path.

Related reading: The call closure load test, the CRM-to-voice AI workflow, and more guides in the Retell Learn hub.