RTP：SSRC碰撞检测单播会话

Question

从RFC 3550：

如果接收器发现其他两个 源碰撞，它可以从一个保持数据包，当这一点可以从其他丢弃 包由不同的 源传输地址或CNAME检测到。 这两个来源预计 来解决冲突，使情况不会持续。

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

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

更新：

如下回答，也有独立SSRC空间两个单独的RTP会话，所以不需要碰撞检测。

RTP会话的显着特征是，每个 保持SSRC标识符

和一个完整的，独立的空间：

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

而且甚至还有为我所描述的状况的一个例子：

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

Answer 1

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

Answer 2

甲再见可以设置为适当的值的原因被发送..

参见http://www.ietf.org/rfc/rfc3550.txt @ 6。6 BYE：再见RTCP数据包

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

此外，如果一个RTCP数据包被一个新的SSRC接收到，RTP数据包ssrc可能也应该改变，因此将在验证序列号时处理，如果ssrc改变但序列号仍然有效，那么新ssrc将被使用。