When we were designing the architecture for the Red5 Pro Mobile video streaming SDK, we had some critical early choices we needed to make. One of the biggest was what protocol we should base it on. After some initial research and experimenting, we decided on RTSP (Real Time Streaming Protocol). But why did we choose… Continue reading RTSP vs. WebRTC: Which to use for a Mobile App
When we were designing the architecture for the Red5 Pro Mobile video streaming SDK, we had some critical early choices we needed to make. One of the biggest was what protocol we should base it on. After some initial research and experimenting, we decided on RTSP (Real Time Streaming Protocol).
But why did we choose RTSP and not WebRTC (Web Real Time Communication)? The choice really came down to the stability of the protocol at the time and fast connection times.
Selecting RTSP
When we first started our mobile SDK implementation it was in 2014. WebRTC was still a moving target at that time, and it hadn’t yet made it to a final specification (this only happened in Sep 2017). On the other hand, RTSP had been around for years, and there were many stable implementations to reference. For example, RTSP streaming has long been used for security cameras, video surveillance applications, a wide variety of other video feed use cases. Plus, RTSP and WebRTC shared the same underlying low latency transport technology.
The other major reason we decided against WebRTC for our mobile SDK streaming protocol is that connection times can be high (a few seconds) due to the need for signaling and ICE negotiation. WebRTC actually uses multiple steps before the media connection starts and video can begin to flow.
Conversely, RTSP takes just a fraction of a second to negotiate a connection because its handshake is actually done upon the first connection. We saw too many use cases that relied on fast connection times, and because of this, it was the major factor that pushed us to use RTSP. Slow connection times with WebRTC is less relevant today with WHIP and WHEP becoming a more efficient standard for negotiating the media connections allowing to connect to low latency streaming to happen very quickly.
We also looked at other protocols including RTMP for real-time communication, but it had too many limitations including having limited codec support and being stuck with TCP (Transmission Control Protocol) only. We eventually settled on RTSP as our preferred choice.
What About Performance?
WebRTC is often touted as being designed as a low latency video streaming protocol. While that is certainly true, both WebRTC and RTSP employ the same underlying transport protocol for video and audio data streaming: RTP (or SRTP when encrypted). Due to this similarity, they both provide very low latency streaming. Video streams over both protocols can be encrypted using SRTP as well, and both employ critical packet retransmission over UDP such as NACK.
Our mobile SDK performs quite similarly to WebRTC in terms of low latency, but on the server side, RTSP is simpler to implement. RTSP is a little lighter so that allows us to fit more RTSP connections per streaming server instance because we don’t have as much overhead from WHEP/WHIP/WebSocket signaling and ICE negotiations.
Thus, the threading model is vastly simplified so overall our video streaming code is more optimized with RTSP due largely to the fact that the protocol is simpler to implement.
This simplicity and performance gains carries over to the client side as well. When compared to a laptop, mobile phones usually have less processing power, so the easier it is to send and receive streams the better.
When to Use WebRTC
When we first wrote the Red5 Pro Mobile SDK, we only really cared about and used WebRTC when we are dealing with real-time communication in a browser client. The only low latency protocol that browsers support is WebRTC. Since we had to adhere to what the browsers give us, we had no other choice.
Alternatively, when writing the mobile SDK we had a lot more flexibility and thus chose RTSP for its simplicity and performance.
That all said, WebRTC has come along way, and we’ve seen hardware encoders begin to support WebRTC streaming using WHIP as an ingest protocol, including popular software implementations like OBS. Because WebRTC continues to improve and support more and more endpoints, we’ve begun adding WebRTC as an option in our low latency video streaming SDKs.
Check out the Mobile SDK combined with the Red5 Pro streaming platform for yourself and send any questions over to info@red5.net or let us show you a demo.