RTSP vs. WebRTC: Which to use for a Mobile App

When we were designing the architecture for the Red5 Pro Mobile 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.

But why did we choose RTSP and not WebRTC? The choice really came down to the stability of the protocol 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. Plus, RTSP and WebRTC shared the same underlying transport technology.

The other major reason we decided against WebRTC for our mobile SDK 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.

What About Performance?

WebRTC is often touted as being designed for low latency. While that is certainly true, both WebRTC and RTSP employ the same underlying transport protocol for video and audio streaming: RTP (or SRTP when encrypted). Due to this similarity, they both provide very low latency streaming.

Our mobile SDK performs quite similarly to WebRTC in terms of latency, but on the server side, RTSP is simpler to implement. RTSP is a little lighter so that allows us to fit more streams per server instance because we don’t have as much overhead from WebSockets signaling and ICE negotiations.

Thus, the threading model is vastly simplified so overall the code is more optimized with RTSP due largely to the fact that the protocol is simpler to implement.

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

We only really care about and use WebRTC when we are dealing with 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.

Check out the Mobile SDK for yourself and send any questions over to info@red5.net or let us show you a demo.