Quick Answer
SRT is usually the better fit for contribution over unpredictable links because it is built around controlled recovery and an intentional latency buffer. RTMP is still common for platform ingest, but the right choice depends on whether the job is contribution, delivery, or browser/platform compatibility.
The Problem with TCP-based RTMP
RTMP runs on TCP (Transmission Control Protocol). TCP is designed to guarantee that every single packet arrives in the exact order it was sent. If a packet drops over a bad hotel WiFi connection, TCP halts the entire stream data flow until the receiver sends a requested ACK, and the sender re-transmits the dropped packet.
That ordered recovery can add delay or stall media delivery when loss and RTT vary. RTMP can still be the correct choice for a platform ingest workflow; it is simply a different tradeoff from an SRT contribution link.
The SRT Solution (UDP + ARQ)
SRT runs over UDP (User Datagram Protocol) and adds sequencing, timing, and loss-recovery behavior suited to live media. UDP alone does not provide ordered, reliable delivery; the application protocol decides how missing or late packets are handled.
SRT uses ARQ (Automatic Repeat reQuest) with a configured latency window.
- The latency window: Configured latency creates time in which a missing packet may be retransmitted. End-to-end latency also includes encoding, decoding, queues, and application behavior.
- Recovery: The receiver can request missing packets. Recovery succeeds only if the retransmission arrives before it is too late for playout.
If the packet does not arrive in time, SRT drops the frame and moves on, causing a momentary visual glitch rather than stalling the entire stream. That gives you a more controlled latency target, but the result still depends on RTT variation, loss, and buffer settings.
Caller, Listener, and Rendezvous
One common hurdle for engineers switching to SRT is Firewall Traversal. Unlike RTMP, which always pushes to a server, SRT lets you choose which end initiates the connection:
- Caller: The side that initiates the connection. Usually the OB van in the field.
- Listener: The side that waits for a connection. Usually the studio or cloud production server. Requires a firewall port-forward (default UDP 6000).
- Rendezvous: A specialised mode where both sides initiate the connection. It can help in some NAT/firewall topologies, but must be tested against the actual network policy.
The linked calculator uses four times measured RTT as a visible planning default, with a small RTT floor. This is not an SRT protocol rule. Test RTT variation, burst loss, encoder delay, and the exact endpoints before choosing a final setting.
Common Mistakes
- Treating RTMP ingest and SRT contribution like the same workflow.
- Using RTT alone as the final latency setting without testing jitter and loss.
- Assuming lower latency is always better if packet recovery margin disappears.
- Ignoring firewall mode when setting up caller, listener, or rendezvous.
Related Tools & Next Step
Use the SRT latency calculator to size the buffer, and use the OBS & vMix Streaming Planner when the transport decision is part of a wider streaming setup.