Streaming 对多个拖缆和单个接收器使用RTP协议有意义吗？

我正在学习并尝试使用RTP/RTCP协议。我的情况是，有1到n个拖缆和1个（或可能是1到m个，如果需要）接收器，但拖缆本身并不了解彼此（由于技术原因，例如不同的网络、有限的带宽等，它们不能直接联系）。因此，它更像是多个单播会话，但接收者实际上了解所有会话，从所有会话收集数据，只是发送者彼此不了解

现在读到这个协议，在我看来，其中很大一部分与发送反馈、碰撞检测等有关所以我有疑问，RTP真的适用于这种情况吗？是否已在某处以这种方式使用？

在我看来，收集RTP提供的数据传输的统计数据（数据发送、丢失、时间等）仍然是有益的，只是觉得协议的大部分内容被忽略了

---

另外，我还有一个问题，通过各种RTP库，它们都假设发送方也会打开端口来接收RTP/RTCP数据，RTP是否禁止使用单向通信？我指的是只流式传输数据的应用程序，不希望接收任何回发数据。库（如ccRTP）似乎只假设双向通信…

RTCP是提供统计信息的协议。流接收方（客户端）将通过RTCP向发送方（服务器）发送统计数据。我不相信客户端会从服务器上得到任何统计报告

一个客户端从不同的服务器接收多个单播会话没有什么错

RTP在设置过程中需要双向通信。一旦安装完成并发送play cmd，这主要是一种方式。例外情况是“保持活动”数据包，必须定期（通常每60秒左右）发送到服务器以保持流继续。在安装过程中，会将确切的超时值发送到客户端

但是，如果您实现自己的RTP，没有什么可以阻止您让服务器在没有客户机反馈的情况下连续发送流。基本上，它将实现一个无限的超时值

您可以阅读规范中的所有详细信息：