Explicit video boundary
Name the upstream platform, protocol, bridge if any, and responsible owner before Callaba receives the feed.
Callaba begins only after the responsible agency or platform provides an approved video handoff. From that boundary, operators can receive compatible media, inspect it in Multiview, route approved outputs, and create operational recordings without treating Callaba as a drone, dispatch, evidence, or aviation system.
Document the handoff first, then validate receiving, viewing, routing, recording, access revocation, and reconnect behavior with the real upstream system.
Record who owns dispatch, flight control, airspace authorization, the upstream platform, evidence policy, and the approved video egress.
Use a compatible RTMP or RTSP handoff, or name and verify the separate bridge when downstream architecture requires SRT.
Place approved feeds in Multiview and route only the outputs and viewer roles accepted by the operating plan.
Treat Callaba recordings as operational media copies unless the agency's approved evidence system and policy explicitly govern a separate transfer.
Operators can validate the media path without expanding Callaba's role into mission control or regulated agency responsibilities.
Name the upstream platform, protocol, bridge if any, and responsible owner before Callaba receives the feed.
Give approved viewers a browser operations surface without granting aircraft-control or dispatch privileges.
Exercise primary and backup paths, reconnect behavior, access revocation, and recording retrieval with representative accounts.
Receive the documented platform output after the agency and authorized pilot have established the mission and aviation boundary.
Present approved live feeds to operational viewers without representing the media surface as a dispatch or incident-command system.
Bring compatible field feeds into a monitored wall, controlled routes, and operational recording on cloud or approved Linux infrastructure.
Start with the modules the operators need. Add the remaining capabilities as the production path, audience, and retention plan become clear.
Receive a documented compatible RTMP handoff with explicit access controls.
Give approved operators a browser view of accepted live feeds.
Keep prepared media inputs and operator recovery choices explicit.
Provide controlled playback for operational media after retention policy is defined.
Separate agency, aircraft, dispatch, aviation, and evidence responsibilities from Callaba's monitored ingest, Multiview, routing, operational recording, playback, and recovery layer.
No. Callaba starts at the approved video handoff and does not replace the drone platform, remote pilot, dispatch process, flight-control system, airspace authorization, or agency operating procedures.
Only if that exact upstream capability is documented and verified. The existing DFR guide records DJI FlightHub 2 livestream forwarding as RTMP or RTSP; if SRT is required, the architecture must name and validate a separate bridge.
Not by itself. A Callaba recording is an operational media copy unless the agency's approved evidence system and policies separately govern classification, chain of custody, retention, disclosure, and deletion.
The responsible agency and its authorized operators own the applicable aviation pathway, mission approval, pilot authority, and operating procedures. Those responsibilities remain outside Callaba.
No. It demonstrates the browser viewing surface only. Acceptance requires the actual upstream handoff, representative accounts, authorization boundaries, primary and backup paths, reconnect behavior, access revocation, and retention review.
Talk to our experts to learn about Callaba.
You can also email us at [email protected]