Efficient tools to build your streaming infrastructure


Deliver and receive SRT bonded streams with Nimble Streamer

Secure Reliable Transport bonding is a technology used to aggregate multiple internet connections to improve the stability and speed of data transmission. SRT bonding lets you combine different types of network connections, like broadband, cellular, and satellite, in order to give you a more reliable stream delivery.

SRT bonding can operate in two modes: Broadcast and Main/Backup.
Here are the setup details for these two modes in Nimble Streamer.

Prerequisites

  • Two virtual or physical Linux servers with Nimble Streamer installed (preferably Ubuntu) or one Nimble Streamer server and a encoder device or software that supports SRT Bonding.
  • Nimble Streamer instances registered in WMSPanel, with latest updates.
  • Nimble has libsrt 1.5 package installed.
  • At least two network interfaces are dedicated to receiving bonded streams.
  • At least one network interface is dedicated to viewing streams on the receiving side.
  • A stream which is received by any preferred protocol to transfer via bonded connection

Install libsrt 1.5 using the following command if it’s not yet installed:

sudo apt-get install nimble-srt-1.5

This is an advanced setup. It’s assumed that you have some experience with networking and SRT before attempting this type of setup. Basic knowledge of sending and receiving MPEGTS streams with Nimble is also required. Read more about SRT setup details and MPEGTS setup.

Abstract of bonding modes and usage patterns

The SRT protocol provides two different modes for bonded streams. Nimble Streamer may use both Broadcast and Main/Backup modes.

Broadcast mode sends data over all links in a group simultaneously. If a link fails or has issues, the data still arrives via another link. The receiver discards any duplicate packets.

The receiving side receives the redundant streams on two or more NICs specified by IPs for the bonded group. These NICs can be connected to different ISPs or different network types (e.g., wired and cellular or just different ISPs) and will provide a stable stream even if one of the links fails. SRT will find the proper route to deliver a stream, but a specific interface could also be specified.

In Main/Backup mode, only one primary link handles data transmission at a time, while backup connections remain on standby. This setup aims to detect potential link failures early, allowing for a smooth switch to a backup link if the primary one fails.

Please note that we used local networks in our screenshots to simplify the explanation. In a real-world scenario, it would be public IPs.

Nimble supports sending streams in Caller (Push) mode and receiving streams in Listener mode.

Please refer to the official bonding guide to get more details.

If you have suggestions about bonding improvement in Nimble Streamer, don’t hesitate to send us a message with your feedback.

Sending Bonded Streams

We assume you have already received some stream in Nimble. We will refer to it as ‘live/bbb’ in our screenshots, as it’s a regular test file with Big Buck Bunny video pushed by FFmpeg and received by any of the supported Nimble protocols.

To send this stream to the bonded SRT group, navigate to UDP Streaming -> Add SRT setting. Specify mode as Push.
The Remote address field is the first IP of the remote interface that will receive the first bonded stream. Alias, Description, and Tags are optional, but will help identify and group the settings later.
Fill in Source application name and Source application name with the stream details to send.
It’s all like a regular setup yet.

Now the most important thing: fill in srt-bonding-enabled in the additional options and set its parameter to true to enable the bonding.

The next option is srt-group-nodes which may have a list of destination IPs and ports separated by commas.
These are IPs assigned to remote NICs. Here, we use local addresses, but in a real-world scenario, it would probably be some public IPs from different networks. Several addresses can be used here.

It’s assumed that different networks are reachable via different NICs, but additionally you may specify the NIC to use for the specific destination. Use %<interface> after the IP, e.g. to deliver traffic for the 192.168.2.44 via ens224 interface, add 192.168.2.44%ens224. It is probably needed in rare cases, as the SRT should route traffic properly.

The srt-group-type defines the bonding’s mode. Type in broadcast for broadcast mode or backup for backup mode.

Here’s the list of bonding-specific options:

  • srt-bonding-enabled: Set this parameter to true to enable bonding.
  • srt-group-nodes: List of destination IPs and ports, separated by commas.
  • srt-group-type: Defines the bonding mode. Acceptable params are either broadcast or backup.

Don’t forget to add latency and maxbw, these are crucial to the stability of a stream, as we explained earlier. We also recommend to set maxbw to 0 to let the SRT library auto-select bandwidth efficiently and handle re-transmission of lost packets.

Click the Save button and allow Nimble to sync settings with WMSPanel.
Now continue with the setup on the receiving server.

Receiving bonded streams

Switch to the receiving server in WMSPanel. The setup is performed just like in case of regular stream reception but with some additional bonding options. Both broadcast and backup modes can use the same receiving settings. The interface’s IPs and ports that are receiving the bonded stream are enumerated.

Go to Live streams settings, MPEGTS In, and Add SRT stream. In the opened dialog, set Receive mode to Listen.

Local IP’ and ‘Local port’ options refer to the IP and port of the first interface dedicated to receiving stream.

srt-bonding-enabled’ is the parameter that enables bonding, and must be set to true.

Next, the ‘srt-group-nodes’ parameter defines the IP and port of additional nodes participating in bonding. Here we define the second interface’s IP and port. If more interfaces are used, then use commas as delimiters between them.

Specify the output of the received stream via the Add outgoing stream option as usual. We use bonded/out in the screenshots meaning the stream that was received via bonded interfaces. It will be defined in MPEGTS Out.

As the best practice, we recommend using the additional dedicated interface for viewing the received stream.

Click Save and after syncing up and a few moments later, the stream will be received.
Notice that if you’re editing settings on either the sending or receiving side (e.g. bonding type or any other), you must restart the source stream on the receiving side.

Check up the resulting bonding

The first check is simple: go to ‘Live Streams’ menu page to see if the stream has been received.

To make sure the traffic is flowing on both interfaces, you may use any preferred tool.

Notice that WMSPanel doesn’t show additional information about bonded publishers and its statistics at the moment. Contact us if you need it.

To make sure the traffic is flowing on both interfaces, you may use any preferred traffic monitoring tool. (e.g. nload, iftop, etc)
We’ll show you how the traffic looks in a brief screenshot with the free Speedometer Linux tool.

After the above setup, let’s run the traffic viewing utility on different interfaces. You will notice that the outgoing stream will be available whenever you put any bonded interfaces down.

The ens160 (192.168.0.61) is the interface for viewing streams, and ens224 (192.168.1.10:49501) and ens256 (192.168.2.44:49502) are bonded interfaces of the receiving side. The broadcast mode is shown here.

You may see that the traffic graph has the same shape. Output HLS works seamlessly whenever the traffic is out on any of the interfaces that were forcefully put down or shaped. And not a single 404 error in a video player.

In conclusion, implementing SRT bonding with Nimble Streamer opens up new possibilities for achieving reliable and high-quality stream delivery, even in challenging network environments. Following the steps above in this guide, you can enhance your streaming infrastructure’s resilience and ensure a seamless viewing experience for your audience. We welcome your feedback and feature requests, particularly regarding support for additional bonding modes.