RTSP – All You Need to Know About Real-Time Streaming Protocol

What is RTSP?

RTSP is one of two very long-running media-streaming protocols still in current use; you might be familiar with the acronym due to RTSP’s utility with streaming media servers.

You may be less familiar with RTSP’s long history (it was invented in 1996!) and its current status and application.

As protocols go, RTSP streaming is sometimes considered a less-popular competitor to other “old-timer” streaming technology, RTMP, or less relevant than newer web-server-based protocols. Technology has changed over time and the older protocols have changed roles and remained useful, however in most cases they’re no longer employed as streaming solutions in their own right. Rather RTSP and RTMP are now most often in use for encoding and ingesting media as the “first mile” of a larger streaming workflow, as opposed to their former role as “last mile” delivery formats.

Streaming protocols and video broadcasting can get highly complex and technical, not to mention filled with acronyms, but this article will lay out everything you need to know about Real-Time Streaming Protocol in a few concise bullets to determine whether using RTSP is going to be a key part of your workflow and suggesting a potential RTSP to RTMP ingest solution that can help make your RTSP devices input more compatible with platforms that favor RTMP encoding.

• The History of RTSP Streaming
• How Does RTSP Protocol Work?
• RTSP vs. RTMP
• A Sample RTSP to RTMP Ingest Solution

The History of RTSP Streaming

RTSP streaming has been around for quite some time. A partnership between RealNetworks, Netscape, and Columbia University first developed and delivered the protocol in 1996-97. RTSP protocol was developed through hands-on experience of streaming practice with RealNetworks’ RealAudio and Netscape’s LiveMedia. Its main purpose was as Mozilla’s wiki puts it, “VCR-like control” (younger readers, ask your parents) over media streams—in other words, the now-common ability to play, pause, rewind, and otherwise direct the viewing experience.

RTSP was standardized in 1998 as RFC 2326 and immediately became useful as a way for users to play audio and video straight from the internet as opposed to having to first download the files to their device.

It built on existing standards of the time, resembling HTTP in operation (and therefore easily compatible with existing HTTP networks), and was able to use SDP (Session Description Protocol, standardized 1998) for multimedia communication sessions.

Essentially RTSP is an application-layer protocol that communicates with a media server for session establishment and to send commands such as “Pause” and “Play,” rather than transmit actual stream data. Traditionally most RTSP servers also use RTP (Real-time Transport Protocol) and RTCP (Real-time Control Protocol) to deliver their media streams.

RTSP was immediately employed for a variety of uses such as live presentation, internet camera sites, online education, and internet radio, and subsequently included by platforms still in use today such as YouTube and Spotify, communications applications like Skype, and media players WMP and VLC.

RTSP and RTMP were once the leading technologies for internet audio and video streaming, however since both protocols require dedicated servers to be used for last-mile content delivery, they didn’t scale up well to large broadcasts. Over time HTTP-based progressive download technologies and adaptive bitrate streaming solutions began to eclipse the old go-to’s. Original authors Anup Rao and Rob Lanphier, as well as others, proposed an RTSP version 2.0 in 2016, with updates intended to shorten round trip communications with the media server and address some issues with network address translation (NAT).

Nowadays, RTSP is most often used as a contribution protocol, that is, a means to encode content that will then be streamed out to viewers through other methods. RTSP also remains the protocol of choice for IP cameras, which are used in a majority of surveillance, CCTV, and conference video technologies, all of which might be used as a source for live broadcast.

How does RTSP protocol work?

Broadly, protocols are rules that dictate how data travels from one system to another. For example, the well-known Hypertext Transfer Protocol (HTTP) governs communications between web servers and browsers, defining how page data and hypertext/links are sent across the web.

As noted above, RTSP is conceptually similar to HTTP in function and was easily compatible with existing HTTP networks when it was first developed.

We noted before that its authors described RTSP as a “network remote control” for media servers. It was designed to control the streams without any need for local download. When a video stream is started, a device using the protocol sends an RTSP request to the media server that initiates the setup process.

RTSP also supports several control request operations (also known as “commands”) such as play, pause, setup, etc. The initial request should also report back to the client what options are available through the “OPTIONS” command. From there on out a user can watch, cue up, or shut down the stream based on what parameters are allowed. RTSP maintains an end-to-end connection with TCP and achieves high transmission speed by turning on the proverbial data spigot through this stable connection without requiring any local download or caching.

Because RTSP depends on a dedicated server for streaming and relies on RTP to transmit actual media, the protocol does not support content encryption or the retransmission of lost packets. And while RTSP is similar in syntax and operation to HTTP, it also has differences and incompatibilities, and there was no way to stream it in an easy, straightforward way from a web browser without adding additional software. Due to these factors and the previously mentioned issue of scaling to large broadcasts, it was gradually eclipsed by newer streaming technology.

On today’s internet, a video streaming workflow that includes RTSP would most likely use a media server to ingest streams transmitted through RTSP/RTP (per its designation as a “contribution protocol” or “first-mile” technology) and then utilize another means of delivery to repackage and send the content to be watched on a wide range of devices.

RTSP vs RTMP

Since both protocols are long-time workhorses of the video streaming world, let’s take a look at how RTSP and RTMP stack up next to one another.

RTMP or Real-Time Messaging Protocol is a technology that runs on top of Transmission Control Protocol (TCP) and was originally developed as a proprietary protocol for Macromedia-Adobe to be used for real-time streaming of audio, video, and data. RTMP’s best feature is the persistent TCP connection between video player and server which delivers a consistent and reliable stream to the viewer.

Notably, although it was originally designed for streaming delivery through Adobe Flash Player— as of 2021 Flash is sadly defunct. But like RTSP, today the protocol is not as widely used for actual viewer-facing stream delivery. When employed as part of a workflow, RTMP’s issues over requiring Flash Player technology are no longer a concern.

RTMP was similarly the product of a time (the 1990s) when streaming audio and video was difficult to do, and solutions had to overcome the very real limitations of hardware. It kickstarted the rise of internet streaming and took a dominant role as a veritable king of content delivery due to its reliability and efficiency.

Eventually, Adobe loosened its grip and released a version of the protocol for public use in 2012, but by that time the writing was on the wall: Flash was beginning to be considered a potential security risk and was also starting to be edged out as a delivery method by adaptive bitrate streaming and HTML5 players. A few years later in 2015, YouTube dumped Flash for HTML5, and RTMP was on its final leg as a last-mile technology.

As far as current use cases, RTMP is widely used as an ingestion protocol for modern live-streaming platforms, often to be converted to HLS (HTTP Live Streaming) and delivered to an HTML 5 video player that works for both browsers and mobile devices. RTMP’s main advantage in the first mile is that it allows users to take advantage of low-cost or open-source encoders for live streaming content.

As neither protocol remains in wide use for last-mile streaming transmission, it can’t be said that there’s a true rivalry between the two of them anymore. By now they share many similarities and are best looked at in terms of “the right tool for the right job.” RTMP and RTSP are both application-level protocols to control media streams, both are low-latency protocols able to deliver media on demand in real-time or nearly real-time through a stable connection.

Each protocol has pros and cons and there’s no right or wrong answer; whether or not you use one or the other depends on how to best serve the needs of your streaming operation and the demands of the platforms and hardware you’ll want to use.

RTSP was an open standard, developed by Adobe’s competitors at the time. Generally, RTSP was designed for communication and control between endpoints and is preferred in situations that call for a cheaper, simpler streaming alternative. It was in some ways better developed since it was used widely by engineers through the many years RTMP was walled off as a proprietary technology. However, due to the previous dominance of RTMP, it’s not as familiar to many broadcasters.

RTSP is a good choice for localized streams and is frequently built into IoT software for accessing video feed. RTSP is also the standard for most IP cameras, which makes it likely that some or all of the devices you’ll be relying on for stream input for conferencing or monitoring systems will use the protocol.

A Sample RTSP to RTMP Ingest Solution

As you now know, RTSP is still in widespread use with IP cameras, which are often employed for use in video conferencing, public streams/webcams, and security, monitoring, and CCTV systems. And they also just might be the input device you have at your disposal.

At Kaltura we’re aware of the obvious utility of IP-enabled cameras in your live broadcasts. Since you might find yourself in a situation where your best bet for an input device runs RTSP protocol but you need to ingest to a platform that prefers RTMP, our knowledge base provides at least one encoding workaround. Keep it in mind as a potential workflow!

Additionally, the procedure laid out in the linked article could potentially be applied to other protocols such as RTP, RTMP, MPEG-TS, and ICY. Here’s a quick breakdown on how to convert RTSP to RTMP for ingestion to ensure you can seamlessly use your IP camera devices (and all other things RTSP!) as input for a stream.

The method we’re suggesting uses an intermediary server to receive the data from an RTSP-configured device, and from there converts to an RTMP stream which will then be broadcast to your final, viewer-facing platform. As the data reaches your final delivery system, it can broadcast out to further formats more suitable for watching on contemporary devices, such as HLS Viewer, HDS Viewer, or MPEG-DASH Viewer. So keep in mind that IP cameras and other IoT devices aren’t a dead end limited solely to RTSP streaming. When using an RTSP device to capture your streaming content, there are options; if your distribution destination has restrictions on which protocol it accepts in a pinch you can still broadcast to an intermediary server, configure parameters, et Voila! …your viewer-facing destination is ingesting through RTMP.

If you need further guidance on our products and technical solutions for live streaming, we also have a range of detailed articles in our knowledge center covering an overview of live streaming with Kaltura, live encoding best practices, and the use of RTMP endpoints in streaming. Whatever your technical questions and requirements are, we aim to have you covered.