RTSP over UDP vs TCP: Transport, Loss & Testing | Callaba
More live video workflow notes and product updates.
RTP over UDP and interleaved RTP over the RTSP TCP connection carry the same RTSP-controlled media session through different paths. UDP usually keeps packet loss from delaying later packets, but it needs reachable RTP and RTCP ports. Interleaved TCP sends media on the RTSP connection, which often crosses restrictive networks more easily but can turn loss into a visible stall. Choose from packet evidence and recovery requirements, not from a universal preference.
The RTSP control session negotiates the RTP transport
Callaba accepts the source; the wire tells you the transport
Callaba Multiview accepts RTSP URLs directly for browser monitoring. Restream workflows can also receive supported RTSP sources when the job needs transformation or another output. Callaba's documentation does not describe a user-facing switch that forces UDP or interleaved TCP, nor does it promise a particular automatic selection rule.
That means the source, Callaba runtime and network evidence must confirm the chosen transport. Inspect the RTSP SETUP request and response, the reported transport in source logs, or a controlled packet capture. Do not infer UDP from an rtsp:// URL or TCP from the fact that RTSP control itself connected.
| Callaba workflow | Use it when | Transport evidence to retain |
|---|---|---|
| Direct Multiview input | An operator needs to see the RTSP source | SETUP result, per-input live state and decoded frames |
| Restream input | The source needs processing or another output | Input transport, packet continuity and pipeline status |
| Network change test | A firewall or route changed | Before-and-after transport plus loss, delay and recovery |
UDP uses separate RTP and RTCP flows
RFC 7826 defines RTSP transport negotiation. RTP over UDP commonly uses a pair of client and server ports, with RTP carrying media and RTCP carrying control information. Because UDP delivers datagrams independently, a missing media packet does not make the transport wait before handing later datagrams to the receiver.
The network contract is broader than the RTSP control port. Firewalls, NAT, security groups and container networking must permit the negotiated UDP flows in the correct direction. A successful DESCRIBE or PLAY response proves control-plane progress, not media arrival.
Interleaved TCP carries media on the RTSP connection
RTSP also defines interleaved binary data. RTP and RTCP frames are assigned channel identifiers and sent within the RTSP TCP connection. This is useful when the receiver cannot accept separate UDP ports or when policy permits one established connection more readily than dynamic datagram flows.
TCP provides an ordered, reliable byte stream as specified by RFC 9293. When a segment is lost, later bytes wait until the missing data is recovered. For a live video receiver, that can appear as growing latency or a bursty freeze even though no RTP packet is ultimately reported missing at the application boundary.
Compare failure behaviour, not slogans
On a clean managed LAN, UDP often gives you a short, observable media path. Under congestion, the decoder may conceal a missing packet and continue, or quality may degrade until the next clean reference frame. The result depends on loss pattern, codec, packetization, buffer and error resilience.
TCP can be the only workable choice on a restrictive remote network. It can also be entirely stable when the path has adequate capacity and little loss. The relevant question is not “Is TCP slow?” It is “What happens to glass-to-glass delay and continuity when this path loses or reorders data?”
Use RTCP and receiver measurements
RFC 3550 defines RTP and RTCP. Receiver Reports include fraction lost, cumulative loss, highest sequence number and interarrival jitter. A single jitter value is a sample of timing variation, so compare it over time and align it with receiver buffer, decoded-frame and display evidence.
For UDP, record sequence gaps, late packets, jitter, socket drops and decoder errors. For TCP, add transport round-trip time, retransmissions, receive-buffer growth and latency drift. For both, record first frame, steady glass-to-glass delay, interruption length and time to recover after the network is restored.
A transport decision table
| Constraint | Start with UDP when | Start with interleaved TCP when |
|---|---|---|
| Firewall | Negotiated RTP and RTCP ports are explicitly allowed | Only the established RTSP connection is practical |
| Loss response | Continuing with occasional packet loss is preferable to waiting | Reliable ordered delivery is required and the path is clean |
| Latency | Short delay under imperfect conditions is the priority | Measured delay remains inside the operating target |
| Operations | The team can observe and secure a UDP port policy | One connection materially simplifies remote access |
This is a starting hypothesis, not an outcome guarantee. Run the same source, codec and receiver through both transports on the intended network before standardizing a policy.
The remote camera authenticates, yet the tile stays black
A camera works in Multiview on the studio LAN. From a remote site, RTSP authentication succeeds and the session reaches PLAY, but no frames appear. Increasing probe time changes nothing. Compare the SETUP Transport response, firewall logs, UDP packet capture at both ends and decoded-frame counter. The session selected separate UDP ports that the site firewall never allowed. Approve the negotiated UDP range or use an explicitly supported interleaved TCP path, then confirm media packets or framed RTP arrive, frames decode, and delay remains stable during a controlled loss test.
Run the same source through both paths
- Freeze the variables. Use the same source profile, codec, resolution, frame rate and receiver.
- Capture negotiation. Save the SETUP offer and accepted Transport parameters.
- Verify the network. Confirm the exact control and media flows, not a broad firewall assumption.
- Impair the path. Introduce bounded loss, delay and jitter in a test environment.
- Measure recovery. Track frames, audio, latency drift and time to resume after interruption.
- Document fallback. State whether the runtime retries another transport and how operators can tell.
RTSP TCP vs UDP FAQ
Does RTSP always use TCP?
The RTSP control connection commonly uses TCP, while RTP media may use separate UDP flows or be interleaved on the RTSP TCP connection.
Is RTSP over UDP lower latency?
It can avoid TCP retransmission delay, but actual latency depends on the network, jitter buffer, codec and receiver. Measure the complete path.
Why does RTSP connect but show no video?
Control can succeed while the negotiated RTP ports are blocked. Inspect SETUP transport details, packet arrival and decoded frames.
Can I force the RTSP transport in Callaba?
Callaba documents direct RTSP workflows but not a force-UDP or force-TCP control. Verify current support and observe the negotiated transport for your deployment.