For cloud CCTV and distributed video surveillance, Callaba begins when a camera, gateway, or encoder hands off a compatible live feed. The operator can place that feed in browser Multiview, record the feeds the team has selected, and test a prepared recovery path. Camera fleet control, VMS functions, access control, and incident handling stay with the systems that already own them.
Keep contribution health, the operator view, and the selected recording target in the same workflow instead of hiding failures behind an isolated player.
Receive the SRT, RTMP, RTSP, or NDI handoff that the camera, site gateway, or encoder is verified to publish.
Place approved feeds in browser Multiview so the operator can confirm picture and source state before relying on the path.
Configure primary and backup SRT PULL routes, then validate reconnect and routing-host fallback after a controlled disconnect.
Record selected feeds for review or controlled playback after the team has set the storage target, capacity, and retention policy for this deployment.
Camera menus and protocol support vary by model and firmware. Earlier Callaba walkthroughs used a UNV DC12V PoE camera to demonstrate two useful paths. Treat that device as an example, then confirm the output mode, codec, address format, and credentials on the camera being deployed.
Use this route when the camera can publish RTMP or RTMPS. Create a controlled Callaba publisher, copy its server address and stream key into the camera, then confirm publisher identity, bitrate, decoded picture, and audio.
Use this route when the camera provides UDP but the destination expects RTMP. Receive and validate the camera output in Restreaming, then configure the required RTMP destination. Older examples used UDP port 2335 and a local RTMP target; choose ports and destinations for the current deployment instead of copying them blindly.
Product boundary: Callaba begins at a compatible video handoff and can monitor, route, record, and play back reviewed video paths. Connecting a camera does not make Callaba a VMS, camera-fleet or ONVIF/PTZ controller, physical-access system, incident-management system, or evidence archive.
Start with one representative site, not the final camera count. Record the source format and measured bitrate, decide who needs the live view, and choose the retention window. Those inputs expose network, storage and access questions before the same assumptions are copied across every location.
Operating boundaryCallaba starts at a compatible video handoff. This workflow does not add camera-fleet provisioning, PTZ or ONVIF control, alarms, forensic search, incident management or physical access control.
The workflow stays useful before, during, and after an operational event because operators can see the live source and retain selected media on storage controlled by their team.
Combine approved feeds in one browser wall without giving every viewer access to the management UI.
Keep primary and backup inputs explicit so operators know which source is active.
Record continuously or selectively, inspect completed media in File Manager, and use the storage target, capacity, and retention policy selected for that deployment.
Watch stores, campuses, venues, construction sites, or industrial locations from a central operations room.
Bring temporary camera feeds into a monitored wall and retain the feeds required for review; incident response and access decisions remain external.
Combine live contribution, signal health, and recording for distributed technical sites.
Deploy the streaming, monitoring, and recording layer on infrastructure selected by the integrator while keeping camera and physical-access systems separate.
Start with the modules the operators need. Add the remaining capabilities as the production path, audience, and retention plan become clear.
The browser-based operator wall for live inputs.
Prepared primary and backup SRT PULL routes with reconnect and fallback after a disconnect.
Continuous or operator-selected recording with storage and retention validated for the deployment.
Controlled browser playback for retained media.
Reliable contribution from remote locations.
Turn feed count, measured bitrate, recording hours, retention days, and an optional backup copy into a transparent CCTV storage baseline.
Plan source ownership, Multiview monitoring, recording location, retention, and recovery without treating Callaba as a VMS or physical-access platform.
Create and start the Multiview through the REST API, then connect recording and storage modules when the operating policy is stable.
Yes. Approved live sources can be arranged in a Multiview so an operator can watch several locations from one browser surface.
Yes. Recording and storage are separate modules. The team decides which feeds to retain, then validates the storage target, permissions, capacity, and retention policy for its deployment.
No. Callaba starts at a compatible live-video handoff and can operate reviewed monitoring, routing, recording, and playback paths. It does not provide camera fleet management, ONVIF or PTZ control, VMS functions, incident alerting, surveillance archive search, evidence management, or physical-access functions.
Yes. Callaba can run in the cloud or on a self-hosted Linux server. Network, storage, retention, permissions, and governance requirements remain deployment-specific.
Yes. A reviewed SRT PULL workflow can keep several routing hosts configured and use reconnect and fallback behavior after a disconnect. Recovery time and any release-specific manual action must be validated with the real encoders, buffers, and network.
