20. Operational Considerations (運用上の考慮事項)
このセクションでは、ICE の導入を検討しているネットワーク事業者に関連する問題について説明します。
20.1. NAT and Firewall Types (NAT およびファイアウォールの種類)
ICE は、既存の NAT およびファイアウォール機器と連携するように設計されています。したがって、ICE の導入を容易にするために、既存のファイアウォールや NAT 機器を交換または再構成する必要はありません。実際、ICE は、Voice over IP (VoIP) 事業者がファイアウォールや NAT を含む IP ネットワークインフラストラクチャを制御できない環境に導入するために開発されました。
とはいえ、ICE は、NAT デバイスが [RFC4787] および [RFC5766] で定義された推奨事項を満たす「behave」準拠である環境で最適に機能します。behave 準拠の NAT を備えたネットワークでは、ICE は TURN サーバーを必要とせずに機能するため、音声品質が向上し、通話セットアップ時間が短縮され、ネットワーク事業者の帯域幅需要が削減されます。
20.2. Bandwidth Requirements (帯域幅の要件)
ICE の導入は、事業者が考慮すべき利用可能なネットワーク容量といくつかの相互作用を持つ可能性があります。
20.2.1. STUN and TURN Server Capacity Planning (STUN および TURN サーバーの容量計画)
何よりもまず、ICE は TURN および STUN サーバーを使用します。これらは通常、ネットワーク事業者のデータセンターに配置されます。STUN サーバーは、比較的少ない帯域幅を必要とします。各メディアストリームの各コンポーネントについて、各クライアントから STUN サーバーへの 1 つ以上の STUN トランザクションが発生します。基本的な音声のみの IPv4 VoIP 導入では、通話ごとに 4 つのトランザクション（発信者と着信者の両方の RTP 用と RTCP 用）が発生します。各トランザクションは単一のリクエストと単一のレスポンスであり、前者は 20 バイト、後者は 28 バイトの長さです。したがって、システムに N 人のユーザーがいて、それぞれが最繁忙時に 4 回通話する場合、これには N*1.7bps が必要になります。100 万人のユーザーの場合、これは 1.7 Mbps であり、（比較的言えば）非常に小さな数値です。
TURN トラフィックはより実質的です。TURN サーバーは、実際のメディアトラフィックのトラフィックに加えて、STUN ボリュームに等しいトラフィックボリューム（実際、TURN サーバーが導入されている場合、別の STUN サーバーは必要ありません）を確認します。メディアリレーに TURN を必要とする通話の量は、ネットワークトポロジに大きく依存し、時間の経過とともに変化する可能性があります。100% behave 準拠の NAT を備えたネットワークでは、それは正確にゼロです。執筆時点では、大規模な消費者向け導入では、通話の 5〜10 パーセントが TURN サーバーを必要としていました。G.711 を使用した音声のみの導入（各方向 80 kbps）を考慮し、最繁忙時に 0.2 アーランの場合、これは N*3.2 kbps です。100 万人のユーザーの人口の場合、TURN サーバーの使用率を 10% と仮定すると、これは 3.2 Gbps です。
20.2.2. Gathering and Connectivity Checks (収集および接続チェック)
候補の収集と接続チェックの実行のプロセスは、帯域幅を大量に消費する可能性があります。ICE は、これら両方のプロセスのペースを調整するように設計されています。収集フェーズと接続チェックフェーズは、メディアトラフィック自体とほぼ同じ帯域幅でトラフィックを生成することを目的としています。これは、ネットワークが特定のタイプ（音声、ビデオ、またはテキストのみ）のマルチメディアトラフィックをサポートするように設計されている場合、そのメディアの ICE チェックをサポートするのに十分な容量があることを保証するために行われました。もちろん、ICE チェックは総使用率をわずかに増加させますが、これは通常、極めて小さな増加です。
収集およびチェックフェーズによる輻輳は、ペーシングを利用しなかった導入において問題であることが判明しています。通常、エンドポイントが送信できる限り速くチェックでネットワークを溢れさせると、アクセスリンクが輻輳しました。したがって、ネットワーク事業者は、ICE 実装がペーシング機能をサポートしていることを確認する必要があります。このペーシングは通話セットアップ時間を増加させますが、ICE をネットワークフレンドリーにし、導入を容易にします。
20.2.3. Keepalives (キープアライブ)
STUN キープアライブ（STUN Binding Indication の形式）は、メディアセッションの途中で送信されます。ただし、これらは実際のメディアトラフィックがない場合にのみ送信されます。音声アクティビティ検出 (VAD) を利用していない導入では、キープアライブは使用されず、帯域幅使用量は増加しません。VAD が使用されている場合、キープアライブは無音期間中に送信されます。これには 15〜20 秒ごとに単一のパケットが含まれますが、これは音声があるときに送信される 20〜30 ミリ秒ごとのパケットよりもはるかに少ないです。したがって、キープアライブは容量計画に実際の影響を与えません。
20.3. ICE and ICE-lite (ICE および ICE-lite)
ICE と ICE-lite を組み合わせて利用する導入は、完全に相互運用します。これらは、機能を失うことなくそうするように明示的に設計されています。
ただし、ICE-lite は限られたユースケースでのみ導入できます。これらのケースと、そうする際の注意事項は、付録 A に記載されています。
20.4. Troubleshooting and Performance Management (トラブルシューティングおよびパフォーマンス管理)
ICE はエンドツーエンドの接続チェックを利用し、処理の多くをエンドポイントに配置します。これはネットワーク事業者に課題をもたらします。ICE の導入をどのようにトラブルシューティングできるでしょうか？ ICE がどのように機能しているかをどのように知ることができるでしょうか？
ICE には、これらの問題に対処するのに役立つ組み込み機能があります。シグナリングパス上の SIP サーバー（通常はネットワーク事業者のデータセンターに配置されます）は、ICE パラメータを伝達するオファー/アンサー交換の内容を確認します。これらのパラメータには、各候補のタイプ（ホスト、サーバー反射、またはリレー）と、それに関連するアドレスが含まれます。ICE 処理が完了すると、更新されたオファー/アンサー交換が行われ、選択されたアドレス（およびそのタイプ）が通知されます。この更新された re-INVITE は、まさに ICE 処理の結果についてネットワーク機器（SIP サーバーに接続された診断ツールなど）を教育する目的で実行されます。
その結果、SIP サーバーによって生成されたログを通じて、ネットワーク事業者は各通話に使用されている候補のタイプと、ICE によって選択されたアドレスを観察できます。これは、ICE のパフォーマンスを評価するのに役立つ主要な情報です。
20.5. Endpoint Configuration (エンドポイント設定)
ICE は、エンドポイントに設定されるいくつかのデータに依存しています。この設定データには、タイマー、TURN サーバーの資格情報、STUN および TURN サーバーのホスト名が含まれます。ICE 自体は、この設定のメカニズムを提供しません。代わりに、この情報は、エンドポイント内の他のすべてのパラメータを設定するために使用されるメカニズムに付随していると想定されます。SIP 電話の場合、構成フレームワーク [SIP-UA-FRMWK] などの標準ソリューションが定義されています。