RTP vs RTSP: Media Transport and Session Control | Callaba

RTP and RTSP solve different parts of a real-time media session. RTP carries timestamped audio or video packets and identifies their payload and source. RTSP is a control protocol: a client can describe a presentation, negotiate transport, start playback, pause it or tear the session down. They are often used together, but neither protocol implies the other. RTP can arrive without RTSP, and RTSP can negotiate a transport other than the UDP layout an operator expected.

RTSP controls the session while RTP carries the media

RTP identifies media timing and sequence, not a complete session

RFC 3550 defines RTP for end-to-end delivery of real-time data. Its header includes sequence numbers, timestamps, payload type and a synchronization source identifier. Those fields let a receiver order packets, place media on its sampling timeline, recognize a source and choose an agreed payload interpretation. RTP does not reserve resources or guarantee delivery, timeliness or quality of service.

The dynamic payload type number is only a mapping within a session description or other agreement. Seeing payload type 96 does not reveal a universal codec. A bare RTP workflow therefore needs out-of-band facts: destination address, port, unicast or multicast behavior, payload mapping, clock rate and any format parameters required by the decoder.

RTCP reports help describe reception, not repair the stream

RTP is normally accompanied by RTCP control packets. Sender and receiver reports can expose packet counts, loss fraction, cumulative loss, jitter and timing relationships. Source descriptions help associate streams. These reports are valuable evidence when a session has picture breakup or lip-sync problems, but they do not retransmit missing media or guarantee that a sender will adapt.

Monitor RTP and RTCP as a pair where the implementation provides them. A stream may render while RTCP is blocked, leaving the sender blind to reception quality; conversely, a report may identify a source while the application cannot decode its payload. Preserve source identifiers and negotiated track mapping so reports are not attributed to the wrong media.

RTSP describes, sets up and controls a presentation

RTSP 2.0 defines remote control of real-time media resources. A client can use DESCRIBE to obtain a presentation description, SETUP to establish transport parameters and PLAY to start delivery. The server returns a session identifier where required, and subsequent requests must preserve the correct resource and session context.

RTSP messages do not carry the continuous media payload. The negotiated transport can use RTP over UDP, multicast where supported, or RTP interleaved on the RTSP connection. Treat the setup response as the contract for that attempt. An old assumption that “RTP always uses the next UDP port” is not an adequate production runbook.

UDP and interleaved TCP fail in different ways

Separate RTP and RTCP over UDP avoid TCP head-of-line blocking and are common on controlled networks. They also need reachable negotiated ports and compatible NAT and firewall state. A client may send RTSP successfully over TCP while inbound UDP media is discarded somewhere else. The control plane looks healthy because it is.

Interleaved transport carries RTP and RTCP frames on the RTSP TCP connection. It can cross networks that block the UDP layout, but delayed TCP bytes hold later bytes behind them. Use it as a deliberate transport option, not proof that UDP is inherently broken. Record which transport was selected in every commissioning test.

Authentication and media authorization are related but distinct

An RTSP service may challenge the client before allowing description or setup. Protect credentials, require the appropriate encrypted network boundary and avoid putting secrets in copied URLs or logs. A successful challenge establishes access to the RTSP resource under that service's policy; it does not validate every destination address the server may be asked to send RTP toward.

Constrain transport choices, source addresses and session duration. For multicast or server-selected destinations, prevent an untrusted client from turning setup into an arbitrary traffic target. Rate-limit session creation and teardown, expire abandoned sessions and record safe denial categories without persisting reusable authorization values.

Test control, transport and decode as separate gates

1. Resolve the resource. Record the exact RTSP or RTP source contract, expected tracks and authorization owner.
2. Inspect RTSP control. Capture status categories and the safe parts of DESCRIBE, SETUP and PLAY timing.
3. Read the negotiated transport. Confirm UDP, multicast or interleaved TCP and the actual channels, ports and addresses.
4. Measure RTP continuity. Check source identifier, payload mapping, sequence gaps, timestamps and packet arrival.
5. Correlate RTCP. Observe sender or receiver reports, loss and jitter where available.
6. Prove decode and recovery. Verify picture, sound and restart behavior from the real operator network.

The RTSP owner provides the broader protocol guide. The Multiview guide explains the operator surface, while the Recording API defines supported source creation. This comparison owns the line between session control and the media packets that follow it.