4 Reasons RTSP Streaming is Still Relevant

In 1996, people browsed the Internet(s) with Netscape Navigator, still did searches via Yahoo (not to mention AltaVista), and the first flip phone was the coolest gadget available. ‘96 also marks the year of RTSP streaming’s creation. While many of its technological peers have fallen into disuse (remember the Gopher protocol?), RTSP has still somehow managed to stay relevant.

The question is: why? How, in the ever-changing tech world, has RTSP survived? This post presents four reasons.

What is RTSP?

First, let’s examine the roots of RTSP.

The Real-Time Streaming Protocol (RTSP) is a network control protocol designed to send low latency streams. Developed by experts from RealNetworks, Netscape, and Columbia University around 1996, the protocol defines how the data in the stream should be packaged for delivery. It also defines how both ends of the connection should behave to prepare a pathway for transportation.

The client application uses RTSP to communicate to the server information such as the type of application the client is using, the mechanism of delivery (unicast or multicast, UDP or TCP), the media being requested, and other important control information commands such as DESCRIBE, SETUP, and PLAY. [SOURCE]

It’s important to note that RTSP does not actually transport the media. Like WebRTC, RTSP streams use the Real-Time Transport Protocol (RTP) in conjunction with the Real-time Control Protocol (RTCP) for media stream delivery. RTSP can also use SRTP to encrypt the stream so that it remains secure. However, some vendors implement proprietary transport protocols. The RTSP streaming server software from RealNetworks, for example, also used RealNetworks’ proprietary Real Data Transport (RDT). For the sake of simplicity, when we refer to RTSP, we are talking about the version that also uses RTP or its secure cousin (SRTP) for the transport.

1) Better for a Client-Server Model

Unlike WebRTC, RTSP is a little simpler to run as it does not perform all the signaling and NAT traversal techniques that WebRTC does. This is mainly because RTSP was designed to send and receive media streams from media servers in a client-to-server model, as opposed to WebRTC which was designed as a peer-to-peer protocol. With each WebRTC connection, you also have to maintain a separate signaling connection, whether that’s WebSocket’s or the new web standards WHIP and WHEP. With RTSP, there’s a single connection per subscriber/publisher client.

Without the higher overhead of WebRTC, RTSP streams put less strain on the server and thus allows for more connections.  We have detailed the WebRTC signaling process in another post.

2) Many Supported Devices

The RTSP protocol provides for incredible cross-device compatibility.

IP Cameras

Since IP cameras have been around since the 90s they were one of the earliest adopters of the Real Time Streaming Protocol for streaming, and thus they still continue to use it today. If it ain’t broke, don’t fix it. There are various uses for IP cameras, such as traffic monitoring for reporting or enforcement, security surveillance, and even home monitoring. Acting as a video streaming server to support multiple IP cameras ingest streams continues to be one of the most common use cases for Red5 Pro. This solution combined with Red5 Pro’s highly scalable clustering model allows for virtually unlimited numbers of concurrent RTSP streams from many cameras.

Other IoT Devices

Drones enjoy widespread use expanding well beyond a backyard hobby. Smartphone or laptop controlled drones can be guided with the assistance of a live video feed (often an RTSP stream). Firefighters and U.S. Border patrol agents have used drones to conduct operations. Additionally, aerial surveying is useful for maintaining infrastructure by examining power lines, and roads or even conducting geologic surveying. RTSP support is often built right into the drone software and is a common way to access a drone’s video stream in near real-time.

When connecting the video stream from the drone to an RTSP compatible media server, or even a cluster of media servers, it’s possible to scale the number of viewers of the RTSP stream to as many users as needed. In critical military or first responder use cases, this real-time one-to-many stream can be reviewed with other agencies, high ranking officials, and others to make critical decisions. Most current implementations of this use case involves a high latency stream, usually using high latency streaming HTTP based protocols like HLS (HTTP Live Streaming Protocol) which incurs many seconds of delay. An RTSP to WebRTC solution brings the latency down so that decision makers can make critical calls immediately since the video stream is being captured and transported in mere milliseconds.

A great example of this is the San Diego Sheriff’s Department use of Red5 Pro with Nomad Media for real-time drone streaming, allowing for a cost effective solution deployed on AWS to remotely monitor fires, natural disasters, and other emerging situations.

Robots

From underwater submersibles and radiation tests to bomb diffusing, robots are being created for a variety of video streaming applications. As a well-established solution with very low latency, robot-based computer systems will typically use the RTSP protocol for video delivery. The use of video allows the operator to control the robot and perform a wide variety of operations. Among the most impactful are medical robots such as remote surgery and telepresence robots, which enable doctors to communicate and work in isolated areas. Clearly, real-time latency, measured in milliseconds, is key to this use case.

As is the case with the first responder/military example mentioned above, scaling the single RTSP stream to many viewers can be an important aspect. The use of multiple RTSP servers set up in a cluster to fan out the delivery of the media stream to many viewers (other surgeons/experts) makes real-time collaboration possible.

Luckily, the RTSP protocol, with its ability to transport over UDP using secure RTP and connect to compatible media servers, means it is well-suited for these types of applications.

3) Mobile Support

Normally the list of supported devices would stop there, as RTSP does not enjoy native mobile support. This would be an unfortunate shortfall of a very useful protocol. However, our Red5 Pro Mobile SDK was built to use RTSP to send and receive streams on Android and iOS devices.

The Real-Time Streaming Protocol is a simple way to connect a large number of broadcasters to a large number of subscribers. As mentioned earlier, RTSP puts less strain on the media server than WebRTC. Accordingly, a single server instance will support more connections as reflected by our benchmarks.

For example, a single c5.large instance (2CPU 4GB) running the latest Red5 Pro can handle 500 WebRTC subscribers or 2,000 RTSP connections. That means the cost of the Red5 Pro Mobile SDK will quickly be recouped by the 4X reduction in bandwidth costs. When deploying a streaming server on a cloud platform like AWS, it is possible to rack of huge bills of egress charges. Media Servers like Red5 Pro that support RTSP streaming can make a huge impact on the costs of operating real-time one-to-many use cases, especially when the cloud vendor is charging 6¢ per GB transferred.

4) Low Latency

By using the efficient RTP protocol, RTSP achieves a very low latency: well under 500 milliseconds when used with Red5 Pro. As RTP also forms the underlying protocol for WebRTC, most RTSP implementations are essentially a stripped-down version of WebRTC. One can get the same performance without the complexity.

In order to achieve this low latency, RTP sends video and audio data in small chunks suitable for quick transmission between the servers and clients. Each chunk of data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. As each packet is processed, the following packets may already be in the stage of decompression or demultiplexing.

To cope with the occasional loss of packets (a hazard of Internet delivery in general), the RTP header contains timing information and a sequence number that allows the receivers to reconstruct the timing produced by the source. So if anything is out of order it can be quickly organized in proper order for playback.

The general structure of RTP consolidates essential information which in turn streamlines the process of media delivery. Thus it can achieve effective delivery of media streams with very low latency.

For a very detailed explanation of how RTP works please refer to our blog article on WebRTC.

Why Use RTSP?

RTSP Protocol is a great option for real-time live streaming video. Despite the very rapid pace of technology, RTSP’s simple design means it remains just as relevant and useful today as it did back in ‘96.

An RTSP compatible media server can easily handle a large amount of RTSP streams since the RTSP protocol was built over a client-server model. With native support for a variety of devices such as drones, IoT and robots, it enjoys broad compatibility. When paired with Red5 Pro’s Mobile SDK, RTSP can be extended to Android or iOS devices as well. Like WebRTC, RTSP uses RTP to transport the video and data stream. Thus it boasts a real time latency of sub 500 milliseconds.

Want to try out Red5 Pro’s RTSP solution yourself? Check out our real time latency demo and sign-up for a free trial.

Have a few questions before jumping in? Send a message to info@red5.net or schedule a call. We’d love to show you what Red5 Pro can do!