Preconfigure the allowed upstream set
Attach multiple routing hosts to an SRT server and keep the selected active route at the front of the reviewed source order.
Primary and backup source control
Callaba Live Video Failover
Keep primary and backup SRT upstreams in one reviewed routing set. After a disconnect, the relay can reconnect and cycle through those prepared sources according to the configured loop and reconnect settings.
Visible reliability workflow
Primary source, backup source, controlled output
Define the upstreams before the event, keep the preferred route first, and validate reconnect and source cycling with the real encoder, network, and destination.
- Preconfigure the allowed upstream set
- Callaba Live Video Failover
- Reconnect and cycle after a disconnect
- Prepare the preferred route before a controlled run
Verified operating boundary
Failover built from configured SRT upstreams
The product keeps recovery bounded: reconnect and cycling use only the upstream set reviewed by your team.
Reconnect and cycle after a disconnect
The SRT PULL relay can run in loop mode with a reconnect interval and move through the configured upstream list when the active connection is lost.
Prepare the preferred route before a controlled run
An operator or API client can persist an existing upstream as the preferred active route. Apply that choice before a controlled start or restart; it does not reload a running relay instantly.
Use cases
Protect contribution workflows that cannot depend on one source
Use the product where teams can prepare primary and backup SRT contribution paths before going live.
Live events with a backup encoder
Keep primary and backup encoder endpoints in one reviewed source set so the operator has a prepared alternative during production.
Remote contribution over variable networks
Prepare more than one reachable upstream when a remote venue or network path may disconnect during a contribution session.
Long-running channel operations
Use configured source redundancy for continuous workflows that need an explicit recovery path and operator visibility.
Read-only stream-health assessment
See the live path before changing it
Pair Multiview with current SRT/RTMP operator telemetry to understand live state and establish a normal baseline from observed samples.
- 01
Observe the live state
Place program pictures beside current source state, bitrate, and SRT RTT where available.
- 02
Establish a working baseline
Compare live observed samples with the normal bitrate, RTT, and source-state range for this production.
- 03
Review reason-coded warnings
Turn deviations into clear operator warnings and require approval before any route change.
RECOVERY EVIDENCE
A failover test should leave a record, not a hunch
Run the test during a controlled window. Note when the primary stopped, when the problem became visible, which prepared path resumed, and when the destination was usable again. Keep the result with the exact encoder, buffer, destination and network used for the test.
- BASELINE
Baseline
Record the active source, destination and normal operating state before the interruption. Without that baseline, the recovery result has no useful comparison.
- INTERRUPTION
Interruption
Write down the deliberate action and the time it occurred. Separate the source stop from the moment an operator or system first noticed the loss.
- PROGRAMME RECOVERED
Programme recovery
Identify the prepared path that resumed and the point when the real destination became usable, not merely when a control surface changed state.
- DECISION
Decision
Review the result before changing recovery policy. Keep the operator step when the measured behavior or downstream requirement still needs human approval.
TEST ENVIRONMENT
Operating boundaryThis record describes reconnect and recovery behavior in one tested deployment. It does not demonstrate a hitless transition or establish a universal recovery-time promise.
Technical specification
What the product supports, and what to verify
Supported behavior sits beside a practical acceptance check. The installed Callaba interface and the real source, destination, and infrastructure profile remain authoritative.
| Capability | Supported behavior | Acceptance check |
|---|---|---|
| Preconfigure the allowed upstream set | Attach multiple routing hosts to an SRT server and keep the selected active route at the front of the reviewed source order. | It keeps reviewed primary and backup SRT upstreams in one routing workflow and lets the relay reconnect and cycle through that configured list after a disconnect. |
| Reconnect and cycle after a disconnect | The SRT PULL relay can run in loop mode with a reconnect interval and move through the configured upstream list when the active connection is lost. | A relay configured in loop mode can reconnect and move through its existing upstream list. Actual recovery time depends on the connection and the prepared sources. |
| Prepare the preferred route before a controlled run | An operator or API client can persist an existing upstream as the preferred active route. Apply that choice before a controlled start or restart; it does not reload a running relay instantly. | Yes. An existing routing host can be saved as the preferred active route before a controlled start or restart. Saving that preference does not instantly reload a relay that is already running. |
| Live events with a backup encoder | Keep primary and backup encoder endpoints in one reviewed source set so the operator has a prepared alternative during production. | No. The product provides a controlled recovery path, but it does not claim a hitless transition or guaranteed zero downtime. Source readiness and network conditions still matter. |
| Long-running channel operations | Use configured source redundancy for continuous workflows that need an explicit recovery path and operator visibility. | The SRT Servers API can manage the reviewed routing hosts and persist the preferred active route. It does not turn that configuration update into an immediate live switch of the running relay. |
| Observe the live state | Place program pictures beside current source state, bitrate, and SRT RTT where available. | This is a read-only assessment. It does not claim predictive AI, end-to-end QoE, root-cause diagnosis, durable SRT history, or an automatic live switch. |
Continue in the product
Set it up in Callaba. Then check the full path.
You have seen what the product does. These three guides take you into the exact controls, show what to connect next, and give you a practical check before the workflow goes live.
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.
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 AWSSelf-hosted deployment
Run Callaba Engine on Linux when the routing hosts, network access, and operational data must remain in your infrastructure.
Install on LinuxAPI is the second layer
Open the live video failover solution recipeManage an already reviewed recovery plan
Use the SRT Servers API to manage the server, routing hosts, and preferred active route for an SRT PULL workflow. The preferred route is configuration for a controlled start or restart, not a live switch of the running relay.
- Configure the SRT server and its approved routing_hosts
- Read the saved server configuration and enabled state
- Persist the preferred existing route before a controlled start or restart
Live video failover questions
What does Callaba Live Video Failover do?
It keeps reviewed primary and backup SRT upstreams in one routing workflow and lets the relay reconnect and cycle through that configured list after a disconnect.
What happens when the active upstream disconnects?
A relay configured in loop mode can reconnect and move through its existing upstream list. Actual recovery time depends on the connection and the prepared sources.
Can an operator prepare a different preferred source?
Yes. An existing routing host can be saved as the preferred active route before a controlled start or restart. Saving that preference does not instantly reload a relay that is already running.
Does this promise hitless or zero-downtime switching?
No. The product provides a controlled recovery path, but it does not claim a hitless transition or guaranteed zero downtime. Source readiness and network conditions still matter.
What can the API automate in this workflow?
The SRT Servers API can manage the reviewed routing hosts and persist the preferred active route. It does not turn that configuration update into an immediate live switch of the running relay.
Prepare before going live
Build a reviewed primary and backup path
Use the live demo to inspect the operator surface, then deploy Callaba in the cloud or on Linux for your own SRT routing plan.