RIST is one of a number of error correction protocols that provide backwards error correction. These are commonly used to transport media streams into content providers but are increasingly finding use in other parts of the broadcast workflow including making production feeds, such as multiviewers and autocues available to staff at internet-connected locations, such as the home.
The RIST protocol (Reliable Internet Stream Protocol) is being created by a working group in the VSF (Video Services Forum) to provide an open and interoperable specification, available for the whole industry to adopt. This article provides a brief summary, whereas this talk from FOSDEM20 goes into some detail.
We’re led through the topic by Sergio Ammirata, CTO of DVEO who are members of the RIST Forum and collaborating to make the protocol. What’s remarkable about RIST is that several companies which have created their own error-correcting streaming protocols such as DVEO’s Dozer, which Sergio created, have joined together to share their experience and best practices.
Press play to watch:
Sergio starts by explaining why RIST is based on UDP – a topic explored further in this article about RIST, SRT and QUIC – and moves on to explaining how it works through ‘NACK’ messages, also known as ‘Negative Acknowledgement’ messages.
We hear next about the principles of RIST, of which the main one is interoperability. There are two profiles, simple and main. Sergio outlines the Simple profile which provides RTP and error correction, channel bonding. There is also the Main profile, which has been published as VSF TR-06-2. This includes encryption, NULL packet removal, FEC and GRE tunnelling. RIST uses a tunnel to multiplex many feeds into one stream. Using Cisco’s Generic Routing Encapsulation (GRE), RIST can bring together multiple RIST streams and other arbitrary data streams into one tunnel. The idea of a tunnel is to hide complexity from the network infrastructure.
Tunnelling allows for bidirectional data flow under one connection. This means you can create your tunnel in one direction and send data in the opposite direction. This gets around many firewall problems since you can create your tunnel in the direction which is easiest to achieve without having to worry about the direction of dataflow. Setting up GRE tunnels is outside of the scope of RIST.
Sergio finishes by introducing librist, demo applications and answerin questions from the audience.
An important factor when sending production video feeds and other media over the internet for most people is encryption. When distributing to the end user, it’s different, but for contribution having the assurance that no-one else can view the video is very reassuring to all parties even when the content doesn’t necessitate it. RIST has been in development for a while and has grown beyond the simple profile which only dealt with packet loss. Now with the main profile, encryption is possible; there are actually two ways to encrypt. One uses DTLS which is the UDP-based equivalent of the same TLS encryption that https:// websites use, the other uses pre-shared keys (PSK).
Sergio Ammirata from DVEO starts the talk by introducing the main profile and the use of GRE tunnels. The use of a tunnel from sender to receiver allows for a single connection to carry multiple channels of multiplexed data. Importantly. it also allows the encryption to happen to the tunnel rather than to each media stream separately.
The next section of the talk revises what DTLS is: part of the main profile providing TLS encryption to UDP. Given this is an encryption method, it’s important to realise it is not part of the data-loss recovery algorithms. Since DTLS is based on TLS, it will also need certificates. Just like websites you have the choice of having a self-signed certificate or one signed by a trusted authority. This means that you not only know that you are sending encrypted data, you are also sending it to a trusted computer, not someone unintended. Sergio takes us through the workflow of verifying the certificates highlighting, for instance, the requirement for a realtime clock otherwise the start and expiry dates in the certificates wouldn’t have any meaning.
With PSK, there is no authentication. It encrypts the whole of the GRE tunnel except for headers with an AES key related to the pre-shared passphrase. The encryption is changed periodically by an automatic process. It’s important to realise that because this is so deterministic, this can be used for bonded connections. When Sergio then looks at the data flow for using PSK, we see that that it is much simpler with many fewer handshakes.
As to when PSK is the route to take over using DTLS, one-to-many transmission is an obvious candidate but also where there is only one-way communication such as most satellite links. Sergio finishes the talk by looking at the use of FEC and taking questions from the floor.
RIST is a streaming protocol which allows unreliable/lossy networks such as the internet to be used for critical streaming applications. Called Reliable Internet Stream Protocol, it uses a light-touch mechanism to request any data that’s lost by the network. As losses are often temporary and sporadic, the chances are that the data will get through the second or, perhaps, third time. For a more in-depth explanation of RIST, check out this talk from Merrick Ackermans
The panel here at the IBC 2019 IP Showcase give an brief definition of RIST and then examine how far they’ve got with the ‘Simple Profile’ of RIST calling out things that are yet to be done. Still on the to-do list are such things as ‘pull’ streams, encryption, simplifying the port structure and embedding control.
Fixed Key encryption comes under the microscope next asking whether there’s a practical threat in terms of finding the key but also in terms of whether there are any side-channel attacks in a ‘non-standard’ encryption. The fixed key encryption has been implemented in line with NIST protocols but, as Kieran highlights, getting enough eyes on the detail is difficult with the specification being created outside of an open forum.
The panels covers the recent interop testing which shows overall positive results and then discusses whether RIST is appropriate for uncompressed video. Already, Kieran points out, Amazon Direct Connect is available in 100s of Gb/s links and so it’s completely possible to do uncompressed to the cloud. RTP is over 20 years old and is being used for much more than ever imagined at the time. As technology develops, use of RIST will also develop.
What are the other uses for RIST? Videoconferencing is one possibility, creating a generally secure link to equipment and ingest into the cloud are the others offered.
The panel fishes by looking to the future. Asking how, for instance, the encoder could react to reduced quality of the link. How much of the all the technology needed should be standardised and what features could be added. Sergio Ammirata suggests opening up the protocol for the bandwidth estimation to be requested by any interested device.
This session, bringing together DVEO, OBS, Zixi and Net Insight finishes with questions from the audience.
Deployments and Future Development,
Open Broadcast Systems
Senior Software Engineer,
Executive Vice President of Engineering,
Subscribe to get daily updates
Views and opinions expressed on this website are those of the author(s) and do not necessarily reflect those of SMPTE or SMPTE Members.
This website is presented for informational purposes only. Any reference to specific companies, products or services does not represent promotion, recommendation, or endorsement by SMPTE