The short answer

Your phone doesn't connect to the camera. The camera connects to a cloud broker first, and stays connected. Your phone asks that same broker for the camera by its serial number, not its IP. The broker then tells each side the other's public address, and both sides send packets outward at the same time. Each router sees that outbound packet and lets the reply back in, thinking it's part of a conversation it started. That's a direct path opened without anyone forwarding a port. If it doesn't work, video routes through the vendor's relay instead. Either way, the camera is never sitting on the open internet waiting for you.

Why the IP address is useless to you

The recorder in that factory has a private address. It means nothing outside its own LAN. Even if you had it, there's a good chance you couldn't route to it anyway, because a lot of ISPs — especially mobile and newer fibre — put customers behind CGNAT. Under CGNAT, many customers share one public IP, and there is no inbound port available to forward, at any price, on a normal connection. So for a large share of sites, the only way in is something that works outbound-only. That's the actual reason P2P exists. It's not a feature, it's a workaround for the internet running out of addresses.

The three ways in

  1. Port forwarding — needs a public IP, needs someone with router access at the site, and puts a recorder with a factory-default login directly on the internet. It also breaks the moment the ISP rotates the address.
  2. VPN — technically clean, but needs equipment and cooperation at every single site. Fine for one factory you administer. Not viable across dozens of small sites you don't.
  3. P2P through a vendor cloud — what almost every CCTV brand actually ships, because it's the only one of the three that works when you have zero access to the site's network.

What actually happens, step by step

Recorder (private IP, behind CGNAT)
  -> dials OUT to vendor broker on boot, keeps connection alive
  -> registers under its serial number (e.g. SERIAL-XXXXXXX)

Phone app
  -> contacts the same broker, asks for that serial

Broker
  -> sees the public IP:port each side is reachable from
  -> tells the recorder the app's address, tells the app the recorder's

Both sides
  -> send UDP packets toward each other's address, simultaneously
  -> each NAT sees its own outbound packet and allows the reply in
  -> direct path forms — this is hole punching

If hole punching fails:
  -> video flows through the vendor's relay servers instead

The serial number matters more than it looks like it should. It's the identity the broker knows the device by. That's why you add a camera to an app by typing a serial, not an IP — the IP is private and useless, and the address that matters is decided later, dynamically, by whichever public port the device happens to be dialing out from.

Direct vs relayed, and why it matters

A direct connection carries no vendor traffic and behaves like you'd expect. A relayed connection works, but adds latency and is rate-limited by whoever runs the relay, because now your video is going through their servers instead of a straight line between the two endpoints. If you're benchmarking latency or complaining about a laggy feed, the first question is which of the two you actually got — those numbers aren't comparable and most people never check.

Where this quietly breaks

A few things trip people up in ways that look like bugs but aren't:

  • "Offline" almost always means the recorder lost its connection to the broker, not that the camera itself failed. Check outbound internet at the site first.
  • Vendor clouds are regional. The same brand often runs separate broker infrastructure for different markets. Point a device at the wrong region and it fails in a way that gives you no useful error.
  • The same brand can run two incompatible P2P stacks at once. A newer recorder may be on entirely different infrastructure from an older model in the same product line. Credentials right, device online, still refuses to connect — because the client and the device are talking to two different clouds. Working out which stack a device is on comes before any other debugging step.
  • You don't control the broker's uptime. It's a dependency you didn't choose. Plan for it the way you'd plan for any third-party outage.

The honest trade-off

P2P gets you into a network you don't administer, behind a NAT you can't configure, on a connection that may not even offer you a port to forward. That's genuinely useful and for most remote sites it's the only option that exists. But it means a third party's server sits in the middle of your ability to reach your own hardware. Worth using. Worth describing as what it is.