Comprehensive Survey: NVR P2P Remote Access Technologies

How do NVR (Network Video Recorder) systems let mobile apps view surveillance feeds from any network? This is a core requirement for the security industry and smart home ecosystems. This article systematically surveys three dimensions: open-source NVR projects (Frigate, go2rtc, Kerberos.io, Agent DVR, etc.), commercial surveillance vendors (Hikvision, Dahua, EZVIZ, Ubiquiti, Synology, Reolink, etc.), and third-party P2P platforms and security research (TUTK Kalay, iLnkP2P/PPPP, GB/T 28181, key CVEs).

All technical descriptions are verified against primary sources—official documentation, security advisories, and academic papers. Key statistics include citations.

Core Concept Quick Reference

Four Remote Access Modes

The NVR industry’s remote access solutions fall into four patterns:

flowchart TD
    A["NVR Remote Access"] --> B["A. Closed Cloud Relay<br/>Agent DVR · Shinobi<br/>Hikvision · Dahua · Reolink"]
    A --> C["B. Centralized Hub Relay<br/>Kerberos.io<br/>(Hub self-deployable)"]
    A --> D["C. Pure P2P + Self-hosted Relay<br/>go2rtc · Frigate<br/>UniFi Protect"]
    A --> E["D. No Remote Solution<br/>ZoneMinder · MotionEye<br/>(pure user DIY)"]
    style B fill:#fce4ec,stroke:#f44336
    style C fill:#fff3e0,stroke:#FF9800
    style D fill:#e8f5e9,stroke:#4CAF50
    style E fill:#e3f2fd,stroke:#2196F3

• Mode A (Closed Cloud Relay): Closest to consumer-grade NVR P2P—WebRTC or proprietary protocol + vendor’s own STUN/TURN/relay, subscription or vendor-hosted
• Mode B (Centralized Hub, Self-deployable): Agent→Hub→Browser, MQTT signaling + WebRTC streaming, Hub is closed-source but self-deployable
• Mode C (Pure P2P + Self-hosted Relay): Standard WebRTC + STUN hole-punching, TURN self-hosted via coturn or public services like Twilio
• Mode D (No Remote Solution): Port forwarding/reverse proxy/VPN, entirely user-managed

Open-Source NVR Remote Access Solutions

go2rtc: The De Facto Standard Engine

go2rtc is a zero-dependency streaming gateway supporting dozens of protocol conversions (RTSP↔WebRTC↔HLS↔HomeKit, etc.). It’s the underlying streaming engine for Frigate, Home Assistant, and other projects. MIT licensed, runs standalone.

go2rtc’s WebRTC architecture philosophy clearly articulates all decision points:

1. Almost always direct P2P: Browser to go2rtc is a direct peer-to-peer connection
2. Middleware only does signaling: Home Assistant, Frigate, Nginx, Nabu Casa, etc. only participate in connection establishment, not media data transmission
3. STUN hole-punching: Uses public STUN servers by default (e.g., stun.l.google.com:19302), bypassing NAT via UDP hole-punching
4. Symmetric NAT limitation: About 20% of users cannot P2P due to Symmetric NAT, requiring TURN relay
5. Self-hosted TURN supported: Can configure coturn or other self-hosted TURN servers

1
2
3
4
5
6

webrtc:
  ice_servers:
    - urls: [stun:stun1.l.google.com:19302]
    - urls: [turn:123.123.123.123:3478]
      username: your_user
      credential: your_pass

ICE Servers is the WebRTC configuration list for STUN/TURN servers. The client tries them in order: first STUN for public address discovery and hole-punching, falling back to TURN relay on failure.

go2rtc has no official cloud relay—it relies entirely on the standard WebRTC ecosystem. It provides P2P hole-punching in its purest form for upper-layer applications. Remote access “hardcore” methods include: static public IP + port forwarding, dynamic public IP + stun:8555 auto-detection, self-hosted TCP tunnel, self-hosted TURN server.

Frigate: Modern NVR Powered by go2rtc

Frigate is an open-source AI object detection NVR (MIT license) with a built-in go2rtc instance as its streaming engine. Frigate itself provides no official cloud relay or P2P hole-punching service—remote access entirely depends on user self-hosting:

• Nabu Casa Cloud (Home Assistant’s official subscription service): Acts as reverse proxy + WebRTC signaling proxy
• Reverse Proxy: Nginx Proxy Manager, Caddy, Cloudflare Tunnel
• VPN: Tailscale / WireGuard, need to add Tailscale IP to WebRTC candidates
• Port Forwarding + STUN: Forward port 8555, use stun:8555 for auto public IP detection

Frigate has no official mobile app—the community relies on third-party apps (like Lumen for Frigate, ViewPane), which depend on user-built reverse proxies/VPNs for remote access.

Kerberos.io: Dual-Channel Architecture Paradigm

Kerberos.io is the most architecturally complete relay model reference. It uses a three-layer architecture:

flowchart TD
    A["Kerberos Agent<br/>(Edge · MIT Open Source)"] -->|"Low-res: MQTT snapshots"| B["Kerberos Hub<br/>(Central · Closed Commercial)"]
    A -->|"HD: WebRTC stream"| B
    B -->|"WSS push to browser"| C["User Browser"]
    B -->|"WebRTC live stream"| C
    style A fill:#e3f2fd,stroke:#2196F3
    style B fill:#fff3e0,stroke:#FF9800
    style C fill:#e8f5e9,stroke:#4CAF50

Key design—dual-channel streaming:

• Low resolution (JPEG snapshot stream): Agent pushes JPEG snapshots to Hub via MQTT (TCP), Hub displays to browser via WSS—signaling-friendly, good traversal
• High resolution (WebRTC): Agent pushes full-resolution + high-FPS stream to Hub via WebRTC, traverses NAT via STUN + TURN—good real-time performance

Hub’s open-source dependencies include MongoDB, Kafka, Pion Turn/Coturn (TURN servers), Vernemq (MQTT broker). Hub deploys via Helm + Kubernetes, can be self-hosted on user’s own cluster (but Hub itself is closed-source and requires enterprise license).

Pion Turn is a Go-language TURN server implementation, officially chosen by Kerberos. coturn is a C-language veteran TURN server with more comprehensive features.

Agent DVR / Shinobi: Closed Cloud Relay

Agent DVR (iSpy series) is primarily closed-source, with only the plugin SDK open (GPL). It uses a typical “vendor cloud relay” model:

“Agent DVR leverages WebRTC for setting up remote connections… all of which we provide through ispyconnect.com.”

• ispyconnect.com closed cloud relay: Provides SSL + STUN + TURN + relay全套
• SignalR signaling: Used to establish remote connections. SignalR is ASP.NET’s real-time communication library, providing server-to-client bidirectional communication
• Subscription: Remote access requires paid subscription
• Built-in TURN server: Agent DVR comes with a TURN server and auto-configures it

Shinobi (GPL CE)’s “P2P” is essentially a closed relay service operated by Shinobi Systems, requiring a Mobile License purchase. Technical documentation doesn’t disclose underlying protocol details.

ZoneMinder / MotionEye: Pre-Cloud Era

ZoneMinder (GPL-2.0, established 2002) and MotionEye (GPLv3) represent the most traditional NVR remote access model—no cloud relay or P2P whatsoever:

• Port forwarding / reverse proxy (Nginx + TLS)
• VPN (WireGuard / Tailscale)
• No WebRTC support, primarily MJPEG / HLS / single-frame JPEG

They serve as a “counter-example”—showing the pain points when there’s no remote solution.

Open-Source Project Comparison

Commercial Vendor P2P Solutions

Industry Universal Architecture

All mainstream vendors follow the same architectural pattern:

flowchart TD
    D["NVR/IPC Device<br/>(LAN)"] -->|"Register UID"| S["Vendor Signaling Server<br/>(Public)"]
    C["Mobile App<br/>(Any network)"] -->|"Query UID"| S
    S -.->|"Exchange NAT mappings"| D
    S -.->|"Exchange NAT mappings"| C
    D -->|"P2P Direct<br/>(hole-punch success)"| C
    D -.->|"Relay fallback<br/>(hole-punch fail)"| R["Vendor Relay Server"]
    R -.-> C
    style S fill:#fff3e0,stroke:#FF9800
    style D fill:#e3f2fd,stroke:#2196F3
    style C fill:#e3f2fd,stroke:#2196F3
    style R fill:#fce4ec,stroke:#f44336

Device registers UID with vendor signaling server → App queries device by UID → Server exchanges NAT mapping info for both sides → Attempt P2P hole-punching → Fall back to Relay on failure.

Hikvision Hik-Connect

Hikvision uses a proprietary lightweight P2P protocol (not standard STUN/TURN/ICE), reportedly to save resources and licensing fees on embedded IPCs. Protocol characteristics include fixed port pre-negotiation and lack of dynamic NAT type adaptation.

Measured success rates (from third-party technical analysis): ~95% on home broadband, <30% behind enterprise Cisco ASA firewalls, up to 98% failure rate on China Mobile 4G.

Dahua DMSS / Lechange Cloud

Dahua uses a mediator server to evaluate network topology and auto-select connection method:

1. Same LAN → Direct connection
2. Single-side NAT → NAT-side proactively establishes outbound connection
3. Dual-side NAT → Both connect outbound to Dahua relay server

P2P connections use random UDP ports, requiring all outbound UDP to be allowed.

EZVIZ Cloud

Hikvision’s consumer brand. Key finding: official documentation states P2P is attempted by default with a success rate of only ~20% (from EZVIZ SDK documentation). The open platform provides complete SDKs (Android/iOS/C++/Web), commercialized by bandwidth/device tiers.

Ubiquiti UniFi Protect: The Only Standard WebRTC Adopter

Ubiquiti is the only vendor fully adopting standard WebRTC + STUN/TURN:

• Core technology: Standard WebRTC
• STUN/TURN: Uses Twilio public services (global.stun.twilio.com, global.turn.twilio.com)
• No port forwarding required
• Symmetric NAT auto-falls back to TURN relay
• Cloud service (unifi.ui.com) only provides signaling/centralized remote access, does not store video data

Synology Surveillance Station: Three-Step Fallback

Synology QuickConnect provides the clearest official architecture description—a three-step fallback strategy (confirmed by official whitepaper):

1. LAN/WAN Detection: Client queries NAS registration info, attempts direct connection
2. Hole Punching: QuickConnect Server assists both sides in punching holes in their respective NATs
3. Relay Service: Final fallback, traffic relayed through Synology Relay Server

When direct connection fails, WebRTC implements hole punching. URL format distinguishes connection type: [alias].direct.quickconnect.to (direct) vs [alias].[relay_id].quickconnect.to (relay).

Reolink: Most Thoroughly Reverse-Engineered

Reolink’s P2P protocol was fully reverse-engineered by Nozomi Networks. Protocol flow: NVR registers with p2p.reolink.com:9999 → server returns reg/log/relay endpoints → client queries UID → server returns device public mapping → client connects directly to NVR.

Encryption uses an 8-byte hardcoded key for simple obfuscation (not real encryption), with severe security vulnerabilities (CVE-2020-25169/25173).

White-Label: iLnkP2P / PPPP

This is the most important research for understanding the consumer surveillance P2P ecosystem. Paul Marrapese’s DEF CON 28 talk “Abusing P2P to Hack 3 Million Cameras” affected over 3.6 million IoT devices (talk data), involving HiChip, TENVIS, SV3C, VStarcam, and other brands.

PPPP/CS2 protocol (affecting 50 million+ devices) technical details: UDP port 32100 is the primary communication port, messages contain Magic 0xF1, message types (HELLO/PUNCH_TO/P2P_RDY/DEV_LGN, etc.). Encryption uses XOR obfuscation (hardcoded keys like BBAA, FFFF), not real encryption.

UID verification codes use only 22 letters (excluding A/I/O/Q), approximately 5 million combinations that can be brute-forced.

P2P Traversal Success Rate Baselines

Different solutions show dramatically different P2P traversal success rates:

flowchart TD
    A["P2P Traversal Success"] --> B["TUTK Kalay<br/>~92%"]
    A --> C["Standard WebRTC<br/>~80%"]
    A --> D["DCUtR Decentralized<br/>~70%"]
    A --> E["EZVIZ SDK<br/>~20%"]
    style B fill:#e8f5e9,stroke:#4CAF50
    style C fill:#e8f5e9,stroke:#4CAF50
    style D fill:#fff3e0,stroke:#FF9800
    style E fill:#fce4ec,stroke:#f44336

Conclusion: Symmetric NAT (common with CGNAT) almost always requires relay fallback. NVR relay server capacity planning should estimate approximately 30% of traffic going through relay.

CGNAT (Carrier-Grade NAT) is the core pain point for remote access in China—>95% of broadband users have no fixed public IP and are behind CGNAT. This makes P2P traversal a necessity, not an option.

Security Lessons: Three Fatal Flaws

P2P protocol security issues are alarming. Based on disclosed CVEs, three fatal flaws emerge:

flowchart TD
    A["P2P Protocol<br/>Three Fatal Flaws"] --> B["Hardcoded Keys<br/>TUTK: Charlie...<br/>Reolink: 8-byte key<br/>PPPP: BBAA/FFFF"]
    A --> C["Cleartext Transmission<br/>No E2E encryption<br/>A/V streams reconstructable<br/>CVE-2020-25169"]
    A --> D["No/Weak Auth<br/>UIDs enumerable<br/>Firewall bypass<br/>CVE-2019-11219"]
    style A fill:#f44336,stroke:#c62828,color:#fff
    style B fill:#fce4ec,stroke:#f44336
    style C fill:#fce4ec,stroke:#f44336
    style D fill:#fce4ec,stroke:#f44336

Key CVE Summary

Paul Marrapese’s iLnkP2P research (DEF CON 28, 2020) is the most authoritative academic-grade security research in this field. The talk title “Ain’t Nobody Got Time for NAT” hits the nail on the head—vendors sacrificed security to bypass NAT.

Security Red Lines

Based on these vulnerability lessons, self-built systems must:

1. No hardcoded keys—TUTK’s "Charlie is the designer of P2P!!", Reolink’s 8-byte key have all been cracked
2. Must enable AuthKey + DTLS/SRTP end-to-end encryption—avoid AES misuse (IV as key, ECB + hardcoded)
3. Cloud server instructions must verify source authenticity—prevent spoofing (TUTK 0x1008 redirect attack)
4. OTA/command processing must validate input—prevent injection
5. Must not upload local user plaintext passwords to cloud servers—Reolink CVE-2020-25173 counter-example
6. UID verification code entropy must be sufficient—iLnkP2P only ~5M combinations, brute-forceable

Third-Party P2P Platforms and Protocol Standards

TUTK Kalay: The Supply Chain P2P SDK King

TUTK (ThroughTek) was founded in Taipei in July 2008. Its core platform Kalay (aka IOTC platform) is the most widely adopted third-party P2P supply chain SDK in the IPC/NVR space. Affected firmware covers numerous vendors: QNAP, LiLin, Tenvis, KGuard, Xiaomi, TRENDnet, and more.

IOTC platform core signaling flow: Device IOTC_Initialize connects to Master server → Device IOTC_Device_Login(UID) logs in (UID is a 20-byte unique identifier, confirmed by Mandiant CVE-2021-28372) → Client IOTC_Connect_ByUID(UID) requests connection → Server returns device IP/port → Both sides communicate P2P.

Security evolution: Old versions (≤3.1.10) used simple XOR+ROL obfuscation (hardcoded key "Charlie is the designer of P2P!!", confirmed by security researchers); new versions introduced AuthKey (per-device random key) + DTLS dual-layer protection.

Chinese P2P IoT Cloud Platforms

GB/T 28181: Chinese National Standard SIP Signaling

GB/T 28181-2022 is China’s national standard for public security video surveillance networking, based on SIP (Session Initiation Protocol). Confirmed as the current standard (implemented 2023-07-01, supersedes 2016 version). Protocol stack includes session channel (SDP/SIP/MANSCDP) and media stream channel (RTP/RTCP, H.264/SVAC).

GB/T 28181 is essentially a centralized signaling architecture—devices REGISTER with SIP server, platforms INVITE to pull streams, media forwarded through streaming servers. It provides no P2P traversal mechanism. But it can interoperate with WebRTC: via SIP-over-WebSocket proxy conversion, mapping SIP signaling to WebRTC messages, then using ICE/STUN/TURN for P2P.

ONVIF: LAN-Standardized Interconnection

ONVIF (Open Network Video Interface Forum) doesn’t involve true P2P remote traversal, focusing on LAN-standardized interconnection. Device discovery uses WS-Discovery (UDP multicast 239.255.255.250:3702). Profile S defines RTSP live A/V streaming as the most widely implemented profile. Remote access still requires VPN/port mapping/P2P tunnels.

WebRTC for Surveillance: SFU vs P2P

flowchart TD
    A["WebRTC Surveillance<br/>Architecture"] --> B["Pure P2P (Mesh)<br/>1-to-1 viable<br/>Multi-viewer: bandwidth/CPU scales"]
    A --> C["SFU<br/>Server forwards only<br/>1 upstream, many downstream<br/>✅ Surveillance mainstream"]
    A --> D["MCU<br/>Mix/transcode<br/>High CPU overhead<br/>Rarely used"]
    style C fill:#e8f5e9,stroke:#4CAF50
    style B fill:#fff3e0,stroke:#FF9800
    style D fill:#fce4ec,stroke:#f44336

SFU (Selective Forwarding Unit) is the mainstream approach for surveillance—open-source implementations include Mediasoup, Janus, LiveKit, Pion. go2rtc converts IPC’s RTSP stream to WebRTC output, with latency as low as ~0.5 seconds (vs 5-10s for RTSP/HLS).

User-Side: App or Web?

The previous sections all focus on the “supply side”—how devices, vendors, and platforms implement P2P. But once the P2P path is open, how does the end user actually see the picture? This is the “last mile” of the remote access loop.

Three Client Form Factors

Once a device is connected via P2P, the user-side viewing entry point comes in three main forms: native app, web browser, and desktop client.

flowchart TD
    A["How Users Watch"] --> B["Native App<br/>Daily·Alerts"]
    A --> C["Web Browser<br/>Ad-hoc·Cross-platform"]
    A --> D["Desktop Client<br/>Central Monitoring"]
    style A fill:#9C27B0,stroke:#6A1B9A,color:#fff
    style B fill:#e8f5e9,stroke:#4CAF50
    style C fill:#e3f2fd,stroke:#2196F3
    style D fill:#fff3e0,stroke:#FF9800

Commercial vendors almost always ship a native app, while open-source self-hosted solutions center on the web. The two aren’t mutually exclusive—mainstream solutions typically offer both app and web entry points.

• Native apps are the consumer P2P standard: scan to bind the UID, then watch remotely; APNs/FCM pushes alerts, with two-way audio, PTZ control, and a message center
• The web is the heart of open-source self-hosting: go2rtc / Frigate pull streams directly via native browser WebRTC, requiring no client install—just open and watch, cross-platform
• Desktop clients serve professional monitoring: Hikvision iVMS-4200, Dahua DSS Client—multi-screen patrol, electronic maps, centralized recording management

User-Side Onboarding Steps

Whether app or web, the user-side onboarding flow reduces to three steps:

flowchart TD
    A["1. Get Client<br/>App / Browser"] --> B["2. Bind Device<br/>Scan UID / Login"]
    B --> C["3. Watch & Control<br/>Live·Talk·Playback"]
    style A fill:#fff3e0,stroke:#FF9800
    style B fill:#e3f2fd,stroke:#2196F3
    style C fill:#e8f5e9,stroke:#4CAF50

Commercial vendor path (e.g., Hikvision / EZVIZ / Reolink): the user downloads the official app from the App Store / Google Play → registers an account → scans the QR code on the bottom of the device or packaging (i.e., the UID) → the device auto-binds to the account → opening the app on any network thereafter streams instantly. The whole process is zero-config for the user; P2P hole-punching / relay is handled automatically by the vendor cloud, with NAT type, STUN/TURN details invisible to the user.

Open-source self-hosted path (e.g., Frigate / go2rtc): the user must solve “how the client reaches the self-hosted service”—either configure a reverse proxy (Nginx Proxy Manager / Caddy / Cloudflare Tunnel) to safely expose the web end to the public internet, or use a VPN (Tailscale / WireGuard) to bridge the network, or subscribe to a managed signaling service like Nabu Casa. Once bound, opening the domain in a browser streams instantly—no app install needed.

Smart Home Ecosystem Integration

The user side of modern NVRs has long outgrown apps and web—surveillance feeds are further integrated into larger smart home ecosystems:

• Apple HomeKit: go2rtc / Home Assistant can bridge RTSP streams into HomeKit cameras, viewable directly via Siri / Home app, supporting Apple TV / Apple Watch
• Google Assistant / Alexa: officially integrated by mainstream vendor clouds (EZVIZ / Reolink / Ubiquiti), voice retrieval of feeds, alert broadcasting
• Mi Home / Tuya: Chinese IoT platform integration, linking surveillance with door locks, sensors, and lighting
• Home Assistant: the open-source hub that unifies cameras across brands, pulling vendor-private P2P back under local control

Multi-Viewer: Is Pure P2P Enough?

P2P is point-to-point—one upstream maps to one downstream. When multiple people watch the same IPC simultaneously, the architecture must be reconsidered:

flowchart TD
    A["Multi-Viewer Scenario"] --> B["1-2 streams<br/>Home use"]
    A --> C["3+ streams<br/>Commercial / shared"]
    B --> D["Pure P2P viable<br/>Bandwidth scales linearly"]
    C --> E["SFU aggregation<br/>1 upstream, many downstream"]
    style A fill:#9C27B0,stroke:#6A1B9A,color:#fff
    style B fill:#e8f5e9,stroke:#4CAF50
    style C fill:#fff3e0,stroke:#FF9800
    style D fill:#e8f5e9,stroke:#4CAF50
    style E fill:#e3f2fd,stroke:#2196F3

• Home scenario (1-2 simultaneous viewers): pure P2P is entirely sufficient; device-side bandwidth pressure is manageable
• Commercial / shared scenario (3+ simultaneous viewers): IPC upstream bandwidth becomes the bottleneck (most IPCs can only encode one stream), requiring an SFU (go2rtc / Mediasoup / Janus) to do one upstream and many downstream—otherwise the feed stutters or drops

This is also why commercial vendor cloud relays generally adopt an SFU architecture—not merely as a fallback for P2P hole-punching failure, but to aggregate traffic for multi-viewer scenarios.

Engineering Takeaways

Architecture Design Insights

1. Centralized signaling is industry mainstream—TUTK Master, Hik-Connect, EZVIZ/Lechange Cloud all use “device→public signaling server→client” centralized signaling, with P2P only for the media layer
2. Typical architecture triad: UID identifies device → signaling server mediates → relay fallback on hole-punching failure
3. Kerberos Hub dual-channel architecture is worth studying: low-res via MQTT+WSS (signaling-friendly), HD via WebRTC+STUN/TURN (real-time)
4. go2rtc is the most worthwhile codebase to study: its WebRTC module docs comprehensively explain all decision points, MIT license allows direct borrowing

Protocol Selection Guide

Relay Capacity Planning

Symmetric NAT (common with CGNAT) almost always requires relay fallback. Relay server capacity planning should estimate approximately 30% of traffic through relay. EZVIZ officially acknowledges ~20% P2P success rate, go2rtc docs note ~20% of users fail P2P due to Symmetric NAT—these figures are highly consistent.

References

Open-Source Projects

Security Research & CVEs

Academic Papers

Commercial Vendor Documentation