Cloud deployment
Deploy a Callaba instance near the contribution or delivery region and configure primary and backup SRT upstreams in the web interface.
Deploy Callaba on AWSPrimary and backup source control
Callaba Live Video Failover
Configure a primary SRT path and alternate PULL routes, then test reconnect behavior and the receiving destination before the event.
Keep main and backup SRT sources on one operational path
This released SRT recovery path switches at the transport layer between prepared main and backup feeds while keeping downstream receiver and puller connections in place.
Main sourcePrepared main feed with visible stream state
Backup sourcePrepared backup feed with matching operational checks
SRT PULL relayTransport-level main/backup switching that does not depend on a particular audio or video codec
DestinationReceiver and puller connections stay attached through switching
Prepare the SRT PULL recovery path
- Open Routing settings
- Choose SRT Routing, select SRT main/backup failover, set Routing mode to Pull, then add each Routing Host and Routing SRT Port with Add SRT Host.
- Match the connection details
- Check the SRT mode, port, latency, stream identity, and passphrase where the chosen sources use them.
- Set the operating policy
- Confirm the released manual or automatic main/backup behavior and test return from backup to main on the actual contribution path.
Check the path your event will actually use
Test with the event encoder, network, relay, and destination. Record what happened on this path instead of assuming another source pair will behave the same way.
- Interrupt the main sourceDuring a planned window, interrupt the main feed and observe main-to-backup switching, downstream continuity, stream statistics, and connection events.
- Check the destinationConfirm the receiving platform or receiver accepts the recovered feed; a running relay alone does not prove delivery.
- Check return to mainRestore the main feed and verify the configured return behavior alongside the event and log history for this deployment.
Deployment
Use the same failover model in cloud or self-hosted Callaba
Choose where the SRT routing layer runs, then configure the upstream set around your network and production boundary.
Self-hosted deployment
Run Callaba Engine on Linux when the routing hosts, network access, and operational data must remain in your infrastructure.
Install on LinuxLive video failover questions
What does Callaba Live Video Failover do?
It keeps main and backup SRT feeds in one released transport-level workflow, switches between them without depending on a particular media codec, and preserves downstream receiver and puller connections through the switch.
What happens when the active upstream disconnects?
The released workflow can switch from main to backup while preserving downstream receiver and puller connections. Actual recovery behavior remains specific to the prepared sources, network, buffers, and destination.
Can the workflow return from backup to main?
Yes. The release improves switching back from backup to main and aligns manual and automatic failover behavior. Test the configured behavior with the real sources and destination before an event.
Will downstream receivers stay connected during SRT failover?
The released transport-level workflow preserves downstream receiver and puller connections through a main-to-backup switch. The visible recovery still depends on the prepared sources, network buffers and destination.
Can SRT failover switch automatically from main to backup?
Yes. The released workflow supports manual and automatic main-to-backup switching, while preserving downstream receiver and puller connections. Test the configured sources, network buffers and destination before an event.
Prepare before going live
Build a primary and backup path you can test
Use the live demo to inspect the operator surface, then deploy Callaba in the cloud or on Linux to test your main/backup switching, return behavior, destination acceptance, and event/log visibility.