Internet and redundancy for live streaming: bonding and failover.

You are about to stream a set, and the entire project depends on one thing you do not control: the connection. The venue’s fibre subscription delivers 200 Mbps download and perhaps 20 upload, and that asymmetry determines whether you can sustain 1080p50 at 6 Mbps with headroom or barely manage. On event day, roadworks, a storm or a saturated operator are enough to make the encoder stop delivering frames and the platform close the stream itself.

The solution is designing a network architecture with no indispensable piece, rather than buying more bandwidth. That means several uplink routes, a protocol capable of surviving packet loss, and local recording ensuring the material exists even if the live stream fails. This guide orders those decisions from greatest to least impact.

Redundancy: what fails and how it is covered

Before buying anything, separate failures by nature, because each is covered differently. There are access failures (the operator goes down, the building’s fibre is cut), equipment failures (the router restarts, the switch locks up) and quality failures (the link remains up but has loss and congestion). Only the first is solved with a second line; the other two are solved with configuration and monitoring.

The practical rule is that the second route must share neither medium nor provider with the first. One operator’s primary fibre and another’s secondary line, with a different physical entry, are real redundancy; two services from the same operator on the same cable are not: cut the cable and both fail. Without a second fixed line, the alternative is a 4G/5G modem as backup, accepting worse latency and stability.

The most common error is treating redundancy as a purchase rather than a procedure. Having two lines without ever testing switching means having one line and a false sense of security.

Primary fibre and its secondary line

Size the primary fibre sensibly. If your target is 6 Mbps video plus audio and overhead, that total must sit comfortably below 50% of measured actual upload, rather than the operator’s advertised figure. The remaining headroom absorbs peaks, SRT retransmissions and management traffic.

The secondary line enters through a different router interface or its own router. If it is another fibre, check that its entry shares neither trench nor cabinet with the primary. If it is 4G/5G, measure actual upload at the location and event time: a mobile link may deliver 40 Mbps at eleven in the morning and 4 Mbps at ten at night, exactly when you stream.

Configure and document both routes before setup, with reserved addresses and credentials available. Networks are not improvised during the show.

Bonding and dual-WAN: combining or switching

This is where architecture is decided. Dual-WAN is classic failover: it keeps one route active and the other in reserve; when the primary stops responding, the router switches and traffic leaves through the secondary. The interruption usually lasts from one to several seconds, enough for the receiver to cut off if the protocol cannot withstand that gap.

Bonding goes further: it aggregates several simultaneous routes and distributes the stream among them, combining capacity. An encoder bonding two modems and one fixed line can maintain the stream even if one of the three routes disappears, because the receiver reconstructs the stream from the packets that arrive. It is the natural option for mobile units, outdoor work and events without fibre.

Bonding’s trade-offs are added latency and dependence on a compatible receiver, usually from the same manufacturer or a cloud service. If that receiver is unavailable, bonding is useless. For a fixed venue, good dual-WAN with automatic failover and a gap-tolerant protocol is usually simpler and cheaper.

QoS and the production VLAN

With two routes and several services sharing the network, streaming traffic competes with everything else. QoS ensures the video stream leaves first: encoder traffic is marked with the highest priority, while the rest (updates, backups, guests) goes into lower classes. Without QoS, uploading photos over Wi-Fi may ruin the broadcast.

The production VLAN separates critical traffic physically and logically. The encoder, IP cameras and control live in one VLAN; guest Wi-Fi and the office network in another. That separation prevents an infected device or a laptop running torrents consuming the upload needed by the live stream, and makes coherent QoS rules easier.

In installations with audio over IP, the production network deserves its own addressing and policy. Mixing production-control traffic with office browsing is asking for trouble at show time.

Monitoring: bandwidth, packet loss, jitter and latency

Start with bandwidth monitoring: what is not measured cannot be defended. Before the event, measure each route’s actual upload with several tests at live-stream time. During the event, keep a dashboard visible with available bandwidth per interface, encoder bitrate and each link’s state.

Set the alarm threshold beforehand: if the margin between actual bitrate and measured capacity falls below 40%, reduce bitrate or resolution before the platform does it for you. A stable 720p50 picture is better than retaining 1080p50 and delivering a frozen broadcast.

Monitoring is not only technical: someone on the team must be responsible for watching the dashboard and alerting others. A graph nobody reads protects nothing.

Packet loss, jitter and latency

Bandwidth explains only part of the problem. Packet loss indicates the percentage of packets that do not arrive; above a sustained 1%, the picture starts showing artefacts and audio breaks up. Jitter measures variation in packet arrival time: high jitter demands larger buffers and more latency.

Total latency is the sum of encoding, transport, network and decoding. For a live stream with chat interaction, keeping it low matters; for a concert recorded for later, stability matters more. Every buffer decision trades resilience against delay.

When all three metrics deteriorate together, congestion is almost always present somewhere: a link shared with other uses, an overloaded router, or an operator overselling in the area. The correct response is reducing load and switching routes, rather than raising buffers indefinitely.

SRT for unstable links

SRT is designed precisely for this: it transports video over UDP, detects missing packets and retransmits them selectively, with a latency margin you configure. That lets it cross mobile or congested links without TCP’s penalty of slowing the entire connection after a loss.

In practice, configure SRT with recovery latency suited to the link: low on stable fibre, higher on 4G/5G. That value is not decoration; set it too short and there is physically no time to recover losses, producing artefacts.

RIST addresses a similar objective with profiles defined by its forum, and is a valid alternative when supported by the receiver. For consumer-platform outputs, RTMP remains the standard ingest, but SRT should be placed between the venue and aggregation point, where you control both ends.

Local recording even if streaming fails

No network architecture is infallible, so the last line of defence is on disk rather than the network. Record programme output locally at publishable quality and, if your switcher supports it, also record camera ISOs and multitrack audio. That recording depends on neither internet, operator nor platform.

Local recording must start before the stream and be verified within the first minute: check that the file grows, audio is embedded, and free space covers the expected show length. A full disk halfway through the set is the same disaster as a network outage, only avoidable.

With local recording, internet failure becomes an incident rather than a definitive loss: you lose the live broadcast, rather than the content. For more on programme capture, ISOs and multitrack audio, consult multicamera recording and multitrack postproduction.

Checking the architecture before the show

An hour before the event, run a short list and check results rather than intentions. Measure upload on each route separately; force primary failure and time how long the secondary takes over; verify bonding distributes traffic and the receiver reconstructs without breaks; confirm QoS is applied and the production VLAN receives no unrelated traffic.

If the target bitrate does not fit with headroom on the worst route, lower quality before starting. During the show, keep the monitoring dashboard visible and define who decides to switch. Afterwards, note what happened: an event’s network incidents are the best documentation for the next.

To understand how bitrate and codec govern all the above, review live streaming: encoding, bitrate and multistream; for transport options between venue and output point, see video transport: SDI, HDMI, NDI, SRT and fibre.

Next step

With the network resolved, the next concern is losing none of what is already on the desk: move to multicamera recording and multitrack postproduction to define what is recorded, how it is named, and how it is backed up before editing the aftermovie.