Post-Dial Delay in Voice AI: The Latency Nobody Measures

Post dial delay is the wait between a caller finishing dialing and hearing anything at all, and it is the most common reason a voice agent that traces fast still feels slow to the person on the phone, because the wait ends before your first metric starts.

Your agent responds well inside two seconds. You have the traces to prove it. Your callers still say it drags.

The wait happens before the call connects, which means it happens before every metric in your observability stack starts counting. Your dashboards are honest. They are just measuring a window that opens too late.

The short version:

• Post dial delay is the interval from the last dialed digit to the first ringback, measured in SIP as the gap between the INVITE and a 180 Ringing or 183 Session Progress response.
• The telecom industry treats anything under seven seconds as acceptable, and most carriers will not open a ticket below that threshold.
• Seven seconds is more than thirty times the 208 millisecond mean offset at which people answer a question.
• The published voice AI latency benchmarks we know of, including ours, start their clock at call answer. The connect wait sits entirely outside it.
• It is largely a routing property, not a code property, so testing surfaces it and carrier selection fixes it.

What Is Post Dial Delay?

Post dial delay, usually shortened to PDD, is the time between a caller sending the last digit of a number and hearing the first ringback tone. Voipfuture defines it as the interval measuring "the time elapsed between dialing the last digit of a phone number and hearing the initial ringback tone or other in-band information".

In a SIP network the definition gets precise. Twilio describes PDD as the delta between the SIP INVITE that starts the call and the first provisional response indicating the far end is alerting, which is either a 180 Ringing or a 183 Session Progress.

A 100 Trying does not stop that clock. It confirms your request was received, not that anyone is being alerted, so the delay keeps accruing until a 180 or a 183 arrives.

The difference between those two matters more than it looks. A 180 tells your equipment to generate local ringback. A 183 carries actual audio in the session description, so the far network supplies the tone. When one side expects one and gets the other, the caller hears silence where a ring should be.

Telnyx frames the same thing from the caller's side: "the time from the sending of the final dialed digit to the point at which they hear ring tone or other in-band information".

Three definitions, one measurement. What varies is who is expected to care about it.

The Seven Second Standard, and Who It Was Written For

The number the telecom industry converged on is seven seconds. Voipfuture reports that the telecommunications industry "generally considers a PDD under seven seconds acceptable". Telnyx states the same figure, and adds the part that actually determines what happens to you: most carriers decline to troubleshoot delays below that level.

Read that again if you run a voice agent. A six second wait before your caller hears a ring sits inside the industry threshold, so by default it is not treated as a fault. Individual providers do better than that baseline. Telnyx asks customers to contact support for delays over seven seconds, and Twilio monitors its carrier partners for rising PDD and reports per-call figures through its Voice Insights dashboard. But the industry default is that anything under seven seconds is working as intended, which puts the burden of noticing squarely on you.

Tolerance is also regional, and the spread is wide:

Kolmisoft puts the other end of the range on record: "In general, a PDD of fewer than three seconds is considered excellent, and more than seven seconds is considered problematic." The gap between three and seven seconds is the whole negotiating room you have with a carrier.

Voipfuture also notes that crossing the seven second line correlates with rising caller frustration, call abandonment and a falling Average Success Rate. So the threshold is not arbitrary. It is roughly where human patience with a telephone runs out.

The trouble is that a telephone is not what your caller thinks they are using.

Why the Carrier Standard Does Not Fit a Voice Agent

Conversation runs on a much tighter clock than telephony does. In a study of ten languages across five continents, Stivers and colleagues found that the mean offset between a question and its answer is 208 milliseconds, with a modal gap of zero. Every language studied showed the same pattern, which is a strong hint that it is a property of human interaction rather than of any particular culture.

So the two numbers governing your caller's experience sit more than thirty times apart. Seven seconds is an acceptable wait to find out whether a phone is ringing. Two hundred and eight milliseconds is the pause after which a person starts wondering why nobody has answered them.

A human caller forgives the first because they know what dialing feels like. They have waited for connections their whole lives. What they do not forgive is the same silence once they believe a conversation has begun. The moment your agent says hello, the clock they are judging you against changes by two orders of magnitude, and it never changes back.

This is why it is worth measuring even though it is not conversational latency. It spends your caller's patience before your agent gets to say a word.

Post Dial Delay Is Invisible to Voice AI Observability

Here is the structural problem, and it applies to every vendor in this category including us.

Voice AI latency metrics measure turns. Time to first token, time to first audio, per-turn response latency, p50 and p95 and p99. All of them start their clock at a point after the call has connected, because a turn cannot exist until there is a session to hold it. That is not an oversight, it is what the metric means.

The connect phase ends where those metrics begin. The two windows are adjacent and do not overlap:

A team looking only at the middle column will conclude their agent is fast, because within its window it is. The caller experiences all three phases as one continuous wait and cannot tell which layer failed them.

It also arrives misdiagnosed. Twilio notes that "In extreme cases high post-dial delay will be reported as dead air, one-way audio, or dropped calls since the calling party has no indication that the call has been properly established, or whether the destination has answered." A bug report saying your agent dropped the call may be describing a call that never connected.

If you are debugging a "slow" agent that traces clean, the connect phase is the first place to look, and it is the one place your application logs will never show you. A useful adjacent read is our guide to testing the telephony layer, which covers the signaling path this metric lives on.

Where Post Dial Delay Actually Hurts

The damage is asymmetric, and it is worth being precise about it because the two call directions fail in completely different ways.

For inbound agents this is the more serious of the two. A caller who hangs up during that wait never reaches your agent, never appears in your call logs, and never shows up as a failure anywhere in your stack. The call simply does not happen. Whatever your answer rate is, the abandoned-before-ring population sits underneath it, uncounted.

For outbound the cost is economic rather than experiential. Every second of it is a second of held concurrency you are paying for and not using. At small volumes this is noise. Across a large campaign it is the difference between one dialer capacity tier and the next.

A Worked Example: One Agent, Two Routes

Two callers dial the same number. Same agent, same prompt, same model, same code. One is routed over a direct interconnect, the other over an aggressive least cost route that is still comfortably inside the seven second industry threshold. Here is what each of them sits through before hearing a single word.

Only one of those rows is measured. One is route dependent, one is a stated assumption you can replace with your own answer behavior, and the last is simply their sum. The point survives either way: the two callers differ by four and a half seconds, and every millisecond of that difference comes from a layer the agent team does not own and cannot see.

Run this agent's traces and both calls look identical, because they are. The p50 is the same. The prompt is the same. The tool calls are the same.

One caller had a decent experience and the other very likely hung up, and nothing in the application telemetry distinguishes them. If you are already testing call quality end to end, the VoIP call quality guide covers the network side of the same path.

What Causes High Post Dial Delay?

Almost none of it is your application code, which is what makes it frustrating to own.

Signaling mismatches between networks. Twilio attributes most PDD to improper SIP signaling responses from destination networks, caused by different readings of the same SIP specification. One network answers with a 180 where the other expects a 183, or supplies silence where a tone was assumed.

The far carrier has not confirmed alerting. Telnyx describes the core mechanism plainly: the carrier of the number you dialed has not yet received an indication that the end user's device is ringing. Everything upstream waits.

Wireless conditions at the destination. Telnyx notes that devices with poor signal strength, or simply a long distance from the serving tower, take longer for the connection to be established. You cannot fix your callers' reception.

Geography and route length. Twilio lists physical distance between caller and destination, and non-geographic destinations such as satellite phones, as direct contributors.

Cheap wholesale routing. Least cost routes reach a destination by trying carriers in sequence. Each attempt that fails or hesitates adds to the total before anyone hears a ring. This is the one cause you control, and you control it with procurement rather than code.

Fake Ringback: When Your PDD Looks Fine and Is Not

A route can report a good delay figure and still be broken. Kolmisoft notes that "Providers can use a fake ring to decrease PDD rates", and is blunt about what that is: "The fake ring is not a solution but a way to mask a problem." Your equipment hears a ring, your measured delay drops, and the destination device has not started alerting.

This is not the same as playing early media on your own outbound leg, where you know the tone is yours and you chose it. Here the tone is inserted upstream and nothing tells you.

For a voice agent that difference is expensive. Answer detection keys off signaling that no longer describes what the far end is doing, so a greeting can start playing into a call nobody has picked up. The caller arrives mid-sentence or hears nothing and hangs up.

The tell is a delay figure that improved without a routing change. Kolmisoft's advice is to raise it with the vendor and to change vendors if they will not fix it. If you test routes on a schedule, compare the measured delay against what actually happened on the answered calls rather than trusting the delay number alone.

How Do You Measure Post Dial Delay?

Every method below works. They differ in what they cost you, so pick on that basis rather than on accuracy alone.

Whichever you choose, record the distribution rather than the mean. The metric is tail-shaped for the same reason response latency is: the median tells you the route works, and the 95th percentile tells you how many callers it works for. The same argument applies to per-turn timing, which we cover in the guide to voice agent performance testing.

How to run a post dial delay test

1. Pick origination in each region you actually serve. A test dialed from one datacenter measures one path, not your callers' paths.
2. Dial a number that answers automatically on the first ring, so answer behavior is held constant and every run stays comparable.
3. Capture the INVITE and the first 180 or 183 at your own edge, and keep the PCAP. Carrier escalations move faster with one attached.
4. Repeat on a schedule across peak and off-peak hours. Routing changes through the day and a single run will not show it.
5. Report p50 and p95 per route, never the mean. The average is where a bad tail hides.

How Do You Reduce Post Dial Delay?

Fewer levers than you would like, and each one costs something real.

Change routes, not code. The single most effective change available. Moving off aggressive least cost routing to a direct or tier one interconnect typically removes seconds. It costs more per minute, sometimes substantially, and that is the whole trade.

Buy origination close to your callers. Distance is a real contributor, so numbers terminated near your caller base shorten the path. It costs procurement effort and a larger number estate to maintain.

Play early media deliberately. Sending a 183 with in-band audio gives the caller something to hear while the far end is still alerting. It masks the delay rather than removing it, and it can confuse downstream answer detection if configured carelessly.

Set expectations in the number you publish. A caller who dials from a web widget can be shown connection state. A caller dialing a phone number cannot. Where you own the surface, use it. It costs frontend work and does nothing for direct dials.

Accept it and shorten what follows. If the connect path cannot improve, the response path can. Time saved after answer partially offsets time lost before it, and unlike routing it is entirely within your control. Cekura measures response-path latency across hundreds of simulated scenarios before an agent takes a real call, which is where that offset gets found. It costs engineering effort on the response path and does nothing for the connect phase itself.

Notice that four of those five are procurement or infrastructure decisions. This is one of the few voice quality problems an engineering team genuinely cannot fix by writing better software, which is exactly why it goes unowned.

Where the Clock Picks Up After the Call Connects

Once the call is answered, the timing problem becomes measurable, and the numbers vary more between platforms than most teams expect.

Cekura's public voice AI benchmark measures per-turn response latency under a fixed configuration: "With the model, prompt and TTS fixed, per-turn latency reflects the platform's turn-taking: endpointing, VAD, buffering and network path." The same agent, a scheduling assistant, ran 59 evaluation scenarios three times on each platform, giving roughly 1,100 to 1,570 turns per platform.

One caveat rides every figure below. The telephony path differs by platform, native on some and SIP-bridged on others, so part of the spread reflects how each platform reaches the phone network rather than its orchestration alone.

Two things are worth drawing out. The first is that even the fastest p50 here, 1,730 ms, is more than eight times the 208 ms mean offset at which people answer a question. The second is how differently each platform behaves in its own tail. Vapi runs 610 ms between p50 and p95 while Pipecat runs 2,269 ms, nearly four times wider. Two platforms with similar medians can therefore deliver very different experiences to the slowest served tenth of callers, which is why a median on its own tells you almost nothing.

Adding Both Halves Together

Add the connect wait on top of any of these figures and you have the wait your caller actually experiences. That total is rarely reported, because few tools own both halves of it. Cekura measures the second half on every simulated run before an agent takes a real call, which is the half you can act on without renegotiating a carrier contract.

That split is worth being explicit about, because it decides who owns the fix. Cekura will tell you your agent's median and 95th percentile response latency. It will not tell you that a least cost route added six seconds in front of both, because that wait happens before the session its metrics describe exists. Catching it takes a separate measurement aimed at the connect path, whether that is SIP capture, provider reporting or scheduled test calls. Pair the two measurements or you will keep optimizing the half that was already fast.

Frequently Asked Questions

What is a good post dial delay?

The telecom industry treats anything under seven seconds as acceptable, and most carriers will not investigate below that. For a voice agent, treat seven seconds as a ceiling rather than a target. North American callers begin noticing delay at around five seconds, so measure your own distribution and judge it against your callers rather than against the carrier standard.

Is post dial delay the same as latency?

No, and conflating them is what hides it. Latency in voice AI normally means response time within a connected call, measured from the caller finishing speaking to the agent starting. The connect delay happens before the call exists. The two are adjacent phases of one experience and are measured by completely different systems.

Why does my voice agent feel slow when the traces look fast?

Because your traces begin at call answer. If the connect phase is adding four seconds before your agent is offered the call, every measurement you have will look healthy while your callers wait far longer than your dashboards suggest before hearing a word. Check the connect phase before optimizing the response phase.

Can post dial delay be fixed in code?

Rarely. It is determined by SIP signaling between networks, carrier routing and physical distance. The effective fixes are changing routes, buying origination closer to your callers, and playing early media to mask the wait. Only the last of those is an engineering change, and it hides the delay rather than removing it.

Does post dial delay affect outbound calls?

Yes, but not in the way it affects inbound. On an outbound call the recipient's phone has not rung yet, so they experience nothing. You pay instead in held concurrency, reduced dialer throughput, and greetings that land at the wrong moment when the delay varies between runs.

How do I measure post dial delay accurately?

SIP capture at your own network edge gives exact INVITE to 180 or 183 timing per call and is the most accurate method available. Synthetic test calls are more practical for comparing routes and regions on a schedule. Carrier-reported averages are free and the least useful, because averaging conceals the tail where the failures live.

Cekura runs your agent through hundreds of realistic scenarios and scores response latency, turn-taking and conversational quality before your callers meet it. Book a demo to hear how yours performs once the call connects.