1. 引言

在 [RFC3550] 第 6.5.1 节中, 有若干关于为 RTP 端点选择唯一 RTCP CNAME 的建议. 但是在实践中, 其中一些方法并不能保证生成唯一的 RTCP CNAME. [RFC6222] 更新了选择 RTCP CNAME 的指南, 取代了 [RFC3550] 第 6.5.1 节中的内容. 遗憾的是, 新算法的某些部分相当复杂, 并且在某些情况下, 即使为每个会话生成新的 RTCP CNAME, 所生成的 RTCP CNAME 仍可能在多个 RTCP 会话之间被关联. 本文档规定了 [RFC6222] 第 5 节算法的替代方案, 它没有这种限制, 且实现更简单.

关于 [RFC6222] 生成的 RTCP CNAME 可关联性的讨论, 请参见 [RESCORLA].

2. 要求表示法

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 [RFC2119] 中的说明进行解释.

3. 早期 RTCP CNAME 选择指南的缺陷

[RFC3550] 中的建议是, 对多用户系统生成形如 "user@host" 的 RTCP CNAME, 或在用户名不可用时生成 "host". 其中 "host" 部分被规定为实时数据来源主机的完全限定域名 (Fully Qualified Domain Name, FQDN). 虽然该指南在 [RFC3550] 编写时是合适的, 但 FQDN 不再必然唯一, 在大型服务提供商网络中有时可能在多个端点之间共用. 本文档用替代机制取代使用 FQDN 作为 RTCP CNAME 的做法.

[RFC3550] 还建议在 RTCP CNAME 中使用 IPv4 地址, 其中 RTCP CNAME 的 "host" 部分是 RTP 数据来源接口 IPv4 地址的数字表示. 如 [RFC3550] 所述, 使用私有网络地址空间 [RFC1918] 会导致主机拥有并非全局唯一的网络地址. 此外, 如果多个主机被分配同一个公共 IPv4 地址并连接到网络地址转换 (Network Address Translation, NAT) 设备 [RFC3022], 这种对同一 IPv4 地址的共享使用也可能发生在公共 IPv4 地址上. 当多个主机共享同一个 IPv4 地址时, 无论该地址是私有还是公共地址, 使用 IPv4 地址作为 RTCP CNAME 都会导致 RTCP CNAME 不一定唯一.

[RFC3550] 还指出, 如果具有私有地址且无法直接通过 IP 连接到公共互联网的主机, 通过 RTP 层转换器将其 RTP 数据包转发到公共互联网, 它们最终可能拥有非唯一的 RTCP CNAME. [RFC3550] 的建议是, 此类应用提供一个配置选项, 允许用户选择唯一的 RTCP CNAME; 这种技术把负担放在转换器上, 要求它在必要时把来自私有地址的 RTCP CNAME 转换为公共地址, 以避免暴露私有地址. 经验表明, 这在实践中效果并不好.