What is RTSP and why is it necessary? RTSP protocol explained
Robotic couriers, drones, unmanned cars, and other achievements of modern science and technology no longer seem like something out of a fantasy world. They have become a common phenomenon (or almost) for us. Built-in IP cameras allow them to “see” what is happening and we can see the world through their “eyes”. But what if we told you that the vision (IP cameras) of these high-tech creatures is based on technology that is over 20 years old?
Can you believe it? Sit back and prepare to be amazed.
In this article, we tell you how technology from the 90s is still used successfully today, why there is nothing better, and why you should know more about it.
Spoiler alert: this veteran’s name is RTSP.
In this text, we will talk about RTSP, RTP, RTCP, how they exist in today’s IP cameras that support HEVC (H.265), with computer vision and analytics technology, and how they have survived to this day. So what’s so good and successful about RTSP and why isn’t it used on TV?
Table of contents:
What is RTSP and why is it necessary?
RTSP (Real-Time Streaming Protocol) is an application layer protocol designed for telecommunications and entertainment systems to control the delivery of multimedia data. RTSP is a signaling protocol, it controls the data transmission session.
RTSP was originally intended to be used to deliver entertainment television. And it really was for the moment. Then an evil fate decided otherwise: RTSP was erased from television and can now only be found on IP cameras.
The principles established in RTSP can be observed in the modern WebRTC standard.
RTSP can be compared to a TV remote control. It can be used to start, pause, stop, etc. the video on the TV, the media server. The control is not via infrared but via the Internet. Humanity has not yet learned to transmit the content itself through the TV remote control (even if it is our years), but it is more than enough to control it.
Wait, so RTSP only manages the content, but how does the content itself get streamed?
In the transport layer, RTP (Real-Time Protocol) is used to transmit the stream in real-time. The RTSP function is equivalent to the remote control of a streaming media server. IP cameras can use both TCP and UDP to transmit streaming content. However, it should be noted that UDP does not make any practical sense for this task.
Why not UDP?
Due to the lack of modern loss compensation mechanisms. So the data is simply lost somewhere along the way. In our practice, we stick to TCP, where data and data management coexists in a symbiotic flow. It should be noted that everything works fine.
We have the concept, we also have the purpose in a general sense. But what about practice?
Let’s take an example: suppose you have installed video surveillance on your property and you are afraid that your VCR and all the data on it will be stolen, and it will never be possible to see the faces of the thieves. What to do in this case? Put it in a safe? You can set up a video recording directly in the cloud. Using the RTSP protocol, you can send the information to a remote cloud service. Also, if you want to remotely view the file from the DVR, communication with it will also be via RTSP, but only if the device supports the RTSP protocol.
RTSP is no longer used for web streaming as such, it has been overshadowed and replaced by younger representatives of streaming technology: HLS and DASH, leaving us not even a chance to resist and fight change.
Never Miss RTSP and Other Protocol Updates!
Subscribe to receive the latest industry news.
The relationship between RTSP and HTTP RTP (RTCP)
Similarities:
- Both use plain text to send messages, and the RTSP protocol syntax is similar to HTTP.
- RTSP was originally designed to be compatible with previously written HTTP protocol parsing code.
Differences:
-
RTSP save state. RTSP commands need to know what state they are currently in. In other words, RTSP commands are always sent in order, with each next command coming after the previous one. RTSP will not drop the connection, no matter what state it is in. HTTP, on the other hand, does not save the state. After how the protocol sends a command, the connection is broken and there is no dependency between the commands.
-
RTSP uses port 554, while HTTP uses port 80.
-
Compared to RTSP, HTTP requests are sent by the client and the server responds. With RTSP, both the client and the server can send requests, which means that RTSP can be bidirectional.
Relationship between RTSP, RTP, RTCP and SDP
Let’s consolidate how RTSP, RTP, RTCP and SDP are related:
- RTP (Real Time Protocol).
A real-time streaming protocol. RTP provides timestamps, serial numbers, and other methods to ensure processing time during real-time data transmissions.
- RTCP (Real-Time Transport Control Protocol)
A protocol to ensure the quality of service and control of participants. RTP and RTCP are used together.
- RTSP (Real-Time Streaming Protocol).
A protocol for controlling the delivery of data.
- SDP (Session Description Protocol).
A protocol for describing a streaming data session.
The basic methods of the RTSP protocol. SIP and RTSP
Here we would also like to mention SIP (Session Initiation Protocol) to highlight the characteristics of RTSP and contrast it with SIP.
SIP (Session Initiation Protocol) is similar to RTSP visually, but its logic is very different. For example, RTSP is often characterized by a single TCP session, while SIP is an anti-pattern.
Let’s do a comparison based on SDP. RTSP (today SDP) is used exclusively to describe the content. In SIP, as well as in WebRTC (which is an extension of SIP), SDP is used to configure ports and network communication.
The main RTSP methods are listed below:
| Methods |
Description |
| DESCRIBE |
Request a content description, e.g. in SDP format |
| OPTIONS |
Request supported methods |
| PLAY |
Request to start broadcasting content |
| PAUSE |
Requesting a temporary stopĸ and broadcasting |
| RECORD |
Request to write content to the server |
| REDIRECT |
Request to redirect to other content |
| SETUP |
Requesting a transport mechanism for the content |
| ANNOUNCE |
Request to update content description data |
| TEARDOWN |
Request to stop the flow and release resources |
RTSP What was/is?
Let’s start with a bit of history.
RTP together with RTCP was developed in 1996 and set in the standard RFC 1889. SDP was released in April 1998 in RFC 2327. RTSP was also developed in April 1998 by the Internet Engineering Task Force (IETF) and is reflected in the standard RFC 2326. It became very popular right away because it allowed you to play video and audio directly over the Internet without having to download content to a client device. People were delighted with the amount of time and resources it could save!
RTSP comes from networks where delivery delays and losses are small and stable, i.e. local area networks. It’s also where many other solutions come from.
RTSP was conceived and developed when the task of controlling delivery to the client was to be entrusted to the server. Thus, the server took care of all the logic: what, when and to whom to send. We can say that the server had to be as complex as possible and the client as simple and uncomplicated as possible. When we switched to the HLS and DASH protocols, the situation was just the opposite. The client was now more ornate and the server more primitive.
But it turned out that the functions of intelligent control over the delivery of the RTSP server have not survived to this day and have fallen into oblivion.
Today’s RTSP servers are mostly IP cameras unaware of all the RTSP capabilities that were conceived decades ago. This means that it doesn’t really matter if there are customer comments. If the client gets the data, great, if not, well, that happens, there are problems.
Note that RTSP was created along with telephony. It was based on very successful solutions that already existed on the market, but we have changed them a bit: RTP for data delivery, RTCP for signalling quality of data delivery (QoS), and SDP for content information transfer. To give you an idea of the success of these solutions, the same RTP and RTCP developed some 25 years ago are now used in the same way in the WeRTC standard, which is the de facto standard for real-time communication. So even back then, they had everything they needed to stay afloat until now!
At one time, RTSP was the leader among streaming video and audio technologies. But over time, HTTP-based technologies using an adaptive bitrate algorithm eclipsed RTSP and RTMP. Despite this, RTSP is still actively used in video surveillance today to capture the feed from IP cameras.
It is important to note that RTSP for IP cameras and for television are two completely different protocols. The same RTSP for television can only be found on legacy systems that are still working.
Since we started talking about RTSP, we must mention RTMP.
RTSP vs RTMP
RTMP (Real-Time Messaging Protocol) was created as a protocol for transferring functions, remote code management, a kind of RPC protocol, as was CORBA before or now gRPC. RTMP was quite complex in its own right. In fact, as rude as it sounds, RTMP is alive only because CDNs started supporting it in time. Today, almost any CDN gives you the ability to stream video via RTMP, but not play it. Today RTMP is only a publishing protocol, but not a playback protocol because it has no advantages over current HLS, CMAF, etc.
In the old days, IP cameras basically lived on the MPEG-4 Part 2 codec and TV had all the benefits of MPEG-2. And then they all moved on to MPEG-4 Part 10, also known as H.264 or AVC. That’s right, there’s no need to sit still, it’s time to evolve.
Ok, the codecs have been changed, but what about RTSP and RTMP? What do they hold?
Well, there is no way around it.
Do you remember that RTSP was made from already successful solutions: RTP, RTCP, SDP? Well, IP cameras, thanks to the flexibility of SDP, have seamlessly migrated to H.264. In the same way, IP cameras moved to H.265 or HEVC.
RTMP, on the other hand, has not been able to make similar transitions as easily. Why, because RTMP does not have that superpower of being able to add new codecs, that is, to expand.
As the saying goes, survival of the fittest.
Flussonic and RTSP
IT products, which were written in a hurry and not in the best way, the transition from UDP to TCP was difficult. They failed to qualitatively master the asynchronous programming model. In practice, it is expressed in the translation of the TCP-socket to ’non-blocking’ mode, in which data can be lost, that is, the software’s attempts to write data to the socket appear to be in vain because the socket is blocked. locked. As a result, the operating system itself does not accept the data. It turns out that the camera software simply “throws away” the data, and as a result, we have a mess.
Is there any way to solve this problem?
Sure, like connecting the IP camera directly to the server with a cable. Despite the fact that this is an official way to install cameras (they were not actually designed to transmit data over the Internet), in today’s reality it seems like a ridiculous and frivolous solution.
In Flussonic there are modes to restore synchronization. For example, if the Chinese camera loses synchronization and data, in Flussonic there are special mechanisms to recover lost bytes of information, which allows the data stream to be resurrected. How cool is that?
What do you need to start getting video from the IP camera in Flussonic?
First, the IP address of the camera. Second, just the IP address of the camera is not enough to get video from it. You always need to specify another path. This is not always provided in the documentation, so you may need to contact your camera vendor or manufacturer.
What RTSP links look like:
- rtsp://hostname/path - syntax;
- rtsp://user:password@ip/path - authorization URL;
- rtsp2://hostname/path - enables audio transcoding in AAC.
- rtsp://192.168.0.100/h264 - example of a real link.
In Flussonic, among other things, you can use the tracks=1 option to capture only the video track. The following is an example of the configuration:
stream fake {
input fake://fake;
}
stream input_rtsp {
input rtsp://localhost/fake tracks=1;
}
Flussonic Media Server allows you to receive streams via RTSP and many other other protocols.
You can find how to add an IP camera to Flussonic and send video to the website in the [documentation].
You can also read about these and many other Flussonic features in the documentation section of our website.