On the Port Phones homepage we lead with a number: sub-15ms RTT from a UK ISP to our London-hosted 3CX, talking to UK Gamma SIP trunks. It sounds like a strong technical claim. The honest version is: for most calls, you can’t hear the difference between 15ms RTT and 30ms RTT.
So why do we lead with it?
Because in network voice, latency isn’t what you can hear under good conditions. It’s what determines whether you start hearing the bad conditions before they get to a level your customer notices. Sub-15ms gives you headroom. EU-hosted PBX at 25–40ms RTT also works fine, until something on the network has a bad five minutes.
This post is about what those milliseconds actually are, where they come from, and why “UK-hosted” is a sensible thing to insist on even when the marginal hearing experience is identical.
What “RTT” is, and isn’t
“Sub-15ms RTT” measures the round-trip time for a network packet from one endpoint, to the server, and back. It is network plumbing. It is not call quality.
What humans actually perceive on a call is mouth-to-ear latency: how long it takes from one speaker’s mouth to the other speaker’s ear. That is a longer chain than RTT measures. The mouth-to-ear budget for a typical UK VoIP call breaks down roughly as follows.
- Codec encoding (Opus or G.711): 5–20ms.
- Jitter buffer on the receiving side: 20–50ms.
- Network transit, one-way: 5–20ms.
- Codec decoding: 1–5ms.
- Phone or headset output processing: 5–15ms.
For a healthy UK-to-UK call on G.711, total one-way mouth-to-ear lands at 50–80ms. The ITU-T G.114 recommendation is that anything below 150ms one-way is “transparent” — most listeners can’t tell a delay is there. Above 150ms, people start unconsciously cutting each other off because the conversational handover gets clumsy.
Healthy UK VoIP sits comfortably in the transparent band. EU-hosted sits comfortably in it too. The 15ms vs 30ms RTT delta moves your one-way mouth-to-ear from, say, 60ms to 67ms. Imperceptible.
Why headroom matters anyway
The “imperceptible” comparison only holds when the network is behaving. The trouble starts when it isn’t, and that is where the 15ms number earns its keep.
Jitter spikes. Variable packet arrival times. The jitter buffer expands to absorb them, which adds latency. A 30ms baseline plus a 60ms jitter expansion lands at 90ms — still transparent. A 60ms baseline plus the same expansion lands at 120ms — also fine, but you’re approaching the 150ms cliff.
Codec renegotiation. When network conditions degrade, 3CX or the SIP provider may renegotiate to a more resilient codec, which adds encoding latency. A lower baseline gives you room to absorb that.
Packet loss recovery. Lost packets trigger retransmission, jitter buffer expansion, or audio concealment. All of these recover cleaner when starting from a low-latency state.
The case for UK-hosted UK SIP isn’t “your customers hear 15ms vs 40ms in a healthy call”. It’s “when your office Wi-Fi has a bad ten minutes on a Tuesday afternoon, the low baseline absorbs the degradation before your customers notice”. The headroom is the actual signal.
Where the difference is audible
There are use cases where the millisecond difference does show up at the listener.
Trading-floor adjacent calls. When call timing matters for compliance or quote-acceptance reasons. Most City of London law firms and brokerages we audit don’t actually need this, but a few do, and they’re rightly picky about hosting location.
Simultaneous interpretation. Live conference interpretation has a tighter latency budget than ordinary conversation. UK-hosted matters here.
Real-time transcription accuracy. Streaming transcription (for example, 3CX AI-tier call analytics) is more accurate on cleaner audio, and cleaner audio comes from lower baseline latency plus less jitter recovery.
Music-on-hold timing. Edge case, but transfer-flow scripts that rely on a specific musical cue timing can drift on high-latency hosts. We’ve seen this exactly once, and the fix was moving to UK-hosted.
How to test your own network
The number we publish is from our perspective: ISP-to-PBX RTT. You can measure your own perspective in thirty seconds.
On a Mac or Linux machine, in Terminal:
ping -c 30 your.pbx.host
On Windows, in PowerShell:
ping -n 30 your.pbx.host
If you’re on a UK office network talking to a UK-hosted PBX, you should see a steady stream of replies in the 8–25ms range. Spikes above 50ms on a wired connection mean something local is wrong (overloaded switch, contended Wi-Fi, broken QoS). Average above 30ms on a wired connection from a UK location means your PBX isn’t actually UK-hosted — worth asking your provider where it is.
The deeper test is mtr (Linux or Mac) which shows per-hop latency and packet loss. If your provider can’t tell you where the PBX is hosted, or won’t run an mtr with you on the call, that’s a signal on its own.
What we do
We host our 3CX deployments on DigitalOcean’s LON1 data centre in London. Tier-3 facility, UK data residency, no cross-border transfer. We pair them with Gamma SIP trunks. UK ISP, UK PBX host, UK SIP provider. The cleanest network path UK voice traffic can take.
The 15ms isn’t what makes calls sound good. It’s what gives you the room to absorb the network having a bad afternoon. That is the part worth paying for.
If you’d like us to test the network path between your office and a 3CX deployment we already run, book a free audit. We’ll run a 30-second mtr together and tell you what you’re working with.