Real Time Streaming Protocol (RTSP)

How RTSP works

RTSP messages resemble the syntax of HTTP requests and responses, using methods and status codes, but the protocol is focused on control rather than delivery. A typical exchange begins with a client sending DESCRIBE to obtain a description of the media presentation (usually returned as an SDP — Session Description Protocol — body). The client then issues SETUP for each media stream to negotiate transport parameters and reserves resources. After setup, PLAY and PAUSE control media flow, and TEARDOWN ends the session.

Core methods and common messages

• OPTIONS — query server-supported methods.
• DESCRIBE — request a description of the media and available streams.
• SETUP — establish transport for a given media stream and create a session.
• PLAY / PAUSE — control playback timing and flow.
• TEARDOWN — release resources and end the session.
• ANNOUNCE, RECORD — used for publishing or recording media to a server.

Transport, interoperability and ports

RTSP itself does not transport audio or video samples. Instead, it typically controls media transported with RTP (Real-time Transport Protocol) and coordinated with RTCP (RTP Control Protocol). The control channel commonly runs over TCP (which simplifies firewall traversal), while RTP streams often use UDP for lower latency. Servers can also interleave RTP over the RTSP TCP connection when UDP cannot be used. The well-known default port for RTSP control is 554, but deployments may use other ports or tunnel RTSP over HTTP to traverse restrictive networks.

History and standardization

RTSP was first standardized as RFC 2326 in 1998 and was developed through work at the IETF to meet the needs of interactive streaming systems. Over time the protocol has seen revisions and extensions; later work addressed interoperability, additional methods, and a refreshed specification effort (often referenced as RTSP 2.0 in standards discussions). Implementations vary, and some vendors introduced proprietary transports or extensions to meet specific requirements.

Use cases, advantages and limitations

RTSP has been widely used in IP cameras, video surveillance systems, digital media servers and professional streaming setups because it supports precise control and low-latency delivery. Advantages include fine-grained session control and compatibility with RTP/RTCP for synchronized audio/video. Limitations include difficulties with NAT and firewall traversal, and a relative decline in some consumer applications as HTTP-based adaptive streaming formats (such as HLS and DASH) gained popularity for broad web compatibility and CDN support.

Notable distinctions and related protocols

• RTSP vs RTP: RTSP controls sessions; RTP carries the media data.
• RTSP vs RTMP/HLS/DASH: RTMP is a different streaming protocol historically used with Flash; HLS and DASH are HTTP-based chunked delivery schemes optimized for wide-scale distribution and adaptive bitrate.
• Security: RTSP control messages can be protected by TLS or tunneled over HTTPS; some systems add authentication and encryption at transport or application layers.

Overall, RTSP remains a useful protocol where interactive control and low latency are priorities, particularly in surveillance, professional broadcasting, and specialized streaming systems. For widespread web delivery, many services favor HTTP-based streaming for easier caching and firewall traversal, but RTSP continues to play a role where its control semantics and integration with RTP are required.