ONVIF and UNIVIP: Architecture and Security ComparedLink to the section ONVIF and UNIVIP: Architecture and Security Compared
On this page
Status: Research note, 2026-10-14. Statements about ONVIF reflect the publicly documented specifications as understood at the time of writing; items marked ⚠ should be confirmed against the current ONVIF Core, Security and Profile V specifications during the formal review.
1. Why compareLink to the section 1. Why compare
UNIVIP's second objective, after drone interoperability itself, is to show what an ONVIF-class interoperability standard looks like when it is designed on the current web stack rather than the 2008 stack. ONVIF deserves credit: it solved the quadratic integration problem for cameras and is still being extended (Profile M, Profile V, WebRTC, MQTT). But its base layers were fixed when SOAP and WS-* were the enterprise norm, and a drone standard does not have to inherit them.
2. Stack side by sideLink to the section 2. Stack side by side
| Layer | ONVIF (classic Profiles S/T/G/M) | ONVIF Profile V (release candidate) | UNIVIP v0.1 |
|---|---|---|---|
| Message encoding | SOAP 1.2 XML envelopes, WSDL-described | SOAP for configuration ⚠; JSON for uplink/WebRTC signaling ⚠ | JSON (RFC 8259), JSON Schema 2020-12, OpenAPI 3.1 |
| Configuration API | SOAP web services over HTTP(S) | SOAP over the uplink ⚠ | HTTPS REST |
| Discovery | WS-Discovery (SOAP over UDP multicast) | Device-initiated uplink to a configured cloud endpoint | Device-initiated session + optional DNS-SD on LAN + claim-code enrollment |
| Connection direction | Client → device (device is a server on the LAN) | Device → cloud (reverse connection, tunnelled) | Device → client (single outbound TLS connection, all channels multiplexed) |
| Live video | RTSP/RTP (RTP over RTSP/TCP interleaved, UDP, or multicast); SRTP via Media2 ⚠ | WebRTC | WebRTC (DTLS-SRTP) mandatory; RTSPS, SRT optional |
| Metadata stream | XML metadata stream over RTP (tt:MetadataStream) |
as classic plus WebRTC data channel ⚠ | JSON telemetry on session channel and WebRTC data channel; MISB ST 0601 KLV in TS |
| Events | WS-BaseNotification pull-point subscriptions (SOAP polling) or MQTT binding (newer) | MQTT ⚠ | JSON events on session channel; MQTT 5 alternative |
| PTZ / control | PTZ Service SOAP operations with normalized spaces | same | JSON commands with explicit units and frames, command lifecycle, leases |
| Capability discovery | GetCapabilities/GetServices SOAP responses |
same | Single JSON capability document, schema-validated |
| Extensibility | XML extension elements, vendor namespaces | same | Ignore-unknown JSON members, x-vendor, reverse-DNS topics/commands, must-understand marker |
| Conformance | ONVIF Device/Client Test Tool, member-only, formal program | same | Planned open-source conformance tool (Part 14) |
3. Security side by sideLink to the section 3. Security side by side
| Concern | ONVIF (classic) | UNIVIP v0.1 |
|---|---|---|
| Transport encryption | TLS optional in Profile S; TLS 1.2 support required in Profile T ⚠; RTSP commonly unencrypted in practice; SRTP optional | TLS 1.3 mandatory on every connection; TLS 1.2 forbidden; media encrypted by construction (DTLS-SRTP, SRT AES); plaintext RTSP/HTTP forbidden by default and fails conformance |
| Device authentication | WS-Security UsernameToken (password digest with nonce and created time) or HTTP Digest; certificate-based (TLS client auth) supported in the Security Service ⚠ | mTLS client certificates or OAuth 2.0 client-credentials / private-key JWT; static passwords, HTTP Basic and HTTP Digest not permitted |
| Client authorization | User levels (Administrator, Operator, User, Anonymous) per device; coarse, per-device, locally stored users | Scoped tokens from the client's authorization server: univip.view, univip.camera, univip.vehicle, univip.config, univip.admin; enforced per device; vehicle and camera scopes separately assignable |
| Control authority | None beyond user level: any Operator may move PTZ at any time; last writer wins | Time-limited, heartbeat-kept control leases; one vehicle lease at a time; pilot override always wins; camera and vehicle leases independent |
| Replay protection | WS-Security nonce/created (when used) | Per-message msg_id, issued_at window, duplicate command_id rejection, leases bound to client_id |
| Input validation | XML Schema (where implementations validate at all) | Schema validation of every message is a MUST; invalid messages rejected with MALFORMED |
| Credential rotation | Device-local user management via SOAP | Rotatable without device_id change; revocation closes sessions; claim-code enrollment single-use, 15-minute expiry |
| Audit | Not specified | Mandatory audit record of every lease and vehicle.* command, 90-day retention, both sides |
| Firewall posture | Inbound ports on device (HTTP, RTSP, multicast discovery); often exposed to the LAN with default credentials | One outbound TLS connection from device; no inbound ports required |
| Privacy of position | n/a for fixed cameras | Telemetry treated as sensitive as video; retention and access policy must match |
4. Why the modern stack matters for drones specificallyLink to the section 4. Why the modern stack matters for drones specifically
- Mobility. A drone is on cellular, behind NAT, often connecting through a vendor cloud. WS-Discovery multicast and inbound RTSP ports do not work there. The device-initiated single-connection model does, and it is what ONVIF itself adopted for Profile V.
- Safety. Fixed cameras do not fly into restricted airspace. Authority over movement needs leases, scopes, pilot precedence and audit. None of this exists in ONVIF because none of it was needed.
- Time alignment. Position changes every frame. JSON telemetry on the same clock as RTCP, plus a data channel riding the WebRTC connection, plus ST 0601 for recordings, gives alignment that a polled SOAP event or an XML metadata stream struggles to deliver.
- Developer reach. VMS vendors already ship WebRTC, JSON and OAuth stacks for their web clients and cloud services. Dropping SOAP removes the single largest integration friction ONVIF implementers report.
- Testability. JSON Schema and OpenAPI let the conformance suite be a few hundred lines of open-source code that anyone can run, rather than a member-only tool.
5. What UNIVIP keeps from ONVIFLink to the section 5. What UNIVIP keeps from ONVIF
- The profile concept and the discipline that a profile claim means every mandatory feature.
- PTZ semantics (absolute, relative, continuous with timeout, stop, home), mapped one-to-one so a gateway can present a gimbal to any PTZ-capable VMS.
- The event-topic idea with a mapping so UNIVIP events can appear as ONVIF events.
- The capability-first design: ask the device what it can do, offer only that.
- Profile V's architecture of device-initiated secure connectivity, WebRTC and MQTT.
6. Interoperability pathLink to the section 6. Interoperability path
An UNIVIP gateway SHOULD be able to expose an ONVIF persona (Profile S/T/M subset) for VMS products that do not yet speak UNIVIP: video via RTSP(S), gimbal via PTZ, telemetry in the metadata stream, events via pull-point or MQTT. This gives a day-one path into every existing VMS while the native UNIVIP client ecosystem grows. The mapping lives in spec/annex-a-mappings.md.