Ingest protocols are the first mile of a live stream. They define how encoded audio and video move from a contribution encoder—often a hardware appliance, a software encoder like OBS, or a mobile app—to the ingest server that will transcode, package, and distribute the signal. The main protocols in production today are RTMP, SRT, RIST, and, increasingly, WebRTC-based ingest. Each protocol has a different failure profile under packet loss, jitter, and variable latency. For engineers running contribution, encoding, and delivery pipelines, the choice of ingest protocol is not a preference; it is a reliability decision that shows up in every packet capture and every viewer-side rebuffer metric.
This article examines how RTMP, SRT, RIST, and WebRTC ingest behave under real network conditions. It focuses on measurable behavior: retransmission logic, latency accumulation, connection recovery, and the failure modes that appear in production logs. The goal is to give you a protocol-level understanding that helps you choose the right ingest path and debug it when it breaks.
Why Ingest Protocols Fail Differently
Every ingest protocol is built on a transport layer with a specific reliability model. RTMP runs over TCP. SRT and RIST run over UDP with their own retransmission and congestion control. WebRTC ingest runs over UDP with RTP, RTCP feedback, and often a custom congestion controller. These differences determine what happens when a packet is lost, when latency spikes, or when a connection drops.
TCP-based protocols like RTMP guarantee delivery but at the cost of head-of-line blocking. A single lost packet forces the sender to retransmit, and all subsequent data waits in the receive buffer. For live video, this means the stream stalls rather than degrades. UDP-based protocols with selective retransmission can skip a lost packet and continue, producing a visible artifact but keeping the stream moving. That is the core tradeoff: guaranteed delivery versus bounded latency.
RTMP: The Legacy Workhorse with TCP Limits
RTMP has been the default ingest protocol for over a decade. It is supported by nearly every encoder, every media server, and every major live platform. But its reliability model is inherited from TCP, and that inheritance creates specific failure modes.
Head-of-Line Blocking in Practice
When an RTMP connection experiences packet loss, TCP retransmits the missing segment. During that retransmission, the receive buffer holds all subsequent data. The encoder continues to send, but the ingest server cannot process the stream until the missing packet arrives. In a capture, you will see a flat line in the receive window, followed by a burst of data when the retransmission completes. That burst is the accumulated video data arriving late. The result is a latency spike that can range from hundreds of milliseconds to several seconds, depending on the round-trip time and the loss rate.
For contribution feeds where latency is not critical—say, a 24/7 linear channel with a 30-second delay—this is acceptable. For interactive streams or low-latency delivery, it is a problem. The stream does not drop, but it stalls. Viewers see a frozen frame, then a jump forward.
Connection Recovery and Encoder Behavior
RTMP has no built-in connection migration or fast reconnect. If the TCP connection drops, the encoder must establish a new connection and re-send the stream from the next keyframe. The time to recover depends on the encoder’s reconnect logic and the keyframe interval. A 2-second keyframe interval means up to 2 seconds of lost video, plus the time to re-establish the TCP handshake and re-send the RTMP handshake. In production, this often appears as a 3-5 second gap in the output.
Some encoders implement RTMP reconnect with a configurable retry count and backoff. But the protocol itself offers no help. The ingest server sees a new connection, not a continuation of the old one. Any server-side state—like a persistent publishing point—must be re-created.
SRT: Selective Retransmission and Latency Control
SRT (Secure Reliable Transport) was designed to solve the problems of RTMP over unreliable networks. It runs over UDP and implements its own retransmission, congestion control, and encryption. The key difference is selective retransmission: SRT can request only the missing packets, not the entire stream since the loss event.
How SRT Handles Packet Loss
SRT uses a negative acknowledgment (NAK) mechanism. The receiver detects a gap in the sequence numbers and sends a NAK for the missing packets. The sender retransmits only those packets. Meanwhile, the receiver continues to process the packets that arrived after the gap. This avoids head-of-line blocking. The stream continues, with a brief artifact where the lost packet was, and the retransmitted packet is inserted into the buffer if it arrives before the latency window expires.
The latency window is set by the latency parameter, typically in milliseconds. If a retransmitted packet arrives after the latency window, it is discarded. The receiver does not wait indefinitely. This is a deliberate tradeoff: bounded latency over perfect delivery. In a packet capture, you will see NAK packets and retransmitted data packets interleaved with normal traffic. The stream does not stall; it degrades gracefully.
Congestion Control and Bandwidth Adaptation
SRT’s default congestion control is based on a live bandwidth estimation algorithm. It adjusts the sending rate based on round-trip time and loss. This is different from TCP’s additive increase/multiplicative decrease. SRT is more aggressive in probing for available bandwidth, which can cause issues on networks with policers or strict rate limits. In production, you may see SRT overshoot the available bandwidth, trigger packet loss, and then back off. The result is a sawtooth pattern in the sending rate, visible in encoder logs and server-side metrics.
For contribution feeds over the public internet, SRT’s congestion control is generally more stable than raw TCP for live video. But it is not immune to bufferbloat. If the network path has large buffers, SRT can fill them, increasing latency without visible loss. Monitoring one-way delay is essential.
RIST: A Simpler Alternative with Similar Goals
RIST (Reliable Internet Stream Transport) is a family of protocols defined by the Video Services Forum. RIST Simple Profile uses UDP with retransmission based on NAKs, similar to SRT. RIST Main Profile adds encryption, authentication, and multiplexing. The core reliability model is the same: selective retransmission over UDP, with a configurable buffer for reordering and retransmission.
RIST vs. SRT in Failure Modes
RIST and SRT are often compared, and for good reason. Both solve the same problem: reliable contribution over lossy networks without TCP’s head-of-line blocking. The differences are in implementation details and ecosystem support. RIST is an open standard with multiple independent implementations. SRT is an open-source project with a single reference implementation and a large ecosystem of hardware and software support.
In terms of failure modes, RIST behaves similarly to SRT under packet loss. The receiver sends NAKs, the sender retransmits, and the stream continues. The main difference is in congestion control. RIST Simple Profile does not mandate a specific congestion control algorithm. Some implementations use a fixed sending rate, which can be problematic on variable networks. Others implement a form of bandwidth estimation. This variability means that two RIST implementations may behave differently under the same network conditions. When debugging RIST issues, you need to know which implementation is on each end.
WebRTC Ingest: Low Latency with Different Tradeoffs
WebRTC-based ingest is increasingly used for interactive streams, remote guests, and low-latency contribution. It runs over UDP with RTP, RTCP feedback, and a congestion controller, typically Google’s GCC (Google Congestion Control). The reliability model is different from SRT and RIST: WebRTC prioritizes latency over perfect delivery. It uses forward error correction (FEC) and retransmission, but the retransmission window is very short—often under 100 milliseconds.
Loss Tolerance and Degradation
WebRTC ingest is designed for real-time communication, not for pristine contribution. Under packet loss, WebRTC will first try to recover using FEC and retransmission. If the loss persists, the congestion controller reduces the sending bitrate. The encoder then reduces quality or frame rate. The stream does not stall; it degrades. This is the opposite of RTMP, which stalls to preserve quality.
For contribution feeds that will be transcoded and delivered to a large audience, WebRTC’s loss tolerance can be a problem. A 2% packet loss on the ingest path may cause visible artifacts that are then amplified by the transcoding and delivery pipeline. For remote guests or low-latency monitoring, that tradeoff is acceptable. For primary contribution, it is often not.
Connection Setup and NAT Traversal
WebRTC ingest requires ICE (Interactive Connectivity Establishment) to traverse NATs and firewalls. This adds a setup phase that can fail in ways that RTMP, SRT, and RIST do not. If the ICE negotiation fails, the stream never starts. If the network changes mid-stream—for example, a mobile contributor switches from Wi-Fi to cellular—the connection may drop and require a full renegotiation. This is a different failure mode from a simple TCP or UDP connection drop. It requires different debugging tools and a different mental model.
Comparing Failure Profiles in Production
The table below summarizes the key differences. These are not theoretical; they are observable in packet captures and server logs.
- RTMP (TCP): Stalls under loss, recovers slowly, no built-in encryption, universal support.
- SRT (UDP): Selective retransmission, bounded latency, aggressive congestion control, strong encryption.
- RIST (UDP): Selective retransmission, open standard, variable congestion control, growing ecosystem.
- WebRTC (UDP): Very low latency, loss-tolerant, complex setup, designed for interactive use.
The choice depends on the contribution path. For a fixed encoder in a studio with a reliable network, RTMP is still common and works fine. For a remote encoder over the public internet, SRT or RIST is the better choice. For a remote guest on a laptop or phone, WebRTC is often the only practical option.
Debugging Ingest Failures: What to Look For
When a stream fails, the first question is always: where did it fail? The ingest protocol determines what you will see in the logs and captures.
RTMP Debugging Signals
For RTMP, look for TCP retransmissions in the capture. A high retransmission rate correlates with latency spikes and viewer-side buffering. Also check the encoder’s reconnect logs. If the encoder reconnects frequently, the network path is unstable, or the keyframe interval is too long. The fix is often to move to SRT or RIST, or to improve the network path.
SRT Debugging Signals
For SRT, monitor the pktRetrans and pktLost counters. A high retransmission rate with a low loss rate indicates that the latency window is too small. The receiver is requesting retransmissions, but the packets arrive too late. Increasing the latency parameter gives the retransmissions more time. A high loss rate with a low retransmission rate indicates that the sender is not receiving NAKs, possibly due to a firewall blocking the return path.
RIST Debugging Signals
For RIST, the debugging signals depend on the implementation. Most implementations expose similar counters: retransmitted packets, lost packets, and buffer occupancy. The key is to compare the sender’s and receiver’s counters. If the sender reports no retransmissions but the receiver reports loss, the NAK path is broken. This is often a firewall or routing issue.
WebRTC Debugging Signals
For WebRTC, use the webrtc-internals page in Chrome or the equivalent in other browsers. Look at the packetsLost, jitter, and roundTripTime metrics. Also check the ICE state transitions. A stream that starts and then drops after a network change is a classic ICE failure. The fix is often to improve the ICE configuration, not the network.
Practical Recommendations for Ingest Reliability
Based on production experience, here are concrete recommendations for choosing and configuring ingest protocols.
- Use SRT or RIST for primary contribution over the public internet. The selective retransmission and bounded latency are worth the added complexity. RTMP over TCP is a liability on lossy paths.
- Set the SRT latency parameter to at least 4 times the round-trip time. This gives retransmissions enough time to arrive without causing excessive delay. For a 50 ms RTT, use 200 ms latency. For a 200 ms RTT, use 800 ms.
- Monitor one-way delay, not just packet loss. Bufferbloat can cause latency spikes without visible loss. Use a tool like
tcpdumpwith timestamps, or a dedicated monitoring agent, to track one-way delay on the ingest path. - For WebRTC ingest, configure the ICE servers carefully. Use both STUN and TURN. A missing TURN server is a common cause of failed connections for contributors behind symmetric NATs.
- Test failover paths regularly. A redundant ingest path is only useful if it works. Simulate packet loss, latency spikes, and connection drops in a lab environment before they happen in production.
FAQ
Why does RTMP stall under packet loss while SRT does not?
RTMP runs over TCP, which guarantees delivery but suffers from head-of-line blocking. A single lost packet forces the receiver to wait for retransmission before processing subsequent data. SRT runs over UDP with selective retransmission. The receiver can process packets that arrive after a gap and request only the missing packets. The stream continues with a brief artifact instead of stalling.
What is the right SRT latency setting for a given network?
A good starting point is 4 times the round-trip time. For a 50 ms RTT, use 200 ms. For a 200 ms RTT, use 800 ms. This gives retransmissions enough time to arrive without adding excessive delay. Monitor the pktRetrans and pktLost counters. If retransmissions are high but loss is low, increase the latency. If loss is high but retransmissions are low, check the NAK return path.
Can WebRTC ingest replace SRT for primary contribution?
Not for most production pipelines. WebRTC is designed for real-time communication, not pristine contribution. It prioritizes low latency over perfect delivery. Under packet loss, it reduces bitrate and quality rather than retransmitting aggressively. For primary contribution that will be transcoded and delivered to a large audience, SRT or RIST is the better choice. WebRTC is appropriate for remote guests, low-latency monitoring, and interactive use cases.
How do I know if my ingest failure is a protocol issue or a network issue?
Start with a packet capture at both ends. For RTMP, look for TCP retransmissions and out-of-order packets. For SRT and RIST, compare sender and receiver counters. If the sender reports no retransmissions but the receiver reports loss, the NAK path is broken—likely a firewall or routing issue. If both sides report high retransmissions, the network path is lossy or congested. For WebRTC, check the ICE state transitions and the packetsLost metric in webrtc-internals.
Next Steps for This Blog
This article is the first in a series on ingest reliability. The next article will cover SRT’s congestion control in depth, including how to tune the maxbw and inputbw parameters for specific network paths. If you have a production ingest failure that you cannot explain, send the packet capture and the encoder logs. I will use them as a case study in a future post.
