RTSP: Real-Time Streaming Protocol Explained [2026 Update]

RTSP — Real-Time Streaming Protocol — is a network control protocol that establishes and manages media sessions between a client and a media server. The IETF standardized RTSP as RFC 2326 in 1998 and published RTSP 2.0 as RFC 7826 in 2016. RTSP operates at the application layer, uses port 554 by default, and functions as a network remote control: it issues play, pause, and teardown commands while RTP (Real-Time Transport Protocol) carries the actual audio and video frames.

RTSP occupies the first-mile ingest role in modern streaming infrastructure. Virtually every IP camera, NVR, and DVR on the market outputs an RTSP stream, and the protocol delivers approximately 1–2 seconds of latency on a local network. RTSP streams do not play natively in any browser, which is why production architectures pair RTSP ingest with a media server that transcodes the stream to WebRTC, HLS, DASH, or CMAF for viewer delivery.

What is RTSP?

RTSP stands for Real-Time Streaming Protocol. The acronym breaks down as: RT = Real-Time, S = Streaming, P = Protocol. RealNetworks, Netscape, and Columbia University developed RTSP jointly between 1996 and 1997, and the IETF formalized it in RFC 2326 in 1998. A second version, RTSP 2.0, was published as RFC 7826 in 2016.

RTSP is a stateful application-layer protocol that establishes and controls one or several time-synchronized streams of continuous media — audio, video, or both. It does not transport the media data itself; instead, it issues commands (play, pause, teardown) to a media server that then delivers the actual content via RTP (Real-Time Transport Protocol).

The IETF definition from RFC 2326 describes RTSP as: "a network remote control for multimedia servers." When a user starts a video stream from an IP camera, the client device sends RTSP requests to the media server. Once the session is set up, the server delivers audio and video data over RTP while RTSP continues managing the session state.

RTSP was once a leading internet streaming protocol for both audio and video. HTTP-based adaptive bitrate streaming — HLS, DASH, and CMAF — eventually displaced RTSP for browser-based delivery. Today RTSP's primary role is first-mile ingest: IP cameras, NVRs, DVRs, and surveillance systems output RTSP streams that a media server receives, transcodes, and re-publishes in browser-compatible formats.

What is the RTSP Full Form?

The RTSP full form is Real-Time Streaming Protocol. Documentation, camera configuration panels, and network equipment interfaces use the abbreviation RTSP almost exclusively; the expanded form appears mainly in standards documents such as RFC 2326 and RFC 7826. Two adjacent acronyms cause frequent confusion: RTP (Real-Time Transport Protocol) carries the media payload, and RTCP (Real-Time Control Protocol) reports delivery statistics. RTSP, RTP, and RTCP operate together as a single stack in every RTSP deployment.

What is RTSP Streaming?

RTSP streaming is the delivery of live audio and video from a source device to a client using RTSP for session control and RTP for media transport. The term describes the complete workflow — camera or encoder output, session negotiation, RTP packet delivery, and playback in a compatible client — rather than the control protocol in isolation.

An RTSP stream originates at a device that has an RTSP server built into its firmware. IP cameras, NVRs, DVRs, drones, and encoders all expose one or more RTSP endpoints. A client connects to that endpoint, negotiates transport parameters, and receives a continuous RTP packet flow for as long as the session remains open. No separate encoder or ingest software is required, which is the single largest operational reason RTSP remains standard in surveillance.

What is an RTSP URL?

An RTSP URL identifies a specific stream on a specific device and follows this structure:

rtsp://[username]:[password]@[ip-address]:[port]/[stream-path]

The table below defines the 5 components of an RTSP URL and the values each component typically carries.

Component	Example	Purpose
Scheme	rtsp://	Declares the protocol; rtsps:// declares RTSP over TLS
Credentials	admin:password@	Digest or basic authentication for the device
Host	192.168.1.64	IP address or hostname of the camera, NVR, or server
Port	:554	RTSP control port; omitted when the device uses the 554 default
Stream path	/Streaming/Channels/101	Selects channel, profile, and resolution on multi-stream devices

The stream path is the only component that varies by manufacturer. Most cameras expose a main stream at full resolution and a sub-stream at reduced resolution on separate paths, and the correct path appears in the device's own documentation or its ONVIF profile. Guessing the path is the most common cause of a failed RTSP connection.

How Do You View an RTSP Stream?

Open the RTSP URL in a media player that supports the protocol. VLC Media Player is the standard verification tool because it ships RTSP support on Windows, macOS, and Linux and reports connection errors directly.

1. Open VLC Media Player and select Media → Open Network Stream.
2. Paste the complete RTSP URL including credentials, IP address, port, and stream path.
3. Set the caching value under Show more options — 300 ms is a practical starting point for a local network.
4. Press Play and confirm the stream renders.
5. Force TCP transport in VLC's RTSP preferences if playback stutters or fails, which indicates UDP is being blocked upstream.

A stream that plays in VLC but fails elsewhere confirms the camera and network are working and isolates the fault to the receiving application. A stream that fails in VLC points to credentials, the stream path, or port 554 access.

How Does RTSP Work?

RTSP works by separating session control from media transport: the RTSP layer handles signaling (play, pause, stop) while RTP handles the actual frame delivery. Here is the sequence of events in an RTSP streaming session.

1. OPTIONS request: The client queries the server to discover supported methods.
2. DESCRIBE request: The client requests the SDP (Session Description Protocol) file that describes the media stream's codecs, bitrate, and transport parameters.
3. SETUP request: The client specifies transport parameters — UDP or TCP, client port range for RTP/RTCP.
4. PLAY request: The server begins delivering RTP packets containing encoded video and audio frames.
5. PAUSE / TEARDOWN: The client halts or terminates the session; the server stops RTP delivery.

RTSP maintains a persistent TCP connection for this control channel throughout the session. The protocol resembles HTTP in syntax — requests use methods, headers, and status codes — but RTSP is stateful while HTTP is stateless. RTSP does not support content encryption natively and does not retransmit lost RTP packets, which contributes to its limitations in unreliable network conditions.

What Transport Protocol Does RTSP Use?

RTSP uses TCP for its control channel and relies on RTP (Real-Time Transport Protocol) over UDP for media delivery. The full protocol stack in a standard RTSP deployment consists of three components working together.

• RTSP — application-layer session control; runs over TCP port 554
• RTP (Real-Time Transport Protocol) — carries encoded audio/video frames; runs over UDP (dynamic ports)
• RTCP (Real-Time Control Protocol) — monitors RTP delivery quality (packet loss, jitter, round-trip delay); runs over the UDP port adjacent to the RTP port

When UDP is blocked by a firewall, RTSP can interleave RTP and RTCP data inside the TCP control connection — a mode called "RTSP interleaved binary data." This preserves connectivity at the cost of higher latency because TCP's retransmission mechanism introduces jitter. The entire RTSP/RTP/RTCP stack is commonly referred to simply as "RTSP" in product documentation and camera configuration interfaces.

RTSP Technical Specifications

The table below lists the core technical specifications of RTSP across 8 dimensions relevant to streaming infrastructure decisions.

Specification	RTSP Details
Standard	RFC 2326 (1998), RFC 7826 — RTSP 2.0 (2016)
Default Port	554 (TCP/UDP)
Transport Layer	TCP (control), RTP over UDP or TCP (media)
Latency	~1–2 seconds (network-dependent)
Video Codecs	H.265 (preview), H.264, VP9, VP8
Audio Codecs	AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis
Encryption	RTSPS over TLS (port 322); native RTSP has no built-in encryption
Primary Use Case	IP camera ingest, surveillance, NVR/DVR, first-mile delivery

The most important row is transport: RTSP uses TCP for its control channel but delivers media frames over RTP, which defaults to UDP. This separation is why RTSP achieves low latency for surveillance but struggles with scalable browser playback — UDP delivery and lack of native encryption are incompatible with modern browser security models.

Advantages and Disadvantages of RTSP

RTSP delivers low-latency ingest and universal device compatibility, and it lacks browser playback, adaptive bitrate, and native encryption. The table below compares 6 advantages against 6 disadvantages across the dimensions that determine whether RTSP fits a given deployment.

Advantages of RTSP	Disadvantages of RTSP
Delivers ~1–2 second latency on local networks	No native browser playback in Chrome, Firefox, Safari, or Edge
Built into virtually every IP camera, NVR, and DVR	No adaptive bitrate — a single rendition serves every client
Requires no separate encoder or ingest software	No encryption in the base specification; RTSPS over TLS is optional
Full session control — play, pause, seek, teardown	UDP media transport is blocked by many enterprise firewalls
Segment-level transport avoids buffering entire files	Unicast delivery caps concurrent viewers in the hundreds
IETF-standardized and stable since 1998	Incompatible with HTTP CDNs, so distribution cannot scale on cache

The disadvantage that determines architecture is browser incompatibility. Every other limitation has a workaround inside the RTSP ecosystem — TCP interleaving solves firewall traversal, RTSPS solves encryption — but no browser will ever play an RTSP URL, so any deployment with web viewers requires a media server performing protocol transcoding.

What Port Does RTSP Use?

RTSP uses port 554 by default for both TCP and UDP connections. Port 554 is the IANA-assigned standard port for RTSP. RTSPS — RTSP over TLS for encrypted transport — uses port 322 by default. The RTP data streams that carry the actual media are assigned dynamically on even-numbered UDP ports (typically in the range 6970–9999), with RTCP using the adjacent odd-numbered port.

For firewall configuration when deploying an RTSP streaming server, the following ports require access: port 554 (RTSP control), port 322 (RTSPS), and the dynamic UDP port range used by RTP. Many enterprise networks block UDP traffic, which forces RTSP to tunnel RTP over TCP — increasing latency but maintaining connectivity through restrictive network environments.

What is RTSPS and When Should You Use It?

RTSPS is RTSP transported inside a TLS tunnel, and it operates on port 322. The base RTSP specification defines no encryption for control messages, which means credentials in an RTSP URL and the session commands that follow travel in plaintext on an unencrypted connection. RTSPS closes that exposure for the control channel; encrypting the media payload itself requires SRTP alongside it. Deployments that route camera traffic across public networks, shared infrastructure, or any segment outside a trusted VLAN should use RTSPS rather than plain RTSP on port 554.

RTSP vs. Other Streaming Protocols

RTSP occupies the ingest layer of a streaming pipeline while HLS, DASH, and CMAF occupy the delivery layer, which means most protocol comparisons involving RTSP are comparisons between different pipeline stages rather than direct substitutes. The table below compares RTSP against 5 protocols across 5 dimensions that determine protocol selection.

Protocol	Latency	Transport	Browser Playback	Pipeline Role
RTSP	~1–2 seconds	TCP control + RTP/UDP media	No	Ingest
RTMP	~2–5 seconds	TCP only	No	Ingest
SRT	Configurable buffer	UDP with ARQ recovery	No	Ingest / contribution
WebRTC	Sub-500ms	UDP with DTLS-SRTP	Yes — native	Ingest and delivery
HLS	5–20 seconds (LL-HLS: sub-2s)	HTTP/HTTPS	Yes — universal	Delivery
CMAF	3–5 seconds (chunked: sub-3s)	HTTP/HTTPS	Yes — via HLS/DASH players	Delivery packaging

The clearest signal in the table is the browser column: only WebRTC, HLS, and CMAF reach a viewer directly. RTSP, RTMP, and SRT all terminate at a media server, which is why a complete architecture always pairs one ingest protocol with one delivery protocol.

RTSP vs RTMP: What Are the Differences?

RTSP and RTMP (Real-Time Messaging Protocol) are both first-mile ingest protocols, but they differ in origin, transport mechanism, and current ecosystem support. The table below compares 8 critical dimensions.

Dimension	RTSP	RTMP
Developed by	RealNetworks + Netscape + Columbia University (1996–97)	Macromedia / Adobe (mid-2000s)
Standard	IETF RFC 2326 / RFC 7826	Proprietary (Adobe); open spec published 2012
Transport	TCP (control) + RTP/UDP (media)	TCP only
Default Port	554	1935
Latency	~1–2 seconds	~2–5 seconds
Primary Use	IP camera ingest, CCTV, NVR	Encoder-to-server ingest (OBS, Wirecast, vMix)
Browser Playback	Not supported natively	Not supported (Flash is dead)
Encryption	RTSPS over TLS	RTMPS over TLS

The key operational difference is use case: RTSP is the native output protocol of IP cameras and NVRs, while RTMP is the native output of encoder software like OBS Studio. Both protocols serve exclusively as ingest mechanisms — neither can deliver video directly to a browser. A media server receives both RTSP and RTMP streams, then transcodes and re-distributes them in browser-compatible formats (WebRTC, HLS, or DASH).

RTSP vs WebRTC: What Are the Differences?

WebRTC is a browser-native real-time communication standard that achieves sub-500ms latency, making it fundamentally different from RTSP in scope and capability. RTSP is a session control protocol for managed server-client ingest; WebRTC is a peer-to-peer communication framework built into every modern browser.

Dimension	RTSP	WebRTC
Latency	~1–2 seconds	<500ms (sub-half-second)
Browser Support	None (requires plugin or transcoding)	Native — Chrome, Firefox, Safari, Edge, Opera
Encryption	Optional (RTSPS)	Mandatory — DTLS-SRTP for all streams
Architecture	Client-server (unicast)	Peer-to-peer or SFU/MCU server-mediated
Primary Use	IP camera ingest, surveillance	Video conferencing, interactive streaming, real-time apps
Scalability	Limited — single server unicast	Scales to thousands of viewers via an SFU
Codec Support	H.264, H.265, VP8, VP9	VP8, VP9, H.264, AV1 (browser-dependent)

RTSP and WebRTC are complementary rather than competing. A common architecture pairs them directly: an IP camera outputs an RTSP stream, Ant Media Server ingests it, transcodes the content, and re-publishes it as a WebRTC video stream for sub-500ms browser playback. This RTSP-to-WebRTC conversion eliminates the browser compatibility gap while preserving the low-latency ingest from IP cameras.

RTSP vs HLS: What Are the Differences?

HLS (HTTP Live Streaming), created by Apple in 2009, is an adaptive bitrate delivery protocol that operates over standard HTTP infrastructure — CDNs, load balancers, and web servers. RTSP is a session control protocol that requires a dedicated media server and direct TCP connections. Their use cases do not overlap.

Dimension	RTSP	HLS
Transport	TCP + RTP/UDP	HTTP/HTTPS
Latency	~1–2 seconds	5–20 seconds (LL-HLS: sub-2 seconds)
Browser Playback	Not supported	Universal — all major browsers and devices
Adaptive Bitrate	No	Yes — multiple quality renditions per stream
CDN Compatible	No	Yes — works with CloudFront, Akamai, Fastly
Scalability	Hundreds of viewers max	Millions of viewers via CDN
Primary Use	Camera ingest, surveillance	VOD delivery, broadcast, large-scale live streaming

HLS is the dominant protocol for last-mile delivery to viewers; RTSP is the dominant protocol for first-mile ingest from cameras. They operate at opposite ends of the streaming pipeline. A production streaming architecture typically uses RTSP for camera ingest, a media server for transcoding, and HLS (or Low-Latency HLS) for viewer delivery.

RTSP vs SRT: What Are the Differences?

SRT (Secure Reliable Transport) is an open-source contribution protocol that adds error recovery and AES encryption to UDP transport, which makes it the standard choice for long-distance links that RTSP handles poorly. RTSP was designed for local networks where packet loss is rare; SRT was designed for lossy public internet paths between production sites.

The practical division is distance. Inside a building or campus network, RTSP moves camera feeds to a media server with minimal overhead and no additional software. Across regions or over an unmanaged internet connection, SRT's ARQ retransmission and configurable latency buffer recover packets that RTSP would simply drop, at the cost of the buffer delay you configure. Neither protocol plays in a browser, so both terminate at the same place: a media server that converts the stream for delivery. Ant Media Server ingests SRT streams alongside RTSP, which allows a single deployment to accept camera feeds locally and contribution feeds remotely.

RTSP vs RTP: What Are the Differences?

RTSP and RTP are not alternatives — they are two layers of the same stack, and every RTSP session uses RTP. RTSP carries the commands; RTP carries the media. A client sends PLAY over RTSP on port 554, and the server responds by emitting a stream of RTP packets on a separately negotiated UDP port.

The confusion arises because camera interfaces label the whole stack "RTSP" while packet captures show mostly RTP traffic. Three distinctions resolve it: RTSP is stateful and connection-oriented over TCP, RTP is stateless and connectionless over UDP; RTSP defines methods (OPTIONS, DESCRIBE, SETUP, PLAY), RTP defines a packet header with sequence numbers and timestamps; and RTSP can exist without media flowing, while RTP cannot exist without a session to describe it. RTCP completes the stack by reporting jitter, packet loss, and round-trip delay back to the sender.

RTSP vs CMAF: What Are the Differences?

CMAF (Common Media Application Format) is an ISO/IEC 23000-19 standard that unifies HLS and MPEG-DASH into a single container format, reducing encoding, storage, and delivery costs. RTSP and CMAF solve different problems: RTSP controls ingest sessions, CMAF standardizes delivery packaging.

Before CMAF, broadcasters had to encode and store separate file packages for HLS (.ts segments) and MPEG-DASH (.mp4 segments) — doubling storage costs and CDN cache competition. CMAF eliminates this by using fMP4 (fragmented MP4) containers compatible with both HLS and DASH players. Latency with CMAF delivery targets 3–5 seconds, with chunked CMAF achieving sub-3 seconds in optimized deployments.

RTSP is irrelevant at the delivery layer where CMAF operates. An RTSP stream from a camera feeds into a media server, which can then package and deliver output as CMAF for cross-platform compatibility — the two protocols operate at different pipeline stages.

Common RTSP Use Cases and Applications

RTSP serves deployments where the video source is a fixed device that must reach a server with minimal latency and no encoder in between. The 6 applications below account for the majority of production RTSP traffic.

Video surveillance and CCTV. Security installations are the largest RTSP deployment category. Cameras publish RTSP endpoints, an NVR or VMS pulls those endpoints continuously, and operators view feeds on a control-room wall. RTSP's ~1–2 second latency is sufficient for monitoring, and its presence in camera firmware removes any per-device software cost. Deployments that add remote or browser-based viewing convert RTSP to WebRTC at the server; Ant Media Server supports this pattern for live video monitoring and surveillance.

Traffic and public infrastructure monitoring. City transport authorities, toll operators, and highway agencies run thousands of fixed cameras that feed automatic number plate recognition and congestion analytics. RTSP suits this because the analytics engine consumes frames directly from the RTSP endpoint, and no viewer-facing playback is required for the machine-vision path.

Retail loss prevention and operations analytics. Multi-site retailers aggregate store camera feeds into a central platform for shrinkage investigation and footfall measurement. The volume of endpoints — hundreds of cameras per chain — makes RTSP's zero-configuration availability more valuable than any latency advantage a different protocol could offer.

Drones, robotics, and remote vehicles. Onboard cameras on drones and unmanned ground vehicles commonly expose RTSP over the vehicle's network link, giving a ground station a live feed for navigation. These deployments frequently pair RTSP ingest with WebRTC delivery, because the operator needs latency low enough to control the vehicle in response to what the camera shows.

Telehealth and medical imaging. Clinical video — surgical cameras, endoscopes, ultrasound outputs — often originates from equipment that speaks RTSP natively. The receiving platform transcodes to an encrypted, browser-deliverable format so that clinicians can view feeds without installing device-specific software.

Broadcast contribution and remote production. Camera and encoder hardware in field production frequently offers RTSP output alongside SRT and RTMP. RTSP handles the local leg from camera to on-site server, and the server forwards the feed onward for distribution.

Every one of these applications shares the same downstream requirement: the RTSP feed must become something a browser or mobile app can render. That conversion step, not the RTSP ingest, is where deployments differ.

What are the RTSP Requests?

RTSP defines 12 methods that clients send to the server to control media sessions. Each method maps to a specific phase of the streaming lifecycle. The table below lists each method, the direction it travels, and its function.

Method	Direction	Function
OPTIONS	Client → Server	Queries which methods the server supports; typically used to determine available operations
DESCRIBE	Client → Server	Retrieves the SDP description containing stream codecs, bitrate, and transport parameters
ANNOUNCE	Both directions	Provides or updates the media presentation description
SETUP	Client → Server	Specifies transport parameters, such as UDP or TCP, before playback begins
PLAY	Client → Server	Instructs the server to begin RTP media delivery
PAUSE	Client → Server	Temporarily halts media delivery without terminating the session
RECORD	Client → Server	Requests the server to record the media stream
TEARDOWN	Client → Server	Terminates the session and associated media streams
REDIRECT	Server → Client	Instructs the client to reconnect using a different server URL
GET_PARAMETER	Both directions	Retrieves a session parameter and can be used as a keep-alive request
SET_PARAMETER	Both directions	Sets or updates a session parameter on the receiving endpoint
EMBEDDED	Server → Client	Carries interleaved binary RTP data within the RTSP TCP connection

The OPTIONS-DESCRIBE-SETUP-PLAY sequence is mandatory for every RTSP session; the remaining eight methods are optional depending on the use case. GET_PARAMETER deserves particular attention in production deployments — cameras and servers use it as a session keep-alive, and a client that omits it will see sessions drop at the server's timeout interval.

How Does RTSP Work with IP Cameras?

RTSP is the native output protocol of virtually all IP cameras, NVRs, and DVRs — it is included on almost every IP camera on the market. IP cameras stream to a media server using the RTSP URL format: rtsp://[username]:[password]@[camera-ip]:554/[stream-path]. The media server establishes an RTSP session with the camera and pulls the RTP stream continuously.

IP cameras do not require a separate encoder — RTSP is the built-in transmission mechanism. This makes RTSP the standard for surveillance, CCTV, fixed-location broadcasting, and remote monitoring use cases. The limitation is that RTSP streams cannot be delivered directly to browsers; they require a media server to transcode and re-publish the content in browser-compatible formats. Ant Media Server handles IP camera streaming via RTSP pull, converting ingest to WebRTC, HLS, or DASH for viewer delivery.

RTSP Streaming with Ant Media Server

Ant Media Server supports RTSP as both an ingest and output protocol. On the ingest side, Ant Media Server pulls RTSP streams from IP cameras, NVRs, and any RTSP-compatible source. On the output side, it can deliver streams as RTSP output alongside WebRTC, HLS, DASH, and CMAF.

Key RTSP capabilities in Ant Media Server include RTSP stream pulling from IP cameras, RTSP output for downstream RTSP-compatible systems, protocol transcoding from RTSP ingest to WebRTC or HLS delivery, and support for H.264 and H.265 codec passthrough from RTSP sources. Ant Media Server deploys on AWS, Azure, GCP, Alibaba Cloud, and on-premises Linux environments.

How to Set Up a Free RTSP Server in 7 Steps

Ant Media Server Community Edition is free, open-source, and self-hosted. It includes RTSP ingest support, HLS playback, MP4 recording, and IP camera integration.

1. Download Ant Media Server

Download the Ant Media Server installer to your Linux server.

• Community Edition: download from GitHub releases

2. Open Terminal and Navigate to the Directory

cd /home/ubuntu

3. Download the Installation Script

wget https://raw.githubusercontent.com/ant-media/Scripts/master/install_ant-media-server.sh && chmod 755 install_ant-media-server.sh

4. Run the Installation Script

Run the script without parameters to install the latest Community Edition automatically:

sudo ./install_ant-media-server.sh

5. Control the Service

sudo service antmedia status
sudo service antmedia stop
sudo service antmedia start

6. Install SSL for Your RTSP Server

Skip this step for localhost installations. For public deployments, assign a domain to your server's public IP, navigate to the Ant Media installation directory, and run the SSL script:

cd /usr/local/antmedia
sudo ./enable_ssl.sh -d {DOMAIN_NAME}

7. Access the Web Panel

Open your browser and navigate to http://SERVER_IP_ADDRESS:5080. If the panel is inaccessible, verify that port 5080 is open in your firewall rules. The RTSP server is now running and ready to receive streams from IP cameras on port 554.

Frequently Asked Questions

What does RTSP stand for?

RTSP stands for Real-Time Streaming Protocol. It is an IETF-standardized application-layer protocol (RFC 2326, 1998) that controls multimedia streaming sessions between a client and a media server. RTSP issues commands like play, pause, and teardown; actual media delivery uses RTP (Real-Time Transport Protocol).

What port does RTSP use?

RTSP uses port 554 by default for both TCP and UDP connections. RTSPS (RTSP over TLS) uses port 322. RTP media streams are delivered on dynamically assigned even-numbered UDP ports, typically in the 6970–9999 range, with RTCP on the adjacent odd port.

Is RTSP still used?

Yes. RTSP is the dominant ingest protocol for IP cameras, NVRs, and DVRs and remains the standard in surveillance and CCTV architectures. It is no longer used for browser-based playback delivery — HTTP-based protocols (HLS, DASH, WebRTC) have replaced it at the delivery layer.

How do I view an RTSP stream?

Open the RTSP URL in VLC Media Player under Media → Open Network Stream. Enter the full URL including credentials, IP address, port 554, and the stream path from the camera documentation. Force TCP transport in VLC's RTSP preferences if UDP is blocked on the network.

Do all IP cameras support RTSP?

RTSP is included on virtually all IP cameras, NVRs, and DVRs. Most IP cameras expose an RTSP URL in the format rtsp://[user]:[password]@[camera-ip]:554/[stream-path]. Exact URL format varies by manufacturer — check your camera's documentation for the specific stream path.

What is the difference between RTSP and RTP?

RTSP and RTP are two layers of one stack, not alternatives. RTSP carries session commands over TCP port 554; RTP carries the encoded audio and video frames over dynamically assigned UDP ports. Every RTSP session uses RTP for media transport, and RTCP reports delivery quality alongside it.

What are the disadvantages of RTSP?

RTSP has no native browser playback, no adaptive bitrate, and no encryption in the base specification. Its UDP media transport is blocked by many enterprise firewalls, and unicast delivery caps concurrent viewers in the hundreds. RTSP is also incompatible with HTTP CDNs, which prevents cache-based distribution.

How do I set up a free RTSP server?

Install Ant Media Server Community Edition on a Linux machine using a single-command installation script from the Ant Media GitHub repository. The Community Edition is free, supports RTSP ingest on port 554, IP camera pulling, HLS playback, and MP4 recording. Installation takes under 10 minutes on a standard Ubuntu server.

Conclusion

RTSP — standardized as RFC 2326 in 1998 — operates on port 554, uses TCP for session control and RTP/UDP for media delivery, and remains the dominant ingest protocol for IP cameras, NVRs, and DVRs across surveillance and CCTV architectures. RTSP does not compete with WebRTC, HLS, SRT, or CMAF; it occupies the first-mile ingest role while those protocols handle contribution and browser-based delivery at different latency tiers: WebRTC at sub-500ms, LL-HLS at sub-2 seconds, and standard HLS at 5–20 seconds.

The correct deployment pattern is RTSP ingest → media server transcoding → WebRTC or HLS delivery to viewers. A media server such as Ant Media Server can handle this full pipeline — pulling RTSP streams from cameras on port 554, converting to WebRTC for real-time browser playback, and scaling to viewer loads that single RTSP unicast connections cannot support.

---

Disclosure: I work on the marketing team at Ant Media, whose media server is used in the setup example above. This article was originally published on the Ant Media blog.