Setting up High-Availability Ingest and Clients

High availability ingest leverages the independent and fault tolerant architecture of the Phenix platform to provide streams that can withstand the failure of individual data centers or components therein that would interfere with the health of a stream.

High-Availability logic is only available for content published to Channels, not for content published to Rooms.

Possible single points of failure include:

  1. Capture hardware that is running the publisher software

  2. The ISP that the publisher is using to access the internet

  3. The Phenix data center to which publisher is publishing

  4. The stream within the channel

 

 

To be fully redundant, a publisher would have separate capture hardware, encoder and/or RTMP hardware, ISPs, data centers, and streams within channels (screenNames).

 

Setting up HA does not guarantee that the streams will end up on separate egress infrastructure.

This page shows how to set up ingest for high availability, as well as how to set up clients to take advantage of high-availability streams. There are two levels of redundancy discussed in this document: physically separate data centers and redundant streams within a channel; redundant capture hardware, encoder and/or RTMP hardware, and ISPs are out of the scope of this document.

Using alternate ingests is less efficient in terms of internet routing. This is a necessary compromise to ingest into a different data center.

Screen Names

Any screenName containing the string “primary” is considered primary, and any screenName containing the string “secondary” is considered an alternate stream having the same content as the primary stream. The string is not case-sensitive.

Should a failure event occur when using a channel, clients that have been set up to take advantage of high availability will automatically fail over from the primary to the alternate or secondary stream.

When there is more than one primary stream, the data centers spread the load across primary streams. If no primary streams are available, the load is spread across all secondary streams.

When both stream paths are equal, we recommend using using “primary” in the screen name for both streams. If one path is preferred to the other (e.g., one path uses an ISP that has higher quality of service than the other), the screen name of the stream corresponding to the preferred path should include “primary” while the screen name of the stream corresponding to the less-desirable path should include “secondary”.

Ingest Setup

Phenix Encoder Ingest

When using Phenix encoders, set up data centers and screen names as described in this section.

Data Centers

To use multiple data centers for Phenix encoding, use the following hosts for ingest:

Screen Names

To create screen names, use the CLI option: --screen-name=screenName

For example, to create a primary stream, use --screen-name=myPrimaryStream. To create a secondary stream, use --screen-name=mySecondaryStream.

RTMP Ingest

When using RTMP ingest, set up data centers and screen names as described in this section.

Data Centers

To use multiple data centers for Phenix encoders, contact your Phenix support representative.

Screen Names

When one stream path is preferred to another’s, the preferred stream’s screen name should include the string “primary” while the less desirable stream’s screen name should include the stream “secondary” as shown in the examples below.

  • rtmp://ingest.phenixrts.com:80/ingest/<streamkey>;screenName=myPrimaryFeed;capabilities=hd

  • rtmp://ingest-secondary.phenixrts.com:80/ingest/<streamkey>;screenName=mySecondaryFeed;capabilities=hd

It’s possible to have multiple primaries and alternates within a data center by providing unique screen names, for example:

  • rtmp://ingest.phenixrts.com:80/ingest/<streamkey>;screenName=primary;capabilities=hd

  • rtmp://ingest.phenixrts.com:80/ingest/<streamkey>;screenName=secondary;capabilities=hd

Notes

  • You can use any capabilities that you normally would use.

  • For informational purposes only, you can verify the latency from your site with ping ingest.phenixrts.com and compare it against ping ingest-secondary.phenixrts.com

Client-Side Setup

The client side integration of high-availability logic is simple. In order to leverage the redundant ingest streams, client SDKs need to be configured to treat them as equivalent with the high-availability subscription option.

Clients connect to whichever data center is closest. If the closest data center is unavailable, the client will connect to the next closest data center.

Mobile

When building the join-channel options, ensure that the High Availability stream selection strategy is set as shown in this section for the client platform.

iOS

let joinChannelOptions = PhenixChannelExpressFactory.createJoinChannelOptionsBuilder() .withStreamSelectionStrategy(.highAvailability) ... .buildJoinChannelOptions() channelExpress.joinChannel( joinChannelOptions, {(requestStatus: PhenixRequestStatus, roomService: PhenixRoomService?) in ...

For further details, please refer to the documentation.

Android

final JoinChannelOptions joinChannelOptions = ChannelExpressFactory.createJoinChannelOptionsBuilder() .withStreamSelectionStrategy(StreamSelectionStrategy.HIGH_AVAILABILITY) ... .buildJoinChannelOptions(); channelExpress.joinChannel( joinChannelOptions, (RequestStatus status, RoomService roomService) -> { ...

For further details, please refer to the documentation.

Web

To leverage high-availability on the Web SDK, add the streamSelectionStrategy to the joinChannel options:

var options = { ... streamSelectionStrategy: ‘High-Availability’, ... }; channelExpress.joinChannel(options, ...

For further details, please refer to the documentation.

Related articles

 

©2020-2021 Phenix Real Time Solutions, Inc.