20. 运营考虑 (Operational Considerations)
本节讨论希望部署 ICE 的网络运营商需要关注的问题.
20.1. NAT 和 Firewall 类型
ICE 被设计为可与现有 NAT 和 firewall 设备一起工作. 因此, 为促进 ICE 部署, 无需替换或重新配置现有 firewall 和 NAT 设备. 实际上, ICE 的开发目标就是部署在 Voice over IP (VoIP) 运营商无法控制 IP 网络基础设施 (包括 firewalls 和 NAT) 的环境中.
也就是说, 当 NAT devices 符合 "behave" 要求, 满足 [RFC4787] 和 [RFC5766] 中定义的建议时, ICE 工作得最好. 在具有 behave-compliant NAT 的网络中, ICE 无需 TURN server 即可工作, 从而提高语音质量, 降低 call setup time, 并减少对网络运营商的带宽需求.
20.2. 带宽需求
部署 ICE 可能与可用网络容量产生若干交互, 运营商应予以考虑.
20.2.1. STUN 和 TURN Server 容量规划
首先也是最重要的是, ICE 使用 TURN 和 STUN servers, 它们通常位于网络运营商的数据中心. STUN servers 需要的带宽相对较少. 对于每个媒体流的每个 component, 每个客户端到 STUN server 会有一个或多个 STUN transactions. 在基本的仅语音 IPv4 VoIP 部署中, 每次呼叫会有四个 transactions (主叫和被叫各有一个 RTP 和一个 RTCP). 每个 transaction 包含一个 request 和一个 response, 前者长度为 20 bytes, 后者为 28 bytes. 因此, 如果系统有 N 个用户, 且每个用户在 busy hour 中发起四次呼叫, 则需要 N*1.7bps. 对于一百万用户, 这是 1.7 Mbps, 是一个很小的数值 (相对而言).
TURN 流量更为可观. TURN server 将看到与 STUN 流量相同的流量规模 (实际上, 如果部署了 TURN servers, 就不需要单独的 STUN server), 另外还包括实际媒体流量. 需要 TURN 进行媒体 relay 的呼叫数量高度依赖网络拓扑, 并且会随时间变化. 在具有 100% behave-compliant NAT 的网络中, 该数量恰好为零. 在撰写本文时, 大规模消费者部署中需要 TURN servers 的呼叫比例在 5% 到 10% 之间. 考虑使用 G.711 的仅语音部署 (因此每个方向 80 kbps), busy hour 中为 .2 erlangs, 则为 N*3.2 kbps. 对于一百万用户, 假设 TURN servers 使用率为 10%, 则为 3.2 Gbps.
20.2.2. 收集和连接检查 (Gathering and Connectivity Checks)
收集 candidates 以及执行 connectivity checks 的过程可能消耗大量带宽. ICE 被设计为对这两个过程进行 pacing. gathering phase 和 connectivity check phase 的目标是在大致与媒体流量本身相同的带宽下生成流量. 这样做是为了确保, 如果某个网络被设计为支持某种类型的 multimedia traffic (语音, 视频或纯文本), 它也有足够容量支持该媒体的 ICE checks. 当然, ICE checks 会导致总利用率略有增加; 但这通常是极小的增加.
由 gathering 和 check phases 导致的拥塞已被证明是未使用 pacing 的部署中的问题. 通常, endpoints 会以其能发送的最快速度向网络涌入 checks, 导致 access links 拥塞. 因此, 网络运营商应确保其 ICE 实现支持 pacing 功能. 虽然这种 pacing 会增加 call setup times, 但它使 ICE 对网络友好且更易部署.
20.2.3. 保活 (Keepalives)
STUN keepalives (以 STUN Binding Indications 的形式) 在媒体会话中间发送. 但是, 它们只在没有实际媒体流量时发送. 在未使用 Voice Activity Detection (VAD) 的部署中, keepalives 从不使用, 因而不会增加带宽使用. 当使用 VAD 时, keepalives 会在静音期间发送. 这涉及每 15-20 秒一个分组, 远少于有语音时每 20-30 ms 一个分组. 因此, keepalives 对容量规划没有实际影响.
20.3. ICE 和 ICE-lite
使用 ICE 和 ICE-lite 混合部署可以完美互操作. 它们被明确设计为如此, 且不会损失功能.
但是, ICE-lite 只能部署在有限用例中. 这些用例以及相关注意事项记录在附录 A 中.
20.4. 故障排除和性能管理
ICE 使用端到端 connectivity checks, 并将大量处理放在 endpoints 中. 这给网络运营商带来挑战: 他们如何排查 ICE 部署问题? 如何知道 ICE 的运行表现?
ICE 内置了一些特性来帮助处理这些问题. 信令路径上的 SIP servers 通常部署在网络运营商的数据中心, 它们会看到传递 ICE 参数的 offer/answer 交换内容. 这些参数包括每个 candidate 的类型 (host, server reflexive 或 relayed), 以及其 related addresses. ICE 处理完成后, 会进行一次更新的 offer/answer 交换, 信令所选地址 (以及其类型). 执行这次更新的 re-INVITE 正是为了让网络设备 (例如连接到 SIP server 的诊断工具) 了解 ICE 处理结果.
因此, 网络运营商可以通过 SIP server 生成的日志观察每次呼叫使用了哪些类型的 candidates, 以及 ICE 选择了哪个地址. 这是帮助评估 ICE 运行表现的主要信息.
20.5. 端点配置
ICE 依赖若干配置到 endpoints 中的数据. 这些配置数据包括 timers, TURN servers 的 credentials, 以及 STUN 和 TURN servers 的 hostnames. ICE 本身不提供这种配置机制. 相反, 假定这些信息附加在用于配置 endpoint 中所有其他参数的任何机制上. 对于 SIP phones, 已定义了配置框架 [SIP-UA-FRMWK] 等标准方案.