The client discovers tracks and negotiates a session.
Protocol field guide
RTSP without the protocol folklore
Separate session control from the RTP media path, then test the transport, timing and recovery that determine whether the feed is actually usable.
Use RTSP for controlled source sessions—not as a browser delivery format.
Decision map workflow boundary
Packets, timestamps and codecs make or break the picture.
Validate media and rehearse a real reconnect.
RTP pathTCP / UDPcodec profilerestart test
You have an rtsp:// endpoint and need to decide whether it belongs in production. “Does RTSP stream video?” is not the question that settles it. Ask whether this client can establish the intended session, receive the negotiated media, decode the selected tracks and recover when either side restarts.
The RTSP architecture: control, description, and media
RFC 7826 defines RTSP 2.0 as an application-layer protocol for setting up and controlling the delivery of real-time data. A source may be a live feed or a stored presentation. RTSP maintains the session state; the presentation description and negotiated transport tell the client what it will receive and how.
| Exchange | What it establishes | What it does not prove |
|---|---|---|
OPTIONS | Methods and features the endpoint advertises. | That the requested resource or track exists. |
DESCRIBE | A presentation description, commonly SDP, with media tracks and control URIs. | That the receiver can decode those tracks. |
SETUP | Session state and the selected media transport for a track. | That packets can cross the real firewall or NAT path. |
PLAY | The request to begin or continue delivery through the established transport. | That picture, audio, timestamps, and downstream outputs are healthy. |
TEARDOWN | Session closure and resource release. | How a client should reconnect after an unplanned loss. |
SDP is not the media either. It describes the presentation: track types, encodings, clock rates, connection information and per-track control identifiers. RTP carries the media payload with sequence and timestamp information, while RTCP provides control information such as sender and reception reports. When those layers stay distinct, incident evidence is much easier to interpret.
RTSP 2.0 is current; RTSP 1.0 remains a field reality
RFC 7826 obsoletes the 1998 RTSP 1.0 specification, RFC 2326. Yet that does not make every installed camera or media server an RTSP 2.0 implementation. Axis, for example, still includes RTSP 1.0 request examples in its current VAPIX video-streaming API. The endpoint's documented version and behavior are the interoperability contract; the age of the client or device is not.
The distinction matters when something fails. A method, header, tunnel or transport option that is valid in one specification may be absent, optional or implemented differently in a field device. Capture the version in the actual request and response before reaching for an RFC example.
Choose the media transport at the network boundary
In RTSP 2.0, RTSP messages use TCP or TCP/TLS. The media can arrive as RTP over UDP, multicast UDP, TCP or interleaved on the RTSP connection. In practice, the choice is often between separate RTP/UDP flows and interleaved RTP over TCP.
- RTP over UDP: a natural fit on a controlled network where the required media ports, routing, and loss behavior are understood. Session setup may succeed even when the returning UDP path is blocked.
- Interleaved RTP over TCP: keeps control and media on the RTSP connection and can be simpler through restrictive boundaries. It also places media on an ordered byte stream, so congestion and loss can delay later data.
- Multicast: can serve multiple receivers efficiently on a network designed for it. It is not an Internet traversal shortcut; switching, routing, group management, and receiver behavior all need an explicit operating plan.
Do not choose TCP simply because it sounds “reliable,” or UDP because it sounds “low latency.” Run both supported modes over the path that will carry the real feed. Then compare startup, behavior under loss, delay and recovery.
When RTSP fits—and where it stops
RTSP fits when a receiver needs to request and control a live or stored presentation from a camera or media server. Common examples are camera-to-recorder, camera-to-gateway and server-to-managed-client boundaries. On its own, RTSP is not a browser-delivery architecture, a codec guarantee, a recording policy or a resilient contribution design for an unmanaged WAN.
For camera discovery and commissioning, continue with RTSP camera streaming. If the source can publish and the choice is between that model and an RTSP pull, see RTMP vs RTSP. For a wider comparison of viewer and contribution protocols, use the live-video protocol guide.
An RTSP acceptance runbook
- Write the source contract. Record the responsible team, host, documented path, RTSP version, expected video and audio tracks, codec profiles, resolution, frame rate and credential reference. Keep the secret out of the runbook.
- Inspect the presentation. Confirm that
DESCRIBEreturns the intended resource and that the SDP names the expected tracks, clock rates, payload types and control URIs. - Record the selected transport. Keep the
SETUPrequest and response, session identifier, TCP interleaving channels or UDP address/ports, plus any firewall rule that makes the media path possible. - Prove packet arrival and decode separately. A tool such as
ffprobecan report streams and codecs;ffplaycan exercise explicit UDP or TCP modes. The FFmpeg RTSP documentation defines those transport options. Use a credential-safe test URL and keep the sanitized output. - Watch long enough to expose timing faults. Check motion, audio, timestamp progression, frame cadence, packet loss and drift. A still frame after
PLAYis not acceptance. - Exercise recovery. Restart the source, interrupt the network and restart the receiver. Measure reconnect time, then verify the consuming recorder, monitor or restream—not just the RTSP session.
Troubleshoot the first broken layer
| Observed boundary | Investigate first |
|---|---|
| No RTSP response | DNS or address, route, listening port, firewall, and service state. |
DESCRIBE is rejected | Resource path, authentication, authorization, RTSP version, and supported methods. |
| Session starts; no media arrives | Negotiated transport, UDP return path, interleaving support, NAT, and selected track. |
| Packets arrive; decode fails | Payload type, codec/profile, parameter sets, audio format, timestamps, and receiver support. |
| Preview works; output fails | The recorder, converter, player bridge, storage, or destination. The RTSP source has crossed its acceptance boundary. |
Change one layer at a time. Switching the transport, codec, credentials and destination together may restore service, but it also destroys the evidence needed to prevent the same failure.
Validate an RTSP recording in Callaba
Callaba's Recordings API accepts an RTSP URL as the input to a recording job. Once the source contract is proven, create one recording with INPUT_TYPE_RTSP_URL and the exact input_stream_url. While the job is active, use POST /api/recording/getStat to check bitrate, fps, out_time_ms, speed and progress. Stop it cleanly, call POST /api/recording/getById and confirm that recordedFiles[] is populated. These checks prove the recording boundary only.
