RTSP over HTTP

Bypass firewalls and network restrictions by tunneling RTSP streams through HTTP ports (80/443). Understand the dual-socket mechanism for seamless streaming.

The Problem: RTSP and Firewalls

Standard RTSP uses port 554 for control and dynamically assigned ports for media data. Many corporate or public networks block port 554 and restrict outgoing connections to only common web ports: HTTP (80) and HTTPS (443).

This prevents RTSP clients from connecting to media servers, making live streaming impossible in these environments.

The Solution: RTSP over HTTP (Tunneling)

RTSP over HTTP, also known as RTSP tunneling, solves this by encapsulating RTSP control commands and media data within standard HTTP requests.

Instead of using port 554, the entire RTSP session is tunneled through the open HTTP (80) or HTTPS (443) ports, making it appear as regular web traffic to firewalls.

Note: This is not the same as HTTP streaming (like HLS or DASH). It's a tunneling technique to transport RTSP protocol data over HTTP ports.

How It Works: The Dual-Socket Mechanism

RTSP over HTTP relies on two separate TCP connections (sockets) between the client and server:

  1. Command Socket: Used for sending RTSP commands (e.g., DESCRIBE, SETUP, PLAY, TEARDOWN).
  2. Data Socket: Used for receiving the actual audio/video data (RTP packets).

The process begins with an HTTP handshake that establishes these two dedicated channels.

Step-by-Step Connection Process

1. Establish Data Socket (HTTP GET)

The client initiates a connection to the server's HTTP port and sends an HTTP GET request to signal the desire to establish a media data channel.

Client → Server (Data Socket)
GET /rtsp_tunnel HTTP/1.1
Host: server.com
...

The server responds, acknowledging the request and keeping the connection open.

2. Establish Command Socket (HTTP POST)

The client opens a second connection and sends an HTTP POST request. This socket is dedicated to RTSP control commands.

Client → Server (Command Socket)
POST /rtsp_tunnel HTTP/1.1
Host: server.com
Content-Type: application/x-rtsp-tunnelled
...

After this, the HTTP layer's job is done. The two sockets are now established for RTSP communication.

3. RTSP Communication Over the Sockets

Once the tunnel is set up, standard RTSP commands are sent and received:

  • Commands (e.g., PLAY): Sent via the Command Socket (POST requests).
  • Responses (e.g., 200 OK): Received via the Data Socket (the long-held GET connection).
  • Media Data (RTP): Received via the Data Socket.

This separation ensures that control signals and media data do not interfere with each other.

Key Characteristics

  • Port Agnostic: Uses standard HTTP (80) or HTTPS (443) ports, bypassing firewall restrictions.
  • TCP-Only: Both control and data are transported over TCP, ensuring reliable delivery but potentially higher latency than UDP.
  • Client-Driven: The client manages the two sockets and sends commands through the POST tunnel.
  • Server Response Path: The server sends responses and media data back through the open GET connection (Data Socket).

When to Use RTSP over HTTP

This technique is essential in environments with strict network policies:

  • Corporate networks blocking non-standard ports.
  • Public Wi-Fi hotspots.
  • Cloud environments with restrictive security groups.
  • Integrating with web applications that cannot open port 554.
Consideration: Tunneling adds a small overhead. Use standard RTSP (port 554) when network access is available for optimal performance.

Implementation with Happytime

Happytime RTSP Server supports RTSP over HTTP tunneling. Clients can connect using the server's HTTP/HTTPS endpoint, and the server will handle the dual-socket negotiation and RTSP command routing seamlessly.

For client developers, ensure your RTSP client library supports the tunneling mode (often called "HTTP tunneling" or "RTSP over HTTP").