0

来自RFC 3550

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

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

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

更新:

正如下面所回答的,有两个单独的 RTP 会话具有单独的 SSRC 空间,因此不需要冲突检测。

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

和:

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

我描述的情况甚至还有一个例子:

例如,考虑使用单播 UDP 实现的三方会议,每个参与者在单独的端口对上从其他两个参与者接收。如果每个参与者仅将有关从另一个参与者接收的数据的 RTCP 反馈发送回该参与者,则会议由三个单独的点对点 RTP 会话组成

4

2 回答 2

1

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

于 2014-01-07T19:00:20.830 回答
1

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

请参阅http://www.ietf.org/rfc/rfc3550.txt @ 6.6 BYE:再见 RTCP 数据包

按照传统,我已经看到用于指示 SSRC 正在发生变化的值“ssrc”。

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

于 2014-06-07T20:51:40.700 回答