Wisenet NVR P2P (HBIRD) Technical Guide
1. P2P Concept
1-1. Overview
The Wisenet NVR P2P (Peer-to-Peer) service, powered by Hanwha Vision’s HBIRD (HummingBird) Cloud platform, allows secure remote access to NVRs without manual port forwarding.
Based on WebRTC and MQTT, users can easily connect to NVRs through QR code scanning via the Wisenet Mobile App (iOS/Android) or Wisenet Viewer (PC).
1-2. Terminology
| Term | Description |
|---|---|
| DDNS (Dynamic DNS) | Maps a domain name to the NVR’s public IP, allowing direct remote access. |
| P2P (Peer-to-Peer) | WebRTC-based connection using Cloud signaling and NAT traversal without port forwarding. |
| STUN | Server that reveals the device’s public IP/port through NAT (hole punching). |
| TURN (Relay) | Cloud relay server used when direct STUN connection fails. |
| MQTT | Lightweight messaging protocol for signaling, heartbeats, and event delivery. |
| Product ID | Unique identifier for each NVR; also used as the DDNS name and embedded in the QR code. |
| Quick Connect (UPnP) | Automatic port forwarding helper for DDNS (unrelated to P2P). |
1-3. Connection Flow
1. NVR → Wisenet Cloud
- Registers via HTTPS (443) and MQTT (5000)
- Cloud stores Product ID and status
2. Viewer/Mobile → Cloud
- Requests access using Product ID
3. Cloud ↔ NVR
- Exchanges ICE candidates via MQTT signaling
4. WebRTC Session
- STUN (UDP) attempt → if fails → TURN (Relay via TLS 443)
Connection Priority: DDNS (if failed) → P2P (STUN) (if failed) → TURN (Relay)
1-4. Required Ports & Server Domains
| Purpose | Protocol | Port | Direction | Domain |
|---|---|---|---|---|
| HTTPS (Common Services) | TLS | 443 | Outbound | config.prod.wra1.wisenetcloud.com, auth.prod.wra1.wisenetcloud.com |
| WebRTC Signaling & Event (MQTT) | TLS | 4000, 5000 | Outbound | mqtt.prod.wra1.wisenetcloud.com |
| STUN (WebRTC) | UDP/TCP | 3478, 3479 | Outbound | *.wra1.wisenetcloud.com |
| TURN (WebRTC) | UDP/TCP | 32355–65535 | Outbound | turn.prod.wra1.wisenetcloud.com |
- No inbound ports required.
- Note: TURN data communication uses port range 32355–65535 (UDP/TCP). Port 443 (TLS) is used only for the TURN configuration API, not for actual media transport.
| Purpose | Protocol | Port | Description |
|---|---|---|---|
| TURN (Data Relay) | UDP/TCP | 32355-65535 | Media relay traffic |
| TURN Discovery (API) | HTTPS (TLS) | 443 | Used only for obtaining TURN configuration tokens |
1-5. Event Push Notification Structure
(1) NVR → MQTT Server (Event Publish)
(2) MQTT → Push Gateway
(3) Push Gateway → FCM
(4) FCM → Android / APNs (iOS)
(5) Mobile App → Notification Display
| Component | Role | Description |
|---|---|---|
| MQTT Server | Receives event messages from NVR | HBIRD Core |
| Push Gateway | Converts MQTT → Push format | Internal Cloud Service |
| FCM | Firebase Cloud Messaging for Android | Google service |
| APNs | Apple Push Notification Service for iOS | Apple service |
- Push Notifications only work when the NVR is P2P-connected and MQTT (port 5000) is not blocked.
1-6. Behaviour by Network Type
| Environment | NAT Type | P2P Success | TURN Need | Notes |
|---|---|---|---|---|
| Wi-Fi | Cone / Port-Restricted | High | Low | Typical home/office router |
| 4G/LTE | Symmetric / CGNAT | Low | High | STUN often fails; relay used |
| 5G | Mixed | Moderate | Medium | Depends on carrier policies |
- TURN (Relay) activates automatically when STUN fails.
- If both P2P and TURN fail under mobile networks, it indicates carrier or Cloud restrictions.
NAT types include Full Cone, Restricted Cone, Port-Restricted Cone, and Symmetric.
P2P connection is impossible when either side uses Symmetric NAT, and very difficult when both sides use Port-Restricted Cone.
Most mobile networks use Port-Restricted Cone or Symmetric types for security, which limits P2P success rate.
| NAT Type Combination | P2P Feasibility | Notes |
|---|---|---|
| Full Cone ↔ Any | ✅ | Always possible |
| Restricted Cone ↔ Restricted Cone | ✅ | Usually fine |
| Port-Restricted Cone ↔ Port-Restricted Cone | ⚠️ | Unstable |
| Any ↔ Symmetric | ❌ | Not possible |
1-7. Technical Specification & Limitations
| Item | Specification |
|---|---|
| Max devices for Wisenet Viewer | 128 |
| TURN Relay Support | Mobile App only |
| Wisenet Viewer Relay Support | ❌ (Not supported by policy) |
| Protocols Used | WebRTC (STUN/TURN), MQTT, TLS |
| Certificate Requirement | Hanwha Root CA Device Certificate |
| Required Outbound Ports | 443, 5000, 3478, 3479, 32355–65535 |
2. P2P FAQ
2-1. Do DDNS and P2P both need to be active?
Yes. P2P uses DDNS for device identification and Cloud metadata.
If DDNS is disabled, the Cloud cannot locate the Product ID for initial connection.
However, media transmission itself occurs over the independent P2P channel.
2-2. What information is contained in the P2P QR Code?
The QR code includes the NVR’s Product ID, which also serves as its DDNS name.
The viewer or mobile app uses this ID to find the device in the Cloud registry.
2-3. Why must DDNS be active for P2P to work?
P2P queries the DDNS database to obtain the NVR’s Product ID and registration data.
DDNS provides the “identity,” while P2P handles the “connection.”
2-4. Is there any security or GDPR concern when using P2P?
No. HBIRD uses TURN over TLS (443) and DTLS-SRTP encryption for all data streams.
TURN servers only relay encrypted packets and cannot decrypt user data.
All communication is end-to-end encrypted and GDPR compliant.
2-5. What is Quick Connect (UPnP), and is it required?
Quick Connect automatically performs port forwarding on the router to assist DDNS connections.
It improves direct access (HTTP/RTSP) success rate but has no effect on P2P, which works entirely via outbound Cloud connections.
3. P2P Troubleshooting
3-1. Push Notifications are not received. What should I check?
- Push notifications require an active P2P connection.
- To enable this, the device must be registered via P2P in either Wisenet Viewer or the mobile app.
- Verify that MQTT port 5000 is open.
- Check for any temporary Cloud or Push Gateway service issues.
- If all above are normal, contact technical support.
3-2. P2P works on Wi-Fi but not on 4G/5G.
Mobile carriers often use CGNAT/Symmetric NAT, blocking STUN UDP traffic.
The Mobile App automatically attempts TURN Relay (TLS 443), but failure may still occur due to:
| Cause | Description |
|---|---|
| Carrier Firewall Policy | Outbound UDP 3478 or TCP 443 blocked |
| SSL Proxy / DPI Filtering | TURN over TLS blocked by security gateway |
| Cloud TURN Failure | Temporary AWS or relay cluster issue |
| MQTT Instability | ICE signaling failed → no TURN candidates received |
How to Verify:
1. Test connection over Wi-Fi (if works → carrier restriction).
2. Use a network utility (e.g., Termius(mobile), Powershell(PC)) to check connectivity to turn.prod.wra1.wisenetcloud.com on port 443 using telnet or nc.
- If connection fails: TURN over TLS is blocked by carrier firewall.
- If connection succeeds: TURN reachable, other issues likely MQTT or ICE signaling.
3-3. Error: “No certificate exists.”
This means the device certificate (Hanwha Root CA) is missing or invalid — typically after a mainboard replacement (RMA).
The service team must regenerate and inject a new certificate using the NVR’s MAC address.
3-4. Wisenet Viewer shows “Relay mode.” What does it mean?
Wisenet Viewer does not support TURN relay connections by policy.
When it falls back to Relay mode, video will not stream.
Follow the recommendation message from Wisenet Viewer and configure DDNS + port forwarding:
Message:
“Currently P2P connection is switched to Relay mode.
Recommendation:
1. Enable ‘Quick Connect (UPnP)’ in [Network] → [DDNS & P2P].
2. If #1 fails, perform Port Forwarding and configure DDNS.”