关于RTSP 与 WebRTC 在移动应用程序应选用哪一种协议作为基础，需要看具体情况来分析。以下内容来自 Red5 团队的分享，可作为技术选型的参考。
全文如下：
在设计 Red5 Pro 移动 SDK 的架构时，我们需要在早期做出一些关键选择。其中最大的一个问题就是我们应该以什么协议为基础。经过初步研究和实验，我们决定采用 RTSP。
但我们为什么选择 RTSP 而不是 WebRTC 呢？选择的真正原因在于协议的稳定性和快速连接时间。
选择 RTSP
我们刚开始实施移动 SDK 时是在 2014 年。当时，WebRTC 仍是一个不断变化的目标，它尚未成为最终规范（2017 年 9 月才）。另一方面，RTSP 已经存在多年，有许多稳定的实现可供参考。此外，RTSP 和 WebRTC 共享相同的底层传输技术。
我们决定不在移动 SDK 中使用 WebRTC 的另一个主要原因是，由于需要进行信令和 ICE 协商，连接时间可能会很长（几秒钟）。在媒体连接开始和视频开始流动之前，WebRTC 实际上需要多个步骤。
相反，RTSP 只需要几分之一秒的时间来协商连接，因为它的握手实际上是在第一次连接时完成的。我们看到了太多依赖快速连接时间的使用案例，正因为如此，这是促使我们使用 RTSP 的主要因素。
性能如何？
WebRTC 经常被吹捧为专为低延迟而设计。当然，WebRTC 和 RTSP 都采用了相同的视频和音频流底层传输协议： RTP（或加密后的 SRTP）。由于这种相似性，它们都能提供延迟极低的流媒体。
我们的移动 SDK 在延迟方面的表现与 WebRTC 非常相似，但在服务器端，RTSP 的实现更为简单。RTSP 更轻便一些，因此我们可以在每个服务器实例中容纳更多的流，因为我们没有 WebSockets 信令和 ICE 协商带来的那么多开销。
这样，线程模型就大大简化了，所以总体而言，RTSP 的代码优化程度更高，这主要是因为该协议更易于实现。
与笔记本电脑相比，手机的处理能力通常较弱，因此发送和接收流越简单越好。
何时使用 WebRTC
我们只有在使用浏览器客户端时才会真正关心和使用 WebRTC。浏览器支持的唯一低延迟协议就是 WebRTC。由于我们必须遵守浏览器的规定，因此别无选择。
另外，在编写移动 SDK 时，我们有更大的灵活性，因此选择了 RTSP，因为它既简单又高性能。
参考：https://www.red5.net/blog/rtsp-vs-webrtc-which-to-use-for-a-mobile-app/
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/47377.html
