RTSP: The Real-Time Streaming Protocol Explained (Update)

   

The Real-Time Streaming Protocol (RTSP) is a tried-and-true video technology. It’s used to control audio/video transmission between two endpoints and facilitate the transportation of low-latency streaming content across the internet.

Along with the Real-Time Messaging Protocol (RTMP), RTSP once dominated the streaming landscape. That’s no longer the case today. Yet, RTSP remains standard in many surveillance and closed-circuit television (CCTV) architectures. The reason for this is simple: it’s still the protocol of choice for IP cameras.

In this article, we’ll look at the RTSP specification, the history behind RTSP streaming, and typical workflows using this protocol.

 

Table of Contents

 

• What Is a Protocol?
• What Is RTSP?
• RTSP Snapshot
• RTSP Requests
• History of RTSP Streaming
• RTSP vs. Other Streaming Formats
• IP Camera Streaming
• Typical RTSP Workflow
• Using Wowza as Your RTSP Server

 

What Is a Protocol?

Protocols provide a set of rules governing how data travels from one communicating system to another. For instance, the Hypertext Transfer Protocol (HTTP) defines how webpage data and hypertext links are transmitted across the World Wide Web by governing communications between web servers and browsers.

By extension, streaming protocols handle the delivery of live and on-demand streaming content. RTSP is a foundational technology making up the streaming protocol suite. It was designed to establish and maintain sessions between a source and the streaming server.

   

What Is RTSP?

RTSP is an application-layer protocol used for commanding streaming media servers via pause and play capabilities. It thereby facilitates real-time control of the streaming media by communicating with the server — without actually transmitting the data itself. Rather, RTSP servers often leverage the Real-Time Transport Protocol (RTP) in conjunction with the Real-Time Control Protocol (RTCP) to move the actual streaming data.  

The official definition from a 1998 proposal of the standard states:

“The Real-Time Streaming Protocol (RTSP) establishes and controls either a single or several time-synchronized streams of continuous media such as audio and video. It does not typically deliver the continuous streams itself, although interleaving of the continuous media stream with the control stream is possible. In other words, RTSP acts as a ‘network remote control’ for multimedia servers.”

When a user initiates a video stream from an IP camera using RTSP, the device sends an RTSP request to the streaming server. This jumpstarts the setup process. Subsequently, the video and audio data can then be transmitted using RTP. You can thus think of RTSP as a television remote control for media streaming, with RTP acting as the broadcast itself.

 

RTSP: A Snapshot

• Audio Codecs: AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis
• Video Codecs: H.265 (preview), H.264, VP9, VP8
• Playback Compatibility: Not widely supported and rarely used for playback (Quicktime Player and other RTSP/RTP-compliant players, VideoLAN VLC media player, 3Gpp-compatible mobile devices)
• Benefits: Low-latency and ubiquitous in IP cameras
• Drawbacks: Not optimized for quality of experience and scalability
• Latency: 2 seconds
• Variant Formats: RTSP as an umbrella term describes the entire stack of RTP, RTCP (Real-Time Control Protocol), RTSPS (RTSP over SSL / Secure RTSP), and good-old RTSP

 

RTSP Requests

RTSP uses the following commands, typically sent from the client to the server, when negotiating and controlling media transmissions:

• Options: This request determines what other types of requests the media server will accept.
• Describe: A describe request identifies the URL and type of data.
• Announce: The announce method describes the presentation when sent from the client to the server and updates the description when sent from server to client.
• Setup: Setup requests specify how a media stream must be transported before a play request is sent.
• Play: A play request starts the media transmission by telling the server to start sending the data.
• Pause: Pause requests temporarily halt the stream delivery.
• Record: A record request initiates a media recording.
• Teardown: This request terminates the session entirely and stops all media streams.
• Redirect: Redirect requests inform the client that it must connect to another server by providing a new URL for the client to issue requests to.

Other types of RTSP requests include ‘get parameter,’ ‘set parameter,’ and ’embedded (interleaved) binary data,’ which are detailed here.

 

History of RTSP Streaming

First developed by Netscape Communications, Progressive Networks (now RealNetworks), and Columbia University, the RTSP specification was published by the Internet Engineering Task Force in 1998. Version 2.0, published in 2016, amended the early version in an effort to shorten round-trip communication with the media server.

Before the emergence of adaptive bitrate streaming via HTTP-based protocols, both RTSP and RTMP powered most streams on the internet. But because both require dedicated servers, they didn’t lend well to large-scale broadcasts.

As such, RTSP is now used primarily as a contribution protocol. Most workflows leverage a media server to ingest streams transmitted via RTSP/RTP and then repackage the file for delivery to viewing devices — ranging from iPhones to smart TVs.

Next-generation alternatives like Secure Reliable Transport (SRT) are competing directly with RTSP for video contribution today. Even so, RTSP remains popular in surveillance workflows as the de facto standard for IP cameras.

   

RTSP vs. Alternative Ingest Formats

If you’re looking to swap out RTSP for a proven alternative, RTMP is the most popular protocol used for first-mile contribution today. In fact, a whopping 76.6% of respondents to our 2021 Video Streaming Latency Report indicated that they use RTMP for ingest.

As shown below, Web Real-Time Communications (WebRTC) and SRT are also popular formats, with only 18.6% of content distributors today relying on RTSP.  

 

Which streaming formats are you currently using for ingest?

 

Here’s a look at how the three options compare.

RTMP

RTMP is RTSP’s oldest rival, and it’s a better choice if streaming directly to a social media platform. Both protocols are used for contribution, but more encoders and live streaming services accept RTMP.

Facebook, Twitch, and YouTube — for instance — only accept RTMP for low-latency live streaming. That means you’ll either want to encode your stream as RTMP from the get-go, or repackage any RTSP streams as RTMP using a video platform like Wowza. The latter option would also enable simulcasting to multiple destinations at once, making it a good route for those looking to live stream from an IP camera to social media.

 

SRT

As an open-source technology optimized for unpredictable networks, SRT promises to displace RTSP and RTMP once widely supported. Encoders and media servers are still adding support for SRT, and streaming services like Facebook could very well follow.

In a recent Wowza LinkedIn poll, SRT generated the most interest for first-mile contributions. The protocol is also optimized for unpredictable public networks — combining speed and reliability into a single solution.

 

WebRTC

WebRTC is the speediest technology available right now, delivering near-instantaneous voice and video to and from any major browser. It’s also the only answer if simplicity is key. Unlike RTMP, RTSP, and SRT, WebRTC can be streamed from end to end, without additional processing.

WebRTC used to be restricted to small-scale streaming and browser-based publishing, but that’s all changing. A technology called the WebRTC HTTP Ingest Protocol (WHIP) provides encoding software and hardware with a standard signaling protocol when talking to media servers, thus removing WebRTC connectivity barriers between encoders and media servers. And Wowza’s  Real-Time Streaming at Scale feature for Wowza Video supports WHIP, as well as streaming to a million viewers.

 

IP Camera Streaming

As emphasized above, the RTSP protocol and IP cameras are a match made in heaven. Often, a media server pulls the RTSP signal from an IP camera.

These user-friendly streaming devices don’t require a separate encoder and are often used in surveillance, conferencing, and live event production. You will want to transmux the source stream for playback on websites and mobile apps.

One proven workflow for real-time surveillance is ingesting an RTSP-encoded IP camera stream and repacking it into WebRTC with sub-second latency. For a step-by-step look at setting this up, check out our tutorial.

 

Typical RTSP Workflow

RTSP is a stateful protocol used more often for video contribution (ingest) than for last-mile delivery and playback (egress). Android and iOS devices don’t have RTSP-compatible players out of the box, for which reason RTSP is rarely used for streaming from end to end. Instead, most broadcasters leverage a streaming server like Wowza to repackage the RTSP stream into a more user-friendly format like HLS.

 

Using Wowza as Your RTSP Server

Despite its age, RTSP has staying power as an ingest format. But — to drive it home once more — you’ll need a video repackaging solution to deliver the stream to end-user devices.

RTSP servers allow you to convert live RTSP streams into another format for playback. A media server software or service can be used to achieve this and more. For instance, you may want to repackage your RTSP stream into HLS for large-scale delivery, or perhaps you want to use WebRTC to maintain sub-second delivery.

No matter what type of streaming architecture you’re trying to build, Wowza makes it happen. Our full-service platform can power any workflow — with reliability to boot. Try a free trial to get started today.