When we announced Velo Meet last week, we made a claim that deserves evidence: that it's built "from the transport layer up" on carrier-grade principles. This post is the evidence. It's more technical than our usual updates — deliberately so.

The problem with the default path

Most video platforms hand your packets to the public internet and hope. BGP chooses routes for reachability and economics, not for the 150-millisecond round-trip budget a natural conversation demands. A route that's perfectly good for loading a webpage can be quietly terrible for real-time media — and it can become terrible mid-call without anyone's routing table caring.

Telecom networks solved this decades ago with a simple discipline: measure constantly, route deliberately, fail over instantly. Velo Meet applies that discipline to WebRTC media.

Three layers of the Velo network

1. The edge mesh

Every participant connects to their nearest media edge — a point of presence selected by real measured latency, not by geographic guesswork. Edges are interconnected over managed backbone links with known, monitored performance characteristics. Your media rides the public internet only for the short first hop; after that, it travels on paths we measure every second.

2. Adaptive routing

Between edges, every viable path is continuously scored on latency, jitter, and loss. When a path's score degrades past threshold, active calls shift to the next-best path in under a second — mid-sentence, without renegotiation, without the participants noticing. This is the same philosophy behind SS7 route management and MPLS fast reroute, applied to conversational media.

3. The selective forwarding layer

Inside each edge, our SFU (selective forwarding unit) makes per-subscriber decisions: which simulcast layer to forward, when to drop to audio-only, when a screen-share deserves the bandwidth a face doesn't. Every decision follows one hard rule inherited from telephony:

Voice is the 911 line of a meeting. Video is negotiable; screen-share is negotiable; audio is never negotiable.

Failure is a feature we test

We run continuous chaos drills against our own infrastructure: killed edges, saturated links, injected packet loss, poisoned routes. The platform's job is to make those events invisible. Current internal numbers from drill conditions:

  • Median failover time on edge loss: under 900 ms, with audio continuity preserved
  • Audio MOS held above 4.0 at sustained 15% packet loss
  • Join time, click-to-media, 75th percentile: under 1 second

These are lab-and-beta numbers, and we'll keep publishing them as they harden under real load. If they ever get worse, we'll publish that too — measurement you can't see is marketing, not engineering.

Security at the transport layer

End-to-end encryption in Velo Meet uses insertable streams with per-frame encryption, so media transiting our SFUs stays opaque even to us. Key exchange happens between clients; edges forward ciphertext. We designed for the assumption that every network — including ours — is untrusted.

What's next

Next week we'll switch lenses entirely and talk about the human layer: how Velo Meet's product design earns trust in the first five seconds of a meeting. And in early July, the private beta opens — where you can put every claim in this post to the test yourself.