RTP 数据包头中的 SSRC=0 是否有效？答案

【问题标题】：Is SSRC=0 in RTP packet header valid?RTP 数据包头中的 SSRC=0 是否有效？
【发布时间】：2019-11-07 14:48:44
【问题描述】：

同步源（SSRC）：RTP流的源数据包，由携带的 32 位数字 SSRC 标识符标识 RTP 标头，以便不依赖于网络地址。

RFC 声明 SSRC 是一个 32 位数字。那么，让 SSRC 为零 (SSRC=0x00) 在 RTP 标头中是否可以接受？

【问题讨论】：

【解决方案1】：

SSRC 允许从 0 到 2^32 -1 的所有 32 位二进制值。但正如 RFC 中所述：

SSRC应该是一个随机值；
SSRC必须检测到冲突。

SSRC：32 位 SSRC 字段标识同步源。这标识符应该是随机选择的，目的是没有两个同一 RTP 会话中的同步源将具有相同的 SSRC 标识符。
1. SSRC标识符分配和使用
  
  RTP 头和各个字段中携带的 SSRC 标识符 RTCP 数据包的数量是一个随机的 32 位数字，需要在 RTP 会话中全局唯一。数量很重要谨慎选择，以便同一网络上的参与者或在同一时间开始不太可能选择相同的数字。
  
  仅使用本地网络地址是不够的（例如 IPv4 地址）作为标识符，因为该地址可能不是独特。由于 RTP 转换器和混频器能够实现之间的互操作具有不同地址空间的多个网络，分配两个空格内的地址模式可能会导致很多与随机分配相比，冲突率更高。
  
  在一台主机上运行多个源也会发生冲突。
  
  仅通过以下方式获取 SSRC 标识符也是不够的调用 random() 而不仔细初始化状态。

【讨论】：

我理解 RFC 并且 SSRC 可以是任何随机的 32 位数字。但奇怪的是，MS Lync 丢弃了 SSRC=0x00 的 RTP 数据包。这让我想知道零是否是一个有效的随机 32 位数字。

【解决方案2】：

是的，零是有效的 SSRC 值，应该考虑在内。

如果对方始终使用 0 作为 SSRC 值，则其熵可能会受到质疑（xkcd 和 dilbert）。与许多与 VoIP 相关的 RFC 一样，实现方式差异很大，以至于大多数端点软件（UAS、UAC 尤其是 B2BUA）必须适应协议偏差。想想不同的 DTMF 实现和不太合规的应用程序。

【讨论】：