Your video's route: a tour of WebRTC without the jargon
DTLS-SRTP, ICE, STUN, TURN, signaling — the jargon makes direct video sound arcane. Here's the whole pipeline told as a delivery story, and where VirtualCam's server is (and isn't) in it.
Every few years a technology gets a name so off-putting that people assume it must be complicated. WebRTC — “web real-time communication” — is that technology. Under the acronyms it’s a delivery service with a doorbell. Let’s walk your video’s route the human way.
The problem WebRTC solves
Your phone and your PC sit behind home routers that translate addresses for a whole household. Neither device has a public address the other could simply knock on. Sending live video between them means: find each other through the address translators, agree on encryption without eavesdroppers, and handle the fact that one side might be on a phone network. That’s all WebRTC is: the plumbing that makes two browsers (or a browser and a phone page) able to talk directly.
The tour, as a delivery story
Signaling: the phone call that arranges delivery. Before any video moves, the two devices exchange “here’s how to reach me” notes. Someone has to pass those notes — any server can. That’s VirtualCam’s pairing service: a postbox for introductions. The notes are useless to us; they’re only meaningful to the two devices that made them.
ICE: trying every door. Each device lists the ways it might be reachable — local address, router-translated address — and both sides try combinations until one connects. On the same Wi-Fi (our free tier’s assumption), the first door opens immediately: they’re already neighbors.
STUN: “what’s my address from outside?” A tiny helper server that tells a device how its router presents it to the world. Our ICE endpoint hands out a list of these helpers. It sees nothing but the question.
DTLS-SRTP: the armored truck. Once a route opens, the devices negotiate encryption keys directly with each other, then wrap every frame. The keys never touch the postbox. This is the step that makes “the server can’t see your video” a mathematical statement rather than a policy promise.
TURN: the courier that carries boxes when doors won’t open. Some networks — strict offices, mobile carriers — refuse direct routes. A TURN relay ferries the (still encrypted) packets between the two ends. It costs real bandwidth, which is exactly why cross-network pairing is planned, not shipped: it needs a relay budget first, funded by the ads on this site — and it will stay free. Note the word encrypted: a relay forwards boxes it cannot open.
So what does VirtualCam’s server actually see?
Session metadata. A random session ID, two temporary reachability notes, heartbeats. If a court asked for “the video”, there is no video to produce — not because we’d refuse, but because the media path never touched us. The pairing walk-through covers this step by step.
Why this matters for a camera tool
Most “phone as webcam” products stream your face to their server and back out, because it’s easier to build. It also means their database is one breach away from being a database of your face. Architecture is privacy policy; everything else is a press release. Ours is written down on the security page and checkable in any network inspector.
That architecture is also the practical difference in the field: see VirtualCam vs DroidCam and VirtualCam vs Iriun for what “no desktop app” means against the established tools.