问题描述
来自 RFC 3550:
如果接收者发现另外两个源发生冲突，它可能会保留数据包并丢弃来自另一个的数据包，当这可以被不同的源传输地址或 CNAME.预计两个来源解决冲突，以免这种情况持续下去.
在具有一个接收器和两个仅与接收器通信的发送器的单播配置中，发送器如何检测 SSRC 冲突?
In a unicast configuration with one receiver and two senders that only communicate with receiver, how SSRC collisions may be detected by senders?
一种猜测是接收者应该定期将所有已知的 CNAME 发送给所有已知的参与者(发送者).这是真的吗?但在这种情况下，发件人如何将收到的 CNAME 与传输地址关联起来?
One guess is that receiver should periodically send all known CNAMEs to all known participants (senders). Is it true? But in this case, how senders will associate received CNAME with a transport address?
更新:
如下所述，有两个单独的 RTP 会话具有单独的 SSRC 空间，因此不需要冲突检测.
As answered below, there are two separate RTP sessions with separate SSRC spaces, so no collision detection is needed.
RTP 会话的显着特征是每个维护一个完整的、独立的 SSRC 标识符空间
还有:
一个 RTP 会话中包含的一组参与者由可以接收发送的 SSRC 标识符的那些组成由 RTP 中的任何一个参与者作为 SSRC 或中国证监会(也定义如下)或在 RTCP 中.
我所描述的情况甚至还有一个例子:
And there is even an example for the situation I have described:
例如，考虑一个三使用单播 UDP 实现的派对会议参与者在不同的端口对上从其他两个接收.如果每个参与者发送 RTCP 反馈关于从另一个参与者只返回给那个参与者，然后 会议由三个独立的点对点 RTP 组成会话.
推荐答案
据我所知，此规则仅适用于多播和/或数据包循环.使用您描述的设置(两个发送器向一个接收器单播)，它们彼此不认识并且没有检测冲突的措施.处理这个问题是接收方的任务.如果接收方是媒体处理器，它可能会充当终端方，重新格式化流并在其自己的 SSRC 下重新发送所需的内容.
As far as I understand, this rule is applicable only for multicasting and/or loops of packets. With the setup described by you (two senders are unicasting to one receiver), they don't know each other and have no measures to detect the collision. It's receiver task to deal with this issue. If the receiver is media processor, it likely will act as an end party, reformat the stream and resend needed contents under its own SSRC.
这篇关于RTP:单播会话中的 SSRC 冲突检测的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！