Capabilities, Compatibility, and Known Boundaries
The existence of a feature in the code does not mean it has been production-verified for every device, network, and scale. Procurement, solution design, and deployment decisions should be marked with evidence levels.
flowchart LR
A[L1 Implemented] --> B[L2 Build passed]
B --> C[L3 Automated regression]
C --> D[L4 Real environment]
D --> E[L5 Production observation]
Evidence Levels
| Level | What it indicates |
|---|---|
| L1 Implemented | Ready for development and joint debugging |
| L2 Build Passed | Compiles successfully; does not prove correct runtime behavior |
| L3 Auto-Regression | Repeatable in standard simulated scenarios |
| L4 Real Environment | Passed with real devices, browsers, or target architectures |
| L5 Endurance Test | Recording, resources, tasks, and recovery verified over an agreed duration |
| L6 Production Verified | Canary deployment, rollback, and observation window completed |
Only declare the actual level achieved for the target scenario.
Current Explicit Capabilities
- Deployment and host governance for Linux, Windows, macOS, and Docker.
- Unified management of devices, channels, MediaServer, streams, and recordings.
- ONVIF discovery, Profile, stream pulling, PTZ, Imaging, events, and intercom-related workflows.
- GB28181 Server/Client, catalog, real-time streams, playback, control, subscription, and cascading workflows.
- RTSP stream pulling and media egress via HLS/FLV/RTSP/RTMP/WebRTC.
- Recording schedules, file indices, playback/download, disk governance, and clipping/merging.
- RTC rooms, members, WHIP/WHEP media sessions, and events.
- NodeAgent, configuration versions, tasks, logs, security, and auditing.
Specific capabilities still depend on the current version, enabled modules, licensing, and on-site compatibility verification.
Boundaries Not to be Misunderstood
- RTC is an SFU control plane based on MediaServer; it does not provide server-side MCU mixing or transcoding.
- Multi-node deployments do not guarantee lossless migration of existing RTP, RTSP, or RTC sessions.
- Task and event consumption for Active/Active multi-instance control planes requires specialized verification.
- Vendor-specific extensions for ONVIF and GB28181 require a real device matrix.
- GB28181 has a multi-version negotiation framework, but it should not be claimed that all 2022 extended commands and formal compliance certifications are complete.
- FFmpeg is not required for all scenarios, but capabilities such as clipping and transcoding depend on it.
- On Linux NodeAgent independently recovers the main service while the main unit uses
Restart=no; systemd still keeps NodeAgent alive. Other platforms must verify the single recovery owner declared by the current release instead of assuming multiple policies can safely compete. - Browsers cannot natively play RTSP.
- GPS FileSegment is a node-exclusive write format; it does not support multiple processes writing concurrently to the same shared directory.
Required Compatibility Matrix
- Versions of AKStream.Next, WebUI, NodeAgent, MediaServer, database, and FFmpeg;
- Operating system, CPU architecture, and deployment method;
- Browser version and network type;
- Device vendor, model, firmware, and protocol version;
- RTP TCP/UDP, NAT, TURN, and media encoding;
- Acceptance date, evidence, and known discrepancies.
When upgrading, copy the old matrix to form the target version plan. Cells without evidence must be marked as "Unverified" and cannot be assumed compatible by default.