4. 选择 RTCP CNAME

主机很难确定自身与其 RTP 对等体之间是否存在 NAT, 在某些情况下甚至不可能确定. 此外, 即使某些公共 IPv4 地址也可能由互联网中的多个主机共享. 不建议 (NOT RECOMMENDED) 使用 IPv4 地址的数字表示作为 RTCP CNAME 的 "host" 部分.

4.1. 持久 RTCP CNAME 与每会话 RTCP CNAME

对于 RTP 端点, RTCP CNAME 可以在不同 RTP 会话之间保持持久, 也可以按会话唯一; 后者意味着 RTP 端点为每个 RTP 会话选择不同的 RTCP CNAME.

如果 RTP 端点正在发出多个相关 RTP 流, 且这些流需要在其他端点处同步, 则必须 (MUST) 对所有需要同步的流使用相同 RTCP CNAME. 这需要一个短期持久的 RTCP CNAME, 该 CNAME 在多个 RTP 流之间共用, 并且可能跨多个相关 RTP 会话共用. 此类使用的常见例子是在多媒体会话中同步音频和视频流, 其中单个参与者必须为其音频 RTP 会话和视频 RTP 会话使用相同 RTCP CNAME. 另一个例子可能是同步分层音频编解码器的各层, 其中每一层都必须使用相同 RTCP CNAME.

如果 RTP 会话中的多个 RTP 流彼此无关, 因而不需要同步, RTP 端点可以为这些流使用不同 RTCP CNAME.

较长期持久的 RTCP CNAME 有时有助于第三方监控, 这与 [RFC3550] 一致. 这种用途之一可能是允许网络管理工具在多个 RTP 会话之间关联某个参与者的持续服务质量, 用于故障诊断并了解长期网络性能统计. 希望抑制此类第三方监控的应用开发者可以选择为应用将加入的每个 RTP 会话或相关 RTP 会话组生成唯一 RTCP CNAME. 这种每会话 RTCP CNAME 不能用于流量分析, 因而提供某种有限形式的隐私. 注意, 第三方还可以使用非 RTP 手段关联 RTP 会话, 因此使用每会话 RTCP CNAME 并不能阻止坚定的流量分析者监控此类会话.

本备忘录定义了实现选择 RTCP CNAME 的几种不同方式. 独立实现即使运行在同一主机上, 也可能并且可以合法地选择不同的 RTCP CNAME. 除非提供某种外部手段为这些实现配置持久的 RTCP CNAME 选择, 否则这可能阻碍第三方监控.

注意, 本备忘录不会引入与兼容 [RFC3550] 的实现之间的向后兼容问题, 因为 RTCP CNAME 对远端对等体而言是不透明字符串.

4.2. 要求

RTP 端点将选择生成持久或每会话 RTCP CNAME. 希望生成持久 RTCP CNAME 的 RTP 端点必须 (MUST) 使用以下两种方法之一:

• 为生成长期持久 RTCP CNAME, RTP 端点必须 (MUST) 生成并存储一个通用唯一标识符 (Universally Unique IDentifier, UUID) [RFC4122], 用作其 RTCP CNAME 的 "host" 部分. UUID 必须 (MUST) 是 [RFC4122] 中所述的版本 1、2 或 4, 并去除 "urn:uuid:" 前缀, 得到 36 八位组的可打印字符串表示.

• 为生成短期持久 RTCP CNAME, RTP 端点必须 (MUST) 按第 5 节所述过程生成并使用一个标识符. 该过程至少在软件每次初始化时执行一次. 获得标识符后, 至少应 (SHOULD) 使用 Base64 编码 [RFC4648] 将最低有效 96 位转换为 ASCII (在数据包大小和唯一性之间折中 -- 参见第 6.1 节). 如果使用 96 位, 所得字符串将为 16 八位组. 注意, Base64 编码值不能超过 [RFC3550] 中 RTCP CNAME 的最大长度 255 八位组.

在上述两种情况下, 为保护隐私, 单用户系统可以 (MAY) 省略 RTCP CNAME 的 "user@" 部分, 多用户系统可以 (MAY) 用不透明令牌替换该部分.

希望生成每会话 RTCP CNAME 的 RTP 端点必须 (MUST) 使用以下方法:

• 对于每个新的 RTP 会话, 按第 5 节所述过程生成新的 RTCP CNAME. 执行该过程后, 至少应 (SHOULD) 使用 Base64 编码 [RFC4648] 将最低有效 96 位转换为 ASCII. 在 RTP 会话生命周期内, RTCP CNAME 不能改变 [RFC3550]. 生成每会话 RTCP CNAME 时省略 RTCP CNAME 的 "user@" 部分.

获得唯一性 (以高概率) 被认为是一项重要属性, 需要仔细评估相关方法. 本文档提供了多种方法, 对任何给定部署场景而言, 至少有一种方法是适用的. 因此, 本文档不允许实现者自行定义并选择替代方法.

未来的规范可以定义生成 RTCP CNAME 的替代方法, 只要所提方法具有适当唯一性, 并且要被关联的多个 RTP 会话所使用的方法之间保持一致. 但是, 此类规范需要在部署前经过审查和批准.

本文档描述的机制用于生成 RTCP CNAME, 不用于生成通用唯一标识符.

5. 生成唯一标识符的过程

要在本地生成唯一标识符, 只需按 [RFC4086] 中所述生成一个密码学伪随机值. 该值必须 (MUST) 至少为 96 位.

实现该算法的最大瓶颈是是否具备适当的密码学安全伪随机数生成器 (Cryptographically Secure Pseudorandom Number Generator, CSPRNG). 在已经具备安全 PRNG 的任何环境中, 本文所述算法都远比 [RFC6222] 第 5 节所述算法简单. SIP 协议栈 [RFC3261] 需要使用密码学随机数生成 To 和 From 标签 (第 19.3 节). Web 实时通信 (Real-Time Communications on the Web, RTCWEB) 实现 [ARCH] 需要具备安全 PRNG, 以实现 ICE [RFC5245] 和 DTLS-SRTP [RFC5764]. 当然, 基本上每个 Web 浏览器都已经支持 TLS, 而 TLS 需要安全 PRNG.