Cisco Unified Contact Center Enterprise ソリューション リファレンス ネットワーク デザイン （SRND）

ネットワーク セグメント

Unified CCE で採用されているフォールト トレラント アーキテクチャには、2 つの独立した通信ネットワークが必要です。プライベート ネットワーク（分離されたパスを使用）では、システム間の同期を維持および復元し、Message Delivery Subsystem（MDS; メッセージ送信サブシステム）のクライアントが通信できるようにするために必要なトラフィックが送信されます。パブリック ネットワークでは、同期されたシステムの各サイドと外部システムの間のトラフィックが送信されます。またパブリック ネットワークは、フォールト トレランス ソフトウェアでノードの障害とネットワークの障害を切り分けるための代替パスとして使用されます。

（注） このマニュアルではパブリック ネットワークとビジブル ネットワークの 2 つの用語を同じ意味で使用しています。

3 番目のネットワークであるシグナリング アクセス ネットワークは、Unified ICM システムに展開され、キャリア ネットワーク（PSTN）とも直接通信し、ホステッド Unified ICM/Unified CCE アーキテクチャを構成します。この章では、シグナリング アクセス ネットワークについては説明しません。

図 12-1 に、二重化構成の PG と、（サイド A とサイド B が地理的に離れている）二重化構成のセントラル コントローラで構成される基本的な Unified CCE システムのネットワーク セグメントを示します。

図 12-1 Unified CCE システムのパブリックおよびプライベート ネットワーク セグメントの例

図 12-1 には、次の注が適用されます。

• プライベート ネットワークでは、セントラル コントローラまたは PG ペアの二重化サイド間の Unified ICM トラフィックが送信される。このトラフィックは主に、同期データと制御メッセージで構成されています。またこのトラフィックでは、分離された状態から回復するときに二重化サイドを再同期するために必要となる状態転送も送信されます。WAN を介して展開された場合は、Cisco Unified ICM 全体のレスポンスにおいてプライベート ネットワークがクリティカルな要素となります。これは積極的な遅延要件を満たす必要があるため、プライベート ネットワーク リンクで IP ベースのプライオリティ キューイングまたは QoS を使用する必要があります。

• パブリック ネットワークでは、セントラル コントローラとコール センター（PG および AW）の間のトラフィックが送信される。パブリック ネットワークは、セントラル コントローラの 2 つのサイドが相互に分離した場合にどちらのサイドの優位を守るかを判断するために使用されるセントラル コントローラの代替パスの役割を果たすこともできます。パブリック ネットワークを使用して同期制御トラフィックが送信されることはありません。また、パブリック ネットワーク WAN リンクには、コール センターで PG および AW をサポートするための適切な帯域幅がある必要があります。パブリック ネットワークの IP ルータでは、IP ベースのプライオリティ キューイングまたは QoS を使用して、Unified ICM トラフィック クラスが遅延およびジッタの許容範囲内で処理されるようにする必要があります。

• セントラル コントローラの 1 つのサイドに対してローカルなコール センター（PG と AW）は、パブリック イーサネットを介してローカル セントラル コントローラ サイドに接続され、パブリック WAN リンクを介してリモート セントラル コントローラ サイドに接続される。この配置では、パブリック WAN ネットワークによってサイド A とサイド B が接続される必要があります。オプションとして、ブリッジを展開して PG と AW をセントラル コントローラ LAN セグメントから分離し、LAN 停止からの保護を強化することもできます。

• 必要な耐障害性を実現するには、プライベート WAN リンクがパブリック WAN リンクから完全に独立している必要があります（別々の IP ルータ、ネットワーク セグメントまたはパスなど）。独立した WAN リンクによって、パブリックおよびプライベート ネットワーク間でシングル ポイント障害が完全に分離されます。また、PG から CC（セントラル コントローラ）へのルート多様性をネットワーク全体で維持できるように、ネットワークを横断するパブリック ネットワーク WAN セグメントを展開する必要があります。PG から CC への複数のセッションで共通のパスが選択されないようにルーティングを設定してください（共通のパスが選択されると、そこが共通の障害ポイントになります）（図 12-1 を参照）。

IP ベースの優先順位付けおよび QoS

図 12-1 の WAN リンクごとに、優先順位を付ける仕組みが必要です。優先順位を付ける仕組みは、IP ベースの優先順位付けと QoS の 2 つがサポートされています。トラフィックの優先順位付けが必要となるのは、大量の低優先順位トラフィックが高優先順位トラフィックの前に来て、受信側への高優先順位パケットの配信の遅延が発生する可能性があるためです。低速ネットワーク フローでは、ネットワークで単一の大きな（たとえば、1500 バイト）パケットにかかる時間（およびこのパケットによる後続パケットの遅延）が、100 ミリ秒を超える場合があります。この遅延によって、1 つ以上のハートビートが確実に失われます。この状況を回避するには、低優先順位トラフィックのアプリケーションでより小さい Maximum Transmission Unit（MTU; 最大伝送ユニット）サイズを使用して、高優先順位パケットが先に送信されるようにします（回線の MTU サイズは、回線帯域幅の機能として、PG のセットアップ時に設定されたとおりにアプリケーション内から計算されます）。

適切に優先順位付けされていないネットワークでは、通常、アプリケーションの負荷が増加したとき、または（より悪い場合）ネットワークに共有トラフィックが配置されたときに、ハートビートの損失による問題およびコールのタイムアウトが発生します。よく見られる第 2 の影響は、極端な遅延状態による送信サイドのアプリケーション バッファ プールの枯渇です。

Unified ICM アプリケーションでは、高、中、低の 3 つの優先順位が使用されます。ただし、QoS が実装されるよりも前のネットワークでは、発信元および宛先 IP アドレス（UDP ハートビートの場合はネットワークの UDP ポート範囲）で識別される 2 つの優先順位だけが効果的に認識されていました（高優先順位トラフィックは別個の IP 宛先アドレスに送信されていました）。IP ベースの優先順位付けを使用したアプローチでは、高優先順位 IP アドレスの TCP パケットと UDP ハートビートをその他のトラフィックより優先するように、プライオリティ キューイングを使用した IP ルータを構成します。この優先順位付けの仕組みを使用する場合は、使用可能な全帯域幅の 90% を高優先度キューに割り当てる必要があります。

QoS に対応したネットワークでは、IP アドレスではなく QoS のマーキングに基づいて、パケットに優先順位が付けられた処理（キューイング、スケジューリング、およびポリシー設定）が適用されます。Unified ICM Release 7. x には、プライベートおよびパブリック ネットワーク トラフィックに対するレイヤ 3 DSCP およびレイヤ 2 802.1p（Microsoft Windows Packet Scheduler を使用）のマーキング機能があります。ネットワークが QoS に対応している場合、Unified ICM のトラフィックのマーキングは、各 Network Interface Controller（NIC; ネットワーク インターフェイス コントローラ）で複数の IP アドレスを設定する必要がなくなることを意味します。ただし、代わりにトラフィックがネットワーク エッジでマーキングされる場合は、IP アドレスに基づいたアクセス コントロール リストを使用してパケットを区別するために、複数の IP アドレスを設定する必要があります。詳細は、「トラフィックをマーキングする場所」を参照してください。

UDP ハートビートおよび TCP キープアライブ

UDP ハートビート設計の主な目的は、回線に障害が発生したかどうかを検出することです。検出はハートビート損失の方向に基づき、接続のいずれかの端から行われます。接続の両端では、他方の端に定期的に（通常、100 または 400 ミリ秒ごと）ハートビートが送信され、各端は他方からの類似したハートビートを探します。いずれかの端が 5 回連続してハートビートを受信しなかった場合（つまり、ハートビート間隔の 5 倍の時間、ハートビートを受信しなかった場合）、この状態を検出したサイドでは問題が発生したものと判断され、アプリケーションによってソケット接続が閉じられます。この時点で、通常、閉じたサイドから TCP リセット メッセージが生成されます。ハートビートの損失は、次のようなさまざまな理由によって発生します。ネットワーク障害、ハートビートを送信するプロセスの障害、送信プロセスが常駐するマシンのシャットダウン、UDP パケットが適切に優先順位付けされていないなどです。

ハートビートには、複数のパラメータが関連付けられています。通常、これらのパラメータはシステムのデフォルト値に設定しておきます。これらの値の一部は接続が確立されたときに指定されます。その他の値は、Microsoft Windows 2000 レジストリの値を設定することにより指定できます。最も重要な値は、次の 2 つです。

• ハートビートの間隔の長さ

• 回線に障害が発生しているかどうかを判断するためにシステムで使用される受信されなかったハートビートの数（現在、5 としてハードコードされている）

二重化サイド間のハートビートの間隔のデフォルト値は 100 ミリ秒です。つまり、1 つのサイドでは、500 ミリ秒以内に回線または他のサイドの障害を検出できます。Unified ICM Release 5.0 よりも前では、セントラル サイトとペリフェラル ゲートウェイの間のデフォルト ハートビート間隔は 400 ミリ秒でした。つまり、この場合、回線障害のしきい値は 2 秒です。

Unified ICM Release 5.0 および 6.0 では、Unified ICM QoS 実装の一部として、セントラル コントローラをペリフェラル ゲートウェイに接続するパブリック ネットワークの UDP ハートビートが TCP キープアライブ メッセージに置き換えられます（例外として、Unified ICM Release 5.0 または 6.0 のセントラル コントローラが Release 5.0 よりも前の PG と通話する場合には、通信は自動的に UDP メカニズムにもどります）。二重化されたサイトを接続するプライベート ネットワークでは、UDP ハートビートは変更されないままとなります。

Unified ICM Release 7. x では、一貫したハートビートまたはキープアライブ メカニズムがパブリックおよびプライベート ネットワーク インターフェイスの両方に適用されます。QoS がネットワーク インターフェイスでイネーブルになっている場合は TCP キープアライブ メッセージが送信され、イネーブルになっていない場合は UDP ハートビートが保持されます。

TCP スタックにある TCP キープアライブ機能によって稼動上の問題点が検出された場合は、サーバ/クライアント サイドが終了します。TCP キープアライブ機能は、接続が一定期間アイドル状態になった後、その接続を介してプローブ パケット（つまり、キープアライブ パケット）を送信することによって動作します。他方のサイドからのキープアライブ応答がない場合、その接続は停止していると見なされます。Microsoft Windows 2000/2003 を使用すると、接続ごとにキープアライブ パラメータを指定できます。Unified ICM パブリック接続の場合は、キープアライブ タイムアウトが 5 × 400 ミリ秒に設定されています。つまり、Release 5.0 よりも前の UDP ハートビートの場合と同様に、障害が 2 秒後に検出されます。

QoS がイネーブルな TCP キープアライブに移行した理由は、次のとおりです。

• 音声・データ統合ネットワークでは、ルータでネットワークの輻輳状態を処理するために使用されるアルゴリズムによって、TCP および UDP に異なる影響が与えられます。これにより UDP ハートビート トラフィックに発生した遅延および輻輳は、TCP 接続にはあまり影響しない場合があります。

• UDP ハートビートを使用すると、ファイアウォール環境での展開が複雑になる。ハートビート通信のダイナミック ポート割り当てによって、広範囲なポート番号を開く必要があり、ファイアウォール デバイスの本来の目的が満たされません。

HSRP-Enabled ネットワーク

Unified CCE サーバで設定されるデフォルト ゲートウェイで Hot Standby Router Protocol（HSRP; ホットスタンバイ ルータ プロトコル）が展開されるネットワークでは、次の推奨事項に従ってください。

• HSRP アクティブ ルータの切り替えの間に ICM プライベート ネットワーク通信を停止させないために、HSRP の保持時間（関連する処理遅延を含む）をハートビート間隔（プライベート ネットワークで 100 ミリ秒、パブリック ネットワークで 400 ミリ秒）の 5 倍未満に設定します。

（注） 収束遅延がプライベートまたはパブリック ネットワークの停止通知の設定値を上回る場合、HSRP のフェールオーバーに必要な時間がネットワーク停止を検出するしきい値を超える可能性があるため、企業システムでは障害およびリカバリの段階を完了する必要があります。HSRP 設定でプライマリとセカンダリの指定が行われているときに、プライマリ パスのルータがセカンダリ サイドにフェールオーバーした場合、HSRP は可能であればその後プライマリ パスを回復します。これにより、2 番目のプライベート ネットワーク停止の検出が可能になります。

したがって、HSRP の収束遅延をプライベート ネットワークで約 500 ミリ秒、パブリック ネットワークで約 2 秒に設定しないことをお勧めします。プライマリとセカンダリの指定で前述のように最初のパスを回復することができません。一方、停止を検出するしきい値未満に設定された収束遅延（HSRP のフェールオーバーはアプリケーションに対して透過的に行われる）では、優先パスの設定は必要ありません。この方法が推奨されます。パスの値とコストが同じであれば、イネーブルにされたルータを対称的に維持することをお勧めします。ただし、使用可能な帯域幅とコストの点から 1 つのパスの優先順位を高くする（およびパスの移行を透過的に行う）場合は、プライマリ パスとルータを指定することをお勧めします。

• ICM の耐障害性設計では、プライベート ネットワークをパブリック ネットワークから物理的に分離する必要があるため、HSRP でプライベート ネットワーク トラフィックとパブリック ネットワーク リンク間にフェールオーバーを設定しないでください。

• ICM の帯域幅要件は HSRP で常に保証される必要があります。そうしないと、システムの予期しない動作が発生することがあります。たとえば、HSRP がもともと負荷分散を実行するように設定されている場合は、障害のワーストケースの状況で存続するリンクの ICM に十分な帯域幅がある必要があります。

RSVP

Cisco Unified Communications Manager（Unified CM） 5.0 では、クラスタ内のエンドポイント間で Resource Reservation Protocol（RSVP; リソース予約プロトコル）がサポートされるようになりました。Call Admission Control（CAC; コール アドミッション制御）のためのプロトコルである RSVP が、コールの帯域幅予約のためにネットワーク内のルータで使用されます。

RSVP の採用前は、帯域幅の使用状況を計算するため、地点間のアクティブ コールの数を各 Unified CM クラスタがローカルで保持している必要がありました。2 つ以上の Unified CM クラスタで同じリンクが共有された場合、各クラスタに専用の帯域幅が必要になるため、この方法では帯域幅の使用が非効率的でした。

RSVP は、電話と同じ LAN 上にある 2 つの RSVP エージェント間のパスを追跡することで、この問題を解決します。RSVP エージェントは、Cisco IOS ルータで実行されるソフトウェア Media Termination Point（MTP; メディア ターミネーション ポイント）です。RSVP エージェントは Unified CM で制御され、コールの発信時に、2 台の電話間のメディア ストリーム内に挿入されます。発信電話の RSVP エージェントが宛先の電話の RSVP エージェントへのネットワークを確認し、帯域幅を予約します。Unified CM に代わってネットワーク ルータが帯域幅の使用状況を追跡するため、コールが複数の Unified CM で制御される場合でも、RSVP で制御される単一のリンクを複数のコールで共有できます。

図 12-2 は、2 つの Unified CM クラスタが、同一リモート サイト上の電話にサービスを提供するシナリオを示しています。IP コール センターの処理が Unified CM クラスタに割り当てられている場合に、このような状況が発生します。このシナリオでは、同じ事務所内の 2 人のユーザが別々のクラスタからサービスを受けています。RSVP により、帯域幅計算の負担が Unified CM からネットワーク ルータに移行します。

図 12-2 異なる Unified CM クラスタの例

Unified CM RSVP の詳細については、次の URL にある『 Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 』を参照してください。 http://www.cisco.com/go/designzone

トラフィック フロー

この項では、パブリックおよびプライベート ネットワークのトラフィック フローについて簡単に説明します。

パブリック ネットワークのトラフィック フロー

アクティブ PG では、各コール センター サイトのエージェント、コール、キューなどに関連した状態情報によりセントラル コントローラの Call Router が継続的に更新されます。このタイプの PG からセントラル コントローラへのトラフィックは、リアルタイム トラフィックです。また、PG では、30 分ごとに 30 分間の履歴データが送信されます。履歴データは低優先順位ですが、30 分以内にセントラル サイトに送信される必要があります（次の 30 分間のデータに備えるため）。

PG が開始されると、セントラル サイトから設定データが提供され、PG で監視する必要があるエージェント、トランクなどが認識されます。この設定のダウンロードによって、ネットワーク帯域幅が一時的に非常に大きくなる場合があります。

要約すると、PG からセントラル コントローラへのトラフィック フローは次の各フローに分類されます。

• 高優先順位トラフィック：ルーティングおよび Device Management Protocol（DMP; デバイス管理プロトコル）制御トラフィックが含まれます。パブリック高優先順位 IP アドレスを使用して TCP で送信されます。

• ハートビート トラフィック：パブリック高優先順位 IP アドレスの UDP メッセージで、ポート範囲は 39500 ～ 39999 です。ハートビートは、PG とセントラル コントローラ間で 400 ミリ秒間隔で双方向に送信されます。Unified ICM Release 7. x では、QoS が Unified ICM 設定を通じてパブリック ネットワーク インターフェイスでイネーブルになっている場合、UDP ハートビートが TCP キープアライブに置き換えられます。

• 中優先順位トラフィック：PG からセントラル コントローラへのリアルタイム トラフィックおよび設定要求が含まれます。中優先順位トラフィックは、パブリック高優先順位 IP アドレスを使用して TCP で送信されます。

• 低優先順位トラフィック：履歴データ トラフィック、セントラル コントローラからの設定トラフィック、およびコール クローズ通知が含まれます。低優先順位トラフィックは、高優先順位以外のパブリック IP アドレスを使用して TCP で送信されます。

アドミン ワークステーション（AW）は、通常、ACD サイトに展開され、PG で使用される物理 WAN/LAN 回線を共有します。この場合、AW のネットワーク アクティビティをネットワーク帯域幅計算に組み込む必要があります。このマニュアルでは、AW トラフィックの帯域幅サイズについては説明しません。

プライベート ネットワークのトラフィック フロー

重要な Message Delivery Service（MDS）クライアント（Router または OPC）に対するトラフィックは、プライベート リンクを経由して他方のサイドに送信されます。

次に、プライベート トラフィックの要約を示します。

• 高優先順位トラフィック：ルーティング、MDS 制御トラフィック、およびその他 PIM CTI サーバ、Logger などのプロセスからのトラフィックが含まれます。プライベート高優先順位 IP アドレスを使用して TCP で送信されます。

• ハートビート トラフィック：プライベート高優先順位 IP アドレスの UDP メッセージで、ポート範囲は 39500 ～ 39999 です。ハートビートは、二重化されたサイド間で 100 ミリ秒間隔で双方向に送信されます。Unified ICM Release 7. x では、QoS が Unified ICM 設定を通じてプライベート ネットワーク インターフェイスでイネーブルになっている場合、UDP ハートビートが TCP キープアライブに置き換えられます。

• 中優先順位および低優先順位トラフィック：セントラル コントローラの場合、このトラフィックには、ルーティング クライアントから供給される共有データに加え、Call Router 状態転送（独立したセッション）などの（ルート制御以外の）Call Router メッセージが含まれます。OPC（PG）の場合、このトラフィックには、ルート制御以外の共有のペリフェラル トラフィックおよびレポーティング トラフィックが含まれます。このクラスのトラフィックは、中優先順位および低優先順位として指定されている TCP セッション内で、それぞれプライベート高優先順位以外の IP アドレスを使用して送信されます。

• 状態転送トラフィック：Router、OPC、およびその他の同期プロセスの状態同期メッセージ。プライベート高優先順位以外の IP アドレスを使用して TCP で送信されます。

トラフィックをマーキングする場所

QoS の計画では、Unified ICM またはネットワーク エッジのいずれでトラフィックにマーキングするかについて不明であることがよくあります。各オプションには長所と短所があります。Unified ICM でトラフィックをマーキングすると、IP ルータとスイッチでトラフィックを分類するアクセス リストが節約されます。また、Microsoft Windows Packet Scheduler を展開すると、Unified ICM ではトラフィック シェーピングと 802.1p マーキングがサポートされます。トラフィック シェーピング機能によって指定された期間の送信ピークがなだらかになり、ネットワークの使用状況がなだらかになるため、Unified ICM 送信のバースト性が軽減されます。LAN QoS 処理メカニズムである 802.1p 機能を使用すると、レイヤ 2 ネットワーク セグメントが輻輳しても低優先順位パケットよりも先に高優先順位のパケットがネットワークに入ります。

（注） シスコでは、帯域幅の要件が明確に理解され、正しく設定されている場合、およびコンバージド ネットワーク リンクで輻輳が時折発生し、発信元における ICM トラフィックのシェーピングが役に立つ場合を除き、Microsoft Packet Scheduler for Unified ICM 7.x は実装しないことを推奨しています。

Microsoft Packet Scheduler を使用するとシェーピング機能と 802.1p 機能を利用できますが、Unified ICM 7. x とともに使用する場合、次のような重大なリスクがあります。

• いくつかの欠陥が Microsoft に報告されています。現時点で一部の修正プログラムは Microsoft からリリースされていますが、修正プログラムがまだリリースされていないものもあります。

• シェーピング帯域幅の設定が低すぎる場合、Packet Scheduler により過度の遅延が発生し、タイムアウト コール、キューのオーバーフロー、およびバッファの消耗の原因になることがあります。

• WAN との通信で LAN がボトルネックになっていなければ、Unified ICM サーバにおけるシェーピングは必要ないか、効果がありません。QoS 対応のネットワークの方が、リソースの使用率に基づいたトラフィックのシェーピング、キューイング、およびポリシー設定でより多くの効果を発揮します。

Unified ICM でのトラフィックのマーキングにはいくつかの短所があります。まず、変更しにくい点です。たとえば、パブリック ネットワークのトラフィックのマーキング値を変更する場合、すべての PG で変更を行う必要があります。システムに PG が 30 個以上ある場合、このような変更をすべて行うにはかなり多くの作業が必要です。2 つ目に、QoS 信頼をアクセスレイヤのルータとスイッチでイネーブルにする必要があり、これによってマーキング レベルが不正に設定された悪意のあるパケットによる攻撃にネットワークがさらされる危険性があります。

一方、ネットワーク エッジでトラフィックをマーキングすると、セキュリティが管理された中央集中型のマーキング ポリシー マネジメントを行うことができ、アクセスレイヤのデバイスで信頼をイネーブルにする必要がありません。わずかなオーバーヘッドとして、Unified ICM パケットを認識するためのアクセス リストを定義する必要があります。エッジ ルータまたはスイッチにおけるアクセス リストの定義基準については、 表 12-2 、 表 12-3 、および 表 12-4 を参照してください。Unified ICM トラフィックを認識するためにアクセス リストでポート番号を使用しないでください（各表のポート番号は参照目的です）。これは、ポート番号を使用するとアクセス リストが非常に複雑になるうえ、システムに新しい顧客インスタンスが追加されるたびにアクセス リストを修正する必要があります。

（注） 一般的な Unified ICM の展開では各 NIC で 3 つの IP アドレスを設定し、そのうち 2 つが Unified ICM アプリケーションで使用されます。PCAnywhere または VNC を使用してリモート モニタリングを行う場合、アクセス リストでポート番号は使用されないため、リモート モニタリング トラフィックがリアル Unified ICM トラフィックとしてマークされないように 3 つ目の IP アドレスを使用する必要があります。

トラフィックをマーキングする方法

Unified ICM QoS のデフォルト マーキングは、シスコ ユニファイド コミュニケーションの推奨事項に準拠するように設定されています（必要であれば、設定を上書きできます）。 表 12-2 、 表 12-3 、および 表 12-4 に、パブリックおよびプライベート ネットワークの各優先順位フローに関連付けられているデフォルト マーキング、遅延要件、IP アドレス、およびポート番号を示します。ここで、 i# は顧客インスタンス番号を表します。パブリック ネットワークでは、中優先順位トラフィックは高優先順位トラフィックと同じように高優先順位のパブリック IP アドレスで送信されてマーキングされます。一方、プライベート ネットワークでは、中優先順位トラフィックは低優先順位トラフィックと同じように高ではないプライベート IP アドレスで送信されてマーキングされます。

シスコ ユニファイド コミュニケーション パケットの分類の詳細については、次の URL にある『 Cisco Unified Communications Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/go/designzone

（注） シスコでは、音声制御プロトコルのマーキングを DSCP 26（PHB AF31）から DSCP 24（PHB CS3）に変更し始めています。ただし、多くの製品では、シグナリング トラフィックが DSCP 26（PHB AF31）としてマーキングされています。このため、シスコでは、コール シグナリングに対して暫定的に AF31 と CS3 の両方を予約しておくことをお勧めします。

QoS の設定

この項では、Unified CCE システムの各種デバイスに対する QoS のいくつかの設定例について説明します。

Unified ICM ルータと PG での QoS の設定

マーキングを Unified ICM で行い、マーキングをネットワークで信頼する場合だけ、Unified ICM ルータと PG で QoS の設定が必要です。詳細については、次の URL にある『 Installation Guide for Cisco ICM/IPCC Enterprise & Hosted Editions 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1001/prod_installation_guides_list.html

Cisco IOS デバイスでの QoS の設定

この項では、QoS の典型的な設定例について説明します。キャンパス ネットワーク設計、スイッチ選択、および QoS の設定コマンドの詳細については、次の URL にある『 Enterprise QoS Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/go/designzone

（注） このマニュアルではパブリック ネットワークとビジブル ネットワークの 2 つの用語を同じ意味で使用しています。

（注） 次の例にあるマーキング値、帯域幅データ、およびキューイング ポリシーは説明目的だけに使用されています。どのような環境下でも実際に使用しているシステムに対応する変更を行わずに、これらの例をコピー アンド ペーストできません。

IP スイッチでの 802.1q トランクの設定

802.1p が対象となる機能であり、ビジブル ネットワークの NIC で 802.1p タギングがイネーブルになっている場合は、次の設定例で示されているように、Unified ICM サーバが接続されるスイッチ ポートを 802.1q トランクとして設定する必要があります。

QoS 信頼の設定

Unified ICM DSCP マーキングが信頼されている場合は、次のコマンドによって IP スイッチ ポートの信頼が有効になります。

マーキングされたトラフィックで動作するためのキューイング ポリシーの設定

パブリック（ビジブル）ネットワークの例を示します。次のクラス マップは、高優先順位トラフィック（実際には中優先順位のパブリック ネットワーク トラフィックも含まれます。このトラフィックはデフォルトでは高優先順位トラフィックと同じようにマークされるためです）用の AF31 と低優先順位トラフィック用の AF11 の 2 つのマーキング レベルを識別します。

リンクが Unified ICM パブリック トラフィック専用とされている場合は、ポリシー マップを使用してキューイング ポリシーを定義します。このポリシーによって ICM_Public_High トラフィックはプライオリティ キューに入り、最小および最大帯域幅 500 kbps が保証されます。また、このポリシーによって ICM_Public_Low トラフィックは標準のキューに入り、最小帯域幅 250 kbps が保証されます。

また、 priority percent コマンドと bandwidth percent コマンドを使用して、帯域幅をパーセンテージで割り当てることもできます。この場合、リンク帯域幅の 90% をプライオリティ キューに割り当てる必要があります。

共有リンクの場合は、「帯域幅のプロビジョニング」で説明したサイジング ツールを使用し、優先順位のレベルごとに帯域幅要件を計算して、これを同じキューの ICM 以外のトラフィック用の割り当てに追加します。たとえば、リンクが Unified CM ICCS トラフィックと RTP トラフィックで共有され、それぞれのトラフィックに 600 kbps と 400 kbps が必要な場合、およびリンクにはフェールオーバー時にプライベート トラフィックも流れ、高優先順位と低優先順位のプライベート ICM トラフィックにそれぞれ 200 kbps と 100 kbps が必要な場合、次のような設定になります。

また、 priority percent コマンドと bandwidth percent コマンドを使用して、帯域幅をパーセンテージで割り当てることもできます。リンクが Unified ICM トラフィック専用にされている場合は、リンク帯域幅の 90% をプライオリティ キューに割り当てる必要があります。共有リンクの場合は、「帯域幅のプロビジョニング」で説明したサイジング ツールを使用し、優先順位のレベルごとに帯域幅要件を計算して、これを同じキューの ICM 以外のトラフィック用の割り当てに追加します。

最後に、キューイング ポリシーが発信インターフェイスに適用されます。

トラフィックをマーキングするためのマーキング ポリシーの設定

前述のとおり、Unified ICM でトラフィックをマーキングするのではなく、トラフィックをネットワーク エッジでマーキングする方法もあります。最初に、Unified ICM トラフィック フローを認識するためのアクセス リストを定義します。

次に、クラス マップを使用してトラフィックを分類します。

次に、ポリシー マップを使用してマーキング ポリシーを定義します。

最後に、マーキング ポリシーを着信インターフェイスに適用します。

QoS パフォーマンス モニタリング

QoS に対応したプロセスが起動し、実行されると、Microsoft Windows Performance Monitor（PerfMon）を使用して、基礎となるリンクに関連付けられているパフォーマンスを追跡できます。これを行うために PerfMon を使用する方法の詳細については、次の URL にある『 ICM Administration Guide for Cisco ICM Enterprise Edition 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1001/prod_maintenance_guides_list.html

Unified CCE パブリックおよびプライベート ネットワークの帯域幅の要件

この項では、パブリック（ビジブル）およびプライベート ネットワークの帯域幅のサイジングについて簡単に説明します。

パブリック ネットワークの帯域幅

専用のツールを使用して、次のパブリック ネットワーク リンクに必要な帯域幅を計算できます。

Unified ICM セントラル コントローラと Unified CM PG 間の通信

シスコ パートナーおよびシスコの従業員が ICM セントラル コントローラと Unified CM の間に必要な帯域幅を計算する場合は、ツールを利用できます。このツールは ACD/CallManager ペリフェラル ゲートウェイから ICM セントラル コントローラの帯域幅カルキュレータ と呼ばれます。このツールは、次の URL から Cisco Steps to Success Portal を通じて入手できます（適切なログイン認証が必要）。

http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100897

Unified ICM セントラル コントローラから Unified IP IVR または Unified CVP PG へのリンク

シスコ パートナーおよびシスコの従業員が ICM セントラル コントローラと IP IVR PG の間に必要な帯域幅を計算する場合は、ツールを利用できます。このツールは VRU ペリフェラルゲートウェイから ICM コントローラの帯域幅カルキュレータ と呼ばれます。このツールは、次の URL から Cisco Steps to Success Portal を通じて入手できます（適切なログイン認証が必要）。

http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100901

現在のところ Unified ICM セントラル コントローラと Cisco Unified Customer Voice Portal（Unified CVP）PG の通信に対応するツールは提供されていません。ただし、試験結果によると、Unified ICM セントラル コントローラと Unified IP IVR PG の間に必要な帯域幅を計算するツールで 1 つのフィールドの値を置き換えることによって、Unified CVP の場合に対しても正確な計算値が得られることが示されています。

[Average number of RUN VRU script nodes] フィールドを、Unified CVP と対話する Unified ICM スクリプトのノード数に置き換えて値を代入します。

プライベート ネットワークの帯域幅

表 12-5 は、プライベート ネットワークのリンク サイズとキュー サイズの計算に便利なワークシートです。この表に続いて、定義と例を示します。

（注） どの場合でも、リンクの最小サイズは 1.5Mbps（T1）です。

プライベート通信に使用するサイト間で専用リンクを 1 つ使用している場合は、すべてのリンク サイズを合算し、 表 12-5 の最下行にある合計リンク サイズに記入して要件として使用します。Router/Logger プライベートに 1 つのリンク、PG プライベートに 1 つのリンクを使用した独立リンクの場合は、最初の行を Router/Logger の要件に使用し、その下の 4 行のうち 3 行の値を合算して PG プライベートの要件に使用します。

WAN を介して分割されている類似のコンポーネントすべてに対する実効 BHCA（実効負荷）は、次のように定義されます。

• Router + Logger

この値はコール センターに対する BHCA の合計で、会議と転送も含まれます。たとえば、着信数が 10,000 BHCA で、これに 10 % の会議または転送を加味すると、実効 BHCA は 11,000 になります。

• Unified CM PG

この値には、Unified CM で制御されている Unified ICM ルート ポイントを通じて着信するすべてのコール、および最終的にエージェントに転送されるすべてのコールが含まれます。これは、各コールがルート ポイントに着信し、最終的にエージェントに送信されることを前提としています。たとえば、ルート ポイントに着信してエージェントに転送される着信コールが 10,000 BHCA で、これに 10 % の会議または転送を加味すると、実効 BHCA は 11,000 になります。

• Unified IP IVR PG

この値は、コール処理とキューイングに対する BHCA の合計です。たとえば、着信コールが 10,000 BHCA で、これらすべてが処理され、うち 40 % がキューイングされると、実効 BHCA は 14,000 になります。

• Unified CVP PG

この値は、Unified CVP 経由の着信に対するコール処理とキューイングの BHCA の合計です。計算では、すべてのコールが処理されることを前提としています。たとえば、着信コールが 10,000 BHCA で、これらすべてが処理され、うち 40 % がキューイングされると、実効 BHCA は 14,000 になります。

• Unified IP IVR 変数または Unified CVP 変数

この値は、Unified IP IVR または Unified CVP のうち実装に使用されているテクノロジーを通じてルーティングされるすべてのコールに関連するコール変数と ECC 変数の数、および変数長を示しています。

プライベート帯域幅の計算例

表 12-6 は、次の特性を持つ、組み合せた専用プライベート リンクの計算例を示しています。

• コンタクト センターに着信するコールの BHCA は 10,000 です。

• コールの 100 % が Unified IP IVR で処理され、うち 40 % がキューイングされます。

• コールは放棄されない限り、すべてエージェントに送信されます。エージェントへのコールのうち、10 % は転送または会議です。

• コールを処理およびキューイングする Unified IP IVR は 4 つで、これらは 1 つの PG ペアでサポートされています。

• 合計 900 名のエージェントに対して 1 ペアの Unified CM PG が設置されています。

• コールには、40 バイトのコール変数が 10 個と、40 バイトの ECC 変数が 10 個あります。

この例にある組み合わせた専用プライベート リンクの計算結果は次のとおりです。

• 合計リンク = 2,550,000bps

• Router と Logger の高優先度帯域幅キュー = 264,000 bps

• PG の高優先度帯域幅キュー = 1,998,000 bps

Router/Logger プライベートと PG プライベートに独立した 2 つのリンクでこの例を実装すると、リンク サイズとキューは次のようになります。

• Router/Logger リンクは 330,000 bps で（前述のとおり、実際の最小リンクは 1.5 MB）、高優先度帯域幅キューは 264,000 bps です。

• PG リンクは 2,220,000 bps で、高優先順位帯域幅キューは 1,998,000 bps です。

WAN 経由の Unified CCE クラスタリングに対する帯域幅の要件

WAN 経由の Unified CCE クラスタリングの詳細については、「IPT：WAN 経由のクラスタリング」を参照してください。

すべての Unified ICM プライベート通信、パブリック通信、CTI 通信、および Cisco Unified CM のイントラクラスタ コミュニケーション シグナリング（ICCS）で使用される帯域幅を、ハイ アベイラビリティ（HA）WAN 上で保証する必要があります。さらに、ハイ アベイラビリティ WAN を流れるあらゆるコールで使用される帯域幅を保証することも必要です。ハイ アベイラビリティ WAN ですべての Unified CCE シグナリングを扱うために最低限必要な帯域幅は、2 Mbps です。

プライベートおよびパブリック ネットワークの帯域幅要件に加えて、この項では、Unified IP IVR PG または Unified CVP PG から Unified IP IVR または Unified CVP への接続、CTI サーバから CTI OS への接続のほか、Unified CM のイントラクラスタ コミュニケーション シグナリング（ICCS）の帯域幅分析についても説明します。

Unified IP IVR PG または Unified CVP PG と Unified IP IVR または Unified CVP 間の通信

現在のところ、Unified IP IVR PG または Unified CVP PG と Unified IP IVR または Unified CVP 間の通信を扱う専用のツールは存在しません。ただし、この前の 2 つの項で紹介したツールを使用すれば、この通信に必要な帯域幅を妥当な精度で計算できます。Unified ICM セントラル コントローラと Unified IP IVR PG 間または Unified CVP PG 間の通信で消費される帯域幅は、Unified IP IVR PG または Unified CVP PG と Unified IP IVR または Unified CVP 間の通信で消費される帯域幅にかなり近い数値となります。

VRU ペリフェラル ゲートウェイから ICM コントローラの帯域幅カルキュレータ ツールは、次の URL から Cisco Steps to Success Portal を通じて入手できます（適切なログイン認証が必要）。

http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100901

Unified IP IVR PG または Unified CVP PG が WAN を介して分割されている場合、必要な全帯域幅はこのツールが報告する値の倍、つまり、Unified ICM セントラル コントローラと Unified IP IVR PG 間または Unified CVP PG 間の値と、Unified IP IVR PG または Unified CVP PG と Unified IP IVR または Unified CVP 間の値を加算した数値になります。

CTI サーバと CTI OS 間の通信

CTI OS と CTI サーバ間の WAN リンクで帯域利用率が最大となるのは、CTI OS と CTI サーバがお互いに遠く離れた場所に存在する場合です。このような場合は、帯域幅のキューを利用してアベイラビリティを保証するようにします。

このモデルの場合、次の簡単な数式を使用すると、最大で必要な帯域幅を計算できます。

• Extended Call Context（ECC; 拡張コール コンテキスト）変数もコール変数も存在しない場合

BHCA × 20 = bps

• ECC 変数またはコール変数（あるいはその両方）が存在する場合

BHCA ×（20 +（（変数の個数 × 変数の平均長さ）/40）= bps

例：BHCA の値が 10,000 で、平均長さ 40 ビットの ECC 変数が 20 個ある場合は、次のようになります。

10,000 × (20 + ((20 × 40) / 40) = 10,000 × 40 = 400,000 bps = 400 kbps

Unified CM イントラクラスタ コミュニケーション シグナリング（ICCS）

Unified CCE を展開する場合、Unified CM サブスクライバ ノード間のイントラクラスタ コミュニケーション シグナリング（ICCS）には、イントラクラスタ コミュニケーションで扱われるコール リダイレクト数と追加で発生する CTI/JTAPI 通信の数を考慮すると、かなり高い帯域幅が必要です。Unified CCE で展開する場合、Unified CM サブスクライバ ノード間の ICCS およびデータベース トラフィックに必要な帯域幅の計算には、次の式を使用できます。

• Unified CM 6.1 よりも前のリリース

– イントラクラスタ コミュニケーション シグナリング（ICCS）

BHCA × 200 = bps

– データベースなどの通信

パブリッシャから離れた場所の各サブスクライバには 644 kbps

• Unified CM 6.1 以降のリリース

– イントラクラスタ コミュニケーション シグナリング（ICCS）

全帯域幅（Mbps）= 2.22 ×（BHCA の合計/10,000）×（1 + 0.006 × Delay）
ここで、Delay は 往復遅延（ミリ秒）です。

– データベースなどの通信

パブリッシャから離れた場所の各サブスクライバには 1.544 Mbps

上記の帯域幅要件は、このマニュアルに記載した推奨事項に基づいて適切な設計と展開が行われていることを前提としたものです。サイト 1 への着信コールがサイト 2 で処理されるような効率の悪い設計では、余分なイントラクラスタ コミュニケーションが発生するため、ここで定義されている帯域幅要件では不十分なこともあります。

Gateway PG と System PG の間の帯域幅の要件

この項では、Gateway PG と System PG の間の接続用帯域幅のプロビジョニングに関するいくつかの基本的なガイドラインについて説明します。

Unified CCE Gateway PG とセントラル コントローラの間の帯域幅の要件

他の TDM PG 経由の PG と CC の間の接続の場合、特別な考慮事項はありません。

エージェント レポーティングが使用されない場合、PG エクスプローラの [Agent distribution] タブの [Enable Agent Reporting] チェックボックスをオフにして、リンクを経由して不要なデータが送信されるのを防ぐ必要があります。詳細は、「帯域幅と遅延の要件」を参照してください。

Unified CCE Gateway PG と System PG の間の帯域幅の要件

図 12-3 に、親 PG/PIM と子 System PG の間の接続を示します。

図 12-3 Gateway PG と System PG の間の接続

（注） モニタリングしている System PG から Gateway PG をリモートで展開することは推奨されません。

リンクが初期化された後、そのリンクを経由して送信されるデータ量は次の要因の影響を受けます。

• メッセージ サイズは、その内容（電話番号、エージェント ID、コール データのサイズなど）によって異なる可能性があります。たとえば、データを持たないルート要求は非常に小さなメッセージになる可能性があります。すべてのコール変数と ECC 変数に大きな値が設定されると、メッセージのサイズに大きく影響します。

• コール シナリオによって、回線で転送される各コールのメッセージ数は大きく異なる場合があります。単純なコール シナリオの場合、回線を経由して 21 個のメッセージが転送されることがあります。キューイング、保留復帰、会議、または転送を伴うより複雑なコール シナリオの場合、回線を経由して転送される各コールのメッセージ数は大幅に増加します。

• エージェントが所属するスキル グループが増加すると、回線を経由して転送されるメッセージも増加します。単純なコール シナリオの場合、スキル グループが 1 つ増加するごとに、コール当たり 2 つのメッセージが追加されます。これらのメッセージはフィールド サイズに応じてそれぞれ約 110 バイトです。

基本的な数値（検討の開始場所）

単一のスキル グループを持つ基本的なコール フロー（保留、復帰、会議、または転送のない単純な ACD コール）では、通常 21 個のメッセージが生成されるため、それに必要な帯域幅として少なくとも約 2,700 バイトを計画する必要があります。

基本的なコール フローには、コール変数と ECC データを 4 つの場所に送信できます。したがって、コール データや ECC 変数を使用する場合、それらはコール フローで 4 回送信されます。大量のコール データを使用すると、コール当たりの見積もり帯域幅の 2,700 バイトがすぐに 2 倍、3 倍、またはそれ以上に増加する可能性があります。

（注） 子 PG で使用するコール変数は、その使用方法や MAPVAR パラメータの設定にかかわらず、親 PG に転送されます。たとえば、コール変数 1 ～ 8 を子 PG で使用するが、親 PG で参照されない場合（MAPVAR = EEEEEEEEEE であることを前提。これはすべてをエクスポートするが、何もインポートしないことを意味します）、これらのコール変数はフィルタリングが行われる PG に転送されるため、帯域幅が必要です。逆の場合、帯域幅は使用されません。たとえば、マップ設定が MAPVAR = IIIIIIIIII（すべてをインポートするが、何もエクスポートしない）の場合、帯域幅は使用されません。コール変数のデータは、ROUTE_SELECT 応答で子 PG に転送されません。

基本的なコール フローの例

単純なコールのコール レートが毎分 300（毎秒 5 コール）で、コール変数または ECC データの受け渡しを行わない単一のスキル グループにすべてのエージェントが含まれているとします。この場合に必要な帯域幅は、次のとおりです。

5 × 2700＝毎秒 13,500 バイト＝108 kbps（必要な帯域幅）

より複雑なコール フローや、コール データを含むコール フローの場合、この帯域幅の要件はすぐに増加する可能性があります。

自動構成

自動構成を使用すると、エージェント、スキル グループ、およびルートポイント設定全体が子 PG から親 PG に転送されます。帯域幅が十分でない場合、このデータの転送時間が相当かかる可能性があります。

表 12-7 に、各データ エンティティで転送されるバイト数の概算（ワーストケース）を示します。子 PG における設定のサイズがわかる場合は、転送される設定データの総バイト数を計算できます。これらの値はワーストケースの見積もり値です。この値は、各フィールドに使用可能な最大値が設定された状態で各レコードで 1 つの項目だけを転送することを想定したものです（これは非常にまれなケースです）。

たとえば、子 PG に 100 個のエージェント、10 個のコール タイプ、5 個のスキル グループ、および 20 個のルート ポイントがある場合、転送される設定データの量は次のとおりです。

100 エージェント×500 バイト＝50,000 バイト

10 コール タイプ×250 バイト＝2,500 バイト

5 スキル グループ×625 バイト＝3,125 バイト

20 ルート ポイント×315 バイト＝6,300 バイト

50,000＋2,500＋3,125＋6,300＝61,925 バイト

この設定で転送される総データ量（最大値の概算）は 61,925 バイトです。

Gateway PG と Unified CCE のベスト プラクティスとオプション

帯域幅の要件を軽減するには、次のオプションを組み合わせて使用します。

• 子 PG ではコール変数と ECC 変数の使用数を抑えます。

メッセージによっては、コール データを子 Unified CCE システムから親に転送する場合があります。使用する変数のサイズと量を低減すると、これらのイベントで転送されるデータを低減できます（「基本的な数値（検討の開始場所）」の注を参照してください）。

• MAPVAR = IIIIIIIIII および MAPECC = IIIIIIIIII ペリフェラル設定パラメータを使用します。

MAPVAR および MAPECC オプションを使用しない場合（つまり、MAPVAR = BBBBBBBBBB と MAPECC = BBBBBBBBBB がデフォルト設定です）、子に送信されるすべての ROUTE_SELECT で、親で使用されるコール変数と ECC 変数もすべて子に送信されます。MAPVAR、MAPECC、またはその両方に I（インポート）または N（なし）オプションを使用すると、Gateway PG はこれらの変数を回線を経由して子システムに送信しません。多くのコール変数や ECC 変数を親で使用する場合は、これらのパラメータを設定することで帯域幅を節約できます。

（注） データのインポート（I または B 設定）を削除しても、帯域幅は節約されません。これは、Gateway PG がデータをインポートしない場合でも子 Unified CCE システムはデータを転送するからです。

Agent Desktop および Supervisor Desktop の帯域幅の要件と QoS

Unified CCE 環境における Agent Desktop と Supervisor Desktop のトラフィックと帯域幅の要件を評価する場合、多くの要因を考慮する必要があります。帯域幅に最も大きく関与する要因は VoIP パケット ストリームの帯域幅ですが、コール制御、エージェント状態シグナリング、サイレント モニタリング、録音、統計情報などのその他の要因についても考慮する必要があります。

VoIP パケット ストリームの帯域幅の要件は、導入する音声コーデック（G.729、G.711 など）から直接派生し、帯域幅の範囲は各音声ストリームで 4 ～ 64 kbps です。コンタクト センターのコール プロファイルには、ストレート コール（着信または発信）数、コンサルテイティブ転送数、および電話会議数が定義されます。つまり、このコール プロファイルにはネットワーク上でアクティブになる VoIP パケット ストリーム数が定義されるため、このコール プロファイルを十分に理解している必要があります。一般に、VoIP パケット ストリームの数は各エージェントで 1 強です。これは、保留されているコール、サイレント モニタリング セッション、アクティブな録音、コンサルテイティブ転送、および電話会議を示します。

コール制御、エージェント状態シグナリング、サイレント モニタリング、録音、および統計情報の帯域幅の要件をまとめると、全帯域利用率の 25 ～ 50 % として表すことができます。VoIP パケット ストリームの帯域幅の計算は非常に単純ですが、これらの他の要因は実装と展開の詳細に大きく依存するため、これらについては以降の項で詳細に説明します。

通常、WAN リンクはシスコ ユニファイド コミュニケーション ネットワーク内で最低速の回線であるため、帯域幅に注意するだけでなく、音声トラフィックがこれらのリンク間で送信されるときのパケット損失、遅延、およびジッタにも注意する必要があります。ネットワークに起因するその他の遅延に加え、G.729 方式による音声サンプリングの遅延は最小（わずか 30 ミリ秒）であるため、G.729 方式は WAN での使用に好まれるコーデックです。また、G.729 コーデックは高い音声品質を優れた圧縮特性で提供し、その結果、各ストリームの帯域利用率が比較的低く（8 kbps）抑えられます。

システム構成では、次の QoS の要因についても考慮する必要があります。

• 遅延合計の見積もり。WAN の遅延、経由するローカルエリア ネットワークのシリアライゼーション遅延、およびネットワーク デバイスのフォワーディング遅延を考慮します。

• ルーティング プロトコルの影響。たとえば、Enhanced Interior Gateway Routing Protocol（EIGRP; Enhanced IGRP）の場合、収束時間はわずかで、帯域幅は控えめに使用されます。また、EIGRP の収束は、コール処理と Unified CCE エージェントのログインにほとんど影響を与えません。

• エージェント コールのサイレント モニタリングと録音の方式。使用する方式によって、特定のネットワーク リンクでの帯域幅負荷が異なります。

• Cisco Unified Mobile Agent（Unified MA）の展開では、QoS メカニズムを使用して WAN の帯域利用率を最適化する必要があります。

• ディストリビューションとコア エリアでは、高度なキューイングおよびスケジューリング手法を使用する必要もあります。

CTI OS Agent Desktop の帯域幅の要件

この項では、CTI OS Agent Desktop と CTI OS サーバとの間におけるトラフィックと帯域幅の要件について説明します。これらの要件は、特に、エージェントが WAN リンクを介してリモートになっている場合に、エージェントと CTI OS サーバ間で必要とされるネットワーク帯域幅のプロビジョニングと QoS において重要となります。エージェントがレイヤ 2 を介してローカルになっている場合でも、定期的に発生するバースト性トラフィックについて把握しておくことが重要です。これは、このトラフィックが原因で帯域幅と QoS 割り当て方式に問題が生じる場合や、ネットワークを経由するその他の重要なトラフィックに影響がある可能性があるためです。

CTI-OS クライアント/サーバのトラフィック フローおよび帯域幅の要件

CTI OS Release 7. x では、次の 2 つの点で CTI OS サーバ/クライアントの帯域幅が強化されています。

• 文字列キーワードが列挙値に置き換えられています。この改良によってパケット サイズが低減し、その結果、帯域幅と CPU 使用率が低減します。

• エージェント スキル グループ統計情報の分配が向上し、ネットワーク トラフィックのバーストが解消されています。スキル グループ統計情報は、エージェントのスクリーン ポップや制御データと同じ TCP 接続で送信されるため、エージェントの制御トラフィックと同じトラフィック キューに影響します。したがって、この改良は重要です。

ネットワークの帯域幅の要件は、エージェント スキル グループ メンバーシップの関数として線形に増加します。ネットワークの全体的な負荷に占めるシステム コール制御トラフィックの影響は比較的小さいものの、スキル グループ統計情報は、ネットワーク キャパシティに対して最も重要なサイジング基準となります。CTI OS 7. x で新機能として導入された CTI OS Security はネットワーク負荷にも影響します。CTI OS Security がイネーブル（オン）になっていると、OpenSSL のオーバーヘッドのため帯域幅の要件が大幅に増加します。

表 12-8 に、各 CTI OS アプリケーションのメッセージ タイプを示します。

サイレント モニタリングによる帯域幅の使用

サイレント モニタリングでは、スーパーバイザは、CTI OS を使用する Unified CCE コール センターのエージェント コールをモニタリングできます。監視されているエージェントの IP ハードウェア フォンで送受信された音声パケットがネットワークから取り込まれ、スーパーバイザ デスクトップに送信されます。この音声パケットはスーパーバイザ デスクトップで復号化され、スーパーバイザのシステムのサウンド カードで再生されます。

エージェントのサイレント モニタリングは、追加の音声コールとほぼ同じネットワーク帯域幅を使用します。単一のエージェントで 1 つの音声コール用の帯域幅が必要な場合、サイレント モニタリングされている同じエージェントでは、2 つの同時音声コール用の帯域幅が必要になります。

コールの負荷のために必要なネットワーク帯域幅の合計を計算するには、特定のコーデックとネットワーク プロトコルのコールごとの帯域幅の値でコール数を乗算します。

CTI OS Server の帯域幅カルキュレータ

CTI OS には、次の図 12-4 に示すように、CTI OS サーバと CTI OS Desktop の間の帯域幅を計算する帯域幅カルキュレータがあります。この帯域幅カルキュレータは、全帯域幅、エージェントの帯域幅、およびスーパーバイザの帯域幅の要件を CTI OS Security がオンの場合とオフの場合で計算します。CTI OS の帯域幅カルキュレータの詳細については、次の URL を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps14/prod_technical_reference_list.html

図 12-4 CTI OS サーバと CTI OS Desktop の通信

CTI OS サーバと CTI OS Agent Desktop のベスト プラクティスとオプション

帯域幅の要件を軽減するには、次のオプションを組み合わせて使用します。

より少ない統計情報の設定

CTI OS では、システム管理者はレジストリに、すべての CTI OS クライアントに送信する統計情報項目を指定できます。統計の選択は、各統計情報パケットのサイズに影響を与えるため、ネットワーク トラフィックにも影響を与えます。設定する統計情報を少なくすると、エージェントに送信されるトラフィックが低減します。この場合、統計情報をエージェントごとに指定することはできません。エージェント統計情報の詳細については、次の URL にある『 CTI OS System Manager's Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps14/prod_installation_guides_list.html

エージェントごとの統計情報のオフ

複数の接続プロファイルを使用して、エージェントごとに統計情報をオフにできます。たとえば、Unified MA で統計情報がオフになった接続プロファイルが使用されている場合、これらのクライアント接続では、CTI OS サーバと Agent Desktop または Supervisor Desktop との間に統計情報トラフィックがなくなります。このオプションを使用すると、リモート ロケーションにある個別の CTI OS サーバが必要なくなることがあります。

リモート サイトで統計情報トラフィックをより制限できる場合でも、リモート スーパーバイザまたは選択したエージェントは、統計情報がオンになっている異なる接続プロファイルを使用して統計情報を記録できます。

Unified MA のグループ統計情報がオフになっており、スーパーバイザがエージェント スキル グループ統計情報を確認する場合は、スーパーバイザは統計情報がオンになっている別の接続プロファイルを使用できます。この場合、スーパーバイザに送信されるトラフィック量はかなり少なくなります。各スキル グループとエージェント（スーパーバイザ）について、スキル グループ統計情報メッセージのパケット サイズは固定されています。このため、2 つのスキル グループに属するエージェントは 2 つのパケットを受信し、5 つのスキル グループを監視するスーパーバイザは 5 つのパケットを受信します。リモート サイトに 10 のエージェントと 1 つのスーパーバイザがあり、すべて同じ 2 つのスキル グループに設定されている（Unified CCE では、スーパーバイザは、そのエージェント チームのエージェントが属しているスキル グループのすべての統計情報を確認できます）場合、スーパーバイザだけが統計情報をオンにして 2 つのスキル グループを監視し、エージェントが統計情報をオフにすると、この方法によってスキル グループ統計情報トラフィックが 90 % 低減されます。

また、メイン ロケーションでは、エージェントがスキル グループ統計情報をオンにする場合、スーパーバイザが異なる接続プロファイルを使用していると、リモート ロケーションへのトラフィックに影響を与えることなくこのことを行うことができます。この場合にも、追加の CTI OS サーバは必要ありません。

リモート ロケーションが複数あり、スーパーバイザだけが統計情報を確認する場合は、すべてのリモート スーパーバイザの接続プロファイルが 1 つあるだけで十分です。

CTI OS でのすべてのスキル グループ統計情報のオフ

スキル グループ統計情報が必要ない場合は、すべてオフにしてください。これにより、CTI OS サーバと Agent Desktop または Supervisor Desktop との間の接続が切断され、すべての統計情報トラフィックがなくなります。

Cisco Agent Desktop の帯域幅の要件

この項では、ネットワーク帯域幅のプロビジョニング、企業のデータ ストアへのアクセスとセキュリティ保護、および Cisco Agent Desktop（CAD）製品を含む Unified CCE 導入の Quality of Service（QoS）の確保に関するいくつかの設計上の考慮事項について説明します。

サイレント モニタリングによる帯域幅の使用

CAD デスクトップ ソフトウェアのサイレント モニタリング機能では、ライブ コールのリッスン、エージェント コールの録音、録音済みコールのリッスンなどを実行でき、この機能の帯域幅の要件は CAD 製品で最大です。WAN 接続を介してメイン サイトに接続する Unified MA にとっては、この機能を適切に設定することが特に重要です。

サイレント モニタリング機能にアクセスするには、VoIP プロバイダーに要求を送信します。VoIP プロバイダーは、コールを表す音声ストリーム（コールごとに 2 つの音声ストリーム）をネットワークから取り込むかディスクから読み取って、それを要求者に送信します。要求者はストリームを受信した後、それをリッスンするためにデコードするか、ディスクに保存します。この項では、要求者とプロバイダーの間のネットワーク リンクの帯域幅の要件について詳細に説明します。

サイレント モニタリングの要求者

CAD ソフトウェアには次の 2 種類の要求者があります。

• Cisco Supervisor Desktop

• 録音再生サービス

Cisco Supervisor Desktop では、スーパーバイザがエージェントのコールをリアルタイムでリッスンする場合や録音済みコールをリッスンする場合にサイレント モニタ要求が送信されます。録音再生サービスは、スーパーバイザまたはエージェントがコールを録音する場合に録音要求を送信します。ライブ コールのリッスンまたは録音を行う場合、VoIP プロバイダーは音声ストリームを取り込んで要求者に送信します。この音声ストリームはスーパーバイザのデスクトップでデコードされ、スーパーバイザのデスクトップのサウンド カードで再生されます。録音の場合、録音再生サービスは音声ストリームを受信し、それをディスクに保存します。

Unified CCE インストールでは 1 つまたは 2 つの録音サービスを使用できます。

サイレント モニタリング プロバイダー

CAD ソフトウェアには次の 3 種類の VoIP プロバイダーがあります。

• Cisco Agent Desktop

• VoIP モニタ サービス

• 録音再生サービス

Cisco Agent Desktop アプリケーションには、エージェントのデスクトップで実行されるデスクトップ モニタ サービスというモジュールが含まれています。このサービスは、デスクトップ上の CAD アプリケーションにログインしているエージェントのサイレント モニタリング要求だけを処理します。このサービスは、ログインしているエージェントに関連付けられている電話または IP Communicator ソフトウェア電話に送信された音声パケットをキャプチャします。電話は、Cisco Unified IP Phone 7910、7940、7960、または 7970 のいずれかで、ネットワーク上のエージェント デスクトップと直列に接続される必要があります。これらの電話は、電話をネットワークやエージェントのコンピュータに接続できる追加のネットワーク ポートを搭載しているためサポートされています。また、これらの IP Phone では、その追加ポートからネットワーク トラフィックを伝播するハブとスイッチの機能もサポートしています。この機能では、デスクトップ モニタ サービスを使用してエージェントの電話での会話内容を見ることができます。

デフォルトでは、このサービスは、アプリケーションの起動時にすべてのエージェント デスクトップでアクティブになります。CAD サーバを初めてインストールした後、すべてのエージェントがすでに、サイレント モニタリング機能でデスクトップ モニタ サービスを使用するように設定されています。

VoIP モニタ サービスは、サイレント モニタリングの複数の要求を同時に処理できます。このサービスは、スイッチの Switched Port Analyzer（SPAN; スイッチド ポート アナライザ）設定を介してスイッチから直接パケットを取り込みます。1 つの環境では、異なるマシンで最大 5 つの VoIP モニタ サービスを使用できます。オフボード VoIP サービスは、リモート オフィス ロケーションにインストールできます。ネットワークの複雑さやキャパシティ計画によっては、このサービスが必要になるときがあります。エージェントのデバイスのサイレント モニタリングでこの種別の VoIP モニタ サービスを使用する場合は、そのエージェントで使用する VoIP モニタ サービスを明示的に設定する必要があります。

（注） デスクトップを持たない Cisco Unified IP Phone エージェントの場合は、サイレント モニタリング機能で VoIP モニタ サービスを使用するように設定する必要があります。

また、録音済みのエージェントのコールをスーパーバイザが再生すると、録音再生サービスがコールを表す 2 つのストリームを提供する場合があります。この場合には、これらストリームはすでに以前の録音セッションでディスクに保存されています。録音再生サービスは未加工のデータ ファイルをディスクから読み取り、ネットワークを経由して RTP ストリームをスーパーバイザのデスクトップに送信します。これらのストリームは、このデスクトップ上でサウンド カードを使用して再生されます。

ここで説明しているように、録音再生サービスは、要求者（ライブ コールを録音する場合）にもプロバイダー（録音済みコールを再生する場合）にもなることができます。

VoIP および録音再生サービスは、通常は CAD ベース サービスとともにインストールされます。追加の VoIP サービスと 2 つ目の録音再生サービスは、他のボックスにインストールできます。

図 12-5 に、WAN 経由でリモート オフィスをサポートする Unified CCE の典型的なインストール方法を示します。メイン オフィスとリモート オフィスの両方で、VoIP モニタをオンサイトで使用しています。

図 12-5 メイン サイトとリモート サイトの VoIP モニタ サービス

要求者とプロバイダーを配置するときに、サイレント モニタリング機能用の帯域幅が必要となる場所を判断できます。図 12-5 には、帯域幅に関する次の注が適用されます。

• 管理者は特定の VoIP サービスをエージェントのデバイスに割り当てることができますが、コールの録音時に使用される録音サービスは、要求の発生時に決まります。ロード バランスのために 2 つの録音サービスがインストールされている場合にも同じ規則が適用されます。場合によっては、プロバイダーと要求者が WAN で分離され、WAN で帯域幅が必要となることがあります。2 つ目の録音再生サービスをインストールする場合は、メイン オフィスのサーバ（CAD ベース サービスが実行される LAN 上に存在する）にインストールすることを推奨します。

• VoIP プロバイダーが VoIP モニタ サービスで、要求者が録音サービスで、これらのサービスが同じマシン上に常駐する場合、コールを録音するためにネットワーク上で追加のネットワーク帯域幅が使用されることはありません。

要求者と VoIP プロバイダーがどのサービスであるかにかかわらず、この 2 つのポイント間の帯域幅の要件は、監視または録音される IP コールの帯域幅です。全帯域幅を計算する場合、各モニタリングや録音セッションを新しい電話と見なすことができます。したがって、サイレント モニタリング機能をサポートする帯域幅を計算するには、コール トラフィックを処理するネットワークをプロビジョニングする場合と同じ計算を使用できます。ただし、例外として、VoIP プロバイダーが提供する音声ストリームは同じ方向の 2 つのストリームで構成されます。通常の IP 電話のコールの場合、電話へのストリームが 1 つ、電話からのストリームが 1 つありますが、VoIP プロバイダーの場合は両方のストリームがプロバイダーから送信されます。WAN のアップロードとダウンロードの速度をプロビジョニングする場合は、この違いに注意してください。

この音声ストリームに必要な帯域幅の要件を判別するには、次の URL にある『 Cisco Unified Communications Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/go/designzone

Cisco Agent Desktop アプリケーションによる帯域幅の使用

CAD デスクトップ アプリケーションには次のものが含まれています。

• Cisco Agent Desktop

• Cisco Supervisor Desktop

• Cisco Desktop Administrator

• Cisco Desktop Monitoring Console

これらのアプリケーションでも一定量の帯域幅が必要ですが、サイレント モニタリング機能と比べればごくわずかです。また、ネットワーク上での通信タイプはバースト性です。一般に、エージェントが処理を実行していない場合、帯域幅の使用状況は低くなります。機能や処理が要求されると、処理を実行するために必要な時間（一般に 1 秒未満）だけ帯域幅が増加し、処理が終了すると、帯域幅の使用状況は安定状態レベルに戻ります。プロビジョニングの観点では、すべての CAD エージェントが特定の処理を同時に実行する可能性を判断する必要があります。コール センターを特徴付け、（ワーストケースで）同時に実行可能な処理の最大数を決定して帯域幅の要件を特定した後、要求された処理の何パーセントに対してどれだけの遅延を許容するかを決定します。

たとえば、同時にログインする 1,000 個の CAD エージェントに対する未加工の帯域幅の要件は 6.4 KB/秒で、各エージェントのログイン時間は約 9 秒（ネットワーク遅延なし）です。WAN リンクにこれだけの帯域幅がない場合、パケットはキューイングされてから送受信されるため、ログインにより多くの時間がかかります。このキューイング遅延によってログイン試行の時間が 2 倍（この場合 18 秒）になる場合に、そのような遅延を受け入れることができますか?受け入れることができない場合、より多くの帯域幅をプロビジョニングする必要があります。

次の各アプリケーションは、サーバ マシン上で実行されるベース CAD サービスと通信します。また、Agent Desktop アプリケーションは、CTI OS サーバを介して CTI サーバと通信してコール制御処理と状態変更を行います。 表 12-9 に、各アプリケーションのメッセージ タイプを示します。

Cisco Agent Desktop による帯域幅の使用

CAD エージェントは、ログイン/ログオフ、エージェント状態の変更、コールの処理、およびベース サーバへのレポート情報の送信を行うことができます。これらのアクティビティの帯域幅の要件は非常にわずかですが、多くのエージェントが考慮される場合は増加する可能性があります。

表 12-10 に、さまざまなエージェント数における平均的な帯域幅の要件を示します。この情報は、帯域幅のテストと帯域幅データの推定から導かれています。帯域幅に影響する可能性がある多くの変数があるため、帯域幅の使用状況がより高くなる設定を選択してワーストケース シナリオに近い状況を示しています。この表に示される帯域幅の要件をエージェントの WAN リンクが満たしていると、Cisco Agent Desktop でメッセージの受け渡しを遅延なく実行できます。

帯域幅には次の設定パラメータが影響します。また、これらの設定パラメータは 表 12-10 と 表 12-11 の情報にも適用されます。

• エージェントごとのスキル数：10

• チームごとのエージェント数：20

• チーム数：50

• エージェントごとのエージェント状態変更数（毎時）：10（コール処理に起因する状態変更は除外）

• エージェントごとのコール数（毎時）：60

• チームごとのチーム パフォーマンス メッセージ（毎時）：8

• 送信または受信されるチャット メッセージ（毎時）：20

• チャット メッセージ サイズの平均（バイト単位）：40

• 録音されるコール数（毎時）：10

ここに示す帯域幅の要件には、コール、録音、またはモニタリング セッションの RTP ストリームの帯域幅は含まれず、セッションを開始/終了するために必要なメッセージングだけが含まれています。

Cisco Supervisor Desktop による帯域幅の使用

Cisco Supervisor Desktop では、スーパーバイザがログインするチームのすべてのエージェントのイベントが受信されます。この情報には、状態変更、コール処理、ログイン/ログオフなどが含まれます。エージェント、スキル、およびコールが増加すると、それに応じてスーパーバイザに送信されるデータも増加します。また、スーパーバイザがレポートを表示している間、特定のレポートが定期的に自動リフレッシュされて、リアルタイム データが表示されます。レポートをリフレッシュするために追加の帯域幅が必要です。

表 12-11 では、 表 12-10 の帯域幅の値を調べるために使用したものと同じ基本的な設定パラメータを使用しています。次の追加のパラメータが含まれています。

• チーム スキル統計情報レポートの表示とリフレッシュ

Cisco Desktop Administrator による帯域幅の使用

Cisco Desktop Administrator の帯域幅の要件はごくわずかで、管理者が設定をアクティブに変更する場合にだけ表示されます。一般に、Cisco Desktop Administrator で使用される帯域幅はプロビジョニングの観点からは無視できます。

Cisco Desktop Monitoring Console による帯域幅の使用

Cisco Desktop Monitoring Console の帯域幅の要件はごくわずかで、帯域幅が必要な時間もごくわずかです。一般に、Cisco Desktop Monitoring Console で使用される帯域幅はプロビジョニングの観点からは無視できます。

Cisco Agent Desktop サービスの配置のベスト プラクティスと推奨事項

Cisco Agent Desktop を使用した Unified ICM のインストールでは、VoIP モニタ サービスおよび録音再生サービス以外の CAD サービスは PG と共存させる必要があります。次に示すように、VoIP モニタ サービスおよび録音再生サービスは他のサーバにインストールできます。

CAD インストールでは、最大 5 つの VoIP モニタ サーバを使用できます。VoIP モニタ サービスは単一のサーバ上に 1 つだけ存在できます。VoIP モニタ サービスは、PG に CAD ベース サービスとともにインストールできます。また、ともにインストールしなくてもかまいません。

VoIP モニタ サービスにおける主な負荷は、モニタリングや録音の同時セッション数ではなく、VoIP サービスに割り当てられているデバイスでその VoIP サービスに送信されるネットワーク トラフィックの量です。Switched Port Analyzer（SPAN; スイッチド ポート アナライザ）がデバイスから特定の VoIP サービスにトラフィックを送信するように設定されている場合、そのトラフィック（音声や多くの場合データも）は VoIP サービスのパケット スニファによってスニファされます。このトラフィックは、モニタリングまたは録音セッションがアクティブになっていない場合でもスニファされます。この理由により、特定の VoIP サービスに割り当てることができるデバイス数には制限があります。

VoIP サービスがベース CAD サービスと共存して実行される場合、この VoIP サービスは最大 100 個のエージェントのネットワーク トラフィックをサポートします。100 個を超えるエージェントが単一の VoIP サービスを使用するように設定されている場合は、このサービスを別のサーバに移動する必要があります。このようにインストールされた単一の VoIP モニタ サービスでは、400 個のエージェントのネットワーク トラフィックを処理できます。単一の VoIP モニタ サービスでは、サイレント モニタリングや録音の同時セッションを最大 58 個処理できます。VoIP モニタ サービスを追加すると、インストールのサイレント モニタリングや録音のキャパシティが増加します。

単一の CAD インストールでは、1 つまたは 2 つの録音再生サービスをサポートできます。VoIP モニタ サービスと同様、これらのサービスもいずれか 1 つだけが単一のコンピュータ上に存在できます。録音再生サービスは、PG に CAD ベース サービスと共存する形でインストールすることも、共存しないようにインストールすることもできます。録音再生サービスを PG にインストールすると、最大 32 個の同時録音セッションをサポートできます。さらに多くの同時録音セッションをサポートする必要がある場合は、録音再生サービスを別のサーバに移動する必要があります（ただし、オフボード VoIP モニタ サービスと共存する場合があります）。オフボード録音再生サービスでは、最大 80 本の同時レコーディングが可能です。

2 つ目の録音再生サービスによって録音キャパシティは増加しませんが、2 つ目の録音再生サーバはロード バランシングと冗長性をインストールに提供します。

HDS とレポーティングがあるディストリビュータ AW の帯域幅の要件

図 12-6 と図 12-7 に、標準的および大規模なレポーティング展開で帯域幅が必要となる部分を示します。

図 12-6 標準的なレポーティング展開

図 12-7 大規模なレポーティング展開

ネットワーク インターフェイス カード（NIC）を 1 つだけ持つサーバの帯域幅の要件を計算する場合は、システムに接続される各リンクの合計を加算する必要があります。たとえば、アドミン ワークステーション（AW）、Historical Data Server（HDS）、および 1 つの NIC がある標準的なレポーティング展開では、必要な帯域幅を次のように計算します。

レポーティングに必要な全帯域幅＝レポート データの帯域幅＋レポートの帯域幅

ただし、大規模なレポーティング展開では、帯域幅は次のように計算します。

レポーティングに必要な全帯域幅＝レポート データの帯域幅＋WebView サーバの帯域幅

（注） 回復プロセスの特性のため、回復時にはネットワークの速度が低下する場合があります。

以降の項では、図 12-6 と図 12-7 に示されている各ネットワーク パスの帯域幅の要件を判断するために必要な計算について説明します。

レポート データの帯域幅

HDS があるディストリビュータ AW とセントラル コントローラの間の帯域幅に影響する要因は、毎秒のコール数（cps）、エージェント数、および Extended Call Context（ECC; 拡張コール コンテキスト）変数を使用するかどうかです。テスト結果から、次の一般的なガイドラインが示されます。

• 10 cps ごとの帯域幅の使用量は毎秒約 42,000 バイトです。

• 10 個のエージェントに対して毎秒約 12,000 バイトが必要です。

• 1000 ECC バイトと 50cps ごとの帯域幅の使用量は毎秒 1,200,000 バイトです。

Unified CCE には、レポート データの帯域幅の要件の決定を支援する帯域幅カルキュレータがあります。このカルキュレータは、次の URL にあります。

http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_technical_reference_list.html

WebView サーバの帯域幅

WebView サーバがディストリビュータ AW と共存していない大規模なレポーティング展開では、WebView の帯域幅が要因になります。

WebView が別のサーバに展開される場合、設定によっては、HDS がある 1 つのディストリビュータ AW で最大 4 つの WebView サーバをサポートできます。WebView サーバのサポート数に関する特定情報の詳細については、次の URL にある『 Hardware & System Software Specification (Bill of Materials) for Cisco ICM/IPCC Enterprise & Hosted Editions 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html

ディストリビュータ AW と WebView サーバの間の帯域幅に影響する要因は、WebView サーバに接続するレポーティング ユーザの総数です。テスト結果によると、50 人のレポーティング ユーザに対して毎秒約 314,573 バイトが必要です。レポーティング ユーザは、次のことを実行するユーザとして定義されます。

• それぞれ 50 個以下の行を返し、20 秒おきにリフレッシュされる 2 つのリアルタイム レポートを作成する。これはモニタリング スクリプトを実行することと同じです。

• 1 時間あたり 1 つの履歴レポートを作成する。

– 8 時間分の 30 分履歴レポートを実行

– 40 時間分の日次履歴レポートを実行

Unified CCE には、WebView サーバの帯域幅の要件の決定を支援する帯域幅カルキュレータがあります。このカルキュレータは、次の URL にあります。

http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_technical_reference_list.html

レポートの帯域幅

WebView サーバと WebView クライアントの間の帯域幅に影響する要因は、レポーティング ユーザ数と Secure Socket Layer（SSL）が完全暗号化モードに設定されているかどうかです。テスト結果によると、50 人のレポーティング ユーザによる帯域幅の使用量は毎秒約 524,288 バイトで、さらに完全な SSL 暗号化によって毎秒約 2,097 バイトが加わります。

Unified CCE には、レポート用の帯域幅の要件の決定を支援する帯域幅カルキュレータがあります。このカルキュレータは、次の URL にあります。

http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_technical_reference_list.html

Cisco E-Mail Manager の帯域幅の要件

Cisco E-Mail Manager は次の目的でディストリビュータ AW と通信します。

• エージェントを認証する

• Unified ICM から設定情報を取得する

• Cisco E-Mail Manager で新しいエージェントまたはスキル グループが作成されたときに設定情報をアップロードする

• Unified ICM AW データベースと Cisco E-Mail Manager データベースの間で設定を同期する

これらの 2 つのコンポーネント間には高い帯域幅要件が存在するため、これらを同じ LAN セグメントに展開することをお勧めします。

User List Tool の帯域幅および遅延の要件

クライアント AW がドメイン コントローラとディストリビュータ AW から離れた場所にある（WAN を介して接続されている）展開の場合、User List Tool で適切なパフォーマンスを達成するには、各ネットワークの高帯域幅と低遅延が要求されます。適切なパフォーマンスは、ユーザの検索に要する時間が 30 秒未満として定義されます。この情報は、エンド ユーザの期待を設定しつつ、Cisco Unified CCE and ICM 7.2（3）以降のリリースへのアップグレードを促す目的で提供されます。このバージョンでは、これらの条件でツールのパフォーマンスを強化するための変更が行われました。

User List Tool のパフォーマンスを向上させるには、他にも実行できることがいくつかあります。ディストリビュータ AW とドメイン コントローラを移動しクライアント AW に対してローカルに設定すると、 表 12-12 の LAN の行に示すように、パフォーマンスが大きく向上します。WAN 接続で遅延を改善した場合や、WAN 接続の帯域幅を拡大した場合もパフォーマンスは向上します。

Unified CCE 7.2（3）以降のリリースで User List Tool を使用して 30 秒以内にユーザを検索できるシナリオのデータ ポイントを次に示します。以前のバージョンの Unified CCE を使用し、検索時間が遅いと感じている場合は、Unified CCE 7.2（3）以降へのアップグレードを検討してください。さらに、ラボのテストでは、一方向の遅延が 50 ミリ秒を超えるネットワークではユーザ数に関係なくツールを適切に実行できないことが確認されました。