The Latest Updates to SRT and RIST
By Adi Rozenberg, CTO & Founder - AlvaLinks
I was asked to write an overview of the recently added features and new capabilities from SRT and RIST. As a result, the goal in this article is to highlight what is new and exciting in both protocols and what to expect on the roadmap for these products.
For those readers who are not familiar with the streaming protection delivery protocols, I recommend background research of how SRT (Secure Reliable Transport) became an open source library in 2017 (https://en.wikipedia.org/wiki/Secure_Reliable_Transport and can be found in many open source implementations such as FFMPEG, VLC, OBS Studio, GStremear and also in commercial products. The protocol is promoted by a strong coalition of companies within the SRT Alliance and its supporting maintainer Haivision, which has provided development and maintenance of the SRT code ( https://github.com/Haivision/srt ).
In parallel RIST (Reliable Internet Stream Transport) is a collaborative effort within the Video Services Forum (VSF) by participating video and streaming transport companies drawing from professional experiences to define an interoperable protocol (see https://en.wikipedia.org/wiki/Reliable_Internet_Stream_Transport ). The RIST specification draws from the collective commercial and field experience of participating companies such as AT&T, AlvaLinks, ARRI, AWS, BBC, CBS, Cisco, Cobalt, DVEO, Haivision, Evertz, Media Transport Solutions, NetInsight, Nevion, QVidium, Turner, VideoFlow, and Zixi. The RIST specification allows each vendor to implement a RIST solution specific to their own requirements, while including additional features unique to their own products. An open-source library, LibRIST, is available and can be found today in VLC, FFMPEG, OBE Studio, GStreamer and many other commercial products.
Many technical articles have been written in the last 5 years on the technical foundations of RIST and SRT. This information is readily available on the Internet. This blog will focus on the more recent features of both protocols.
In June 2022 SRT released a long-awaited update (ver. 1.5.x) with several key features that are very important to the users. I will briefly explain each new feature and its application to real-world scenarios. These features are:
Connection Bonding
Main/Backup Mode
SRT Access Control (Stream ID) and SRT Live Server
Wide use of SLS (SRT Live Server) adoption
Connection Bonding
Beginning with the new SRT 1.5.1 (https://github.com/Haivision/srt), in addition to bug fixes, the new Connection Bonding mode is a very important and welcomed advance for SRT to keep up with one of the initial features of RIST, released in 2018 with VSF TR-06-1. Connection Bonding is similar in nature to the industry standard SMPTE-2022-7 (a.k.a., seamless switching). This is the ability to stream the same feed over multiple links or paths to assure continuous delivery if one link goes down. Before this capability, the user had no way to duplicate and send the same content to the destination, as each SRT connection was unique. But now, this feature facilitates combining multiple connections (links, ISPs, paths) to reach the same destination.
SRT users can now use more than one Internet service provider to ensure that their feed will arrive at the destination, without relying upon a single service provider to operate and be available 100% of the time. For example, the user can use a landline and cellular connection combined to make sure that content like E-Gaming, Video blog, Facebook live will continue to function even if one of the internet service providers has a degradation in service. This feature does come with additional SRT error recovery that some may find a limiting as it consumes overhead.
This feature is a welcome addition to SRT capabilities but it is exceeded by the capability of the RIST Boding & Load Share capability (https://www.rist.tv/articles-and-deep-dives/2020/6/16/rist-bonding-and-load-sharing-demystified). What sets these two features apart? The seamless switching capability within SRT is great but often the connectivity budget does not support enough bandwidth to transport the entire stream. A better practice is to divide the stream to smaller portions and send the different portions over separate connections (links/paths) to be reassembled at the destination. Overloading a connection may result in very high packet loss the other connections cannot recover due to bandwidth limitations and connection latency. Since the path capacity may change due to network performance, a combined, multi-link path can provide bandwidth needed to better support fluctuating conditions and support error free and reliable delivery to the satisfaction of the end-user. My suggestion to the folks maintaining the SRT libraries is to adopt either static or dynamic load sharing in future coming releases.
Main/Backup Mode
In a Main/Backup configuration, only one link at a time is used for data transmission (the Main), while other connections (the Backup) are on standby to ensure the transmission will continue should the main link fail. The goal of Main/Backup Mode is to identify a potential link failure before it occurs, providing a window in which to seamlessly switch to an available backup link. I have specifically tested with this mode during the beta release and after it was implemented. I found that the switching time does not react fast enough. In order to have 100% error-free recovery, the solution was to increase the latency and the bandwidth (overhead). I found the recovery algorithm acting as the switch caused a tremendous spike in packet retransmission that occasionally suffocated the backup link and caused more harm than good.
In RIST, this mode is handled as an application by most product implementations. The biggest difference is that a RIST implementation may elect to keep both connections active for easier reconnection or just decide on a 90/10 ratio between the two connections for even faster switch over.
SRT Access Control (Stream ID) and SRT Live Server
SRT access control (https://github.com/Haivision/srt/blob/master/docs/features/access-control.md) has been available for several years and was initially used as another layer of stream selection verification between two peers, like a second layer of authentication. StreamID can be used for:
· Identifying the file name of a stream that is about to be sent (simple use case);
· Identify the user and purpose of the connection (receive or send), the resources, and additional functions (further below).
Recently I became aware of a wonderful application undertaken by the SRT community, the SRT Live Server (https://github.com/Edward-Wu/srt-live-server). This solution is based on a server with a single listening port allowing remote clients to connect to local SRT Client resources. The mapping between internal resources, files and/or streams, and external connection, is based on the StreamID string values. This is a great solution for:
· Users that don’t want to expose unnecessary ports to the Internet.
· Multiple resource sharing, such as a single stream sent as unicast to a multitude clients.
· Correlating a remote connection to an internal resource.
I know of several organizations beginning to use these capabilities and commercial solutions adding Security Level features that are missing from the SRT open-source library.
The RIST Activity Group studied this feature earlier in 2022 to determine if such application could be supported. The outcome was released as VSF TR-06-03 RIST Advanced Profile. This release includes the option to add Stream and Resource ID and attach to internal streams in a fashion very similar to the SRT Stream ID, but since there could be many streams, the RIST feature allows a single client to connect to more resources at one time and does not require opening multiple sessions.
In parallel RIST activity group was very busy in 2022 issuing several key capabilities and features to address industry requests:
1. RIST Advanced Profile (VSF TR-06-03) – Advanced secure and protected tunnel with the following features:
· Tunnel level reliable delivery
· ST 2110 compatible
· IPv6 support
· Transparent Fragmentation
· Multi-link using SMPTE2022-7
· Multi-Link Bonding/Load share
· Multi-Protocol and Expedited Flow
· Multi-Flow over a common tunnel
· Flow identification registry to assist in quick classification of the payload within a tunnel
2. Link Source adaptation (applicable within all RIST TR-06-01, TR-06-02, TR-06-03), published as VSF TR-06-4 Part 1.
3. New PSK enhancement: EAP SHA256-SRP6a Authentication Protocol (recently submitted as an Internet Draft).
4. Multicast authentication support.
TR-06-03 Advanced Profile
RIST’s most recent new feature is a smart and sophisticated self-healing tunnel. Why is the RIST TR-06-03 Advanced Tunnel so exciting? The simple answer: Initially, each stream was a self-contained element, providing error recovery, de-jitter, and buffer handling (regardless if it is SRT or RIST). If the user wanted to have many streams, they would have to have multiple recovery schemes running in parallel. The Advanced Tunnel comes with a different approach, allowing the tunnel to do the work for the user. The application will accommodate error recovery and jitter handling. The tunnel now is self-healing and takes care of degradation events, regardless of the payload. Now, multiple streams may be sent back and forth, including different protocols types (even TCP), and the tunnel will do the work for you. In addition, the tunnel can do Seamless Switching for you, and it can accommodate bonding.
From its inception, the RIST Advanced Profile had one clear directive: be ready to transport uncompressed SDI and to be ST 2110 compatible (including the timing and the header). RIST Advanced Profile was designed to support a very accurate timestamp and very long sequence numbers suitable for high speeds. The tunnel allows the mixing of different streams (of different protocols); streams can be prioritized or expedited, and metadata is available for each stream to support quick resource allocation at the receiving end. For that, the RIST AG implemented an open registry of protocols available on GitHub. Users are encouraged to submit new entries as needed.
If you want to do IPv6 or Jumbo frames, RIST Advanced Profile can accommodate that as well. The tunnel is IPv6-friendly, and can self-defragment any jumbo frame and reconstruct back the packet. It also supports fragment-level recovery, which is a first in industry. For more information, review this presentation from NAB 2022 : https://youtu.be/PXRrEXrLj_Q
Link Source adaptation TR-06-04 Part 1
For a long time, dynamic adaptation to network conditions was reliant upon a few proprietary protocols. The RIST Activity Group identified source adaptation as a requirement in early 2018. The work was completed in 2022, and Source Adaptation is now available within the RIST Simple Profile on a single stream basis or the RIST Advanced Tunnel, accommodating multiple streams simultaneously.
What is RIST Source Adaptation? It is a set of information packets from the receiver to the sender that provides data regarding the health of the stream as it is received from one or more links. A receiver reports on the number of packets it receives, the number of packets missing, packets arriving late, packet jitter, and additional conditions. The sender can than determine the performance of the link and decide if more or less traffic should be sent in a per-link basis. When several links are in use, this allows the sender to give priority to the links that perform better, excluding or lowering the traffic on links that are struggling. In this way, connectivity adaptation is achieved. The information also allows the sender to decide to throttle down its source (such as lowering the encoding bitrate if this is supported) and restoring the bitrate when conditions are favorable. This way the sender and receiver work in tandem to overcome link issues that regular packet retransmission cannot successfully maintain.
For additional information, here is another presentation from NAB 2022: https://youtu.be/FgarxQz5ff0
New Pre-Shared Key (PSK) enhancements and Multicast Authentication
One of the encryption options supported by the RIST Advanced Profiles is PSK. In order to increase security beyond a regular pre-shared key (as done in SRT), the RIST Activity Group added the EAP SHA256-SRP6a Authentication Protocol, which is now a RFC candidate. Applying this mechanism, a receiver first logs into an authentication server using the very secure SRP6a protocol. One of the most interesting use cases for the newExtensible Authentication Protocol (EAP) Authentication Protocol is the ability to create a secure multicast content distribution system without customers being locked into a vendor’s proprietary system. There is no existing authentication in IP multicast; any device in the network can receive the content by simply doing IGMP. However, the content will be encrypted, and this new EAP feature enables authentication and is based on the use of simple username/password. A device only receives the passphrase after successful authentication. Moreover, the new feature includes mechanisms to de-authorize receivers on-the-fly without disturbing the content. Why is this important? Let’s consider two applications; Multicast in a cloud environment, and a free and open source replacement of Digital Rights Management (DRM). This solution is currently supported by the open source LibRIST library.
If you want to learn more, follow this link : https://www.rist.tv/articles-and-deep-dives/2022/8/4/multicast-authentication-with-rist
On the horizon for WebRTC
WebRTC is becoming more popular with low latency applications and for monitoring. There are some companies working to implement WebRTC by applying either SRT or RIST as the data plane. A shortcoming of WebRTC is the number of packet retransmissions in case of a packet drop. This is where SRT and RIST come into play with RIST providing technical advantage by applying Secure Real-time Transport Protocol (https://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol). SRTP is incorporated within WebRTC. Some implementation used the work completed within RIST and applied it to SRTP to achieve higher error resilience without sacrificing low latency. This will continue to evolve with greater performance achieved as time passes.
I hope that this article has achieved the goal of highlighting advances in both SRT and RIST, illustrating strengths and advantages within both transport protection protocols. Many resources and articles are available beyond what is cited here. Many people have, and continue to contribute to all of the applications, features and protocols referenced and explained; the Open Source community enables both SRT and RIST to adapt to industry requirements and advance in performance. Individual results are conditional to each specific implementation, network conditions, and user payload. Please be certain to contribute to the development community and to participate within industry alliances and activity groups.