摘要
- SSRC 把同一时间与序列空间的 RTP 包归在一起,但它只要求在一个 RTP 会话内唯一,并不是用户的永久身份。
- 源发现自己的 SSRC 被另一源使用时,要为旧值发送 RTCP BYE,再选择并核验一个未占用的随机值。
- 同一 SSRC 从不同传输地址到达,既可能是冲突,也可能是环路、NAT 重映射、转发器重启或移动;CNAME 能补充连续性,却不能认证所有者。
一个号码承载不了两套播放历史
接收端看到 SSRC 后,会把序号、时间戳、接收报告和播放状态归入同一同步源。若两个独立发送者选中同一个值,它们原本无关的时钟与序列就会挤进同一状态。听起来像一次跳变的视频,可能其实来自另一台摄像机;看似突然重排的音频,可能来自另一个发言源。
1996 年的 RFC 1889 采用 32 位随机 SSRC,并明确让它不依赖网络地址。多播、混合器和转换器会让“一个地址等于一个源”失效;会话也不能在每个新发言者出现前等待中央机构发号。
代价是偶然相同永远不能从模型中消失。RTP 因而把冲突处理写入正常实现要求,而不是把低概率当作免责条款。
随机选择也需要工程纪律
RFC 3550 给出两个估算。若一千个源同时启动并独立选择,至少一对碰撞的近似概率约为 10^-4;若一千个现有源已经互不相同,一个新源加入时约为 2×10^-7。这些数字是数学例子,不是现实部署统计。
本地 IP 地址并不足够唯一:不同私网会在转换器后相遇,同一主机也能产生多个源。没有认真初始化的伪随机生成器,可能让同时启动的进程重复同一序列。新源还可以在第一次发包前先监听会话,发现候选值已出现便重新选择。
这一设计没有追求“永不相撞”的承诺。它追求的是:降低概率,并在承诺失效时仍能继续。
旧 SSRC 说再见,媒体源没有消失
源一旦确认另一个源正在使用自己的 SSRC,就必须为旧标识发送 RTCP BYE,然后选择另一个随机值。新候选要先查本地源表;已被占用就必须继续重选。
这里的 BYE 结束的是旧同步标签,不一定是摄像机、麦克风、应用或人的参与。RFC 7656 后来把边界说得很清楚:一条 RTP 流在任一时刻只有一个 SSRC,但 SSRC 可以随时间变化,冲突正是合理原因之一。
若录制系统把 SSRC 当作永久主键,同一媒体会被切成两个对象。若人员面板把 BYE 当作离会,就会制造一次假离开与假加入。协议从未授予这个数字如此持久的身份权力。
接收端只能选择暂时保留哪一路
接收端也可能发现两个第三方源发生冲突。RFC 3550 允许它依据不同传输地址或 CNAME,保留一方的包并舍弃另一方;真正换号仍由冲突源完成。
先到的源常会暂时保留原有状态,但这不是所有权裁决。原源换号并发送 BYE 后,旧表项会退出;若 BYE 没有到达,超时也会改变接收端掌握的事实。
源表不能只记录 SSRC。RTP 与 RTCP 的 UDP 源端口可以不同,所以算法分别保存两者最初的传输地址。经混合器之后,地址可能被统一;此时,同一 SSRC 下两个不同的 RTCP CNAME 仍能暴露冲突。
冲突检测同时承担环路告警
转发环路会制造同样的表面:相同 SSRC 从不同地址回来。仅凭一个包,接收端不能知道面前是第二个源,还是旧包绕路返回。
RFC 3550 要求实现保存一份带时间的冲突地址列表。本地 SSRC 首次遇到冲突时,源换号一次并记住来路。若同一来路继续返回反射包,随后将其忽略,而不是每绕一圈就再次发送 BYE、再次换号。否则一个环路就能诱发控制包风暴。
混合器和转换器必须打断自己可能造成的环路。但 RFC 7667 说明,可见性取决于 SSRC/CSRC 是否被正确保留。背靠背的独立 RTP 会话和某些转发拓扑会切断共同名字空间,环路责任只能上移到别的层次。
地址变化不是攻击结论
2003 年的规范放宽了旧版规则:源改变传输地址时可以换 SSRC,但不再一律强制。移动应用可能在地址变化后合法保持同一媒体流;接收端可以接受新地址,同时防止真假两个来路反复夺取状态。
转换器重启并更换 UDP 端口,会使其转发的多个 SSRC 看起来像环回。RFC 5135 又给出 NAT 情形:映射超时后,相同 SSRC 搭配新的 IP 或端口会触发碰撞处理,诊断工具与抖动缓冲可能受到影响。
因此,“发现 SSRC 冲突”只是一条分类起点。它不能单独证明恶意冒充、重复发送或某台具体设备故障。
CNAME 保存的是另一种连续性
RFC 7022 把 SSRC 与 RTCP CNAME 分开。碰撞或应用重启后,SSRC 可以变化;CNAME 可以在需要同步的一组媒体之间保持稳定,把旧流与新流联系起来。应用也可为跨会话监测选择较长持续期,或为减少关联而每会话更新。
CNAME 并不是隐藏的真实身份。参与者自行选择它,也可能模仿他人的值。它能帮助关联观察,却不能认证一个人、机构或发言权。
即使有现代信令,运行时冲突也没有消失。RFC 8834 要求 WebRTC 端点支持随机 SSRC 和 RFC 3550 的冲突解决。双方可能在信令确认前同时启用新值,重传等辅助功能也会带来此前未宣布的 SSRC。
来源与边界
历史起点见 RFC 1889,成熟算法见 RFC 3550。NAT 边界来自 RFC 5135,CNAME 来自 RFC 7022,流语义来自 RFC 7656,拓扑限制来自 RFC 7667,WebRTC 要求来自 RFC 8834。这些文档不提供当前碰撞率、产品符合性、真人身份、媒体真实性或播放成功的证明。
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
