问题标签 [rtcp]

我需要将文件从一个集中的源传输到数百台客户端计算机。我们目前使用UDPCast来做这类事情，但正在寻找更多基于标准的方法来解决问题。

我一直在阅读 RTP RFC (1889) 并注意到该协议主要是为多个客户端的流媒体（音频和/或视频）而开发的。我突然想到它也可以满足我对文件传输的需求。

当然，我需要能够确保我发送的文件的所有“块”都被每个客户端接收。

RTP 是否适合传输数据文件？可以使用 RTCP 来确保所有客户端都接收到所有发送的数据吗？

任何指导将不胜感激。

我正在使用基于 WinPCap 构建的 SharpPCap 来捕获 UDP 流量。我的最终目标是从 H.323 捕获音频数据并将这些电话对话保存为 WAV 文件。但首先是第一件事——我需要弄清楚我的 UDP 数据包通过 NIC 是什么。

SharpPCap 提供了一个 UdpPacket 类，让我可以访问消息的 PayloadData。但我不确定如何处理这些数据。这是一个 Byte[] 数组，我不知道如何确定它是 RTP 还是 RTCP 数据包。

我已经用谷歌搜索了这个主题，但那里没有太多内容。任何帮助表示赞赏。

是否有基于 Java NIO 或一些 Java NIO 框架（Netty、MINA、...）的 Java RTP/RTCP 库？

我已经捕获了三个不同的流作为带有元数据的 pcap 文件。如何流回 RTP/RTCP 流？

对于某些计算的流时间戳，我RTSP Source的 's RTCP SR不可靠，H.264经常导致大的负跳跃。

这是调试日志中的一个示例。看看它如何从 101006.6130 跳到 -4193861.6830 并继续下去。

所以，我的问题是：

如何使用Live555媒体库解决此问题？我应该忽略RTCP信息还是推荐的解决方案是什么，我该如何申请Live555？

不幸的是，我仍然坚持使用 RTP / RTCP 通信的一点实现来正确访问我的 IP 摄像机。

我想做什么

相机有一个我想读取的内部缓冲区。所以我通过 RTSP 与相机通信并告诉它流式传输数据。当相机穿过整个缓冲区时，流式传输将停止。

到目前为止我有什么

1. 一个 TCP 连接，它通过 RTSP 为DESCRIBE//请求 ( RTSP ) 进行通信以启动流SETUP。PLAY当相机传输其数据时，此连接必须保持打开状态。

2. 我接收通过 RTP（基于 UDP）发送的数据的端口 - 处理这不是我关心的问题，我什至完全无法访问它，我只是为了完整起见而提及它。

3. Sender Reports接收 RTCP /的 UDP 套接字Source Descriptions。这很重要，因为我不知道流何时停止（如第 2 点所述，我不能只看流何时停止）。在这个 Socket 上，我一直读到 RTCPSender Report Goodbye到来，这意味着流式传输已经完成。然后我可以关闭 TCP 套接字（来自 RTSP 通信）。

出了什么问题

它适用于像 2MB 或 4MB 这样的小缓冲区。我收到一些源描述，然后是Goodbye. 但在我的特定测试案例中，我想使用 16MB（这仍然不到相机容量的一半）。我收到了发件人报告，但在某些时候（总是在 8MB +/-300KB 左右）相机会停止发送。

值得注意的是，我可以毫无问题地通过 VLC 访问缓冲区。我什至查看了与我的应用程序中几乎完全相同的通信（ RTSP 和 RTCP ）......缺少的一件事我将在下面提到：

可能的原因

这是我需要你建议的部分。

可能性：缺乏接收方报告

当通过 VLC 进行流式传输时，我注意到有一些 RTCP Receiver Reports从 VLC 发送到相机（像循环一样Sender Reports）。那么，camere 是否期望在Receiver Report特定时间（或发送特定数量的字节后）至少有一个？目前我想不出任何其他原因。

解决方案？

• 如果我们假设相机停止流式传输是因为没有，Receiver Reports我想知道是否有一种方法可以在不携带太多信息的情况下实现它们。我已经阅读了一些RFC 3550并且我猜这些报告消息背后仍然存在一堆逻辑。现在我实际上不需要，所以我也不想在这里实现一个完整的 RTCP 协议。发送一些虚拟帧是否足以Receiver Report让相机继续流式传输？如果是这样，它们看起来如何？

• 如果它与缺少无关Receiver Reports并且我只是不需要它们，那么相机停止流式传输的原因可能是什么？有什么建议么？

编辑：

好的，我只是设法创建了某种 DummyReceiver Report并且它似乎可以工作（我只能收到 12MB 然后我得到了想要的再见）

我刚刚填充了一个 28Byte 的缓冲区，并在 Header 字段中使用了一些值，这意味着：

我刚刚用零填充缓冲区的其余部分。是的，我知道这只是一个 hack，你不应该告诉你的孩子这样编程。

现在我的问题发生了一点变化：这个黑客可以吗？它似乎有效，但我仍然有点担心我的相机会使用那些虚拟数据并更改配置，因为它会在其中插入一些奇怪的东西？

我尝试在 Google nexus S (2.3.7)、HTC Desire (2.3.3) 和三星 Galaxy (3.2) 上进行流式传输。只有 Google Nexus 有 RTSP 会话超时问题。

我阅读了一些关于这个问题的线程。似乎我必须每秒发送一次 RTCP 请求以保持会话处于活动状态，或者我将只发送 RTSP“OPTION”请求，该请求基本上什么都不做，只是为我的应用程序保持活动状态。谁能让我先了解如何生成该请求？我以前没有处理 RTCP 的经验。

根据 RFC4585，AVPF 配置文件允许设备比常规 RTCP 数据包的通常传输更早地发送反馈。但是，根据带宽、用户数量和常规 RTCP 数据包的周期性，会话的参与者可能无法使用早期反馈。

这个阈值是如何计算的？这没有提供（最好有它，至少对于点对点的情况）。

根据 RFC4585：

如果 R 的 FB 消息没有按照 5 被其他接收方 FB 消息抑制，则当达到 te 时，R 必须发送包含其 FB 消息的（最小）复合 RTCP 数据包。然后 R 必须设置 allow_early = FALSE，必须重新计算 tn = tp + 2*T_rr，并且必须将 tp 设置为前一个 tn。一旦达到新计算的 tn，无论 R 是发送其下一个常规 RTCP 数据包还是因为 T_rr_interval 抑制它，它必须再次设置 allow_early = TRUE。

假设在时间 t1'
t1---t1'------t2------------t3传输了一个早期的 RTCP 数据包
，并且 t1, t2, t3 是常规时间将发送 RTCP 数据包。RFC 建议如果在时间 t1' 发送数据包，则在时间 t2 的 RTCP 数据包将被丢弃，并且在 t3 之前不允许反馈消息。
然而，后来在同一个 RFC 中，据说

必须定期发送完整的复合 RTCP 数据包。这些
数据包也可以包含一个或多个 FB 消息。常规 RTCP 数据包的传输
安排如下：

如果 T_rr_interval == 0，则传输必须遵循本文档第 3.2 节和第 3.4 节中指定的规则，并且必须遵守第 3.5.2 节中指定的 tn 调整（即，如果早期 RTCP 数据包传输，则跳过一次常规传输已经发生了）。当按照 [1] 达到 tn 时，将重新考虑计时器。Regular RTCP 数据包在定时器重新考虑后传输。每当发送或
抑制常规 RTCP 数据包时，allow_early 必须设置为 TRUE，并且 tp, tn 必须
按照 [1] 进行更新。在第一次传输常规 RTCP
数据包后，Tmin 必须设置为 0。

这似乎是矛盾的，因为该段是说当一个RTCP数据包被抑制时，allow_early必须设置为TRUE，所以似乎allow_early应该在时间t2设置为TRUE。

我希望能够拦截该流的数据包并从 C++ 代码访问数据。如何在 C++ 代码中执行此操作？RTP-媒体流使用此服务器进行流式传输：link

然后我将对数据包进行 FEC 编码；通过网络发送它们；在接收端对它们进行 FEC 解码，并将数据流传递给 RTCP 客户端。