Validation of the Proposed Transport BaselinesLink to the section Validation of the Proposed Transport Baselines

On this page

Status: Technical assessment, 2026-10-14. This document records how each proposed baseline from the original brief was evaluated and what the draft specification adopted. It is the rationale behind ADR-0005.

1. Evaluation criteriaLink to the section 1. Evaluation criteria

Criterion	Why it matters
Works device-initiated through NAT	Drones are mobile and behind carrier NAT
Zero additional infrastructure for a minimal deployment	A single VMS and a single drone must interoperate with nothing else installed
Already present in VMS vendors' stacks	Adoption cost
Encrypted by default	Part 13 forbids plaintext
Testable	Must be possible to write a deterministic conformance test
Alignment with ONVIF Profile V and major vendor APIs	Gateway and future-contribution cost

2. Assessment per functionLink to the section 2. Assessment per function

2.1 Video: H.264 over WebRTC (proposed baseline) — adopted, with one additionLink to the section 2.1 Video: H.264 over WebRTC (proposed baseline) — adopted, with one addition

WebRTC is the only mainstream transport that is NAT-traversing, encrypted by construction, low-latency and decodable in every browser and modern VMS web client. ONVIF Profile V chose it for the same reasons. H.264 is universally decodable; H.265 is kept optional.
Weakness found: server-side recording is harder over WebRTC than over RTSP or SRT. Most recorders today ingest RTSP; a WebRTC ingest requires a full WebRTC stack (ICE, DTLS, SRTP, RTCP feedback) in the recorder. For a drone on an unreliable link, SRT's ARQ also recovers losses better than WebRTC's NACK/FEC for contribution-style (non-interactive) ingest.
Adopted: WebRTC/H.264 mandatory for live viewing (Profile S); devices SHOULD additionally offer RTSPS or SRT for recorder ingest (Part 09 §9.1 row 9-5). RTSP(S) remains the easiest path into existing recorders; SRT is the better long-haul choice.
Alternatives kept: H.265/WebRTC, RTSP/RTP(S), SRT with MPEG-2 TS.

2.2 Continuous telemetry: Protobuf or JSON over a documented channel, MQTT as alternative — adopted as JSON over WebSocket; Protobuf deferredLink to the section 2.2 Continuous telemetry: Protobuf or JSON over a documented channel, MQTT as alternative — adopted as JSON over WebSocket; Protobuf deferred

JSON wins on adoption cost; every VMS has a JSON parser and so do DJI's and Skydio's APIs. Telemetry volume at 5–10 Hz is a few kilobytes per second, so Protobuf's compactness buys little at this layer. A Protobuf binding is reserved for a later annex once the JSON model is stable, so that the two bindings share one source of truth.
"A documented channel" is made concrete: a secure WebSocket session channel, device-initiated, carrying typed JSON envelopes. It needs no broker, traverses every proxy, and is also needed for WebRTC signaling, so it costs nothing extra.
Addition: the same telemetry envelopes SHOULD also be sent over a WebRTC data channel riding the media connection, which minimizes jitter between video and telemetry arrival (Part 09 §9.3).
MQTT 5 kept as a fully specified alternative with a normative topic mapping (Part 08 §8.7).

2.3 Events: MQTT 5 over TLS (proposed baseline) — adjusted: WebSocket session channel mandatory, MQTT 5 as first alternativeLink to the section 2.3 Events: MQTT 5 over TLS (proposed baseline) — adjusted: WebSocket session channel mandatory, MQTT 5 as first alternative

This is the one place the draft departs from the brief, for these reasons:

Broker requirement. MQTT needs a broker. For a VMS vendor, mandating MQTT means embedding or deploying a broker in every installation, which is a real adoption barrier for the minimal "one drone, one VMS" case. The WebSocket channel already exists for telemetry and signaling, so putting events on it adds no infrastructure.
Single connection. Events, telemetry, command status and lease updates on one connection simplify reconnection, replay and ordering guarantees (Part 08 §8.4).
Where MQTT is right. MQTT is the natural choice for fleets, multi-subscriber fan-out and cloud deployments, and both DJI Cloud API and ONVIF Profile V use it. So it is kept as a first-class, conformance-tested alternative with a normative topic tree, QoS and Will-message mapping, rather than dropped.
Recommendation to revisit: if the first three implementation reports show that every adopter runs a broker anyway, promote MQTT to co-mandatory on the client side (clients accept both, devices choose). This is recorded as an open question in ADR-0005.

2.4 Device configuration: HTTPS REST (proposed baseline) — adoptedLink to the section 2.4 Device configuration: HTTPS REST (proposed baseline) — adopted

REST with OpenAPI 3.1 is the lowest-friction configuration surface and is testable with generic tooling. gRPC is noted as a future alternative; it does not add enough for a low-rate configuration plane to justify a second mandatory binding.
The REST surface is kept small (identity, capabilities, latest telemetry, events history, streams, commands, leases, config) and is served identically by device-hosted and client-hosted endpoints so the connection direction does not change the API.

2.5 Camera control: standard command API with ONVIF PTZ mappings (proposed baseline) — adoptedLink to the section 2.5 Camera control: standard command API with ONVIF PTZ mappings (proposed baseline) — adopted

Commands are JSON documents with explicit units and frames, a lifecycle (ACCEPTED → EXECUTING → COMPLETED/FAILED) and standard rejection reasons. ONVIF PTZ absolute/relative/continuous/stop map one-to-one (Annex A.1.2), so a gateway can expose a gimbal to any PTZ VMS.
Addition: camera.gimbal.point_at (geographic pointing) because click-on-map is the most requested drone-specific camera feature.

2.6 Vehicle control: dedicated, permissioned command API; MAVLink in the adapter (proposed baseline) — adopted and tightenedLink to the section 2.6 Vehicle control: dedicated, permissioned command API; MAVLink in the adapter (proposed baseline) — adopted and tightened

Separate vehicle.* family, separate scope, mandatory leases with heartbeats, pilot precedence, device-enforced limits and geofence, 90-day audit. MAVLink mappings in Annex A.2.3.
Tightening: vehicle.hold, vehicle.return_home and vehicle.cancel are mandatory for any Profile N claim so that every Profile N device has a standard "stop" path.

2.7 Security: TLS, strong device identity, scoped tokens; mTLS for managed deployments (proposed baseline) — adopted and made stricterLink to the section 2.7 Security: TLS, strong device identity, scoped tokens; mTLS for managed deployments (proposed baseline) — adopted and made stricter

TLS 1.3 only. mTLS or OAuth 2.0 client credentials for devices; scoped JWTs for clients; passwords and digest schemes forbidden; schema validation mandatory; replay window; claim-code enrollment for field onboarding.

3. Summary tableLink to the section 3. Summary table

Function	Brief's baseline	Draft v0.1 mandatory	Draft v0.1 alternatives	Change
Video	H.264/WebRTC	H.264/WebRTC	H.265, RTSPS, SRT (SHOULD offer one for recording)	kept + recorder note
Telemetry	Protobuf/JSON, documented channel; MQTT alt	JSON over WSS session channel (+ WebRTC data channel SHOULD)	MQTT 5; Protobuf annex later	JSON chosen; channel made concrete
Events	MQTT 5 over TLS	JSON over WSS session channel	MQTT 5 with normative topic map	adjusted (broker-free baseline)
Configuration	HTTPS REST	HTTPS REST (OpenAPI 3.1)	gRPC (future)	kept
Camera control	Standard command API	`camera.*` JSON commands	ONVIF PTZ mapping	kept + `point_at`
Vehicle control	Permissioned command API	`vehicle.*` + leases	MAVLink in adapter	kept + mandatory stop path
Security	TLS, identity, scoped tokens, mTLS	TLS 1.3, mTLS or OAuth 2.0, scopes, leases, audit	—	stricter

4. What would change this assessmentLink to the section 4. What would change this assessment

Evidence that VMS vendors prefer a broker-based model (→ promote MQTT).
Evidence that WebRTC ingest is routine in recorders by 2027 (→ drop the RTSPS/SRT SHOULD).
A Protobuf binding request from two or more implementers (→ accelerate the annex).

Validation of the Proposed Transport BaselinesLink to the section Validation of the Proposed Transport Baselines#

1. Evaluation criteriaLink to the section 1. Evaluation criteria#

2. Assessment per functionLink to the section 2. Assessment per function#

2.1 Video: H.264 over WebRTC (proposed baseline) — adopted, with one additionLink to the section 2.1 Video: H.264 over WebRTC (proposed baseline) — adopted, with one addition#

2.3 Events: MQTT 5 over TLS (proposed baseline) — adjusted: WebSocket session channel mandatory, MQTT 5 as first alternativeLink to the section 2.3 Events: MQTT 5 over TLS (proposed baseline) — adjusted: WebSocket session channel mandatory, MQTT 5 as first alternative#

2.4 Device configuration: HTTPS REST (proposed baseline) — adoptedLink to the section 2.4 Device configuration: HTTPS REST (proposed baseline) — adopted#

2.5 Camera control: standard command API with ONVIF PTZ mappings (proposed baseline) — adoptedLink to the section 2.5 Camera control: standard command API with ONVIF PTZ mappings (proposed baseline) — adopted#

2.6 Vehicle control: dedicated, permissioned command API; MAVLink in the adapter (proposed baseline) — adopted and tightenedLink to the section 2.6 Vehicle control: dedicated, permissioned command API; MAVLink in the adapter (proposed baseline) — adopted and tightened#

2.7 Security: TLS, strong device identity, scoped tokens; mTLS for managed deployments (proposed baseline) — adopted and made stricterLink to the section 2.7 Security: TLS, strong device identity, scoped tokens; mTLS for managed deployments (proposed baseline) — adopted and made stricter#

3. Summary tableLink to the section 3. Summary table#

4. What would change this assessmentLink to the section 4. What would change this assessment#