将RTP协议用于多个流媒体和单个接收器是否有意义?

时间:2018-05-20 08:16:18

标签: streaming rtp rtcp

我正在学习并尝试使用RTP / RTCP协议。我的情况是有1到3个拖缆和1个(或者可能是1到m,如果需要的话)接收器,但是在某种程度上,拖缆本身彼此不了解(由于技术原因它们不能直接,例如作为不同的网络,有限的带宽等...)。所以它更像是多个单播会话,但接收者实际上知道所有这些,从所有这些中收集数据,这只是发件人彼此不了解。

现在阅读协议,在我看来,它的很大一部分与发送一些反馈,碰撞检测等有关。 所以我有疑问,RTP真的适用于这种情况吗?是否已经以某种方式使用过这种方式?

对我来说,收集RTP提供的数据传输统计数据(数据发送,丢失,时间等等)仍然是有益的,它只是感觉大部分协议都被排除在外...... < / p>

另外我还有一个问题,通过各种RTP库,它们都假设发送方也会打开接收RTP / RTCP数据的端口, RTP是否禁止使用单向通信? I意味着应用程序只会传输数据,而不是期望收到任何回复。库(例如ccRTP)似乎只假设双向通信......

1 个答案:

答案 0 :(得分:0)

RTCP是提供统计信息的协议。流接收器(客户端)将通过RTCP将统计信息发送给发送方(服务器)。我不相信客户端会从服务器获取任何统计报告。

单个客户端从各种服务器接收多个单播会话没有任何问题。

RTP在设置过程中需要双向通信。一旦设置完成并且发送了播放cmd,它主要是单向的。必须定期(通常每60秒左右)发送到服务器的“保持活动”数据包例外,以保持流的运行。在设置过程中,确切的超时值将发送到客户端。

但是如果你实现自己的RTP,没有什么能阻止你让服务器连续发送流而没有来自客户端的任何反馈。基本上它将实现无限超时值。

您可以阅读规范中的所有详细信息:RTP: A Transport Protocol for Real-Time Applications