Two phones, one wifi, zero cloud
For a year this site said, honestly, that a browser monitor couldn't stream to a second phone without a server, so it wouldn't. Half of that sentence turned out to be lazier than we knew. A server is not needed to carry the video. It's only needed to make the introduction — and an introduction can travel by other means. A QR code, for instance, held up between two phones over the kitchen table.
What WebRTC actually is
Every modern browser ships WebRTC, the machinery behind video calls. Its whole premise is that once two devices know about each other, the media flows peer to peer — from one device straight to the other, encrypted, no company in the middle. When you're on a video call, the picture usually isn't bouncing through a data center; it's taking the shortest path the network allows. On a home wifi, the shortest path between two phones is glorious: out of one phone, into the router, into the other phone. A few milliseconds, and not a single hop that anyone else controls.
So why does every video-call product still have servers? Because of the bootstrap problem. Before the phones can talk directly, each needs a small dossier about the other: what media is on offer, the keys to encrypt it, and the network addresses where the other side can be reached. WebRTC writes this dossier in a crusty old format called SDP — Session Description Protocol — and getting each side's SDP to the other side is called signaling. WebRTC famously refuses to do signaling for you. Products solve it with a matchmaking server: both apps phone home, the server passes the dossiers across, done. Convenient — and suddenly there's an account, a company, and a camera pointed at a crib that checks in with the internet.
The dossier fits in a picture
Read an actual SDP and you find it's mostly ritual: dozens of lines describing every codec the browser has ever heard of, in a format from 1998. The parts that genuinely can't be invented by the other side are tiny — a session username and password (so a stranger can't waltz into your stream), a certificate fingerprint (so the encryption can't be impersonated), the codec numbers actually in play, and the address-and-port pairs where the phone is listening, which WebRTC calls candidates. Everything else is boilerplate that both ends can agree to reconstruct, because both ends are running the same page.
Strip the ritual and the dossier shrinks from a few kilobytes to under two hundred bytes. Two hundred bytes is comfortably a QR code. And that changes the shape of the whole thing: the nursery phone builds its offer and shows it; the parent phone scans, builds its answer, and shows that back; the nursery phone scans the reply. Two pictures, held up between phones. That's the entire signaling layer — the part that normally justifies the cloud — done with light bouncing between two screens. The phones then connect over the wifi and the video starts flowing, router-deep and no deeper. Pull the router's internet cable out of the wall first, if you like the demonstration: it keeps working, because nothing it needs is out there.
A word about addresses
One candidate detail is quietly lovely. Phones no longer like revealing their local IP addresses to web pages, so instead they mint a temporary name like a1b2….local — an mDNS name that only makes sense inside your own network, where devices resolve it by shouting politely on the LAN. Our QR code carries that name across the table, the parent phone asks the network "who is this?", the nursery phone raises its hand, and the link comes up. The address in the code is useless to anyone outside your walls, which is exactly the kind of secret a baby monitor should be trading in.
What breaks it, honestly
The same directness that makes this private also makes it delicate, and you deserve the failure list up front. The big one is guest-network client isolation: many routers wall off every device on the guest wifi from every other device. The QR dance still completes — codes are just pictures — but the connection never rises, because the phones genuinely cannot reach each other. Hotels do this almost universally; home guest SSIDs often do. The fix is boring: both phones on the main wifi.
The second is distance. On different networks — office phone, home crib — a direct link needs each phone to learn its own public address, which is what a STUN server does. We put that behind a switch, off by default, with a plain label: it asks Google's public STUN server for your address, which reveals your IP to that server (and nothing more; the video still flows directly). Even with STUN, some carrier networks block peer links outright. The industry's answer is a relay server — a TURN box that all your video passes through — and that's precisely the thing this tool exists to not have. So on stubborn networks, it fails, and says so plainly rather than routing your nursery through a stranger's machine.
And the third isn't a failure so much as physics: both phones must stay awake, lit, and preferably plugged in. A monitor that runs on borrowed hardware borrows its limits too.
What you get for tolerating all this is unusual: a real parent unit — live picture, room audio, alerts in your pocket, a talk button to shush from the hallway — built from two phones in a drawer, where the video's entire journey can be described in one sentence with no company in it. The handshake takes thirty seconds; the pairing-help page has the illustrated version.