p50 120ms is good ?

Thanks for reaching out, G. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Connection latency Percentile distribution of time for participant clients to successfully establish a WebRTC connection through LiveKit server.

Thanks — you clarified you mean p50 connection latency for participant clients establishing a WebRTC connection through the LiveKit server. That helps a lot. Short answer • A p50 of 120 ms is acceptable and indicates a relatively fast connection setup. It’s not perfect, but it’s near the range you’d expect for a well-placed LiveKit edge and typical ICE/DTLS signaling overhead. Why 120 ms is reasonable • WebRTC connection setup includes signaling, ICE candidate exchange, STUN/TURN probing, and DTLS handshakes. Those steps add overhead beyond plain network RTT, so setup times are commonly higher than pure media RTT. • LiveKit’s global mesh aims to keep network paths short (sub-100 ms where possible). A 120 ms p50 means half of your clients connect faster than that, which is close to optimal for many deployments. When you might want lower p50 • Interactive real-time experiences (fast join flows, low perceived wait) benefit from lower connection setup times. If your product requires instant joins for every user, pushing p50 under 100 ms is a reasonable target. • If you see long tails (high p95/p99), users in those tails will experience noticeably worse join times even if p50 looks okay. Quick checks and optimizations to reduce connection latency • Ensure clients connect to the closest LiveKit edge/region. Geographic proximity is the single biggest factor. • Minimize signaling round trips: reduce extra application-level handshakes during join. • Prefer UDP/STUN where possible; TURN (especially TCP/TLS over 443) works but can add latency when used frequently. • Check for client-side network issues (NAT types, captive portals, poor mobile networks) that increase ICE negotiation time. • Monitor higher percentiles (p95/p99) and per-region p50s to find problematic locations or networks. If you’d like, I can help further with: • Interpreting your p95/p99 numbers or per-region breakdowns. • A checklist to instrument more detailed timing (signaling vs ICE vs DTLS) so we can pinpoint where most time is spent. • Suggestions specific to your deployment (edge selection, TURN usage, or signaling flow) — share region and sample metrics and I’ll recommend next steps. Sources: Introducing LiveKit Inference: A unified model interface for voice AI | Liv... | Firewall Tips | How we built a globally distributed mesh network to scale WebRTC | LiveKit | A tale of two protocols: comparing WebRTC against HLS for live streaming | ..., with interactive elements