Device Offline or Not Discovered
First, distinguish between "no candidate devices discovered by the platform," "device record exists but authentication failed," "device offline after registration," and "channel offline." These four scenarios require checks at different layers.
flowchart LR
A[Device is not online] --> B{Does the platform have a device record?}
B -->|No| C[Discovery, registration, and network]
B -->|Yes| D{Did authentication succeed?}
D -->|No| E[Account, time, and authentication]
D -->|Yes| F[Heartbeat, catalog, stream, channel state]
Common Checks for All Protocols
- Record the device, channel, node, and time of failure.
- Test the route from the actual AKStream.Next/MediaServer node to the device; do not use the operator's computer as a substitute.
- Confirm IP, gateway, VLAN, VPN, firewall, and clock settings.
- Check if the device password, address, firmware, platform port, or NAT settings were recently modified.
- Determine if the issue affects a single device, a single network segment, a single protocol, or all devices.
ONVIF Not Discovered
- The server has selected the correct network interface card (NIC).
- WS-Discovery multicast is not blocked by VLAN, VPN, or firewall.
- The ONVIF service is enabled on the device.
- Use XAddr/IP directly when cross-network discovery is unreliable.
If the device is discovered but authentication fails, check credentials, account lockout, device time, WS-Security, and HTTP/HTTPS. If the Profile can be read but the channel has no stream, go to No Image.
GB28181 Unable to Register or Disconnected
Check the platform IP, SIP port, domain, device ID, and password configured on the device; examine REGISTER, 401 challenges, authentication, and heartbeats. In NAT environments, distinguish between the listening port and the advertised port; the advertised value will not automatically open the firewall.
If registration is stable but there are no channels, check Catalog requests, SN, packetization, encoding, and device responses; if channels exist but VOD fails, check INVITE, SDP, and RTP.
RTSP Source Offline
Verify the URL directly from the MediaServer node responsible for pulling the stream. Check credentials, device concurrent connection limits, RTSP TCP/UDP settings, source address changes, and whether the device is saturated by other clients.
Do Not Immediately Delete and Recreate
Deleting and recreating may make a device "appear recovered," but it simultaneously severs stable channel IDs, recording history, and external mappings. Prioritize fixing addresses or credentials, resynchronizing, and retrying; only clean up according to the Channel Lifecycle when it is confirmed that the asset has been permanently removed.
Recovery Criteria
- The device remains online within the expected heartbeat window.
- Channel identities are neither duplicated nor lost after reconnection.
- At least one real stream can be established and played.
- Protocol logs no longer show continuous authentication failures or timeouts.
- The cause of the failure and the changes made are recorded, rather than simply writing "recovered after restart."