Cisco Unified Contact Center Enterprise ソリューション リファレンス ネットワーク デザイン (SRND)
帯域幅のプロビジョニングおよび QoS に関する考慮事項
帯域幅のプロビジョニングおよび QoS に関する考慮事項
発行日;2012/01/08 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 9MB) | フィードバック

目次

帯域幅のプロビジョニングおよび QoS に関する考慮事項

この章の新トピック

Unified CCE ネットワーク アーキテクチャの概要

ネットワーク セグメント

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

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

HSRP-Enabled ネットワーク

RSVP

トラフィック フロー

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

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

帯域幅と遅延の要件

Quality of Service(QoS)

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

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

QoS の設定

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

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

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

帯域幅のプロビジョニング

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

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

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

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

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

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

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

自動構成

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

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

CTI OS Agent Desktop の帯域幅の要件

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

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

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

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

Cisco Agent Desktop の帯域幅の要件

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

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

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

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

レポート データの帯域幅

WebView サーバの帯域幅

レポートの帯域幅

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

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

帯域幅のプロビジョニングおよび QoS に関する考慮事項

この章では、Unified CCE ネットワーク アーキテクチャ、ネットワークの展開特性、および Unified CCE ネットワークのプロビジョニング要件の概要について説明します。ネットワーク アーキテクチャの最も重要な概念には、ネットワーク セグメント、キープアライブ(ハートビート)トラフィック、フローの分類、IP ベースの優先順位付けとセグメント化、帯域幅と遅延の要件などがあります。WAN を介したリモート コンポーネント間のネットワーク トラフィック フローについて、WAN トラフィック フローに適切な QoS を適用する方法に関する推奨事項など、プロビジョニングのガイドラインが示されています。Unified CCE アーキテクチャおよびさまざまなコンポーネントのインターネットワーキングの詳細については、「アーキテクチャの概要」を参照してください。

Cisco Unified CCE は、従来、専用のポイントツーポイント専用回線ネットワーク接続を使用して、プライベート(セントラル コントローラまたはペリフェラル ゲートウェイ、サイドツーサイド)またはパブリック(ペリフェラル ゲートウェイからセントラル コントローラ)の WAN ネットワークシステムに展開されていました。最適なネットワーク パフォーマンス特性(およびフォールト トレラント フェールオーバー メカニズムのためのルートの多様性)が Unified CCE アプリケーションに提供されるのは、自前の専用設備、冗長性を備えた IP ルータ、適切なプライオリティ キューイングが揃っている場合に限られます。

現在すでに複数のトラフィック クラスを共有するネットワークを使用している大企業は、当然のことながら専用ネットワークへの追加投資が必要な状況への後戻りを好まず、現状のインフラストラクチャの維持を望んでいます。ネットワークの集約がコストと運用の効率性を両立させます。そのためのサポートこそが、Cisco Powered Networks の主要な側面となります。

Cisco Unified CCE Release 7.0 以降では(この製品のリアルタイム特性に固有の必要な遅延と帯域幅の要件が満たされていることを前提に)、シスコは QoS に対応している音声・データ統合パブリック ネットワークと Qos に対応している音声・データ統合プライベート ネットワーク環境における Unified CCE の展開をサポートしています。この章では、Unified CCE パブリックおよびプライベート ネットワーク トラフィックの QoS マーキング、キューイング、およびシェーピングに関する推奨事項について説明します。

従来から、QoS に関しては Integrated Services(IntServ; 統合化サービス)と Differentiated Services(DiffServ; 差別化サービス)の 2 種類のモデルが利用されてきました。IntServ モデルでは、Resource Reservation Protocol(RSVP; リソース予約プロトコル)を使用してネットワークの各フローに必要な QoS が提示され予約されます。IntServ ではパスのすべてのルータに膨大な量の予約に関する状態情報を維持する必要があるため、スケーラビリティが問題となります。一方、DiffServ ではトラフィックがさまざまなクラスに分類され、ネットワークの各ノードにおいてクラスごとに指定された転送処理がそれぞれのトラフィック クラスに適用されます。DiffServ は、大まかでスケーラブルなエンドツーエンドの QoS ソリューションとして、より広範に使用され、受け入れられています。Unified CCE アプリケーションは RSVP に対応していません。この章の QoS に関する考慮事項は、DiffServ に基づいています。

Unified CCE の展開を成功させるには、適切な帯域幅のプロビジョニングと QoS の実現が決定的に重要になります。この章で紹介する帯域幅のガイドラインとその適用例を、必要な帯域幅のプロビジョニングを行う際の参考としてください。

この章の新トピック

表 12-1 は、この章の新トピックまたはこのマニュアルの前リリースから大幅な変更があったトピックの一覧です。

表 12-1 新しい情報またはこのマニュアルの前リリースから変更された情報

新規または改訂されたトピック
説明箇所

Intra-Cluster Communication Signaling(ICCS; イントラクラスタ コミュニケーション シグナリング)の帯域幅要件

「Unified CM イントラクラスタ コミュニケーション シグナリング(ICCS)」

高優先順位トラフィックの遅延要件

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

Microsoft Packet Scheduler

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

パブリック ネットワークのポート使用状況

表 12-2

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

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

キューイング ポリシー

Unified CCE ネットワーク アーキテクチャの概要

Unified CCE は分散された復元力のあるフォールト トレラントなネットワーク アプリケーションです。Unified CCE は、ネットワーク インフラストラクチャがリアルタイム データ転送要件を満たすのに十分な性能を備えているかに大きく依存しています。適切に設計された Unified CCE ネットワークの特徴としては、妥当な帯域幅、短い遅延、特定の UDP または TCP アプリケーション トラフィックに優先順位を付ける仕組みがあげられます。これらの設計要件は、二重化された特定の Unified CCE ノード(つまり、セントラル コントローラとペリフェラル ゲートウェイ)間のフォールト トレラントなメッセージ同期や、時間的精度が要求されるシステムのステータス データ(エージェントの状態、コールの統計情報、トランクの情報など)のシステム内での配送を確実に行うために必要となります。コール センター状態の正確な更新と正確なリアルタイム レポート データの取得のために、セントラル コントローラに対して PG データの迅速な配送が必要になります。

シスコ ユニファイド コミュニケーション環境では、WAN および LAN のトラフィックを次に示すカテゴリにグループ化できます。

音声およびビデオのトラフィック

音声コール(音声キャリア ストリーム)は、PSTN ゲートウェイ ポート、Unified IP IVR Q ポイント(ポート)、Unified IP Phone など、さまざまなエンドポイント間の実際の音声データが含まれている Real-Time Transport Protocol(RTP)パケットで構成されています。このトラフィックには、サイレント モニタや録音されるエージェント コールの音声ストリームが含まれています。

コール制御トラフィック

コール制御は、コールのエンドポイントによって異なる、H.323、MGCP、SCCP、TAPI/JTAPI のいずれかのプロトコルに基づくパケットから構成されています。コール制御機能には、コールをセットアップ、管理、ティアダウン、またはリダイレクトする機能が含まれます。Unified CCE の場合、制御トラフィックには、音声コールのペリフェラル ターゲット(エージェント、スキル グループ、サービスなど)とその他のメディア終端リソース(Unified IP IVR ポートなど)へのルーティングおよびペリフェラル リソース ステータスのリアルタイム アップデートに必要となるルーティングおよびサービスのコントロール メッセージが含まれます。

データ トラフィック

データ トラフィックには、電子メールや Web のような通常のトラフィックと、スクリーン ポップやその他の優先順位付きのデータのようなエージェント デスクトップに送信される CTI データベース アプリケーションのトラフィックの両方が含まれます。Unified CCE の優先順位付きデータには、レポーティングと構成の更新を行うイベントのような、非リアルタイムのシステム ステータスに関連付けられているデータが含まれます。

この章では主に、リモートのペリフェラル ゲートウェイ(PG)と Unified ICM セントラル コントローラ(CC)の間、PG またはセントラル コントローラのサイド A とサイド B の間のネットワーク パス、およびデスクトップ アプリケーションと CTI OS あるいは Cisco Agent Desktop サーバの間の CTI フローで使用されるデータ フローと帯域幅のタイプについて説明します。また、必要な帯域幅の見積りに役立ち、これらの WAN セグメントの優先順位を付ける仕組みを実装するためのガイドラインおよび例について説明します。

ここで説明するフローでは、上に述べた 3 つのトラフィック グループのうち後の 2 つがカプセル化されます。残りの 1 つであるメディア(音声とビデオ)ストリームは主に Cisco Unified Communications Manager とそのエンドポイントの間で保持されるため、音声およびビデオのプロビジョニングについてはここで説明しません。

Unified CCE エージェントに対するコールで生成される音声 RTP ストリームおよびさまざまなプロトコルで生成される関連コール制御トラフィックの帯域幅の見積りについては、次の URL にある『 Cisco Unified Communications Solution Reference Network Design (SRND) 』を参照してください。

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

データ トラフィックおよびその他のミッション クリティカルなトラフィックは、どのような統合および展開モデルを採用するかによって異なります。データ トラフィックの適切なネットワーク設計については、次の URL にある『 Network Infrastructure and Quality of Service (QoS) 』を参照してください。

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

ネットワーク セグメント

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 で送信されます。

帯域幅と遅延の要件

一時的な境界の状態(起動設定の負荷など)や特定の設定のサイズもトラフィックの量に影響を与えますが、セントラル コントローラ(Call Router)とペリフェラル ゲートウェイの間で送受信されるトラフィックの量は、そのサイトのコール負荷に大きく影響します。安定状態で動作する Release 5.0 よりも前の Unified ICM ソフトウェアに最適なデータ量の目安は、ペリフェラルに到達したコール 1 件につき 1,000 バイト(8 kb)のデータです。このデータは通常、PG からセントラル コントローラに送信されます。このため、ペリフェラルで 1 秒当たり 10 のコールが処理されている場合、1 秒当たり 10,000 バイト(80 kb)のデータがセントラル コントローラに送信されます。このデータの大半は、低優先順位パスで送信されます。高パス帯域幅に対する低パス帯域幅の比率は、展開の特性(実行されているポストルーティングの程度が最も重要)によって異なりますが、通常、約 10 ~ 30 % です。ポストルート要求が発行されるたびに、高優先順位パスのデータは 200 ~ 300 バイト増加します。トランスレーション ルートでは、コールごとに反対方向の(セントラル コントローラから PG への)データが発生します。このデータのサイズは、デスクトップに送信されるコール コンテキストの量に完全に依存します。

ACD および VRU があるサイトには、2 つのペリフェラルがあり、帯域幅要件の計算では、両方のペリフェラルを考慮に入れる必要があります。たとえば、1 秒当たり 10 のコールを受信するペリフェラルが 4 つあるサイトは、通常、帯域幅が 320 kbps となるように設定されている必要があります。目安は 1 コールにつき 1,000 バイトですが、システムの運用が開始された後は、実際の動作を監視し、十分な帯域幅があるかどうかを確認する必要があります(Unified ICM は、各パスのセントラル コントローラ サイドと PG サイドの両方でデータ送信統計情報を監視します)。

ここで説明した目安と例は、Release 5.0 よりも前の Unified ICM リリースに適用され、ここでは参考までに説明しています。Unified ICM 5.0 以降では帯域幅カルキュレータとサイジングの数式が提供され、帯域幅の要件をより正確に見積もることができます。詳細については、「Unified CCE パブリックおよびプライベート ネットワークの帯域幅の要件」を参照してください。

Unified ICM が設計どおりに機能するためには、帯域幅の要件と同様に、遅延の要件も満たされている必要があります。セントラル コントローラ ノードと PG ノードに二重化されたサイドツーサイドのプライベート ネットワークにおける一方向の最大遅延は 100 ミリ秒です(推奨値は 50 ミリ秒です)。PG から CC へのパスが設計どおりのパフォーマンスを発揮するためには、一方向の最大遅延を 200 ミリ秒以下にする必要があります。このような遅延要件を満たすか、または超えることは、Unified ICM ポストルーティングやトランスレーション ルートを使用する環境で特に重要となります。

前述のとおり、Unified ICM 帯域幅および遅延設計は、基礎となる IP 優先順位付け方式によって大きく異なります。適切な優先順位付けが行われていない場合、WAN 接続は失敗します。Cisco Unified ICM サポート チームには、適切な優先順位付けを示し、展開認定の一部のレベルの帯域利用率モデルを実行できるカスタム ツール(クライアント/サーバなど)があります。

最終的なネットワーク設計によっては、DNP 以外のトラフィック フローと同時に Unified ICM トラフィックの優先順位付けを実現するために、共有ネットワーク環境において IP キューイング戦略が必要になります。このキューイング戦略は、トラフィック プロファイルおよび帯域幅のアベイラビリティによって大きく異なり、製品の厳密な帯域幅、遅延、および優先順位付け要求が満たされない限り、共有ネットワークにおける成功は保障できません。

Quality of Service(QoS)

この項では、Unified ICM QoS ソリューションに移行するときに考慮する必要がある計画および構成に関する問題について説明します。

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

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 の両方を予約しておくことをお勧めします。


表 12-2 パブリック ネットワーク トラフィックのマーキング(デフォルト)および遅延要件

優先順位
サーバ側での IP アドレスとポート
一方向の遅延要件
DSCP / 802.1p マーキング

IP アドレス:ルータの高優先順位パブリック IP アドレス

TCP ポート:

A における DMP 高優先順位接続用に 40003 +(i# × 40)

B における DMP 高優先順位接続用に 41003 +(i# × 40)

UDP ポート:Unified ICM で QoS がイネーブルになっていない場合、UDP ハートビート用に 39500 ~ 39999

200 ミリ秒

AF31 / 3

IP アドレス:ルータの高優先順位パブリック IP アドレス

TCP ポート:

A における DMP 高優先順位接続用に 40017 +(i# × 40)

B における DMP 高優先順位接続用に 41017 +(i# × 40)

1,000 ミリ秒

AF31 / 3

IP アドレス:ルータの非高優先順位パブリック IP アドレス

TCP ポート:

A における DMP 低優先順位接続用に 40002 +(i# × 40)

B における DMP 低優先順位接続用に 41002 +(i# × 40)

5 秒

AF11 / 1

表 12-3 ルータのプライベート ネットワーク トラフィックのマーキング(デフォルト)および遅延要件

優先順位
サーバ側での IP アドレスとポート
一方向の遅延要件
DSCP / 802.1p マーキング

IP アドレス:ルータの高優先順位プライベート IP アドレス

TCP ポート:MDS 高優先順位接続用に 41005 +(i# × 40)

UDP ポート:Unified ICM で QoS がイネーブルになっていない場合、UDP ハートビート用に 39500 ~ 39999

100 ミリ秒(50 ミリ秒を推奨)

AF31 / 3

IP アドレス:ルータの非高優先順位プライベート IP アドレス

TCP ポート:MDS 中優先順位接続用に 41016 +(i# × 40)

1,000 ミリ秒

AF11 / 1

IP アドレス:ルータの非高優先順位プライベート IP アドレス

TCP ポート:

MDS 低優先順位接続用に 41004 +(i# × 40)

CIC StateXfer 接続用に 41022 +(i# × 40)

CLGR StateXfer 接続用に 41021 +(i# × 40)

HLGR StateXfer 接続用に 41023 +(i# × 40)

RTR StateXfer 接続用に 41020 +(i# × 40)

1,000 ミリ秒

AF11 / 1

表 12-4 PG のプライベート ネットワーク トラフィックのマーキング(デフォルト)および遅延要件

優先順位
サーバ側での IP アドレスとポート
一方向の遅延要件
DSCP / 802.1p マーキング

IP アドレス:PG の高優先順位プライベート IP アドレス

TCP ポート:

PG #1 の MDS 高優先順位接続用に 43005 +(i# × 40)

PG #2 の MDS 高優先順位接続用に 45005 +(i# × 40)

UDP ポート:Unified ICM で QoS がイネーブルになっていない場合、UDP ハートビート用に 39500 ~ 39999

100 ミリ秒(50 ミリ秒を推奨)

AF31 / 3

IP アドレス:PG の非高優先順位プライベート IP アドレス

TCP ポート:

PG #1 の MDS 中優先順位接続用に 43016 +(i# × 40)

PG #2 の MDS 中優先順位接続用に 45016 +(i# × 40)

1,000 ミリ秒

AF11 / 1

IP アドレス:PG の非高優先順位プライベート IP アドレス

TCP ポート:

PG #1 の MDS 低優先順位接続用に 43004 +(i# × 40)

PG #2 の MDS 低優先順位接続用に 45004 +(i# × 40)

PG #1 の OPC StateXfer 用に 43023 +(i# × 40)

PG #2 の OPC StateXfer 用に 45023 +(i# × 40)

1,000 ミリ秒

AF11 / 1

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 トランクとして設定する必要があります。

switchport mode trunk
switchport trunk encapsulation dot1q
switchport trunk native vlan [data/native VLAN #]
switchport voice vlan [voice VLAN #]
switchport priority-extend trust
spanning-tree portfast
 

QoS 信頼の設定

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

mls qos
interface mod/port
mls qos trust dscp
 

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

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

class-map match-all Unified ICM_Public_High
match ip dscp af31
class-map match-all ICM_Public_Low
match ip dscp af11
 

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

policy-map ICM_Public_Queuing
class ICM_Public_High
priority 500
class ICM_Public_Low
bandwidth 250
 

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

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

policy-map Converged_Link_Queuing
class RTP
priority 400
class ICCS
bandwidth 600
class ICM_Public_High
bandwidth 500
class ICM_Public_Low
bandwidth 250
class ICM_Private_High
bandwidth 200
class ICM_Private_Low
bandwidth 100
 

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

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

interface mod/port
service-policy output ICM_Public_Queuing
 

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

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

access-list 100 permit tcp host Public_High_IP any
access-list 100 permit tcp any host Public_High_IP
access-list 101 permit tcp host Public_NonHigh_IP any
access-list 101 permit tcp any host Public_NonHigh_IP
 

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

class-map match-all ICM_Public_High
match access-group 100
class-map match-all ICM_Public_Low
match access-group 101
 

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

policy-map ICM_Public_Marking
class ICM_Public_High
set ip dscp af31
class ICM_Public_Low
set ip dscp af11
 

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

interface mod/port
service-policy input ICM_Public_Marking
 

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 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)です。


表 12-5 プライベート ネットワーク帯域幅の計算ワークシート

コンポーネント
実効 BHCA
乗数
推奨リンク
乗数
推奨キュー

Router + Logger

×30

× 0.8

Router と Logger の高優先度キューの合計帯域幅

Unified CM PG

× 100

× 0.9

これらのうち 3 つの値を加算し、その合計を下のグレー背景のボックスに記入して、PG の高優先度キューの帯域幅とします。

Unified IP IVR PG

× 60

× 0.9

Unified CVP PG

× 120

× 0.9

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

×((変数の数 × 変数の平均長さ)/40)

× 0.9

合計リンク サイズ

PG の高優先度キューの合計帯域幅

プライベート通信に使用するサイト間で専用リンクを 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 個あります。

表 12-6 組み合わせた専用プライベート リンクの計算例

コンポーネント
実効 BHCA
乗数
推奨リンク
乗数
推奨キュー

Router + Logger

11,000

× 30

330,000

× 0.8

264,000

Router と Logger の高優先度キューの合計帯域幅

Unified CM PG

11,000

× 100

1,100,000

× 0.9

990,000

これらのうち 3 つの値を加算し、その合計を下のグレー背景のボックスに記入して、PG の高優先度キューの帯域幅とします。

Unified IP IVR PG

14,000

× 60

840,000

× 0.9

756,000

Unified CVP PG

0

× 120

0

× 0.9

0

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

14,000

×((変数の数 × 変数の平均長さ)/40)

280,000

× 0.9

252,000

合計リンク サイズ

2,550,000

1,998,000

PG の高優先度キューの合計帯域幅

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

合計リンク = 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 つの項目だけを転送することを想定したものです(これは非常にまれなケースです)。

表 12-7 ワーストケース条件下において各データ項目で転送されるバイト数

転送されるデータ項目
サイズ

エージェント

500 バイト

コール タイプ

250 バイト

スキル グループ

625 バイト

デバイス(ルート ポイント、デバイス ターゲットなど)

315 バイト

たとえば、子 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 アプリケーションのメッセージ タイプを示します。

表 12-8 CTI OS Desktop アプリケーション別メッセージ タイプ

アプリケーション名
メッセージ タイプ

CTI OS Agent Desktop

エージェント状態の変更

コール制御

コール状態情報

チャット メッセージ

エージェントとスキル グループの統計情報

CTI OS Supervisor Desktop

エージェント状態の変更

コール制御

コール状態情報

エージェント状態の監視

サイレント モニタリング

チャット メッセージ

エージェントとスキル グループの統計情報

AllAgents Monitor Application

すべてのエージェント状態の変更

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

サイレント モニタリングでは、スーパーバイザは、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 に、各アプリケーションのメッセージ タイプを示します。

表 12-9 CAD デスクトップ アプリケーション別メッセージ タイプ

アプリケーション名
メッセージ タイプ

Cisco Agent Desktop

ログイン/ログオフ

エージェント状態の変更

コール制御

コール状態情報

デスクトップ モニタリングおよび録音

チャット メッセージ

チーム パフォーマンス メッセージ

レポート生成

リアルタイム データ リフレッシュ

Cisco Supervisor Desktop

ログイン/ログオフ

エージェント状態のアップデート

コール状態のアップデート

レポート生成

サイレント モニタリング

通話録音

コールの再生

チャット メッセージ

チーム パフォーマンス メッセージ

リアルタイム データ リフレッシュ

Cisco Desktop Administrator

構成情報の取得と保管

設定データのリフレッシュ

Cisco Desktop Monitoring Console

サービス ディスカバリ

SNMP Get メッセージ

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

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

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

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

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

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

チーム数:50

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

エージェントごとのコール数(毎時):60

チームごとのチーム パフォーマンス メッセージ(毎時):8

送信または受信されるチャット メッセージ(毎時):20

チャット メッセージ サイズの平均(バイト単位):40

録音されるコール数(毎時):10

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

表 12-10 Cisco Agent Desktop の平均的な帯域幅の要件

エージェント数
ダウンロードの平均帯域幅(キロバイト/秒)
アップロードの平均帯域幅(キロバイト/秒)

1

0.02

0.003

100

1.7

0.1

200

3.4

0.3

300

5.0

0.4

500

8.4

0.7

600

10.0

0.8

700

11.7

1.0

800

13.4

1.1

900

15.1

1.3

1000

16.8

1.4

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

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

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

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

表 12-11 Cisco Supervisor Desktop の帯域幅の要件

エージェント数
ダウンロードの平均帯域幅(キロバイト/秒)
アップロードの平均帯域幅(キロバイト/秒)

1

0.02

0.01

100

1.3

0.1

200

2.5

0.3

300

3.7

0.4

400

5.0

0.5

500

6.2

0.6

600

7.5

0.8

700

8.7

0.9

800

10.0

1.0

900

11.2

1.1

1000

12.4

1.3

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 ミリ秒を超えるネットワークではユーザ数に関係なくツールを適切に実行できないことが確認されました。

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

一方向の最大遅延(ミリ秒)
使用される帯域幅
サポートされるユーザ数

無視できる程度

LAN

8000

15

3.4 Mb 以上

4000

15

2 Mb

500

15

256 Kb

500

50

64 Kb 以上

25