WebRTC vs. RTSP: Understanding the IoT Video Streaming Protocols
With video surveillance booming, WebRTC and RTSP meet diverse streaming needs in IoT. Let's discuss the basics and benefits of each protocol.
Join the DZone community and get the full member experience.Join For Free
At the moment, there is a constantly increasing number of smart video cameras collecting and streaming video throughout the world. Of course, many of those cameras are used for security.
In fact, the global video surveillance market is expected to reach $83 billion in the next five years. But there are lots of other use cases besides security, including remote work, online education, and digital entertainment.
Among the various technologies powering those use cases, Web Real-Time Communication (WebRTC) and Real-Time Streaming Protocol (RTSP) stand out as two top options. Here’s what you need to know about WebRTC vs. RTSP and their suitability for various streaming needs.
The Basics of WebRTC
Let’s start with WebRTC, which is a communication protocol that allows real-time streaming of audio and video directly in web browsers. Google developed WebRTC, but it’s now an open-source project with wide support and thorough documentation.
When you make a video call through a browser, WebRTC handles the transmission of your video and audio data to the person you’re calling, and vice versa. So, you don’t need to download specialized communication software like Skype; you can just chat through the browser with something like Google Meet.
WebRTC has a few features that set it apart. For one, the protocol adjusts the quality of the call based on your internet speed. So your video might get fuzzy if your internet speed is low, but you typically won’t have to worry about losing the connection. The protocol also encrypts data streams, both incoming and outgoing, which means video streams are private and secure. And lastly, it provides a data channel for also sending files or text chat, so it’s not just limited to video.
Perhaps the most important aspect of WebRTC is that it’s peer-to-peer (P2P), which means it doesn’t have to travel through a server. This enables higher performance and lower latency, or as “real-time” as possible on the Internet (traveling directly from A to B). P2P communication is like sending a letter to your friend who only lives two hours away. You could send your letter via a post office, but there’s always the risk of the letter getting delayed at various points.
If instead, you hand the letter directly to your friend, you can ensure your letter will arrive in just two hours, instead of in a couple of weeks. So P2P communication is more direct and generally faster than server-based communication.
How WebRTC Works
P2P communication via WebRTC involves a few technical steps. The first one is signaling. Think of WebRTC signaling as the process of arranging a meeting. Before two people meet, they need to exchange information like the meeting time, location, and agenda. Similarly, in WebRTC, signaling is the initial arrangement phase in which two devices exchange the necessary information to establish a real-time communication session.
The next step is media capture, which allows your browser to access your device’s camera and microphone to collect streaming data like video and audio.
Next is Network Address Translation (NAT) traversal. NAT is a method that routers use to translate private IP addresses within a local network to a single public IP address for internet access. It’s like a single mailing address used for all devices in a house. NAT traversal, on the other hand, is a technique that allows devices behind different NATs to establish direct peer-to-peer connections. This is akin to arranging a direct line of communication between two houses, each with its own unique mailing system, enabling them to bypass the standard mail route and connect directly.
Once the call goes through and the browsers establish a connection via NAT traversal, the next step is streaming the data. Throughout the call, WebRTC maintains a stable connection, and then at the end of the session, the protocol allows the peers to securely close out the connections — the equivalent of hanging up your phone at the end of a conversation.
When to Use WebRTC
One of the top benefits of WebRTC is that it works across multiple platforms and browsers. So if you use Chrome, for example, but your friend is using Edge, you can still stream video. It’s also easy to access. Unlike when you use Skype, for example, you don’t have to download a separate app. You can just open up a link right in your browser.
Some situations in which you might use WebRTC include the streaming of various events like concerts, sports events, interactive webinars, sharing sensitive files or data between browsers, streaming video footage from a smart camera to a browser, or real-time multiplayer gaming, among many others.
The Real-Time Streaming Protocol (RTSP) is not exactly a video streaming protocol like WebRTC. Instead, it’s a network control protocol. In other words, you use it to send video playback commands like play, pause, etc. just as you would use a handheld remote for a streaming device.
So, unlike WebRTC, RTSP is just for establishing and controlling the media stream rather than being the actual vehicle that delivers it. It starts a streaming session and then allows clients to remotely control the feed. For example, in a smart surveillance system, RTSP lets you start and stop the video feed from a security camera in real-time, so your commands almost instantly reach the device you’re trying to control.
RTSP is not a P2P protocol by nature, though it can be used in that context in certain cases. Generally, RTSP sends commands via a server that hosts and streams the media content, so the server is actually doing the most work, while RTSP merely sends commands. The server is not necessarily a cloud server; it can be a “logical” server (as in the client-server paradigm), so the RTSP server can run on an IP cam on a private network. RTSP is just used for controlling playback and the start or stop of a stream, not the actual delivery of the media.
So, for actual media streaming, you need to pair RTSP with other protocols. The most common is the Real-Time Transport Protocol (RTP). RTP is what streams and delivers audio and video data.
In addition to RTP, RTSP often pairs with the Transmission Control Protocol (TCP), which allows RTSP to transfer commands over the Internet. TCP focuses on reliability and retransmits any lost or corrupted packages, so it’s used in conjunction with RTSP in situations in which reliability is the most important. If the video streaming connection needs to be established through a firewall, a developer can also perform TCP tunneling to establish a p2p-based tunnel without firewall hassles.
How RTSP With TCP Works
Basically, RTSP requires some extra setup compared to WebRTC so the stream can get through firewalls. Developers can either configure the firewalls themselves to receive the RTSP streaming or use TCP tunneling to solve the problem.
TCP tunneling is a technique that allows a video system to bypass firewalls. The firewall does not see TCP traffic when doing TCP tunneling. Instead, a TCP tunneling service transfers UDP packets through the firewall; “translating” these packets to/from TCP at each end of the tunnel, i.e., the applications on each side (client and device/server).
So in many video scenarios, RTSP/TCP is the mode that makes the best sense, despite the performance hit of using a reliable transport.
When to Use RTSP
A lot of older surveillance camera designs have built-in RTSP servers in their software stack for native handling the camera video feed. If you are integrating such a camera into your system, you would normally use RTSP + TCP tunneling. On the other hand, if you have a newer camera software stack with the support of the WebRTC video protocols, you would probably use that. But it also depends on what your backend and middleware support. RTSP is useful for systems in which users want to control video playback from a remote location, for example, with home security or streaming from drones.
WebRTC started as being exclusively for browser-to-browser communication, so it initially wasn’t ideal for situations in which you want to, say, control a video camera from your smartphone or view the feed through an app. But now WebRTC is compatible with IoT and Android apps as well as IoT connectivity software. Meanwhile, RTSP and RTP don’t have the security features or low latency of WebRTC, but the protocols’ security can be enhanced when used with TCP tunneling.
As a result of all of its specialized features, WebRTC is mostly used in IoT situations for two-way communication, like telemedicine meetings, remote work, and other video conferencing scenarios, and now also for mobile-based video surveillance controls. By contrast, RTSP/RTP is primarily used in security cameras and broadcasting from one source to multiple devices.
The choice between WebRTC vs. RTSP is a complicated subject, and many different factors may affect which protocol you choose to use. But ultimately, both are important parts of the IoT ecosystem — particularly in video streaming.
Published at DZone with permission of Carsten Rhod Gregersen. See the original article here.
Opinions expressed by DZone contributors are their own.