RTSP Protocol Explained: How It Works and When to Use It

TL;DR

The Real-Time Streaming Protocol (RTSP) controls streaming sessions between clients and media servers. It handles actions such as describing, starting, pausing, and stopping a stream, while RTP usually carries the audio or video itself.

RTSP remains valuable for IP cameras, network video recorders, and private surveillance systems. However, browsers do not support it natively. If viewers need low-latency playback on the web or in mobile applications, use an RTSP gateway and a browser-compatible delivery layer such as WebRTC.

Understanding the Real-Time Streaming Protocol

RTSP is an application-layer protocol for establishing and controlling media sessions. A client uses it to ask a streaming server what media is available, negotiate transport settings, begin playback, pause it, or close the session.

The simplest analogy is a remote control:

• RTSP issues commands.
• RTP commonly transports the media.
• RTCP reports transmission and reception quality.
• SDP describes the available audio and video tracks.

This distinction matters because RTSP does not define a particular video codec or deliver every media packet by itself. A stream may contain H.264, H.265, AAC, G.711, or another format, depending on what the server and client support.

RTSP was originally standardized as RFC 2326. RTSP 2.0 later updated the protocol in RFC 7826, but many cameras and recorders still implement RTSP 1.0.

How an RTSP Session Works

An RTSP session usually follows a predictable negotiation sequence:

RTSP client                 RTSP server / IP camera
     |-------- OPTIONS ------------------>|
     |<------- supported methods ---------|
     |-------- DESCRIBE ----------------->|
     |<------- SDP media description -----|
     |-------- SETUP video track -------->|
     |<------- session + transport --------|
     |-------- PLAY --------------------->|
     |<======= RTP audio/video ===========|
     |-------- TEARDOWN ----------------->|

Here is the process step by step:

1. Discover capabilities. The client sends OPTIONS to learn which RTSP methods the server accepts.
2. Inspect the stream. A DESCRIBE request retrieves an SDP document listing tracks, codecs, and control URLs.
3. Negotiate transport. The client sends SETUP for each track and specifies whether media should travel over UDP or interleaved over the RTSP TCP connection.
4. Start playback. A PLAY request tells the server to transmit the selected tracks.
5. Maintain the session. Keepalive requests may be required so the camera or server does not expire the session.
6. Close cleanly. TEARDOWN releases server and network resources.

UDP can minimize delay, but firewalls and network address translation may block the required ports. RTP interleaved over TCP is often easier to traverse and avoids packet loss at the transport layer, although retransmission can increase delay on unstable networks.

Essential RTSP Requests

RTSP resembles HTTP in its text-based request syntax, but it is stateful and designed around media sessions. Common methods include:

• OPTIONS: Lists methods supported by the server.
• DESCRIBE: Requests the media description, normally in SDP.
• ANNOUNCE: Publishes or updates a presentation description.
• SETUP: Selects the transport for an individual media track.
• PLAY: Starts or resumes media transmission.
• PAUSE: Temporarily stops playback without destroying the session.
• RECORD: Requests recording when the server supports it.
• GET_PARAMETER: Retrieves a parameter and is often used as a keepalive.
• SET_PARAMETER: Changes a session or stream parameter.
• TEARDOWN: Ends the session.
• REDIRECT: Tells the client to connect to another server.

A basic RTSP protocol example might look like this:

DESCRIBE rtsp://camera.example.com/live/main RTSP/1.0
CSeq: 2
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Length: 156

v=0
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:trackID=1

The response says that the presentation includes an H.264 video track. The client then sends SETUP to the track’s control URL before issuing PLAY.

Not every camera implements every method correctly. For production integrations, test the exact device firmware rather than assuming complete RFC compliance.

RTSP Technical Details That Affect Deployment

Several technical decisions determine whether an RTSP stream will work reliably.

Default port: RTSP conventionally uses TCP or UDP port 554. A server can run on another port, in which case it appears in the URL, such as rtsp://192.168.1.20:8554/live.

Media transport: RTP and RTCP can use separate UDP ports negotiated through SETUP. Alternatively, the media can be interleaved over the same TCP connection as RTSP.

Codecs: RTSP is codec-independent. H.264 is broadly supported by cameras and recorders, while H.265 can reduce bandwidth but may require transcoding for browser delivery. Audio compatibility varies widely.

Authentication: Cameras commonly support Basic or Digest authentication. Do not embed long-lived credentials in public URLs, browser code, logs, or analytics events.

Latency: RTSP does not guarantee a fixed latency. Buffer size, codec settings, keyframe interval, transport choice, transcoding, and player behavior all affect glass-to-glass delay.

Scalability: A camera may support only a small number of simultaneous sessions. Sending every viewer directly to an IP camera can exhaust its connection or upload capacity. A gateway or media server should ingest the camera once and fan the stream out.

Playback compatibility: Desktop players and surveillance software commonly support RTSP, but mainstream browsers do not. Browser delivery therefore requires conversion to WebRTC, HLS, or another supported format.

Where RTSP Is the Right Choice

RTSP is most useful when the source device or existing infrastructure already exposes an RTSP stream.

1. Connecting IP cameras to an NVR

   RTSP provides a practical fallback when an ONVIF discovery or configuration workflow fails. If the recorder supports the camera’s codec and RTSP URL format, it can often ingest the stream directly.

2. Local security monitoring

   RTSP works well on managed networks where operators use dedicated players or surveillance applications. Administrators can control firewall rules, credentials, and device compatibility.

3. Creating a centralized camera gateway

   A gateway can pull one RTSP session from each camera, normalize codecs, record footage, and redistribute video to many viewers. This protects cameras from excessive direct connections.

4. Integrating established media equipment

   Encoders, industrial cameras, and older streaming systems may provide RTSP as their primary output. Replacing that equipment may be unnecessary when a bridge can adapt the stream.

5. Feeding real-time applications

   RTSP is suitable for ingesting a camera feed, but it is usually not the best last-mile format for websites. A real-time application can retain RTSP on the device side and convert the stream for interactive delivery.

Before choosing RTSP, verify the stream URL, authentication mode, codec, resolution, frame rate, transport mode, and maximum number of concurrent sessions. These details have more practical impact than nominal protocol support.

RTSP Compared with RTMP

RTSP and RTMP both appear in low-latency video workflows, but they solve different problems.

RTSP is primarily a session-control protocol. It is common in IP cameras, NVRs, surveillance software, and local media systems. Media generally travels through RTP over UDP or TCP.

RTMP carries media over a persistent TCP connection. Although browser plugins no longer make RTMP directly playable on the web, many live-streaming platforms still accept it as an ingest protocol from broadcasting software and hardware encoders.

Choose RTSP when integrating IP cameras or systems that require commands such as DESCRIBE, SETUP, and PLAY. Choose RTMP when sending a produced broadcast feed to infrastructure that explicitly accepts RTMP ingest.

Neither protocol is natively playable in modern browsers. RTMP commonly feeds an HLS or WebRTC distribution pipeline, while RTSP camera streams usually pass through a gateway before web delivery.

How to Build an App Like This with Tencent RTC

For a browser or mobile application that displays RTSP camera feeds in real time, keep RTSP at the ingest edge and use Tencent RTC Engine as the interactive delivery layer. Tencent RTC provides cross-platform real-time audio and video, global low-latency transport, weak-network resilience, monitoring, and media processing.

A practical architecture is:

IP camera
   ↓ RTSP/RTP
Ingest gateway
   ↓ decode or transcode when required
Tencent RTC publisher
   ↓ Tencent RTC real-time network
Web, iOS, Android, or desktop viewers

Tencent RTC Engine does not turn a browser into a native RTSP client. The gateway owns camera credentials, opens the RTSP session, and converts unsupported camera media. It then publishes the normalized stream as a room participant. Viewers join that room and subscribe without receiving the original RTSP URL.

Follow this implementation path:

1. Pull each camera stream through a protected gateway.
2. Inspect the SDP and normalize codecs when the destination SDK cannot consume the source format.
3. Create a Tencent RTC room and assign the gateway a publisher identity.
4. Generate UserSig credentials on a trusted application server, never in browser code.
5. Publish the gateway media into the room.
6. Let web or mobile viewers enter the room and subscribe to the remote publisher.
7. Use application-level APIs for camera selection or PTZ commands rather than exposing RTSP credentials.
8. Monitor publishing state, viewer quality, packet loss, and reconnect behavior.

For an operator page that can publish its own camera and subscribe to a gateway feed, install trtc-sdk-v5 and use the room and media APIs below. startLocalAudio() and startLocalVideo() capture and publish after room entry; startRemoteVideo() subscribes to an available remote stream.

import TRTC from 'trtc-sdk-v5';

const trtc = TRTC.create();

trtc.on(TRTC.EVENT.REMOTE_VIDEO_AVAILABLE, async ({
  userId,
  streamType
}) => {
  const view = document.createElement('div');
  view.id = `remote-${userId}`;
  document.querySelector('#remote-grid').appendChild(view);

  await trtc.startRemoteVideo({
    userId,
    streamType,
    view: view.id
  });
});

await trtc.enterRoom({
  sdkAppId: APP_ID,
  userId: currentUser.id,
  userSig: userSigFromYourServer,
  roomId: 10001,
  scene: 'rtc'
});

await trtc.startLocalAudio();
await trtc.startLocalVideo({ view: 'local-preview' });

A receive-only camera viewer can omit the two local capture calls. The RTSP gateway remains the publisher, while the browser only enters the room and subscribes. Review the official Tencent RTC integration overview before selecting SDKs and implementing authentication, room entry, publishing, and playback.

Frequently Asked Questions

Do web browsers support the RTSP protocol natively?

No. Chrome, Safari, Firefox, and Edge do not provide native RTSP playback. Convert the stream to WebRTC for low-latency interaction or HLS when scale matters more than delay.

What port does RTSP use?

The default RTSP port is 554 over TCP or UDP. Servers can use alternatives such as 8554, which must be included in the stream URL and allowed by the firewall.

Is RTSP the same as RTP?

No. RTSP controls the session through commands such as SETUP and PLAY; RTP typically transports the actual audio and video packets.