6. 添加和移除 SSRC
单个 RTP 会话中存在的 SSRC 集合可能随时间变化, 原因可能是会话中端点数量的变化, 或者所发送 RTP 流的数量或类型的变化.
RTP 会话中的每个端点将至少有一个 SSRC, 用于 RTCP 报告, 并在需要时用于发送媒体. 它还可以有额外的 SSRC, 用于发送额外的媒体源或用于额外的 RTCP 报告. 如果所发送的媒体源集合发生变化, 那么所发送的 SSRC 集合也会变化. 媒体格式或时钟速率的变化也可能需要改变所使用的 SSRC 集合. 端点还可以拥有比其活动 RTP 流更多的 SSRC, 并发送与当前未发送 RTP 数据包的 SSRC 相关的 RTCP, 以便其对端知晓这些 SSRC, 并使相关上下文 (例如时钟同步和 SDES CNAME) 就位, 从而能够在其一旦变为活动状态时立即播放媒体.
在下文中, 我们描述围绕添加和移除 RTP 流及其关联 SSRC 的一些考虑.
6.1. 添加 RTP 流
当端点加入 RTP 会话时, 它可以有零个、一个或多个它将发送或准备发送的 RTP 流. 如果它没有计划发送的 RTP 流, 它仍然需要一个用于发送 RTCP 反馈的 SSRC. 如果它将发送一个或多个 RTP 流, 它将需要相应数量的 SSRC 值. 端点所使用的 SSRC 通过发送 RTP 和 RTCP 包而为 RTP 会话中的其他端点所知. SSRC 也可以通过非 RTP 手段来通告 (例如 [RFC5576]). 除非受到信令的限制, 端点可以在任何时候发送一个额外的 RTP 流, 由新的 SSRC 标识 (这可能与某个信令事件相关, 但那超出了本备忘录的范围). 由于会话中的端点共享 RTP 会话定义中固有的单一 SSRC 空间, 这会使新的 SSRC 对会话中的其他端点可见.
从未发送过 RTP 流的端点将拥有一个用于 RTCP 报告的 SSRC. 如果该端点想要开始发送 RTP 流, 建议 (RECOMMENDED) 它将该流使用其现有的 SSRC, 否则 RTP 会话中的参与者计数将不必要地增加, 导致更长的 RTCP 报告间隔, 并因交叉报告而产生更大的 RTCP 报告. 如果该端点想要开始发送多于一个 RTP 流, 则它需要为第二个及任何后续 RTP 流生成新的 SSRC.
先前已停止发送某个 RTP 流、现在想要开始发送新的 RTP 流的端点, 通常不能复用现有的 SSRC, 而往往需要生成新的 SSRC, 因为 SSRC 不能改变媒体类型 (例如从音频改为视频) 或 RTP 时间戳时钟速率 [RFC7160], 并且因为该 SSRC 可能已被应用赋予特定的语义 (注: 只要在该暂停期间为该 SSRC 发送 RTCP, RTP 流就可以使用同一个 SSRC 暂停并重新开始; 这些规则仅适用于复用现有 SSRC 的新 RTP 流).
6.2. 移除 RTP 流
SSRC 以两种方式之一从 RTP 会话中移除. 当端点停止使用某个 SSRC 发送 RTP 和 RTCP 包时, 该 SSRC 最终会如 [RFC3550] 第 6.3.5 节所述超时. 或者, 可以如 [RFC3550] 第 6.3.7 节所述通过发送 RTCP BYE 包来显式地将某个 SSRC 从使用中移除. 建议 (RECOMMENDED) 通过发送 RTCP BYE 包来将 SSRC 从使用中移除. 注意 [RFC3550] 要求 RTCP BYE 应当 (SHOULD) 是某个 SSRC 在 RTP 会话中发送的最后一个 RTP/RTCP 包. 如果端点在为其 SSRC 发送 RTCP BYE 之后需要重新开始某个 RTP 流, 则它需要为该流生成新的 SSRC 值.
发送 RTCP BYE 的终结性意味着端点需要考虑某个 RTP 流传输的停止是暂时的还是永久的. 使用特定 RTP 流 (SSRC) 的媒体传输的暂时中止, 需要通过继续为其发送 RTCP 来将该 SSRC 维持为活动参与者. 这样, 在上下文就位的情况下, 媒体发送可以立即恢复. 当永久停止传输时, 参与者需要发送 RTCP BYE, 以便其他参与者可以使用 RTCP 带宽资源并清理它们的状态数据库.
停止其所有 RTP 流传输但仍留在 RTP 会话中的端点, 必须 (MUST) 维持至少一个用于 RTCP 报告和反馈的 SSRC (即它不能为所有 SSRC 发送 BYE, 而是需要保留至少一个活动 SSRC). 由于某些反馈包可能绑定到媒体类型, 可能需要在 RTP 会话内为每种媒体类型维持一个 SSRC. 另一种做法是创建一个新的 SSRC 用于 RTCP 报告和反馈. 然而, 为避免造成端点完全退出 RTP 会话的印象, 这样的新 SSRC 应当先建立起来 —— 在终止所有现有 SSRC 之前.