3

我正在做RFC 3550 (RTP)的 Java 实现，但遇到了一个小问题：

在第 11 章第 2 段中，它指出：

(...) 参与者不得假设传入 RTP 或 RTCP 数据包的源端口可用作传出 RTP 或 RTCP 数据包的目标端口。当双向发送 RTP 数据包时，每个参与者的 RTCP SR 数据包必须发送到另一个参与者为接收 RTCP 指定的端口。(...)

RTP 没有任何机制来通知这些地址和端口（这取决于 SDP 或其他一些设置协议），这将使我将这一段理解为“如果您从未知来源接收数据，则丢弃它” .

但在第 6.3.3 节中，它基本上说，当接收到带有未知 SSRC 的 RTP 或非 BYE RTCP 数据包时，应将新参与者添加到表中。

所以总结一下：

  1. 当收到未知的 SSRC 时，您应该添加一个新的参与者；
  2. 您不能将数据包的源 IP/端口用作该参与者的数据包目标；
  3. SDP 没有定义每个 RTP 参与者将使用的 SSRC；
  4. 您可以手动添加 RTP 参与者（以其他方式发现）但您不知道 SSRC 将是什么。

所以百万美元的问题是：应该如何处理意外的 SSRC？

4

2 回答 2

2
  1. 当收到未知的 SSRC 时，您应该添加一个新参与者 --> 仅在按照第 6.2.1 节验证它之后
  2. 您不能将数据包的源 IP/端口用作该参与者的数据包的目的地 --> 这就是说您不能期望端点 A 的 RTP/RTCP 对与端点 B 的对相同（除非指定）。（在第 11 节 RFC 中没有讨论 IP 地址。）
  3. SDP 没有定义每个 RTP 参与者将使用的 SSRC --> 是的，因为 SSRC 可以即时更改。
  4. 您可以手动添加 RTP 参与者（以其他方式发现）但您不知道 SSRC 将是什么。？？？

所以百万美元的问题仍然值一百万美元。将研究和更新你。同时，如果您找到答案，也请更新我们。

于 2010-09-15T10:04:31.160 回答
0

根据我对 RFC 的解释，对您的问题的答复在第 6.3.3 节：

6.3.3 接收 RTP 或非 BYE RTCP 数据包

当收到来自其 SSRC 不在成员表中的参与者的 RTP 或 RTCP 数据包时，SSRC 将被添加到表中，并且一旦参与者按照第 6.2.1 节所述进行验证，成员的值就会更新。

关于哪个条目应该被认为是有效的：

(...) 新条目可能被认为是无效的，直到接收到多个携带新 SSRC 的数据包（参见附录 A.1），或者直到接收到包含该 SSRC 的 CNAME 的 SDES RTCP 数据包。（... )

我可能会遗漏一些东西吗？;)

于 2010-09-14T08:23:58.087 回答