跳到主要内容

11. 媒体处理 (Media Handling)

11.1. 发送媒体​

full 实现和 lite 实现发送媒体的过程不同.

11.1.1. full 实现的过程​

agent 始终使用一个 candidate pair 发送媒体, 称为 selected candidate pair. agent 会将媒体发送到 selected pair 中的 remote candidate (将分组的目标地址和端口设置为该 remote candidate), 并从 selected pair 中的 local candidate 发出. 当 local candidate 是 server reflexive 或 peer reflexive candidate 时, 媒体从 base 发起. 从 relayed candidate 发送的媒体会使用 [RFC5766] 中定义的过程, 从 base 经由该 TURN server 发送.

如果 local candidate 是 relayed candidate, 则推荐 agent 在 TURN server 上朝向 remote candidate 创建一个 channel. 这通过 [RFC5766] 第 11 节中定义的 channel 创建过程完成.

媒体流某个 component 的 selected pair 为:

  • 如果该媒体流的 check list 状态为 Running, 并且由于 ICE restart 该 component 没有 previous selected pair, 则为空.

  • 如果该媒体流的 check list 状态为 Running, 并且由于 ICE restart 该 component 有 previous selected pair, 则等于该 component 的 previous selected pair.

  • 如果 check list 状态为 Completed, 则等于 valid list 中该 component 的最高优先级 nominated pair.

如果媒体流至少一个 component 的 selected pair 为空, agent 不得为该媒体流的任何 component 发送媒体. 如果媒体流每个 component 的 selected pair 都有值, agent 可以为该媒体流的所有 components 发送媒体.

注意, 媒体流某个 component 的 selected pair 可能不等于最近一次 offer/answer 交换中同一 component 的 default pair. 发生这种情况时, 媒体使用 selected pair, 而不是 default pair. 当 ICE 首次完成时, 如果 selected pairs 与 default pairs 不匹配, controlling agent 会发送一次更新的 offer/answer 交换来修正这种差异. 但是, 在该更新的 offer 到达之前, 二者不会匹配. 此外, 在非常少见的情况下, 更新的 offer/answer 中的 default candidates 也不会匹配.

11.1.2. lite 实现的过程​

lite 实现 不得发送媒体, 直到它拥有一个 Valid list, 且该列表包含该媒体流每个 component 的 candidate pair. 一旦满足这一点, agent 可以开始发送媒体分组. 为此, 它将媒体发送到 pair 中的 remote candidate (将分组的目标地址和端口设置为该 remote candidate), 并从 local candidate 发送.

11.1.3. 所有实现的过程​

ICE 与 jitter buffer adaptation 机制存在交互. RTP 流可以先使用一个 candidate, 然后切换到另一个 candidate, 虽然这在 ICE 中很少发生. 新的 candidate 可能导致 RTP 分组经过不同的网络路径, 该路径具有不同的延迟特性. 如下所述, 当媒体分组的源地址或目标地址发生变化时, 鼓励 agent 重新调整 jitter buffers. 此外, 许多音频编解码器使用 marker bit 来表示 talkspurt 的开始, 用于 jitter buffer adaptation. 对于这类编解码器, 当 agent 将媒体传输从一个 candidate pair 切换到另一个 candidate pair 时, 推荐发送方设置 marker bit [RFC3550].

11.2. 接收媒体​

ICE 实现 必须准备好在最近一次 offer/answer 交换中为某个 component 提供的任何 candidates 上接收该 component 的媒体 (对于 RTP, 如果同时提供了 RTP 和 RTCP 的 candidates, 则包括二者).

推荐当 agent 收到某个特定媒体流中具有新源 IP 地址或目标 IP 地址的 RTP 分组时, 重新调整其 jitter buffers.

RFC 3550 [RFC3550] 在第 8.2 节描述了一种用于检测 synchronization source (SSRC) 冲突和环路的算法. 这些算法部分基于观察同一 SSRC 是否出现不同的源 transport address. 然而, 使用 ICE 时, 当媒体流在 candidates 之间切换时, 有时会发生这种变化. 由于媒体传输之前进行的 STUN 交换, agent 能够判断该媒体流来自同一个对等 agent. 因此, 如果源 transport address 发生变化, 但媒体分组来自同一个对等 agent, 则 不应该将其视为 SSRC 冲突.

最后于 更新