Redundancy can be as simple or as complex as you require. Stream redundancy is different depending on the type of stream setup, typically "audio" or "premium". This article looks at the failover and redundancy options available with a premium-type stream.

With premium streams, there are 2 layers of failover and 2 layers of redundancy working in tandem:

  • Ingest Layer Failover (a-feeds + b-feeds)
  • Configuration Layer Failover
  • Ingest Redundancy
  • Edge Redundancy


Failover + Redundancy types

Ingest Layer Failover (a-feeds + b-feeds)

Redundancy in the ingest layer means sending the encoder output to the same mount on two different ingest servers, referred to as a-feed + b-feed.

Failover in the ingest layer provides stability in scenarios where:

  • Streaming software on the a-feeds server locks up;
  • Changes to the configuration layer (see below) require a stream restart to be implemented;
  • Ingest moves to the secondary ingest due to upstream providers or hardware becoming compromised. 

Failover in the ingest layer will not provide coverage for client-side encoder outages or silences, this is the responsibility of the configuration layer failover detailed below. For this reason, we recommend that your a-feed and b-feed contributions originate from the same machine with identical audio settings to ensure consistency between the two.

Configuration Layer Failover

The configuration layer dictates the failover behaviour when the client contribution to the primary mount (Mount A) is compromised. This is replicated on both the a-feeds (primary) and b-feeds (secondary) ingests.

The following schematic indicates a setup containing a secondary encoder mount (Mount B) within the premium failover hierarchy. By default, premium streams DO NOT have this enabled, instead falling straight to a Timbre feed/playlist.

The configuration layer will be triggered in scenarios where: 

  • The client playout system fails and the stream is silent; or
  • The client encoder fails and is disconnected.

Should any of the layers be missing, unavailable or silent, it will move to the next.

SharpStream Premium feeds contain Mount A + Playlist + Silence as standard. If you are a client wishing to accommodate a second encoder mount (Mount B), please contact our support team.

Ingest Redundancy

Redundancy in the ingest server layer combats outages that occur with our upstream providers, be that network, datacentre, general internet, or otherwise, and it also combats hardware failure that can happen unexpectedly. The ingests are located in different sites and are served by different transit providers, and contain identical configurations for all mounts. Should the primary ingest be compromised, an alternative server will serve the contributions to the edge servers.

Edge Redundancy

Redundancy on the edge server layer spreads the traffic footprint generated by connected audiences and mitigates the impact that maintenance or an outage could have on listeners. In the SharpStream Network, there are six edges split across two sites and served by two different transit providers. 

The Total Setup

The following schematic indicates a setup containing a secondary encoder mount (Mount B) within the premium failover hierarchy. By default, premium streams DO NOT have this enabled, instead falling straight to a Timbre feed/playlist.


Let’s look at a few scenarios and what the expected impact will be on stream redundancy.

The Setup:

Station A has the full premium failover + redundancy set up, and this includes:

  • Contributing from the primary site to Mount A on the primary ingest and the secondary ingest;
  • Contributing from the secondary (disaster recovery) site to Mount B on the primary ingest and the secondary ingest;
  • Configured failover processes to include specifications around failure behaviour, silences and recovery behaviour;
  • Curated playlist for fallback purposes. 

In each of the below scenarios, red will indicate the route that has become compromised, green will indicate the active route and purple indicates the routes that are configured and available but not in active use.

Scenario 1: Customer suffers an outage

When the customer suffers a power or internet outage, the primary site will be compromised and the active contribution flow will switch to the secondary (disaster recovery) site. The same impact will be seen if the customer's encoder becomes disconnected for any other reason, such as a playout system failure.

In the event that the customer’s secondary site fails as well, for example, if it suffers a power outage, internet outage, playout system failure or encoder failure, the audio source would change to playlist and no audience disruption will be experienced. Should the playlist fail, the final mitigation measure is the insertion of silence from the configuration layer. 

As the customer recovers from the outage, the audio source will revert back to the primary source, Mount A.

Scenario 2: SharpStream suffers an outage

During an ingest server outage, the primary ingest with the configuration layer will be compromised and the secondary ingest will take over. 

Once the primary ingest recovers, it will take over from the secondary ingest seamlessly and no audiences will be affected.