来自RFC 3550：
如果接收者发现另外两个 源是冲突的，它可以保持数据包从一个丢弃 来自另一个的数据包可以被不同的检测到 源传输地址或CNAME。 预计这两个来源 解决冲突，以便情况不会持续。
在单播配置中，一个接收器和两个仅与接收器通信的发送器，发送器可能如何检测到SSRC冲突？
一个猜测是接收者应该定期向所有已知参与者（发送者）发送所有已知的CNAME。这是真的吗？但在这种情况下，发件人如何将收到的CNAME与传输地址相关联？
更新
如下所述，有两个单独的RTP会话具有单独的SSRC空间，因此不需要进行冲突检测。
RTP会话的显着特征是每个 维护一个完整的，独立的SSRC标识符空间
和
一组参与者包含在一个RTP会话中 由可以接收传输的SSRC标识符的那些组成 任何一个参与者在RTP中作为SSRC或CSRC （也在下面定义）或在RTCP中。
我所描述的情况甚至有一个例子：
例如，考虑一个三 使用单播UDP与每个实现的聚会会议 参与者从另外两个端口对接收。 如果每个参与者发送有关收到的数据的RTCP反馈 另一个参与者只回到那个参与者，然后 会议由三个单独的点对点RTP组成 会话
答案 0 :(得分：1)
据我了解，此规则仅适用于多播和/或数据包循环。使用您描述的设置（两个发件人对一个接收器进行单播），他们彼此不了解并且没有检测到碰撞的措施。这是接收器处理这个问题的任务。如果接收方是媒体处理器，它可能会充当终端方，重新格式化流并在其自己的SSRC下重新发送所需内容。
答案 1 :(得分：1)
可以使用设置为适当值的原因发送再见..
请参阅http://www.ietf.org/rfc/rfc3550.txt @ 6.6 BYE：Goodbye RTCP Packet
按照传统，我已经看到了价值＆＃34; ssrc＆＃34;用于表明SSRC正在发生变化。
此外，如果接收到带有新SSRC的RTCP数据包，则RTP数据包ssrc也应该更改，因此在验证序列号时会处理，如果ssrc已更改但序列号仍然有效则新ssrc将会被使用。