Wowza Failover: Source, Origin, Edge & Player

Map five failure domains

What Wowza’s secondary origin protects

In a Wowza live stream repeater setup, an edge application connects to an origin. The current configuration flow allows a Primary Origin URL and an optional Secondary Origin URL. If the primary origin fails, the edge can try the secondary. That protects the edge’s origin lookup; it does not automatically replicate every source, application setting, stream file, certificate or custom module required by the secondary origin.

Both origins must be able to serve the same intended live stream identity. Their applications, playback types and security must be compatible with the edge. Wowza notes that RTMP playback must be enabled on the origin application for the server-to-server repeater connection, even when the internal WOWZ protocol is used. Follow the exact installed Wowza release documentation rather than copying an old Application.xml fragment.

When Callaba belongs in front of Wowza

Use a contribution switch before the Wowza origin when two field encoders, two venue paths or two SRT feeds represent the same program. Callaba can make that source choice visible to the operator and send one selected output onward. This prevents the origin from having to infer which of two unrelated publishers should own the live name.

The separation is useful:

• Callaba contribution layer: receives source identities, exposes SRT health, selects primary or alternate route, and provides an operator override.
• Wowza origin layer: ingests the selected program and performs the configured origin processing and packaging.
• Wowza edge/delivery layer: scales playback and applies its own primary/secondary-origin recovery.
• Player layer: determines retry and visible recovery behavior on the audience device.

This is an integration pattern, not a claim that Callaba reconfigures Wowza automatically. Use a Wowza-supported ingest URL as the output of a verified Callaba route, and prove the handoff in the actual origin application.

Design the primary and backup feeds as one program

Source switching is easier when both encoders produce compatible media. Match codec, profile, resolution, frame cadence, GOP, audio sample rate and channel layout. If the origin or packager sees a materially different stream after the switch, it may restart decoders, create a discontinuity or reject the feed. Timecode and encoder timestamps deserve their own rehearsal when recordings or synchronized downstream systems depend on them.

The backup must also be independent enough to matter. Two encoders on the same power strip, switch and ISP protect only against an encoder process failure. Record the failure each duplicate is meant to cover—camera, encoder, LAN, carrier, region or origin—and avoid presenting partial redundancy as end-to-end high availability.

Run a layer-by-layer acceptance test

1. Baseline the program. Start primary and backup sources, verify both independently in Multiview, and confirm the primary route feeds the intended Wowza application.
2. Test manual switching. Change the active source from the Callaba operator surface. Measure the interval from the action to decoded media at the Wowza output and audience player.
3. Test automatic policy. Configure the approved health criteria, interrupt the primary, and record detection and switch timing. Repeat with network loss, encoder stop and malformed media because they may expose different signals.
4. Test recovery. Restore the primary and follow the documented return policy. A system that repeatedly flaps between sources is not ready.
5. Test the origin. Stop or isolate the primary Wowza origin and observe the edge’s configured secondary-origin behavior separately from source failover.
6. Test the player. Watch a real audience device through both failures. Record freezes, errors, audio discontinuity, latency change and whether the player required a reload.

Use the live Multiview and switcher demo to understand the operator surface. Build your acceptance result with your own primary, backup and Wowza path.

Common designs that look redundant but are not

Automate only the switch your test has defined

Callaba’s Live Video Failover API workflow is the second layer for an authenticated control system. The SRT server module includes a route-switching operation for selecting the active pull route. Use it after the system has a known primary, known alternates, observed health and an approved operator fallback.

An API command should be logged with the source, reason, requested route and outcome. It should not be treated as evidence that the Wowza edge or player recovered. Keep final media checks and alerting at the delivery boundary.

Official Wowza references

• Configure a Wowza live stream repeater — primary and secondary origin URLs, origin/edge setup and documented timeout behavior.
• Wowza Streaming Engine scaling overview — origin-edge, load balancing and capacity boundaries.
• Wowza dynamic origin resolution — optional multi-origin resolution module and configuration scope.

Frequently asked questions

Does Wowza Streaming Engine provide automatic failover?

It provides mechanisms for specific layers, including a secondary origin in a live stream repeater architecture. Source, instance, edge, DNS and player recovery remain distinct problems and need their own tests.

Can Callaba switch SRT sources before Wowza?

Yes. A Callaba failover workflow can receive primary and alternate SRT paths and send the selected program to a supported Wowza ingest. Verify media compatibility and the complete player-visible result.

Is the source switch seamless for viewers?

Not by definition. Detection time, source compatibility, timestamp continuity, origin packaging, edge recovery and player buffering all affect the interruption. Measure the result and describe it accurately.