Why This Matters
If you bought into SRT for live contribution in the last five years, the obvious question is: what's the alternative, and when would I actually pick it? RIST is that alternative. It solves the same problem — pushing live video reliably across a lossy public-internet path with sub-second latency — but it solves it through a published open specification rather than a vendor-led reference implementation. For broadcast engineers writing tender documents, that distinction is the entire reason RIST exists.
This article is the canonical Block 3 reference on RIST: what the three profiles actually contain, how the NACK-based reliability layer works, why broadcast engineers care about SMPTE ST 2110 transport over the open internet, how RIST link bonding compares to SRTLA, and the three questions to ask before picking RIST or SRT for a new path. By the end you will be able to defend a "we ship RIST" decision in a procurement meeting and avoid the most common configuration mistakes when bringing up the link.
What RIST Is — In One Page
Reliable Internet Stream Transport, abbreviated RIST, is an application-layer protocol that rides on UDP and the Real-time Transport Protocol, abbreviated RTP, and gives the application four properties UDP and RTP do not give you on their own: reliable delivery, encryption (in Main and Advanced profiles), multi-link aggregation, and a configurable upper bound on end-to-end latency. The Video Services Forum, abbreviated VSF, formed the RIST Activity Group in 2017 to fill an open specification gap that SRT and the proprietary Zixi product had filled with single-vendor implementations. The VSF published the first profile, TR-06-1 (Simple), in October 2018; the second, TR-06-2 (Main), in March 2020; and the third, TR-06-3 (Advanced), in 2021. Each profile is a strict superset of the one below it: a Main Profile receiver can decode a Simple Profile sender, and an Advanced Profile receiver can decode either. The specifications are freely downloadable from the VSF website. There is no membership fee, no licence fee, and no royalty obligation.
Mechanically, RIST runs over UDP — typically on a port the operator picks; common conventions are port 1968 for Simple Profile and port 4755 (the IANA-allocated DTLS-over-GRE-in-UDP port) for Main Profile. A session begins with an RTP stream of numbered media packets flowing one way and an RTCP feedback channel flowing the other way. When the receiver notices a missing sequence number, it issues a negative acknowledgement (NAK) over RTCP, asking the sender to retransmit the missing packet. If the retransmission arrives inside the negotiated latency window, the receiver slots it into place and hands the reassembled stream to the application; if it misses the window, the receiver records the gap and moves on.
The wire format is the same Real-time Transport Protocol used by WebRTC, VoIP, and IPTV multicast — that is the deliberate choice the VSF made to maximise interoperability with existing broadcast equipment. The NAK message format is RFC 4585 generic NACK (a bitmask covering up to 17 consecutive sequence numbers) plus a RIST-defined APP-type RTCP packet for range NACKs (one message that requests an arbitrarily long span). Lost packets get retransmitted on RTCP timer ticks, not on every individual loss event, so a 5 percent loss path is recovered with one retransmission burst rather than 50 individual round-trips. That is the architecture in 200 words.
Figure 1. The three RIST profiles, stacked. Each profile is a strict superset of the one below. Pick the lowest profile that meets your requirements.
The Short Version of How RIST Got Here
The history matters because it explains what RIST optimises for. Around 2016, three problems converged in the professional broadcast world. The first: proprietary protocols (Zixi, VideoFlow, ActionStreamer, QVidium, DVEO Dozer) had solved reliable transport over the public internet, but every implementation was a black box, every licence was paid, and every two vendors needed a custom integration project to talk to each other. The second: Haivision had open-sourced SRT in 2017 and was assembling the SRT Alliance — useful, but SRT was still a single-vendor reference implementation with an expired IETF draft. The third: broadcast engineers writing tender documents in Europe and Latin America needed to point to a published specification number, not a GitHub repository.
The VSF — a non-profit standards body founded in 1997 to standardise video-over-IP transport — formed the RIST Activity Group in 2017 to address all three problems at once. The group brought together broadcast vendors (Cobalt Digital, Net Insight, Nevion, Zixi, VideoFlow, DVEO, Sencore, Cyanview, Aviwest, EVS), Internet platforms (Microsoft Azure, AWS Elemental), and standards-body veterans. The technical architecture was decided early: RTP over UDP for compatibility with existing broadcast gear, RTCP NACK for ARQ to reuse RFC 4585, and a profile-based release cadence so vendors could ship interoperability incrementally instead of waiting years for a complete specification.
The Simple Profile, TR-06-1, was published in October 2018. It defined the baseline interoperability point: RTP packetisation, NACK-based ARQ, link bonding via SMPTE 2022-7. The Main Profile, TR-06-2, followed in March 2020 — adding GRE-in-UDP tunnelling per RFC 8086, DTLS 1.2 encryption, pre-shared key authentication, multiplexing of multiple streams in one tunnel, NULL-PID suppression, and NAT traversal. The Main Profile was refreshed in June 2024 to add generic authentication mechanisms (public-key certificates and TLS-SRP). The Advanced Profile, TR-06-3, followed in 2021 — extending the tunnel concept to carry arbitrary IP payloads including SMPTE ST 2110, SMPTE ST 2022-6, and raw MPEG-TS over UDP. The TR-06-4 ancillary specifications followed in 2023 and 2024, adding the RIST Relay (a SIP-style proxy that lets RIST endpoints meet behind firewalls without opening inbound ports).
The reference implementation, libRIST, lives on the VideoLAN code site and is BSD-2-Clause licensed. It is the C library that VLC 4, FFmpeg, GStreamer, OBS Studio (via plugin), Upipe, TSDuck and Wireshark all use to speak RIST. That common implementation base is the reason RIST plug-fests at the IBC and NAB shows consistently demonstrate working interoperability between three or four vendors at once — every vendor links the same library underneath whatever proprietary UI sits on top.
A useful way to hold this in your head: RIST started as a standards committee project — write the spec first, then ship implementations against it — and that order is the opposite of how SRT happened. RIST's documentation lives entirely in published TR-06 documents on the VSF site; libRIST is a faithful implementation of those specs, not the source of truth. That order is exactly why broadcasters with a procurement process pick RIST.
How RIST Recovers Lost Packets
The reliability mechanism is the same family as SRT's — selective retransmission inside a latency window — but the wire format is different and the feedback message is different. Understanding how it works is the difference between configuring RIST correctly and burning a contribution path in a real production.
The sender packetises the media stream (typically an MPEG-TS multi-programme transport stream, sometimes a SMPTE ST 2022-6 SDI-over-IP stream) into RTP packets, assigns each packet a 16-bit sequence number, and emits them at the source rate over UDP. The receiver reads UDP datagrams, extracts the RTP payload, checks the sequence number, and writes the payload into a reordering buffer sized to the configured latency budget. The reordering buffer is what gives RIST its latency upper bound: anything that arrives later than the budget is dropped.
When the receiver notices a gap in the sequence number stream — packet 46 arrives, then 48, with 47 absent — it does not immediately panic. RTCP feedback is sent on a timer, not on every loss event, because issuing one NAK per lost packet would flood the reverse path on a high-loss link and waste a round-trip on each individual packet. Instead, the receiver collects up to 17 consecutive missing sequence numbers, packs them into a single Generic NACK message (RFC 4585 §6.2.1), and emits the message on the next RTCP scheduling tick. If the gap is longer than 17 packets — for example, a brief link outage that dropped 200 packets — the receiver uses RIST's Range NACK extension (an APP-type RTCP packet defined in TR-06-1 §6.4) to request the entire range in one message.
The sender receives the NAK, looks up the requested sequence numbers in its retransmission buffer (typically sized to twice the negotiated latency budget), and retransmits each requested packet as a new RTP datagram. Retransmissions carry the same sequence number as the original — this is what lets the receiver slot them back into the reordering buffer at the correct position. If the retransmission arrives inside the configured latency window, the receiver writes it into the buffer and the application sees no gap. If it misses the window, the receiver records the gap, the decoder does error concealment (or drops the affected frame), and the rest of the stream flows on unaffected.
Two design choices matter here. First, RIST never sends positive acknowledgements. SRT uses both ACK and NAK; RIST uses only NAK. The trade-off is that NAK-only saves return-channel bandwidth (no per-packet ACK traffic) at the cost of the sender not knowing the receiver is still alive unless the receiver explicitly emits an RTCP receiver report on its standard 5-second interval. In practice this is fine for media transport — the application notices a missing stream within seconds either way — but it is the architectural reason SRT and RIST cannot share a wire format. Second, RIST inherits RTP's timestamp field and uses it for jitter compensation independently of the sequence-number reordering. The receiver's playout buffer is decoupled from the retransmission buffer: jitter smoothing operates on timestamps, reordering operates on sequence numbers, and a missed retransmission deadline drops the packet from both pipelines.
The arithmetic, out loud, with realistic numbers. Suppose the contribution path has 80 ms round-trip time and 2 percent average packet loss. The recommended latency setting is at least 4× RTT, the same rule of thumb the SRT community uses, because the worst-case recovery sequence is: receiver waits one packet-pair time to confirm the loss, sends a NAK on the next RTCP tick (up to one tick interval), the NAK travels half an RTT to the sender, the sender retransmits, and the retransmission travels half an RTT back. With 80 ms RTT, the safe latency setting is 320–400 ms; production deployments often run at 500 ms to leave margin for the second-retransmission case where the first retransmission was also lost.
The 4× RTT Rule, Now From The RIST Side
The 4× RTT rule is the same arithmetic as in SRT — both protocols are NAK-based with a single retransmission round per loss event, both target the recovery of two-to-three retransmission attempts inside the budget — but RIST adds one wrinkle. Because NAKs are emitted on RTCP timer ticks rather than the moment a loss is detected, the inspection delay on a RIST receiver can be longer than on an SRT receiver. RTCP scheduling intervals are typically 100–500 ms on a small flow (RFC 3550 §6.2 calculates the interval based on the participant count and bandwidth share); on a tight flow with a fast-feedback profile (RFC 4585 §3.4) the interval can drop to 5 ms or less, but the default on most libRIST installations is 100 ms.
That means a RIST receiver on the default RTCP interval will notice a loss within ~50 ms of the gap appearing, emit a NAK within the next 100 ms, and the sender will retransmit one half-RTT later. The total recovery time on an 80 ms RTT path is in the 150–250 ms range — slightly slower than SRT's 100–180 ms. For most contribution paths the difference is invisible; for paths where you have squeezed the latency budget below 300 ms it matters, and RIST operators tune the RTCP interval down (via the min-interval parameter in libRIST) to match SRT's recovery speed. The default trade is fewer NAK messages on the reverse path; the tuned trade is faster recovery at the cost of a busier feedback channel.
| Path scenario | RTT | 4× RTT (floor) | Recommended RIST latency setting |
|---|---|---|---|
| Wired LAN, same city | 5–15 ms | 60 ms | 150 ms |
| Wired internet, same country | 20–40 ms | 160 ms | 300–500 ms |
| Wired internet, transatlantic | 80–120 ms | 480 ms | 800–1,200 ms |
| 4G mobile uplink | 80–200 ms | 800 ms | 1,500–2,500 ms |
| 5G mobile uplink | 30–80 ms | 320 ms | 800–1,500 ms |
| Geostationary satellite | 500–700 ms | 2,800 ms | 4,000–8,000 ms |
| Low-earth-orbit satellite (Starlink) | 25–60 ms | 240 ms | 500–1,200 ms |
Link Bonding — Seamless Redundancy vs Load Sharing
RIST supports two distinct multi-link modes that look superficially similar but solve opposite problems. Confusing them is the single most common architectural mistake when designing a bonded RIST contribution path.
Seamless Redundancy uses SMPTE ST 2022-7. The sender emits a full copy of the RTP stream on each available link — two links means two copies, three links means three copies. Each copy carries identical sequence numbers and identical timestamps. The receiver listens on every link, deduplicates packets by sequence number, and hands the first arrival of each packet to the application. If a link fails entirely, the receiver simply continues using the surviving links; if a packet is lost on one link but arrives on another, the receiver never notices the loss. ARQ is unnecessary for link failure because the redundancy is end-to-end.
The cost is bandwidth: a 6 Mbps source over two seamless-redundancy links costs 12 Mbps of egress. The benefit is that link failure is invisible to the viewer. Two diverse ISP paths between a remote site and a central hub, run in seamless redundancy mode, give you the closest thing the public internet offers to a leased line.
Load Sharing uses a RIST-specific bonding mechanism that distributes RTP packets across multiple links. A 12 Mbps source split across two equal links becomes two 6 Mbps slices, one per link. The receiver listens on both links, reorders the packets by sequence number, and runs ARQ over whichever link is least loaded when a NAK needs to be sent. If a link fails, ARQ rebuilds the missing packets from the surviving link; for a brief period the aggregate bandwidth halves and packets may glitch through error concealment, then the contribution path stabilises on the remaining link.
The cost is a brief outage on link failure and the operational complexity of provisioning multiple links. The benefit is that the aggregate bandwidth is the sum of the individual links — a 4 Mbps mobile uplink and a 4 Mbps Wi-Fi connection together carry an 8 Mbps stream. For mobile contribution from a vehicle or a backpack encoder with bonded LTE modems, load sharing is the dominant pattern.
Figure 2. RIST bonding has two distinct modes that solve opposite problems. Pick seamless redundancy when bandwidth is cheap and zero glitches matter; pick load sharing when bandwidth is the constraint.
The mechanical rule of thumb: seamless redundancy doubles your wire bandwidth but eliminates link failure; load sharing keeps your wire bandwidth constant but accepts a brief glitch on link failure. Both modes are SMPTE 2022-7-compatible on the wire, so a load-sharing receiver and a seamless-redundancy receiver can interoperate with a sender configured for either mode if the cardinalities match.
Main Profile — Encryption, Tunnelling, Multiplexing
Simple Profile gives you reliable transport with no encryption. That is acceptable for a private leased line; it is not acceptable for a path that crosses the public internet. Main Profile fixes that by wrapping the entire RTP-and-RTCP exchange in a GRE-in-UDP tunnel — a one-line summary that conceals four distinct mechanisms worth knowing about.
The GRE-in-UDP wrapper comes from IETF RFC 8086, published in March 2017. GRE — Generic Routing Encapsulation — is a 1990s-era IP tunnelling protocol that puts any IP payload inside another IP header; the "in-UDP" variant from RFC 8086 puts the GRE-tunnelled traffic inside a UDP datagram so it can traverse NAT and firewalls. RIST Main Profile uses this wrapper to multiplex an arbitrary number of RTP streams plus an in-band control channel through a single UDP port. The overhead is a constant per-packet header of roughly 24 bytes, which on typical 1300-byte MPEG-TS frames is around 1.8 percent — a meaningful tax but the price of getting all the features Main Profile adds in one package.
DTLS 1.2 encryption rides on top of the GRE-in-UDP wrapper. Datagram Transport Layer Security, abbreviated DTLS, is the UDP-friendly version of TLS that WebRTC also uses for its data plane; RIST inherits the same cipher suites (AES-128-GCM is the default; AES-256-GCM is available for compliance regimes that require it) and the same key-exchange semantics (Diffie-Hellman with certificate authentication). DTLS is fully bidirectional, so the same handshake authenticates and encrypts the control plane and the media plane at once. The IANA-allocated UDP port for DTLS-over-GRE-in-UDP is 4755 — set your firewall rule there.
Pre-shared key authentication is a lighter alternative to certificate-based DTLS, included in Main Profile specifically for the multicast case where every receiver needs the same key. A passphrase is configured on every sender and every receiver out of band; the protocol derives a shared key via PBKDF2 and encrypts the GRE tunnel payload directly. This is the mode satellite news broadcasters use for one-to-many distribution; certificate-based DTLS is the mode unicast contribution paths use.
In-band control multiplexing is what makes Main Profile operationally distinct from Simple. A single GRE-in-UDP tunnel carries an arbitrary number of media streams (each tagged with its own RTP synchronisation source identifier) plus a control channel that handles authentication, key rotation, stream advertisement, and remote diagnostics. One firewall hole, one port forward, one connection — the operations team's life gets meaningfully easier. The 2024 refresh of TR-06-2 added a generic authentication interface that lets a remote ingest endpoint accept either a public-key certificate or a TLS-SRP credential without re-handshaking.
The single most common Main Profile configuration mistake is leaving the encryption negotiation in "permissive" mode, which lets a misconfigured sender connect over Simple Profile (no encryption) without warning. Production deployments must configure the receiver to require Main Profile and reject Simple Profile connections — the libRIST API exposes this as the profile=main parameter and the corresponding firewall rule on port 4755.
Advanced Profile — Carrying SMPTE ST 2110 Across The Open Internet
Advanced Profile is what makes RIST genuinely different from SRT, and it is the reason every "RIST is the broadcast-grade alternative" framing in this article is accurate. Where Simple and Main carry one or more RTP-packetised media streams, Advanced carries arbitrary IP payloads — including the SMPTE ST 2110 family of uncompressed studio formats and SMPTE ST 2022-6 SDI-over-IP. The tunnel-level ARQ at Advanced level operates on the raw IP packets, not on the inner protocol, so the inner protocol can be anything that runs over IP.
This matters because the modern broadcast plant is moving from SDI cables to ST 2110 IP networking inside the facility, and the natural follow-up question is "what protocol carries ST 2110 between facilities?" The honest answer for most paths is a dedicated leased line — ST 2110's uncompressed bitrates of 1.5–25 Gbps per channel are too large for the open internet. But for remote production scenarios where you have a few hundred megabits of public internet capacity (a stadium with a fibre uplink, a remote studio with bonded enterprise broadband) and need to carry a handful of ST 2110 essence streams plus the ancillary data and PTP timing — RIST Advanced Profile is the only published open specification that handles the whole thing.
Mechanically, Advanced Profile defines a reduced-overhead encapsulation mode that strips most of the GRE-in-UDP header and adds just an 8-byte tag plus an 8-byte sequence number for ARQ tracking. The header tax falls from Main Profile's ~1.8 percent to roughly 0.6 percent. Because the payload is opaque IP, the Advanced Profile receiver does not understand the inner protocol — it sees raw bytes, runs ARQ on them, and hands them to the receiving network interface as if they had arrived natively. For an ST 2110 receiver behind a RIST Advanced Profile decoder, the experience is indistinguishable from a direct fibre link.
The 2023 refresh of TR-06-3 added more sophisticated forward-error-correction options (low-density parity-check codes and Raptor codes alongside the original SMPTE 2022-1 XOR FEC), tightened the NAT keep-alive negotiation, and clarified the relationship with the TR-06-4 ancillary specifications. The combination of Advanced Profile and TR-06-4 Part 3 (RIST Relay, published July 2023) gives broadcasters a way to connect two RIST endpoints across firewalls without opening any inbound ports on either side — the Relay sits in the cloud, both endpoints dial out to it, and the two streams meet in the middle. This is the architecture remote production companies use when neither end controls its own network.
RIST vs SRT — The Decision That Actually Matters
Both protocols solve the same problem. Both run on UDP. Both use NACK-based ARQ with a configurable latency budget. Both support encryption, multi-link aggregation, and sub-second contribution latency. The honest comparison is not on technical merit — they are roughly equivalent — but on three operational questions a procurement engineer will ask.
The first question: does the workflow require an open published specification? A "yes" answer points to RIST. The TR-06 documents are downloadable PDFs with section numbers; a tender response can cite them as a normative reference and pass procurement review without a single phone call. SRT's IETF Internet-Drafts expired in 2022 and the protocol's de-facto specification is now the libsrt source code and the SRT Alliance deployment guide — credible engineering artefacts, but not specification documents in the formal sense that broadcast procurement departments require.
The second question: does the workflow require multi-vendor interoperability on the spec, not just the implementation? RIST is designed for this case: every TR-06 document includes interoperability conformance criteria, and the VSF runs annual plug-fests at IBC and NAB where vendors prove they can talk to each other. SRT achieves the same end through a different mechanism: every vendor links libsrt, so by construction every implementation has the same behaviour. If your concern is "can a Net Insight encoder talk to a Cobalt Digital decoder", both protocols answer yes; if your concern is "if Haivision goes out of business tomorrow, can I still get a conforming SRT implementation from a clean-room rewrite", RIST's specification-first model gives you a more comfortable answer.
The third question: do you need to carry SMPTE ST 2110 or SMPTE ST 2022-6 over the open internet? RIST Advanced Profile is the only published protocol that does this. SRT does not. If the workflow touches uncompressed studio essence in any way, the decision is made.
For everything else — public-internet contribution of MPEG-TS or h.264/h.265 streams, single-vendor or near-monoculture vendor environments, contribution from OBS or FFmpeg or a cloud encoder — SRT's ecosystem is roughly four to five times larger than RIST's, integration is faster, and the default answer is SRT. The 2024 Haivision Broadcast Transformation Report measured 68 percent SRT adoption among broadcasters; the equivalent RIST figure published by the VSF in 2024 was approximately 14 percent, concentrated in formal-procurement-driven environments (national broadcasters, government-regulated workflows, European public-service broadcasting). Both numbers are growing year over year; they are not adversarial.
Figure 3. The three questions to walk through before picking RIST or SRT for a new contribution path. The questions are ordered by how often each one is the deciding factor.
A Worked Latency Budget — Remote News Contribution Over RIST
The arithmetic, end to end, for a realistic remote contribution scenario. Setup: a news crew in Berlin uses a portable encoder to send a 6 Mbps H.264 feed to a master control facility in London over a single 80 ms RTT public-internet path with 2 percent average packet loss. The crew uses RIST Main Profile with DTLS encryption and a 400 ms latency budget. We want to know the glass-to-glass latency the viewer at home will see.
The encoder takes one second of camera input and produces a 6 Mbps H.264 elementary stream packaged as MPEG-TS. The encoder's pipeline — capture, scaling, encoding, packetisation — has an internal latency of typically 150–250 ms; we will use 200 ms. The MPEG-TS packets enter the RIST sender, which packetises them into RTP, attaches a DTLS payload header, and wraps the result in a GRE-in-UDP datagram. The RIST sender's processing overhead is small — under 5 ms on a modern CPU — but the sender's own buffer absorbs some jitter before transmission; allow 50 ms.
The datagram travels 80 ms RTT across the public internet, which is 40 ms one-way. The receiver writes the packet into its reordering buffer; the reordering buffer is 400 ms deep, so the packet sits in the buffer for the full 400 ms before being handed to the decoder. The decoder takes another 100–150 ms to decode and feed the next-stage process (DVE, branding, master control switcher). The master control output is then re-encoded for distribution to viewers, which adds another encoder-latency contribution and a packager contribution before the LL-HLS or LL-DASH delivery pipeline takes over.
Glass-to-camera-output-to-contribution-receiver-decoder-output: 200 ms encoder + 50 ms sender buffer + 40 ms network + 400 ms reorder + 150 ms decoder = 840 ms. Add the distribution-side contribution (encoder + packager + LL-HLS pipeline + player buffer) and you are looking at a roughly 4-second total glass-to-glass for the home viewer — typical for a modern remote news production over LL-HLS. The RIST hop contributes 690 ms of that total; the LL-HLS distribution hop contributes the rest. The single number to remember is the 400 ms reorder buffer: it is the dominant contributor on the contribution side, and it is the dial you turn when the path's loss rate changes.
Where Fora Soft Fits In
Fora Soft has shipped video-streaming, WebRTC, OTT, telemedicine, e-learning, surveillance and AR/VR software since 2005 — 239 projects and counting. We see RIST most often in two product categories: broadcast-adjacent OTT platforms where a customer is migrating from satellite contribution to public-internet contribution and needs a published specification to satisfy a procurement requirement, and remote-production tooling where the contribution path is one of several reliability layers in a multi-vendor architecture. For greenfield contribution outside those categories, SRT remains the default in the projects we ship. The right answer is workflow-driven, not protocol-driven, and the work of picking is the work of asking the three questions above and being honest about the answers.
Common Pitfalls
Mixing profiles between sender and receiver without checking. A Main Profile receiver will accept a Simple Profile sender by default (Simple is a strict subset of Main), but the connection will be unencrypted. Production receivers should be configured to require Main Profile explicitly and reject Simple. The libRIST profile=main parameter on the receiver is the safe default.
Setting the reorder buffer below 4× RTT. Tempting on a 30 ms LAN path where 120 ms feels excessive, but the moment the path crosses a Wi-Fi access point with occasional bursts of 200 ms jitter, the buffer is too shallow to recover even one retransmission and the stream glitches every few seconds.
Confusing seamless redundancy with load sharing. A two-link bonded setup configured for load sharing on one end and seamless redundancy on the other is non-interoperable; the receiver will see double the expected sequence numbers and reorder forever. Pick one mode, configure both ends identically.
Forgetting that ports vary by profile. Simple Profile commonly uses port 1968 (the year the original RTP work began at Bell Labs, a small VSF in-joke). Main Profile commonly uses port 4755 (the IANA-allocated DTLS-over-GRE-in-UDP port). The two are not interchangeable.
Treating the RTCP feedback interval as a fixed protocol parameter. It is configurable; on tight-latency paths you tune it down to 5–10 ms to match SRT's recovery speed, at the cost of more reverse-channel traffic. libRIST exposes this as --rtcp-interval on the receiver side.
What To Read Next
- SRT: The Professional Standard for Public-Internet Contribution — the other half of the modern contribution decision.
- Picking an Ingest Protocol in 2026: A Decision Tree — the full ingest-side decision framework, RIST included.
- What Ingest Is, And Why It's The Riskiest Hop In The Pipeline — the Block 3 opening article that frames every protocol in this chapter.
Talk To Us
- Talk to a streaming engineer about your contribution architecture — book a 30-minute scoping call.
- See our case studies — Fora Soft portfolio.
- Download the RIST configuration cheat sheet — one-page reference for profile selection, port assignments, recommended latency settings by path type, and the most common configuration pitfalls.
References
- VSF Technical Recommendation TR-06-1:2018 — Reliable Internet Stream Transport (RIST) Protocol Specification, Simple Profile. Video Services Forum, 17 October 2018. The base interoperability specification; defines RTP packetisation, NACK ARQ, link bonding, SMPTE 2022-1 FEC option. [Open spec, paywalled mirror not required.]
- VSF Technical Recommendation TR-06-2:2024-06-12 — RIST Main Profile. Video Services Forum, 12 June 2024 (originally published March 2020). Defines GRE-in-UDP tunnelling, DTLS encryption, multiplexing, NAT traversal, generic authentication. The procurement-grade reference.
- VSF Technical Recommendation TR-06-3:2021 — RIST Advanced Profile. Video Services Forum, 2021 (refreshed 2023). Defines tunnel-level ARQ, reduced-overhead encapsulation, advanced FEC, and the carriage of arbitrary IP payloads including SMPTE ST 2110 and ST 2022-6.
- VSF Technical Recommendation TR-06-4 Part 3:2023-06-20 — RIST Relay. Video Services Forum, 20 June 2023. Defines the SIP-style proxy mechanism that lets two RIST endpoints meet behind firewalls without inbound port forwarding.
- IETF RFC 4585 (July 2006) — Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF). Defines the Generic NACK message format RIST uses for retransmission requests (§6.2.1), and the reduced-minimum-interval RTCP scheduling that makes fast-feedback profiles possible (§3.4).
- IETF RFC 8086 (March 2017) — GRE-in-UDP Encapsulation. The transport wrapper RIST Main Profile uses to multiplex streams and traverse NAT. Defines the IANA-allocated UDP port 4755 for DTLS-secured operation.
- IETF RFC 3550 (July 2003) — RTP: A Transport Protocol for Real-Time Applications. The base RTP and RTCP specification RIST is built on; §6.2 defines the RTCP scheduling algorithm that determines NAK feedback latency in Simple Profile deployments.
- SMPTE ST 2022-7:2019 — Seamless Protection Switching of RTP Datagrams. The redundancy mechanism RIST uses for two-or-more identical-stream bonding. Defines the sequence-number deduplication algorithm at the receiver.
- libRIST reference implementation, VideoLAN. Source repository at
- Noronha, C., "RIST Advanced Profile" presentation deck, Cobalt Digital / RIST Forum, VSF September 2021 webinar. Operator-level summary of the Advanced Profile feature set.
- Haivision, "Broadcast Transformation Report 2024", October 2024. Industry survey of contribution-protocol adoption. Cited for the 68 percent SRT-adoption figure used to compare ecosystem sizes; per §4.3.2 the RIST adoption figure was cross-checked against VSF-published presentations from the same year because Haivision is an SRT-affiliated source.
- CSI Magazine, "RIST: A Deep Dive", RIST Forum contributors, 2022. Operator-level overview of profile differences. Used here only for orientation; every protocol claim in this article traces back to the relevant TR-06 document.
