RTP：单播会话中的 SSRC 冲突检测答案

【问题标题】：RTP: SSRC collision detection in unicast sessionsRTP：单播会话中的 SSRC 冲突检测
【发布时间】：2014-01-25 09:38:16
【问题描述】：

来自RFC 3550：

如果接收者发现另外两个源发生冲突，它可能会保留数据包并丢弃当这可以被不同的检测到时，来自另一个的数据包源传输地址或 CNAME。 预计这两个来源解决碰撞，以免这种情况持续下去。

在具有一个接收器和两个仅与接收器通信的发送器的单播配置中，发送器如何检测 SSRC 冲突？

一种猜测是接收者应该定期将所有已知的 CNAME 发送给所有已知的参与者（发送者）。这是真的吗？但在这种情况下，发件人如何将收到的 CNAME 与传输地址相关联？

更新：

如下所述，有两个单独的 RTP 会话具有单独的 SSRC 空间，因此不需要冲突检测。

RTP 会话的显着特点是每个维护一个完整的、独立的 SSRC 标识符空间

还有：

一个 RTP 会话中包含的一组参与者由可以接收传输的 SSRC 标识符的那些组成由 RTP 中的任何一位参与者作为 SSRC 或 CSRC （也在下面定义）或在 RTCP 中。

对于我所描述的情况，甚至还有一个例子：

例如，考虑一个三使用单播 UDP 实现的聚会会议参与者在不同的端口对上从其他两个接收。如果每个参与者发送关于从接收到的数据的 RTCP 反馈另一位参与者仅返回该参与者，然后 会议由三个独立的点对点 RTP 组成会话。

【问题讨论】：

标签： rtp rtcp

【解决方案1】：

据我了解，此规则仅适用于多播和/或数据包循环。使用您描述的设置（两个发送方单播到一个接收方），他们彼此不认识，也没有检测冲突的措施。处理这个问题是接收者的任务。如果接收方是媒体处理器，它可能会充当终端方，重新格式化流并在其自己的 SSRC 下重新发送所需的内容。

【讨论】：

【解决方案2】：

可以使用设置为适当值的原因发送再见。

按照传统，我看到用于指示 SSRC 正在更改的值“ssrc”。

此外，如果接收到带有新 SSRC 的 RTCP 数据包，则 RTP 数据包 ssrc 也可能会更改，因此在验证序列号时会进行处理，如果 ssrc 更改但序列号仍然有效，则新的 ssrc将会被使用。

【讨论】：