Troubleshooting · Symptoms
Post-Dial Delay: The Silence After You Dial
You dial, press send, and wait. Five, eight, sometimes fifteen seconds of nothing before the far end starts ringing. Post-dial delay (PDD) feels like a quality problem and acts like one — callers hang up believing the call failed — but nothing is wrong with the audio path. The delay lives entirely in setup, distributed across DNS lookups, dial-plan processing, trunk selection and intercarrier routing, each contributing its slice.
Because PDD is a sum, you fix it by timing the stages, not by upgrading anything. A ladder capture timestamps every stage for you.
Where the seconds hide
| Stage | Typical cost | Pathology |
|---|---|---|
| Interdigit / dial-plan wait | 0–10 s | Phone waits to see if you'll dial more digits; no explicit 'send' and overlapping dial-plan patterns force a timeout |
| DNS (SRV/A-record lookups) | 0.05–2 s | Slow resolver, an SRV record listing a dead first-priority server that must time out first |
| Registration/auth & PBX processing | 0.1–1 s | Overloaded PBX or slow database lookups for routing/LCR |
| Trunk selection & carrier routing | 0.5–3 s | Least-cost routing trying a failing first-choice carrier before falling back |
| Far-end network & ringback | 0.5–2 s | Mobile networks take longer to page the device — partly outside anyone's control |
The classic: the 10-second interdigit timeout
The single most common PDD complaint in offices is self-inflicted: the phone's dial plan cannot tell when the number is complete, so it waits out its interdigit timer (frequently 5–10 seconds) before sending the INVITE. It afflicts dial patterns the plan matches ambiguously — variable-length international numbers are the textbook case. Users 'fix' it by pressing # or Send; the real fix is a dial plan with explicit patterns for your common cases (10-digit national, 11-digit with leading 1, defined international prefixes) so matched numbers transmit immediately. If delay appears only on some number types, suspect the dial plan before any network element.
Time the stages, then fix the fat one
- Capture an outbound call and build the timeline: last digit → INVITE sent → 100 Trying → 183/180 (ringing) → 200 OK. Each gap is a suspect stage.
- Gap before the INVITE leaves the phone: dial plan / interdigit timer. Tighten patterns for your common destinations; keep # as an explicit send in user training.
- INVITE sent, long wait for any response: measure DNS (query time for the provider's SRV/A records) and check for a dead first-priority SRV target; then ask the provider about their first-response time.
- Quick provisional responses but long to ringing: carrier routing/fallback — provide the provider with examples and ask whether the first-choice route to that destination is failing over.
- Compare destinations: delay on one country/carrier but not others localizes the problem to that route, not your system.
- Verify after the fix by timing the same call types; healthy PDD to most destinations is roughly 2–5 seconds end to end.
Frequently asked questions
- Is some delay normal?
- Yes. 2–5 seconds to ringing is typical for external calls; mobile destinations sit at the higher end. Beyond ~7 seconds users perceive failure, and beyond 10 something in the table above is misbehaving.
- Why did delay appear when we changed internet providers?
- DNS is the usual conduit: the new ISP's resolver performance, or your phones still pointing at the old ISP's DNS through DHCP. The gap sits before the INVITE or in the SRV lookup stage — the timeline shows it.
- Do calls to one country always take longer?
- Routes differ: some destinations genuinely involve slower interconnects and mobile paging. Your baseline comparison is the same destination from another system (a mobile phone) — if both are slow, it's the destination network, not yours.