17. Operational Considerations【操作注意事项】

原文链接：https://datatracker.ietf.org/doc/html/rfc8445#section-17

17. Operational Considerations【操作注意事项】

This section discusses issues relevant to operators operating networks where ICE will be used by endpoints.
本节讨论与使用者操作网络相关的问题，其中 ICE 将被端点使用。

17.1. NAT and Firewall Types【NAT和防火墙类型】

ICE was designed to work with existing NAT and firewall equipment.
ICE 被设计成与现有的 NAT 和防火墙设备配合使用。

Consequently, it is not necessary to replace or reconfigure existing firewall and NAT equipment in order to facilitate deployment of ICE.
因此，无需更换或重新配置现有的防火墙和 NAT 设备以便于 ICE 的部署。

Indeed, ICE was developed to be deployed in environments where the Voice over IP (VoIP) operator has no control over the IP network infrastructure, including firewalls and NATs.
事实上，ICE 的开发目的是部署在 IP 语音 (VoIP) 运营商无法控制 IP 网络基础设施（包括防火墙和 NAT）的环境中。

That said, ICE works best in environments where the NAT devices are “behave” compliant, meeting the recommendations defined in [RFC4787] and [RFC5382].
也就是说，ICE 在 NAT 设备“行为”兼容的环境中工作得最好，满足 [RFC4787] 和 [RFC5382] 中定义的建议。

In networks with behave-compliant NAT, ICE will work without the need for a TURN server, thus improving voice quality, decreasing call setup times, and reducing the bandwidth demands on the network operator.
在具有行为兼容 NAT 的网络中，ICE 无需 TURN 服务器即可工作，从而提高语音质量、减少呼叫建立时间并降低对网络运营商的带宽需求。

17.2. Bandwidth Requirements【带宽要求】

Deployment of ICE can have several interactions with available network capacity that operators need to take into consideration.
ICE 的部署可能与使用者需要考虑的可用网络容量有多种交互。

17.2.1. STUN and TURN Server-Capacity Planning【STUN 和 TURN 服务器容量规划】

First and foremost, ICE makes use of TURN and STUN servers, which would typically be located in data centers. The STUN servers require relatively little bandwidth.
首先，ICE 使用 TURN 和 STUN 服务器，这些服务器通常位于数据中心。 STUN 服务器需要的带宽相对较少。

For each component of each data stream, there will be one or more STUN transactions from each client to the STUN server.
对于每个数据流的每个组件，从每个客户端到 STUN 服务器都会有一个或多个 STUN 事务。

In a basic voice-only IPv4 VoIP deployment, there will be four transactions per call (one for RTP and one for RTCP, for both the caller and callee).
在基本的纯语音 IPv4 VoIP 部署中，每个呼叫将有四个事务（一个用于 RTP，一个用于 RTCP，用于呼叫者和被呼叫者）。

Each transaction is a single request and a single response, the former being 20 bytes long, and the latter, 28.
每个事务都是一个请求和一个响应，前者为 20 个字节长，后者为 28 个字节。

Consequently, if a system has N users, and each makes four calls in a busy hour, this would require N1.7bps. For one million users, this is 1.7 Mbps, a very small number (relatively speaking).
因此，如果一个系统有 N 个用户，每个用户在繁忙时间拨打 4 个电话，这将需要 N1.7bps。 对于 100 万用户来说，这是 1.7 Mbps，这是一个非常小的数字（相对而言）。

TURN traffic is more substantial. The TURN server will see traffic volume equal to the STUN volume (indeed, if TURN servers are deployed, there is no need for a separate STUN server), in addition to the traffic for the actual data.
TURN 流量更大。 除了实际数据的流量之外，TURN 服务器将看到等于 STUN 量的流量（实际上，如果部署了 TURN 服务器，则不需要单独的 STUN 服务器）。

The amount of calls requiring TURN for data relay is highly dependent on network topologies, and can and will vary over time.
需要 TURN 进行数据中继的呼叫量高度依赖于网络拓扑，并且会随着时间而变化。

In a network with 100% behave-compliant NATs, it is exactly zero.
在具有 100% 行为兼容 NAT 的网络中，它正好为零。

The planning considerations above become more significant in multimedia scenarios (e.g., audio and video conferences) and when the numbers of participants in a session grow.
上述规划考虑在多媒体场景（例如，音频和视频会议）以及会话参与者数量增加时变得更加重要。

17.2.2. Gathering and Connectivity Checks【收集和连接检查】

The process of gathering candidates and performing connectivity checks can be bandwidth intensive. ICE has been designed to pace both of these processes.
收集候选和执行连接检查的过程可能会占用大量带宽。 ICE 被设计用来加快这两个过程。

The gathering and connectivity-check phases are meant to generate traffic at roughly the same bandwidth as the data traffic itself will consume once the ICE process concludes.
收集和连接检查阶段用来生成与数据流量本身在 ICE 流程结束后消耗的带宽大致相同的流量。

This was done to ensure that if a network is designed to support communication traffic of a certain type (voice, video, or just text), it will have sufficient capacity to support the ICE checks for that data.
这样做是为了确保如果网络设计为支持某种类型的通信流量（语音、视频或仅文本），它将有足够的能力支持 ICE 检查该数据。

Once ICE has concluded, the subsequent ICE keepalives will later cause a marginal increase in the total bandwidth utilization; however, this will typically be an extremely small increase.
一旦 ICE 结束，后续的 ICE keepalives 将在稍后导致总带宽利用率的边际增加；但是，这通常是极小的增加。

Congestion due to the gathering and check phases has proven to be a problem in deployments that did not utilize pacing.
由于收集和检查阶段导致的拥塞已被证明是未使用调步的部署中的一个问题。

Typically, access links became congested as the endpoints flooded the network with checks as fast as they could send them.
通常情况下，当端点以最快的速度发送检查时，访问链路会变得拥塞。

Consequently, network operators need to ensure that their ICE implementations support the pacing feature.
因此，网络使用者需要确保他们的 ICE 实施支持起搏功能。

Though this pacing does increase call setup times, it makes ICE network friendly and easier to deploy.
尽管这种节奏确实增加了呼叫建立时间，但它使 ICE 网络友好且更易于部署。

17.2.3. Keepalives【保活】

STUN keepalives (in the form of STUN Binding Indications) are sent in the middle of a data session.
STUN 保活数据（以 STUN 绑定指示的形式）在数据会话的中间发送。

However, they are sent only in the absence of actual data traffic.
但是，它们仅在没有实际数据流量的情况下发送。

In deployments with continuous media and without utilizing Voice Activity Detection (VAD), or deployments where VAD is utilized together with short interval (max 1 second) comfort noise, the keepalives are never used and there is no increase in bandwidth usage.
在具有连续媒体且不使用语音活动检测 (VAD) 的部署中，或者在使用 VAD 和短间隔（最多 1 秒）舒适噪声的部署中，从不使用保活，并且不会增加带宽使用。

When VAD is being used without comfort noise, keepalives will be sent during silence periods.
当 VAD 在没有舒适噪音的情况下使用时，将在静音期间发送保活。

This involves a single packet every 15-20 seconds, far less than the packet every 20-30 ms that is sent when there is voice.
这涉及每 15-20 秒发送一个数据包，远远少于有语音时每 20-30 毫秒发送的数据包。

Therefore, keepalives do not have any real impact on capacity planning.
因此，保活数据对容量规划没有任何实际影响。

17.3. ICE and ICE-Lite【ICE 和 ICE-Lite】

Deployments utilizing a mix of ICE and ICE-lite interoperate with each other. They have been explicitly designed to do so.
混合使用 ICE 和 ICE-lite 的部署可以相互操作。它们被明确指出可以这么做。

However, ICE-lite can only be deployed in limited use cases. Those cases, and the caveats involved in doing so, are documented in Appendix A.
但是，ICE-lite 只能部署在有限的用例中。这些案例以及这样做所涉及的注意事项记录在 [附录 A]

17.4. Troubleshooting and Performance Management【故障排除和性能管理】

ICE utilizes end-to-end connectivity checks and places much of the processing in the endpoints.
ICE 利用端到端连接检查并将大部分处理放在端点中。

This introduces a challenge to the network operator – how can they troubleshoot ICE deployments? How can they know how ICE is performing?
这给网络操作员带来了挑战——他们如何对 ICE 部署进行故障排除？ 他们怎么知道 ICE 的性能如何？

ICE has built-in features to help deal with these problems.
ICE 具有帮助处理这些问题的内置功能。

Signaling servers, typically deployed in data centers of the network operator, will see the contents of the candidate exchanges that convey the ICE parameters.
信令服务器，通常部署在网络操作员的数据中心，将看到传达 ICE 参数的候选交换的内容。

These parameters include the type of each candidate (host, server reflexive, or relayed), along with their related addresses.
这些参数包括每个候选的类型（主机、服务器自反或中继），以及它们的相关地址。

Once ICE processing has completed, an updated candidate exchange takes place, signaling the selected address (and its type).
一旦 ICE 处理完成，就会发生更新的候选交换，通知所选地址（及其类型）。

This updated signaling is performed exactly for the purposes of educating network equipment (such as a diagnostic tool attached to a signaling) about the results of ICE processing.
执行此更新的信令的目的是让网络设备（例如附加到信令的诊断工具）了解 ICE 处理的结果。

As a consequence, through the logs generated by a signaling server, a network operator can observe what types of candidates are being used for each call and what addresses were selected by ICE.
因此，通过信令服务器生成的日志，网络操作员可以观察到每个呼叫使用了哪些类型的候选以及 ICE 选择了哪些地址。

This is the primary information that helps evaluate how ICE is performing.
这是有助于评估 ICE 性能现的主要信息。

17.5. Endpoint Configuration【端点配置】

ICE relies on several pieces of data being configured into the endpoints.
ICE 依赖于配置到端点中的几条数据。

This configuration data includes timers, credentials for TURN servers, and hostnames for STUN and TURN servers. ICE itself does not provide a mechanism for this configuration.
此配置数据包括计时器、TURN 服务器的凭据以及 STUN 和 TURN 服务器的主机名。 ICE 本身不提供这种配置的机制。

Instead, it is assumed that this information is attached to whatever mechanism is used to configure all of the other parameters in the endpoint.
相反，假定此信息附加到用于配置端点中所有其他参数的任何机制。

For SIP phones, standard solutions such as the configuration framework [RFC6080] have been defined.
对于 SIP 电话，已经定义了配置框架 [RFC6080] 等标准解决方案。