10. 保活 (Keepalives)

所有端点 必须为每个媒体会话发送 keepalives. 这些 keepalives 用于保持该媒体会话的 NAT 绑定处于活动状态. 无论媒体流当前是 inactive, sendonly, recvonly 还是 sendrecv, 也无论 bandwidth 属性是否存在及其取值如何, 这些 keepalives 都 必须发送. 即使会话完全没有使用 ICE, 这些 keepalives 也 必须发送. keepalive 应该使用对等方支持的格式发送. ICE 端点允许对 UDP 流使用基于 STUN 的 keepalives, 因此当 agent 是 full ICE 实现并且正在与支持 ICE 的对等方 (lite 或 full) 通信时, 必须使用 STUN keepalives. agent 可以通过每个媒体会话中是否存在 a=candidate 属性来判断其对等方是否支持 ICE. 如果对等方不支持 ICE, keepalives 的分组格式选择属于本地实现问题. 推荐使用一种即使没有实际媒体内容也易于发送分组的格式. 能够很好满足这一目标的格式示例包括 RTP No-Op [NO-OP-RTP], 以及在双方都支持时的 RTP comfort noise [RFC3389]. 如果对等方不支持任何特别适合 keepalives 的格式, agent 应该发送版本号不正确的 RTP 分组, 或者发送某种其他形式的错误分组, 使其会被对等方丢弃.

如果在 ICE 用于某个媒体 component 的 candidate pair 上已有 Tr 秒没有发送任何分组 (其中分组包括为该 component 定义的分组, 即 RTP 或 RTCP, 以及之前的 keepalives), agent 必须在该 pair 上生成 keepalive. Tr 应该可配置, 并且 应该默认值为 15 秒. Tr 不得配置为小于 15 秒. 或者, 如果 agent 有动态方法发现中间 NAT 的绑定生命周期, 它可以使用该值来确定 Tr. 在更受控的网络环境中部署 ICE 的管理员 应该将 Tr 设置为其环境中尽可能长的时长.

如果使用 STUN 作为 keepalives, 则使用 STUN Binding Indication [RFC5389]. 该 Indication 不得使用任何认证机制. 它 应该包含 FINGERPRINT 属性以帮助解复用, 但 不应该包含任何其他属性. 它仅用于保持 NAT 绑定处于活动状态. Binding Indication 使用与媒体相同的 local candidate 和 remote candidate 发送. 虽然 Binding Indications 被用作 keepalives, agent 仍 必须准备好接收 connectivity check. 如果收到 connectivity check, 则按 [RFC5389] 中讨论的方式生成响应, 但除此之外不会影响 ICE 处理.

一旦 ICE 已选择用于媒体的 candidates, 或者媒体开始流动, 以较早发生者为准, agent 必须开始 keepalive 处理. 当会话终止或媒体流被移除时, keepalives 结束.