この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco Unified CCX のシグナリングは、ネットワークの制御トラフィックにおけるごく一部分(Cisco Unified CCX サーバとエージェント/スーパーバイザ デスクトップ間でのやりとり)のみを表します。Unified CCX および CTI トラフィックに対する TCP ポートと Differentiated Services Code Point(DSCP)のマーキングの詳細については、
計算に音声が含まれていると帯域幅の推定が難しくなります。通常、WAN リンクは IP テレフォニー ネットワークで最低速の回線であるため、音声トラフィックがこれらのリンク間で送信されるときのパケット損失、遅延、およびジッタにも特に注意する必要があります。ネットワークに起因するその他の遅延に加え、G.729 方式による音声サンプリングの遅延は最小(わずか 30 ミリ秒)であるため、G.729 方式は WAN での使用に好まれるコーデックです。
帯域幅に音声が含まれている場所でのシステム構成では、次の要因についても考慮する必要があります。
遅延合計の見積もり(WAN の遅延、経由するローカルエリア ネットワークのシリアライゼーション遅延、およびネットワーク デバイスのフォワーディング遅延を考慮します)。ネットワーク内アプリケーションの一方向の遅延合計についてあらかじめ設定されている一般的な制限は、150 ミリ秒です。
アプリケーション自体に固有の遅延の影響。WAN の遅延がない場合、Unified CCX エージェントの平均ログイン時間は 8 秒です。この時間には、エージェント アプリケーションとさまざまなサーバ間での約 1,000 のメッセージ交換が含まれます。エージェントの全体的なログイン時間は、30 ミリ秒の WAN の遅延が発生するたびにほぼ 30 秒ずつ増えます。
ルーティング プロトコルの影響。たとえば、Enhanced Interior Gateway Routing Protocol(EIGRP)の場合、収束時間はわずかで、帯域幅は控えめに使用されます。また、EIGRP の収束は、コール処理と Unified CCX エージェントのログインにほとんど影響を与えません。
エージェント コールのサイレント モニタリングと録音の方式。使用する方式によって、特定のネットワーク リンクでの帯域幅負荷が異なります。
フレーム リレー |
128 KB |
256 KB |
512 KB |
768 KB |
T1 |
---|---|---|---|---|---|
G.729 |
3 |
7 |
15 |
25 |
38 |
G. 711 |
該当なし |
該当なし |
該当なし |
該当なし |
18 |
リモート エージェントの展開では、QoS メカニズムを使用して WAN の帯域幅利用率を最適化する必要があります。ディストリビューションとコア エリアでは、高度なキューイングおよびスケジューリング手法を使用する必要もあります。集中型コール処理配置のプロビジョニング ガイドラインについては、『Cisco IP Telephony Solution Reference Network Design』を参照してください。このドキュメントは次の URL からオンラインで入手できます。http://www.cisco.com/go/ucsrnd
IP フォン コールは、2 種類のデータ ストリームから構成されています。1 つのストリームは電話機 A から電話機 B に送信されます。他のストリームは電話機 B から電話機 A に送信されます。音声データはパケットにカプセル化されて、ネットワーク経由で送信されます。音声ストリームを保管するのに必要なデータ量は、データの符号化に使用されるコーデックに応じて異なります。
音声データ自体は、Real-Time Transport Protocol(RTP)を使用してネットワークに転送されます。RTP プロトコルは、無音圧縮なしをサポートしています。無音圧縮を使用する場合は、音部分がないと、音声パケットはネットワークを介して送信されません。
それ以外の場合は、無音のパケットでも送信されます。これにより、コールに必要な平均帯域幅は少なくなります。無音圧縮はサポートされますが、ネットワークのプロビジョニング時は、無音圧縮用に必要とされる低い帯域幅は使用しないでください。これは、ワーストケースのシナリオとしてコールが無音でないことがあり、このために無音圧縮が有効にされなかった場合と同様の最大の帯域幅が要求される場合があるためです。
IP コールの帯域幅を計算する場合は、RTP パケットのサイズに加えて、ネットワークでの RTP データ転送に使用するネットワーキング プロトコルの追加オーバーヘッドを使用する必要があります。
たとえば、20 ミリ秒のスピーチ データを送信する G.711 パケットでは、ストリームごとに 64 kbps(キロバイト/秒)のネットワーク帯域幅が必要です。これらのパケットは、4 層のネットワーキング プロトコル(RTP、UDP、IP、およびイーサネット)でカプセル化されます。これらのプロトコルはそれぞれ、個別のヘッダー情報を G.711 データに追加します。その結果、いったんイーサネット フレームにパッケージされた G.711 データは、ネットワークを伝送するデータ ストリームごとに 87.2 kbps の帯域幅が必要になります。IP フォン コールは 2 つの音声ストリームから構成されているため、この例では、1 コールにつき 174.4 kbps の帯域幅が必要です。
単一パケット内の音声データの量もパケットのサイズや帯域幅に影響を及ぼします。前述の例では 20 ミリ秒のスピーチを含むパケットを使って計算していますが、Unified CM の設定では、対応しているコーデックごとにこの値が異なることがあります。パケットにさらに多くのスピーチ情報を含めるように設定すると、ネットワーク経由で送信されるパケットの数と帯域幅が減少します。これは、追加のネットワーキング ヘッダーを含むパケットは減少しますが、パケットのサイズが増加するからです。
コーデック |
パケットあたりのスピーチの長さ(ミリ秒) |
コールごとに必要な帯域幅(Kbps) |
---|---|---|
G.711 |
10 |
220.8 |
G.711 |
20 |
174.4 |
G.711 |
30 |
159.0 |
G.729 |
10 |
108.8 |
G.729 |
20 |
62.4 |
G.729 |
30 |
47.0 |
G.729 |
40 |
39.2 |
G.729 |
50 |
34.6 |
G.729 |
60 |
31.4 |
次の表は、VoIP プロバイダーが処理する同時モニタリング セッションで必要な帯域幅について、ネットワーク接続に基づいて計算した使用可能な総帯域幅の割合を示しています。
同時モニタリング セッションの数 |
利用可能な帯域幅要件のパーセンテージ(無音圧縮なし) |
|||||||
---|---|---|---|---|---|---|---|---|
100 Mbps |
10 Mbps |
1.544 Mbps |
640 kbps |
256 kbps |
128 kbps |
64 kbps |
56 kbps |
|
コールのみ |
0.1 |
0.9 |
5.6 |
13.6 |
34.1 |
68.1 |
サポートされていない(NS)1 |
|
1 |
0.3 |
2.6 |
16.8 |
40.9 |
NS |
NS |
NS |
NS |
2 |
0.4 |
4.4 |
28.1 |
68.1 |
NS |
NS |
NS |
NS |
3 |
0.6 |
6.1 |
39.3 |
95.4 |
NS |
NS |
NS |
NS |
4 |
0.8 |
7.8 |
50.5 |
NS |
NS |
NS |
NS |
NS |
5 |
1.0 |
9.6 |
61.7 |
NS |
NS |
NS |
NS |
NS |
6 |
1.1 |
11.3 |
72.9 |
NS |
NS |
NS |
NS |
NS |
7 |
1.3 |
13.1 |
84.2 |
NS |
NS |
NS |
NS |
NS |
8 |
1.5 |
14.8 |
95.4 |
NS |
NS |
NS |
NS |
NS |
9 |
1.7 |
16.6 |
NS |
NS |
NS |
NS |
NS |
NS |
10 |
1.8 |
18.3 |
NS |
NS |
NS |
NS |
NS |
NS |
同時モニタリング セッションの数 |
利用可能な帯域幅要件のパーセンテージ(無音圧縮なし) |
||||||
---|---|---|---|---|---|---|---|
100 Mbps |
10 Mbps |
1.544 Mbps |
640 kbps |
256 kbps |
128 kbps |
64 kbps |
|
コールのみ |
0.0 |
0.3 |
2.0 |
4.9 |
12.2 |
24.4 |
48.8 |
1 |
0.1 |
0.9 |
6.0 |
14.6 |
36.6 |
73.1 |
サポートされていない(NS)2 |
2 |
2 |
1.6 |
10.0 |
24.4 |
60.9 |
NS |
NS |
3 |
2 |
2.2 |
14.1 |
34.1 |
85.3 |
NS |
NS |
4 |
0.3 |
2.8 |
18.1 |
43.9 |
NS |
NS |
NS |
5 |
0.3 |
3.4 |
22.1 |
53.6 |
NS |
NS |
NS |
6 |
0.4 |
4.1 |
26.1 |
63.4 |
NS |
NS |
NS |
7 |
0.5 |
4.7 |
30.1 |
73.1 |
NS |
NS |
NS |
8 |
0.5 |
5.3 |
34.1 |
82.9 |
NS |
NS |
NS |
9 |
0.6 |
5.9 |
38.1 |
92.6 |
NS |
NS |
NS |
10 |
0.7 |
6.6 |
42.2 |
NS |
NS |
NS |
NS |
帯域幅の値は、当該接続の最高速度に基づいて計算される。接続の実際の速度は、多様な要因のため明示された最大速度とは異なる場合があります。
帯域幅の要件は、アップロードの速度を基準にする。ダウンロードの速度は、IP フォン コールの着信ストリームにのみ影響します。
各値は 20 ミリ秒のスピーチを含む音声パケットを基準にする。
各パケットのバイト数には、イーサネットによるカプセル化全体が含まれる。
データは無音圧縮なしの CODEC を表す。無音圧縮ありの場合は、使用される帯域幅の量は少なくなる場合があります。
提示するデータは、モニタリングされるコールのスピーチ品質については対処しません。帯域幅の要件が利用可能な合計の帯域幅に近く、他のアプリケーションとネットワーク アクセスを共有する必要がある場合、音声パケットの遅延(パケットの遅れ)がモニタリングされるスピーチの品質に影響を及ぼす場合があります。ただし、遅延は録音されたスピーチの品質には影響しません。
Unified CCX を Cisco SocialMiner と共に配置する場合は、次のネットワーク要件を順守してください。
遅延:Unified CCX サーバと SocialMiner 間の最大許容ラウンドトリップ時間(RTT)は、150 ミリ秒です。
帯域幅:Unified CCX と Unified CM のクラスタの要件に加えて、Web チャットを正常に配置するには、SocialMiner、Web サーバ、リモート エージェント/スーパーバイザのデスクトップに十分な帯域幅をプロビジョニングする必要があります。次のコンポーネントに必要な帯域幅を考慮してください。
Unified CCX と SocialMiner:SocialMiner と Unified CCX を同じ場所に配置しない場合は、通信およびコンタクト シグナリングに対する帯域幅要件が増加します。
SocialMiner と Cisco Finnese Agent Desktop:チャット セッションを開始すると、チャット ログのサイズと通信頻度に応じて、SocialMiner と Finnese Cisco Agent Desktop 間の帯域幅要件が増加します。
SocialMiner とカスタマー Web サイト:カスタマー Web サイトはすべての新しいチャット コンタクト要求を SocialMiner に転送します。チャット コンタクトが SocialMiner に到着すると、アクティブ セッションは維持され、チャットが開始されると、チャット エージェントとカスタマー Web サイトは発着信データ トラフィックでチャット メッセージを伝送します。カスタマー Web サイトが SocialMiner と同じネットワーク上にない場合は、帯域幅要件がセッション単位の平均チャット トラフィックに基づく必要があります。
次の表は、Unified CCX と SocialMiner が同じネットワーク上にない場合の最低限の帯域幅要件を示しています。
(注) | これらの数値は、ネットワーク全体の効率によって異なります。 |
Unified CCX と SocialMiner の間(kbps) |
Unified CCX と Agent Desktop の間(kbps) |
SocialMiner と Agent Desktop の間(kbps) |
カスタマー Web サーバと SocialMiner の間(kbps) |
|
---|---|---|---|---|
実際のデータ帯域幅 |
3.35 1 |
4.02 2 |
12 3 |
12 3 |
HTTP トラフィックとその他の要因を考慮に入れたデータ帯域幅 |
40 |
40 |
100 |
100 |
1 次の式に基づいて、シグナル通信で使用するネットワーク帯域幅を割り当てます。
シグナリングのネットワーク帯域幅(Kbps 単位)= 1 秒あたりの新規チャット セッションの数 x チャット セッションごとのメッセージ数 x 平均メッセージ サイズ
例
平均チャット時間が 3 分間、Busy Hour Call Completions(BHCC)が 2400(サポートされている最大数)である場合、1 秒あたりのチャット セッション数は 0.67 になります。平均では、各チャット セッションに状態シグナリングとコンタクト インジェクション用の 5 つのメッセージがあり、各メッセージが 1 KB(500 文字)である場合、帯域幅使用量は 0.67 x 5 × 1 kbps = 3.35 kbps になります。
2 次の式に基づいて、シグナル通信で使用するネットワーク帯域幅を割り当てます。
シグナリングのネットワーク帯域幅(Kbps 単位)= 1 秒あたりの新規チャット セッションの数 x チャット セッションごとのメッセージ数 x 平均メッセージ サイズ
例
平均チャット時間が 3 分間、BHCC が 2400(サポートされている最大数)である場合、1 秒あたりのチャット セッション数は 0.67 になります。平均では、各チャット セッションに 3 つのメッセージがあり、各メッセージが 2 KB(1000 文字)である場合、帯域幅使用量は 0.67 x 3 x 2 kbps = 4.02 kbps になります。
3 次の式に基づいて、チャットで使用するネットワーク帯域幅を割り当てます。
チャットのネットワーク帯域幅(Kbps 単位)= 1 秒あたりのチャット セッションの送信メッセージ数 x 平均メッセージ サイズ
例
120 セッションのすべてがアクティブで、チャット セッションの 10 % が毎秒メッセージを送信している場合、120 x 10/100 = 12 のチャット セッションが毎秒メッセージを送信しています。
平均メッセージ サイズが 1 KB(500 文字)である場合、チャットのネットワーク帯域幅は 12 kbps になります。
Unified CCX を Cisco SocialMiner と共に配置する場合は、次のネットワーク要件を順守してください。
遅延:Unified CCX サーバと SocialMiner 間の最大許容ラウンドトリップ時間(RTT)は、150 ミリ秒です。
帯域幅:Unified CCX と Unified Communications Manager のクラスタの要件に加えて、エージェント電子メールを正常に展開するには、SocialMiner、メール サーバ、リモート エージェント/スーパーバイザのデスクトップに十分な帯域幅をプロビジョニングする必要があります。
次の表は、Unified CCX と SocialMiner が同じネットワーク上にない場合の最低限の帯域幅要件を示しています。
(注) | これらの数値は、ネットワーク全体の効率によって異なります。 |
|
Unified CCX と SocialMiner の間(kbps) |
---|---|
実際のデータ帯域幅 |
0.67 1 |
HTTP トラフィックとその他の要因を考慮に入れたデータ帯域幅 |
40 |
1 次の式に基づいて、シグナル通信で使用するネットワーク帯域幅を割り当てます。
シグナリングのネットワーク帯域幅(Kbps 単位)= 1 秒あたりの新規電子メール セッションの数 x 電子メール セッションごとのメッセージ数 x 平均メッセージ サイズ
例
1 時間あたり 400 の電子メール(サポートされる最大数)がある場合、1 秒あたり 0.11 の電子メール セッションとなります。平均では、各電子メール セッションに状態シグナリングとコンタクト インジェクション用の 6 つのメッセージがあり、各メッセージが 1 KB(500 文字)である場合、帯域幅使用量は 0.11 x 6 × 1 KB = 0.67 KBps になります。
|
Unified CCX と Agent Desktop の間(kbps) |
---|---|
実際のデータ帯域幅 |
2.22 2 |
HTTP トラフィックとその他の要因を考慮に入れたデータ帯域幅 |
40 |
2 次の式に基づいて、シグナル通信で使用するネットワーク帯域幅を割り当てます。
シグナリングのネットワーク帯域幅(Kbps 単位)= 1 秒あたりの新規電子メール セッションの数 x 電子メール セッションごとのメッセージ数 x 平均メッセージ サイズ
例
1 時間あたり 400 の電子メール(サポートされる最大数)があり、エージェントが同時に 5 件の電子メールを処理できる場合、1 秒あたり 0.11 件の電子メールになります。エージェントは電子メールに対して直接再キューイングまたは応答を実行できます。電子メール メッセージの平均 10% が再キューイングされるとして、システム内に 100 の電子メール CSQ、各 1KB の 3 つのメッセージがあり、再キューイング リスト メッセージが 10 KB の場合、帯域幅の要件は次のようになります。
ネットワーク帯域幅(KBps) = 同時電子メール数 x 1 秒あたりの新規電子メール セッション数 x [(電子メール セッションごとのメッセージ数 x 平均メッセージ サイズ) + (再キューイングされる電子メールの割合 x 再キューイングされたリスト メッセージのサイズ)]
5 x 0.11 x ((3 x 1 KB) + (0.1 x 10 KB)) = 2.22 KBps
Agent Desktop、SocialMiner、および Exchange Server 間に存在するエージェント電子メール フローには 4 種類あります。
[基本的な電子メール(Basic Email)] フロー:添付ファイルはなく再キューイングも実行されません。
[添付ファイル付き電子メール(Email with attachments)] フロー:カスタマーの電子メールおよびエージェントの返信に添付ファイルが含まれます。
[電子メール再キューイング(Email requeue )] フロー:カスタマーの電子メールは他のキューに送信されます。
[添付ファイル付き電子メール再キューイング(Email requeue with attachments)] フロー:カスタマーの電子メールには添付ファイルが含まれます。電子メールが再キューイングされ、エージェントの返信には添付ファイルが含まれます。
上記に示すフローは計算を控えめなものにする極端な例が含まれます。
再キューイングおよび添付ファイルは 10% で発生することが予期されます。1 時間あたりの電子メールの最大数は 400 です。各タイプのフローの発生は、まず基本および再キューイング フローを計算し、次に、添付ファイルを含む基本および再キューイング フローの数を計算することによって算出されます。
最大値を考慮した後、計算は次のようになります。
SocialMiner および Unified CCX が同じ場所に配置されていない場合は、通信およびコンタクトのシグナルに追加の帯域幅が必要です。
|
Agent Desktop と SocialMiner 間 |
---|---|
実際のデータ帯域幅 |
1 時間あたり 3560160 KB |
HTTP トラフィックとその他の要因を考慮に入れたデータ帯域幅 |
1024 KBps |
例
6 KB の電子メール サイズおよび 6 KB のエージェント返信を使用すると、各フローに対する Agent Desktop と SocialMiner 間の一連のメッセージに対する帯域幅要件は次のようになります。
添付ファイル付き電子メール フロー = 31888 KB
Finesse に UI ファイルをロード = 6144 KB
シグナリング = 6 KB
添付ファイル付き電子メール本文取得 = カスタマー電子メール サイズ + 添付ファイル サイズ = 5126 KB
下書き保存 = エージェント返信サイズ x (SLA / 下書き保存間隔) = 120 KB
カスタマー添付ファイル ダウンロード = 添付ファイルサイズ = 5120 KB
エージェント添付ファイル アップロード = 添付ファイルサイズ = 5120 KB
エージェント添付ファイル ダウンロード = 添付ファイルサイズ = 5120 KB
添付ファイル付きで返信送信 = カスタマー電子メール サイズ + エージェント返信サイズ + 添付ファイル サイズ = 5132 KB
電子メール再キューイング フロー = 6300 KB
添付ファイル付き電子メール再キューイング フロー = 37020 KB
Finesse に UI ファイルをロード = 6144 KB
シグナリング(コンタクト取得 + コンタクト予約) = 6 KB
添付ファイル付き電子メール本文取得 = カスタマー電子メール サイズ + 添付ファイル サイズ = 5126 KB
シグナリング(再キューイング + コンタクト取得 + コンタクト予約) = 6 KB
添付ファイル付き電子メール本文取得 = カスタマー電子メール サイズ + 添付ファイル サイズ = 5126 KB
下書き保存 = エージェント返信サイズ x (SLA / 下書き保存間隔) = 120 KB
カスタマー添付ファイル ダウンロード = 添付ファイルサイズ = 5120 KB
エージェント添付ファイル アップロード = 添付ファイルサイズ = 5120 KB
エージェント添付ファイル ダウンロード = 添付ファイルサイズ = 5120 KB
添付ファイル付きで返信送信 = (カスタマー電子メール サイズ + エージェント返信サイズ + 添付ファイル サイズ) = 5132 KB
総帯域幅は 1 時間あたり 3560160 KB です。Agent Desktop と SocialMiner 間の帯域幅(KBps)は 1024 KBps です。
SocialMiner は Agent Desktop から電子メールを取得し、下書きを保存して、メール サーバに電子メールを送信する必要があります。メール サーバが SocialMiner と同じネットワーク上にない場合は、帯域幅要件がセッション単位の平均電子メール トラフィックに基づく必要があります。
|
SocialMiner およびメール サーバ間(KBps) |
---|---|
実際のデータ帯域幅 |
1 時間あたり 1516720 KB |
HTTP トラフィックとその他の要因を考慮に入れたデータ帯域幅 |
512 KBps |
例
6 KB の電子メール サイズおよび 6 KB のエージェント返信を使用すると、各フローに対する SocialMiner および メール サーバ間の一連のメッセージに対する帯域幅要件は次のようになります。
添付ファイル付き電子メール フロー = 35996 KB
添付ファイル付きのカスタマー電子メールの初期フェッチ = カスタマー電子メール サイズ + 添付ファイルのサイズ = 5126 KB
添付ファイル付き電子メール本文取得 = カスタマー電子メール サイズ + 添付ファイル サイズ = 5126 KB
下書き保存 = エージェント返信サイズ x (SLA / 下書き保存間隔) = 120 KB
カスタマー添付ファイル ダウンロード = 添付ファイルサイズ = 5120 KB
エージェント添付ファイル アップロード = 添付ファイルサイズ = 5120 KB
エージェント添付ファイル ダウンロード = 添付ファイルサイズ = 5120 KB
添付ファイル付きで返信送信 = 2 x (カスタマー電子メール サイズ + エージェント返信サイズ + 添付ファイル サイズ) = 10264 KB
電子メール再キューイング フロー = 162 KB
添付ファイル付き電子メール再キューイング フロー = 41122 KB
添付ファイル付きのカスタマー電子メールの初期フェッチ = カスタマー電子メール サイズ + 添付ファイルのサイズ = 5126 KB
添付ファイル付き電子メール本文取得 = カスタマー電子メール サイズ + 添付ファイル サイズ = 5126 KB
再キューイング後に添付ファイル付き電子メール本文取得 = カスタマー電子メール サイズ + 添付ファイル サイズ = 5126 KB
下書き保存 = エージェント返信サイズ x (SLA / 下書き保存間隔) = 120 KB
カスタマー添付ファイル ダウンロード = 添付ファイルサイズ = 5120 KB
エージェント添付ファイル アップロード = 添付ファイルサイズ = 5120 KB
エージェント添付ファイル ダウンロード = 添付ファイルサイズ = 5120 KB
添付ファイル付きで返信送信 = 2 x (カスタマー電子メール サイズ + エージェント返信サイズ + 添付ファイル サイズ) = 10264 KB
総帯域幅は 1 時間あたり 1516720 KB です。SocialMiner とメール サーバ間の帯域幅(KBps)は 512 kbps です。
一般に、通常の Context Service 要求には同じ地域内で 100 ~ 300 ミリ秒かかり、国外との通信で最大 1.2 ~ 1.5 秒かかる場合があります。
ネットワークですでに増え続けているデータ トラフィックにさらに音声およびアプリケーション関連のトラフィックが追加されると、Quality of Service(QoS)が問題になります。したがって、Unified CCX や音声などの時間的精度が要求されるトラフィックでは、この要求度が低いファイル転送や電子メールなどに比べて、より高い QoS 保証が必要になります(統合ネットワークを使用している場合は特に)。
パケット分類と使用状況のポリシーである、ポリシー ベース ルーティング(PBR)や専用アクセス レート(CAR)などは、ネットワークのエッジに適用されます。
低遅延キューイング(LLQ)などのエンドツーエンドのキューイング メカニズム。低速リンクでは音声が遅延やジッタの増加の影響を受けやすいため、Link Fragmentation and Interleaving(LFI)を使用して、大きいデータグラムを分割して生成される小さいパケットで低遅延トラフィックをインターリーブすることで遅延やジッタを軽減することもできます。
トラフィック シェーピングなどのスケジューリング メカニズムを使用して出力リンクでの帯域幅利用率を最適化します。
次の表は、Unified CCX および Unified CM のミッション クリティカルな CTI トラフィックの順位付けで使用する、TCP ポートと DSCP マーキングを示しています。Unified CCX と Cisco Unified Communication Manager 間のコール シグナリング トラフィックの DSCP マーキング、および Unified CCX サーバから再生される音声トラフィックの DSCP マーキングは、トラフィック分類の推奨ガイドラインに従ってデフォルトでセットされます。このガイドラインは、次の URL にある『Cisco Unified Communications System Design Guidance』に記載されています。
http://www.cisco.com/go/ucsrnd。
Unified CCX は、ここで説明しているもの以外のネットワーク トラフィックをマーキングしません。そのため、表の推奨事項に従って、エッジでトラフィックをマーキングして優先順位を付ける必要があります。
QoS の詳細な説明は、この設計ガイドの対象外です。QoS 設計の推奨事項については、次の URL にある Quality of Service デザイン ガイドを参照してください。
http://www.cisco.com/go/designzone
Unified CCX コンポーネント |
インターフェイス/プロトコル |
ポート |
DSCP マーキング |
---|---|---|---|
Unified CCX Engine:Unified CCX から Unified CM への CTI-QBE メッセージ |
CTI-QBE |
TCP 2748 |
CS3 |
Unified CCX Administration および BIPPA サービス:Unified CCX 上の Web 管理および BIPPA インターフェイスへの HTTP トラフィック |
HTTP / HTTPS |
TCP 8443 |
AF21 |
Unified CCX Engine および Unified CCX Administration:Unified CCX から Unified CM への SOAP AXL HTTPS メッセージング |
HTTPS / SOAP |
TCP 8443 |
AF21 |
Unified CCX Engine:CAD クライアントから Unified CCX への CTI メッセージング |
[CTI] |
TCP 12028 |
CS3 |
Unified CCX Engine:RTP 音声ベアラ トラフィック(双方向) |
RTP |
UDP 16384 ~ 32767 |
EF |
Unified CM では、クラスタ内のエンドポイント間でリソース予約プロトコル(RSVP)がサポートされるようになりました。RSVP は、コール アドミッション制御(CAC)で使用されるプロトコルで、コールの帯域幅予約のためにネットワーク内のルータで使用されます。制御される帯域幅は、音声ストリーム専用であり、コール シグナリング トラフィックは CAC の一部ではありません。
RSVP の採用前は、帯域幅の使用状況を計算するために、各 Unified CM クラスタがそれぞれに、地点間で送受信されるアクティブ コール数の計算をサポートしていました。2 つ以上の Unified CM クラスタで同じリンクを共有している場合は、各クラスタに専用の帯域幅を確保する必要があるため、この方法では帯域幅を効率的に使用できませんでした。また、ユーザは RSVP を使用して複雑なネットワーク トポロジを配置することもできますが、その一方で、ロケーション ベースの CAC はハブアンドスポーク タイプのトポロジに限定されます。
RSVP は、IP Phone と同じ LAN 上にある 2 つの RSVP エージェント間のパスを追跡することで、この問題を解決します。Cisco IOS で実行されるソフトウェアのメディア ターミネーション ポイント(MTP)またはソフトウェアの トランスコーダ リソースは、RSVP エージェントにできます。RSVP エージェントは Unified CM で制御され、コールの発信時に 2 台の IP フォン間のメディア ストリームに挿入されます。発信元 IP フォンの RSVP エージェントは、宛先 IP フォンの RSVP エージェントまでのネットワークを確認し、帯域幅を予約します。ネットワーク ルータ(および Unified CM 以外)が帯域幅の使用状況を追跡するので、コールが複数の Unified CM によって制御される場合でも、RSVP で制御される同じリンクを複数のコールで共有できます。
詳細については、『Cisco Unified Communications Solution Reference Network Design (SRND)』の RSVP の章を参照してください。
Unified CCX は、RSVP またはロケーション ベースの CAC を使用して、メカニズムには関係なく、コール センター エージェントを選択します。帯域幅不足によってエージェントの電話がコールを受信できない場合でも、Unified CCX は対応可能なエージェントにコールをルーティングします。サイト間で帯域幅を適切にサイジングすることは、非常に重要です。
どのようなコール転送でも、2 つのコールがアクティブになる瞬間があります。いずれかのアクティブなコールがサイト間を通過すると、CAC が使用されます。元のコールが転送中に保留になった場合でも、このコールは、アクティブなコールとまったく同量の帯域幅を占有します。
次の 2 つの例では、音声ゲートウェイとエージェントがリモート サイトに配置され、Unified CCX サーバがデータセンターのサイトに配置されています。PSTN からリモート サイトの音声ゲートウェイに到達したコールは、データセンターの Unified CCX に接続します。この接続には WAN リンクを経由する 1 コールの帯域幅が使用され、これは発信者側のストリームで表されます。エージェントが利用可能になり、リモート サイトで選択されると、Unified CCX からこのエージェントにコールが転送されます。
転送時に、エージェントがコールをピックアップする前に、Unified CCX とエージェントの電話の間で別のコールがセットアップされます。これには、WAN 上の別のコールの帯域幅が使用されます。これは、前の例の図でエージェント ストリームとして示されています。エージェントがこのコールをピックアップすると、音声トラフィックは、いずれもリモート サイトに配置されている音声ゲートウェイとエージェントの電話機の間に流れます。次の例に示すように、その時点では、帯域幅は WAN で予約されません。この例では、コールの帯域幅がコンタクト センターのコールにどのように予約されて最終的にエージェントにルーティングされるかを示します。音声ゲートウェイ、エージェント、Unified CCX サーバが配置されている場所に応じて、WAN の帯域幅を適切にプロビジョニングする必要があります。
エージェントおよびスーパーバイザのログイン操作には、Web ページのロードが関連し、初期のエージェント状態の表示と CTI ログインが含まれます。デスクトップ Web ページのロード後は、必要な帯域幅は大幅に少なくなります。
Cisco Finesse は Web アプリケーションであるため、キャッシングによって必要な帯域幅が大きく影響を受ける可能性があります。ログインに必要な帯域幅を最小化するために、ブラウザでキャッシングが有効になっていることを確認してください。
帯域幅の計算に役立つように、Cisco Finesse にはクライアントのログイン時に必要な帯域幅を概算できる帯域幅計算ツールがあります。
Cisco Finesse の帯域幅計算ツールには、Cisco Finesse コンテナのサードパーティ ガジェットに必要な帯域幅や、エージェントのデスクトップ クライアントで実行されるその他のアプリケーションに必要な帯域幅は含まれていません。
帯域幅計算ツールを使う際は、帯域幅を共有する他のアプリケーションの帯域幅も考慮に入れる必要があり、その計算結果の帯域幅が Cisco Finesse で利用できる必要があります。十分な帯域幅を継続的に利用できない場合、帯域幅を共有する音声の品質も含め、Cisco Finesse のインターフェイス パフォーマンスが低下する可能性があります。
Cisco Finesse エージェントおよび Supervisor Desktop は、Unified CCX とは別な場所に配置できます。Unified CCX サーバとエージェント デスクトップ間のラウンドトリップ時間は、400 ミリ秒未満でなければなりません。
Cisco Finesse は、ネットワーク トラフィックでの QoS の設定をサポートしていません。通常、トラフィックの QoS 分類とマーキングはスイッチまたはルータ レベルで行われます。特に WAN を介するエージェントの場合は、シグナリング トラフィックを優先させることができます。
Unified Intelligence Center のインストールでは、帯域幅に関する次の 2 つの考慮事項があります。
Unified CCX データベースは、サーバに対してローカルです。通常の動作モードでは、Unified Intelligence Center とデータ ソース間の帯域幅は無視されます。
(注) | 各レポートでは、ユーザと Unified Intelligence Center 間の帯域幅として約 2.6 Mbps が必要です。 |
帯域幅に影響する設定パラメータは次のとおりです。
MediaSense では、クラスタ内のサーバ間に遅延が 2 ms 以下のギガビット LAN 接続が必要です。
なし