Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）Release 8.0(x)

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

Unified CVP 環境では、WAN および LAN トラフィックを次のカテゴリにグループ化できます。

• 「音声トラフィック」

• 「呼制御トラフィック」

• 「データ トラフィック」

音声トラフィック

音声コールは、実際の音声サンプルが含まれた、Real-Time Transport Protocol（RTP; リアルタイム転送プロトコル）パケットで構成されています。RTP パケットは、次の場合に送信されます。

• 入力 PSTN ゲートウェイまたは発信元 IP 電話と、次のいずれかとの間

– 別の IP 電話（エージェントなど）

宛先の電話は、入力ゲートウェイや発信 IP 電話と共存しているかまたは異なる場所にあり、WAN または LAN を介して接続できます。

– （レガシー ACD または IVR の）TDM ACD のフロント エンドとなる出力ゲートウェイ

出力ゲートウェイは、入力ゲートウェイと共存しているかまたは異なる場所にあり、WAN または LAN を介して接続できます。

– プロンプト/コレクト処理を実行する VoiceXML ゲートウェイ

VoiceXML ゲートウェイは、通常、入力ゲートウェイと同じゲートウェイですが、別のゲートウェイにすることもできます。いずれの場合も、一般に入力ゲートウェイと VoiceXML ゲートウェイは共存します（同じ LAN に展開されます）。通常は LAN で接続しますが、WAN を介して接続することもできます。

• VoiceXML ゲートウェイと ASR/TTS サーバ間。VoiceXML ゲートウェイと ASR/TTS サーバ間の RTP ストリームは、G.711 である必要があります。

G.729 と G.711 のコーデックのサポート

CVP では、Cisco Unified Border Element Enterprise Edition（CUBE）および Cisco Unified Communications Manager（Unified CM）を使用したスタンドアロンおよび包括 SIP 展開で G.711 および G.729 コーデックの混在がサポートされます。SIP トランクを介してキャリアから CUBE に入力されるコールには、混在コーデックのサポートに IOS 15.1(2)T 以降の T リリースが必要です。コールのレッグではコーデックを任意に組み合わせて使用できます。

CVP 展開での混在コーデックの使用の詳細については、「G.729 および G.711 コーデックの混在サポート」を参照してください。

G.711 コーデックの利点と欠点は、次のとおりです。

• プロンプトを G.729 に変換する必要がありません。

• ただし、ソリューションでは、WAN リンクを介したより多くの帯域幅が必要となります。

G.729 コーデックの利点と欠点は、次のとおりです。

• 追加の帯域幅が必要ありません。

• すべてのプロンプトを G.729 に変換する必要があります。

• G.729 プロンプトの音質は、G.711 プロンプトよりも劣ります。

• ASR/TTS を使用できません。

呼制御トラフィック

Unified CVP ソリューションには、複数のタイプの呼制御トラフィックがあります。呼制御機能には、コールの設定、維持、破棄、またはリダイレクトに使用される機能が含まれます。

H.323 または SIP

Unified CVP は、現在、3 つのタイプの VoIP エンドポイント（Cisco IOS 音声ゲートウェイ、Cisco Unified Communications Manager（Unified CM）、および呼制御モードまたはシグナリング モードの PGW）で認定されています。呼制御トラフィック フローは、次のエンドポイント間で発生します。

• 入力ゲートウェイから Unified CVP コール サーバ、およびその反対方向

入力ゲートウェイには、PGW、Unified CM、Cisco IOS ゲートウェイ、またはその他の SIP デバイス（SIP の場合）があります。接続は、WAN または LAN を介して確立できます。

• Unified CVP コール サーバから出力ゲートウェイ、およびその反対方向

出力ゲートウェイには、Unified CM または Cisco IOS ゲートウェイがあります。出力ゲートウェイは、プロンプト/コレクト処理を発信者に提供するために使用される VoiceXML ゲートウェイであるか、またはエージェント（Unified CCE または TDM）やレガシー TDM IVR への転送のターゲットです。接続は、WAN または LAN を介して確立できます。

（注） 現在承認されている展開設計では、PGW および Unified CVP 間の相互運用性のための SIP をサポートしていません。この機能が設計で必要な場合は、Cisco Assessment to Quality（A2Q）チームに問い合わせてください。

GED-125

Unified CVP コール サーバおよび Unified ICM VRU PG は、GED-125 プロトコルを使用して通信します。GED-125 プロトコルには、次が含まれます。

• 発信者エクスペリエンスを制御するメッセージ（コールが到着したときの通知など）

• 発信者を転送または切断する指示

• 発信者エクスペリエンスに対する IVR 処理を制御する指示

VRU PG は、通常、LAN 接続を介して CVP に接続します。ただし、WAN を介したクラスタリングを使用する展開では、Unified CVP は、WAN を介して冗長 VRU PG に接続できます。

このとき、VRU PG と Unified CVP 間の通信を特別に処理するツールはありません。ただし、Unified ICM Central Controller と VRU PG 間で消費される帯域幅は、VRU PG と Unified CVP 間で消費される帯域幅と非常によく似ています。

VRU ペリフェラル ゲートウェイと ICM Central Controller 間の Bandwidth Calculator ツールは、次の URL にあるシスコの Steps to Success ポータルから（適切なログイン認証を使用して）入手できます。

http://tools.cisco.com/s2s/HomePage.do?method=browseHomePage

また、次の URL にある Bandwidth Calculator に（適切なログイン認証を使用して）直接アクセスすることもできます。

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

複数の VRU PG が WAN を介して分離されている場合、必要となる帯域幅は、計算ツールによって報告された数値の 2 倍になります。そのうちの 1 倍分が Unified ICM Central Controller から VRU PG 用で、残りの 1 倍分が VRU PG から Unified CVP 用となります。

Media Resource Control Protocol（MRCP）

VoiceXML ゲートウェイは、Media Resource Control Protocol（MRCP）v1.0 を使用して、ASR/TTS サーバと通信します。このプロトコルは、現在、Real-Time Streaming Protocol（RTSP; リアルタイム ストリーミング プロトコル）と連携して機能して、ASR/TTS サーバ（Nuance、Scansoft、IBM WebSphere Voice Server など）への制御接続の確立を支援しています。接続は、LAN または WAN を介して確立できます。

ICM Central Controller から Unified CVP VRU PG へのトラフィック

Unified ICM Central Controller と Unified CVP VRU PG 間の通信を特別に処理するツールはありません。ただし、テストによって次のことが判明しました。1 つのフィールドで次の代入を実行すると、Unified ICM Central Controller と IP IVR PG 間で必要となる帯域幅を計算するツールによって、Unified CVP の正確な測定値が生成されます。

[Average number of RUN VRU SCRIPT nodes] というラベルのフィールドで、Unified CVP と対話する Unified ICM スクリプト ノードの数を代入します。Unified CVP と対話できるノードは、Run External Script、Label、Divert Label、Queue to Skill Group、Queue to Agent、Agent、Release、Send to VRU、および Translation Route to VRU です。

この Bandwidth Calculator ツールは、次の URL から（適切なログイン認証を使用して）入手できます。

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

この場合の接続は、WAN または LAN を介して確立できます。

データ トラフィック

データ トラフィックには、VoiceXML ゲートウェイによって実行された HTTP 要求の結果として返される VoiceXML ドキュメントおよび録音済みのメディア ファイルが含まれます。具体的には次のとおりです。

• VoiceXML ゲートウェイは、メディア ファイル サーバへの HTTP 要求でメディア ファイルを要求します。メディア サーバは、その応答で、HTTP メッセージの本体にメディア ファイルを含めて返します。次に、VoiceXML ゲートウェイはそれらのメディア ファイルを RTP パケットに変換し、発信者に対して再生します。この場合の接続は、WAN または LAN を介して確立できます。

• VoiceXML ゲートウェイは、Unified CVP VXML Server または Unified CVP IVR サービスからの VoiceXML ドキュメントを要求します。この場合の接続は、WAN または LAN を介して確立できます。

この章では主に、リモート入力ゲートウェイと、リモート入力ゲートウェイがインターフェイスしている次のコンポーネントとの間で使用されるデータ フローおよび帯域幅のタイプについて説明します。

• Unified CVP VXML Server

• Unified CVP コール サーバ IVR サービス

• Unified CVP コール サーバ SIP または H.323 サービス

• IP Phone

• メディア サーバ

• 出力ゲートウェイ

• ASR または TTS サーバ

必要な帯域幅の見積もりに役立ち、必要に応じてこれらのネットワーク セグメントの QoS をプロビジョニングするためのガイドラインおよび例を示します。

VoiceXML ドキュメント

VoiceXML（VXML）ドキュメントは、Unified ICM スクリプトと Cisco Unified Call Studio のいずれかまたは両方を使用して記述された音声アプリケーション スクリプトに基づいて生成されます。VoiceXML ドキュメントは、発信者に再生されるプロンプトごとに生成されます。VoiceXML ドキュメントのサイズは、使用されるプロンプトのタイプに応じて異なります。多くの選択肢があるメニュー プロンプトのサイズは、通知を再生するだけの単純なプロンプトよりも大幅に大きくなります。

Unified CVP コール サーバまたは Unified CVP VXML Server とゲートウェイとの間の VoiceXML ドキュメントは、平均すると約 7 KB です。1 コールにつき 1 分ごとに使用されるプロンプト数を見積もることで、使用される帯域幅を計算できます。この例の計算は、次のようになります。

7,000 バイト ∗ 8 ビット = 56,000 ビット/プロンプト

（0.166 コール/秒）*（56,000 ビット/プロンプト）*（プロンプト数/コール）= bps/拠点

ただし、（上記で見積もっている平均よりも多い）多数のメニュー プロンプトを使用するさらに複雑なアプリケーションを使用する場合、または帯域幅をより正確に計算する必要がある場合は、 表 9-2 にリストされている VoiceXML ドキュメント サイズを使用して帯域幅の必要量を計算します。 表 9-2 でのドキュメント サイズは、Unified CVP VXML Server から VXML ゲートウェイへの場合で測定されています。

メディア ファイルの取得

メディア ファイル（プロンプト）は、各ルータのフラッシュ メモリにローカルに保存できます。この方法では、帯域幅を考慮する必要がなくなりますが、プロンプトを変更するときに、プロンプトをルータごとに置き換える必要があるため、保守性が問題となります。一方、HTTP メディア サーバ（または HTTP キャッシュ エンジン）にプロンプトが保存されている場合、ゲートウェイは、最初にプロンプトを取得すれば、音声プロンプトをローカルにキャッシュできます。HTTP メディア サーバを適切に設定すると、プロンプトの数およびサイズに応じて（すべてではなくても）多数のプロンプトをキャッシュできます。プロンプトの更新期間は HTTP メディア サーバで定義されます。したがって、使用される帯域幅は、各ゲートウェイでのプロンプトの初期ロード、および更新間隔の失効時の定期更新に限定されます。

ゲートウェイでプロンプトをキャッシュしない場合は、帯域幅が余分に使用されるだけでなく、Cisco IOS のパフォーマンスが大幅に低下します（35 ～ 40%）。ゲートウェイでのプロンプト キャッシングの設定の最新情報については、次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

合計で 50 のプロンプトがあり、平均サイズが 50 kB で、更新間隔が 15 分であるとします。この場合、帯域幅の使用量は次のようになります。

（50 プロンプト）∗（50,000 バイト/プロンプト）∗（8 ビット/バイト）= 20,000,000 ビット

（20,000,000 ビット）/（900 秒）= 平均 22.2 kbps/拠点

H.323 シグナリング

拠点ゲートウェイによって処理される各コールでは、6000 バイトに加えて、エージェントに転送されるコールごとに 1000 バイト必要にあるため、コールごとの合計は 56,000 ビットとなります（7000 バイト ∗ 8 ビット）。このため、必要な平均帯域幅は、（0.166 ∗ 56 kbps）= 9.3 kbps（WAN リンクからリモート拠点への場合）となります。

SIP シグナリング

SIP はテキストベースのプロトコルであるため、使用されるパケットは H.323 の場合よりも多くなります。通常の SIP コール フローでは、コールごとに約 17,000 バイトが使用されます。1 秒ごとのコールに基づいた前述の帯域幅の数式を使用すると、平均の帯域幅使用量は次のようになります。

（17,000 バイト/コール）∗（8 ビット/バイト）= 136,000 ビット/コール

（0.166 コール/秒）∗（136 キロビット/コール）= 平均 22.5 kbps/拠点

ASR および TTS

集中型 Automatic Speech Recognition（ASR; 音声自動認識）および Text-To-Speech（TTS; 音声合成）が、Unified CVP 4.0 以後、分散型 Unified CVP 展開でサポートされるようになりました。このモデルをサポートするには、QoS がネットワークで設定され、帯域幅が ASR/TTS RTP および MRCP トラフィック専用に予約されている必要があります。ASR/TTS では、無音圧縮は使用できず、G.711 コーデックを使用する必要があるため、集中型 ASR/TTS では帯域幅が大量に消費されます。ASR/TTS RTP および MRCP トラフィックは、QoS DSCP マーキングでタグ付けされていないため、Access Control List（ACL; アクセス コントロール リスト）を使用して、リモート サイトおよび中央サイトのトラフィックを分類および再マーキングする必要があります。

（注） シスコでは、WAN を介した ASR/TTS はサポートしていません。

VoiceXML ゲートウェイと ASR/TTS サーバ間の RTP メディア トラフィックの分類

VoiceXML ゲートウェイによって使用される RTP ポート範囲は、標準の Cisco IOS RTP UDP ポート範囲の 16384 ～ 32767 ですが、ASR/TTS サーバによって使用される RTP UDP ポート範囲は、OS および ASR/TTS ベンダーごとに異なる場合があります。ASR/TTS サーバからのトラフィックを VoiceXML ゲートウェイの UDP ポート範囲に基づいて照合するように ACL を構築できますが、可能な場合は、ASR/TTS サーバで使用されるポートを検出することを推奨します。RTP トラフィックは DSCP EF でマーキングされているため、他の音声トラフィックとともにプライオリティ キューに入れられます。

QoS プライオリティ キューについても、予測される ASR/TTS セッションの最大数をサポートするように設定されている必要があります。Cisco Unified CM ロケーションや Resource Reservation Protocol（RSVP; リソース予約プロトコル）などのコール アドミッション制御メカニズムが使用されている場合は、ロケーションまたは RSVP 帯域幅を設定するときに、追加プライオリティ キュー帯域幅を含めないでください。たとえば、2 つの ASR/TTS G.711 セッション（セッションごとに 80 kbps）、および G.729 を使用する 4 つの IP テレフォニー電話コール（コールごとに 24 kbps）をサポートする必要がある場合、プライオリティ キューの合計帯域幅は 256 kbps になります。ロケーションのコール アドミッション制御または RSVP 帯域幅は、IP テレフォニー帯域幅（この例では 96 kbps）のみに制限されます。256 kbps でロケーションまたは RSVP 帯域幅を設定すると、IP テレフォニー コールはすべての帯域幅を使用することができ、ASR/TTS セッションと競合します。

VoiceXML ゲートウェイと ASR/TTS サーバ間の MRCP トラフィックの分類

MRCP トラフィックは簡単に分類できます。ASR/TTS サーバは、MRCP 要求の場合は TCP 554 でリッスンするため、このポートは ACL を使用してトラフィックを分類する必要があります。MRCP によって使用される帯域幅は、アプリケーションが ASR/TTS リソースを使用する頻度によって異なります。MRCP では、対話ごとに約 2000 バイトが使用されます。コール単位で 3 秒ごとに ASR/TTS 対話がある場合、平均帯域幅は次のように計算できます。

（2000 バイト/対話）∗（20 対話/分）∗（8 ビット/バイト）= コール単位で 320,000 ビット/分

（320,000 ビット/分）/（60 秒/分）= 5.3 平均 kbps/拠点

所定の時間で最大 6 の ASR/TTS セッションを設定した場合は、（6 ∗ 5.3 kbps）= 32 平均 kbps/拠点となります。

ASR/TTS 対応のコールの最大数の制限

ASR/TTS 対応のコール数を制限し、制限に達した場合にはコールをすべて拒否するのではなく、標準の DTMF プロンプト/コレクトが使用されるようにすることが可能です。次の例では、5559000 が ASR/TTS DNIS で、5559001 が DTMF DNIS であると仮定します。ASR/TTS VoIP ダイヤル ピアで許可されている最大接続を超えた場合に DNIS を変更することによって、ASR ロード制限を実行するように入力ゲートウェイを設定できます。

（注） 80 kbps は、IP/RTP ヘッダーや圧縮なしなど、VAD を使用しない G.711 全二重でのレートです。24 kbps は、IP/RTP ヘッダーや圧縮なしなど、VAD を使用しない G.729 全二重でのレートです。VoIP 帯域幅の使用の詳細については、http://tools.cisco.com/Support/VBC/do/CodecCalc1.do から入手可能な『Voice Codec Bandwidth Calculator』を参照してください（ログイン認証が必要です）。

音声トラフィック（G.711 および G.729）

Unified CVP では、G.711 と G.729 の両方をサポートしています。ただし、所定のコールでのコール レッグおよびすべての IVR は、同じ音声コーデックを使用する必要があります。音声認識に ASR/TTS を使用している場合、ASR/TTS サーバでは G.711 のみがサポートされているため、G.711 を使用する必要があります。音声 RTP ストリームに関する最新の帯域幅情報については、次の URL から入手可能な最新バージョンの『 Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html

ローカル拠点のコール アドミッション制御（LBCAC/queue-at-the-edge）

Unified CVP 拠点オフィス コール フロー モデル展開を使用する場合、WAN リンクの使用可能な帯域幅に基づいて、WAN リンクを介して拠点オフィスに転送されるコールの数を制御する必要があります。コールの許可の決定は、Call Admission Control（CAC; コール アドミッション制御）計算に基づきます。この計算は、個々のコールで使用される帯域幅を正確に表している必要があります。これらの計算は、CCM 内の 2 つの電話間の IP コールであるか、SIP/H.323 トランクを介したコールであるか、または TDM-IP GW から発信されたコールであるかに関係なく機能します。

また、queue-at-the-edge 機能の場合、特定の拠点オフィスから発信されたコールは、プライオリティに基づいてローカル VXML ゲートウェイにルーティングされる必要があります。つまり、可能な場合は必ずローカル拠点エージェントを選択してください。

次の図は、典型的な拠点オフィスの展開を示しています。

queue-at-the-edge による拠点オフィス展開モデル

集中型 UCM 拠点オフィス展開に Unified CVP を展開して、queue-at-the-edge 機能を提供できます。この展開モデルでは、通常、拠点オフィスに展開した入力ゲートウェイを使用して、発信者にアクセスを提供します。アクセスには、中央番号や非地理的番号ではなく、市内電話番号を使用します。この考慮事項は、複数の国にまたがる国際展開で特に重要になります。

出力ゲートウェイは、局所的な PSTN ブレークアウト用、または CVP スイッチング ソリューションへの TDM プラットフォーム（ACD）をプラットフォームの統合用として、拠点に展開されます。ゲートウェイを除く他の CVP コンポーネントはすべて中央に展開され、WAN リンクによって各拠点から中央データセンターまでのデータ接続が実現されます（メディア サーバは中央に展開されますが、一般に使用される VRU メディアは、ローカル拠点でキャッシュされます）。

queue-at-the-edge を使用する Unified CVP 拠点オフィス展開モデルでは、拠点オフィスの装置は、入力ゲートウェイ（オプションで VXML ゲートウェイとしても機能）、Unified CCE エージェントの IP 電話、IPT（ユーザ）電話、およびエージェント デスクトップだけです。

ある拠点に入った発信者が、プリファレンスによって同じ拠点のエージェントに接続されるように、Unified CCE スキル グループ、ダイヤル プラン、およびルーティング プライオリティを設定できます。この場合、RTP トラフィックは、入力ゲートウェイから IP 電話に直接送信され、WAN を経由する必要はありません（ただし、シグナリングおよびデータは WAN を経由する場合があります）。

このモデルの目的は、可能な場合は拠点オフィス内の使用可能なエージェントに最初にコールをローカルにルーティングして、メディア ストリームをローカルに維持することです。ローカル エージェントを使用できない場合、コールは WAN リンクを介して別の拠点にいるエージェントにルーティングされます。発信コールおよび最初の VRU 処理はローカルで実行されます。

この展開コンフィギュレーションのもう一つの利点は、WAN リンクの障害が発生した場合、TDM が発信したコールのポート ダイヤルピア上で実行されている CVP 存続可能性アプリケーションを使用して、コールを引き続きローカルにルーティングできることです。

LBCAC の概念の定義

次の定義が、LBCAC 機能において重要となります。

• Phantom ロケーション。帯域幅が無制限のデフォルトのロケーション。帯域幅を正確に計算するために、H.323 または SIP トランクを介してヘアピンされたコールを計算する場合や、H.323 または SIP コールがローカル拠点でキューに入れられる場合に使用します。Phantom ロケーションは、CVP のゲートウェイまたはトランクに割り当てる必要があります。

• siteID。siteID は、特定の宛先（拠点 VXML ゲートウェイ、出力ゲートウェイ、UCM ノードなど）にコールをルーティングするようにダイヤル プランを設定できるように、Unified ICM からのラベルに付加される数値ストリングです。siteID は、ラベルの先頭または末尾に付加したり、付加しないこともできます。このコンフィギュレーションは、Unified CM ロケーション コンフィギュレーションとは別になっており、Unified CVP に固有のものです。siteID を使用してコールの実際のロケーションを示し、正しいロケーションから帯域幅を推測できるようにします。siteID は、複数の Unified CM クラスタにわたって一意です。一意の siteID をプロキシ/ゲートキーパー ルートの同じ拠点ゲートウェイにマッピングすることで、複数の siteID を引き続き同じ拠点オフィスにルーティングできます（必要な場合）。

LBCAC 機能の重要点および比較

LBCAC 機能では、以前の CAC 機能での次の 2 つの重要な問題に対処しています。

1. IP からの発信者、およびエージェントからのポスト転送に関する CAC での帯域幅の計算間違い。

2. 問い合わせでの 2 つのコール間に相関関係がないため、エージェントからのウォーム転送時に拠点での VRU 処理用のローカル VXML GW を確定的に選択できないこと。

Unified CM での LBCAC と OrigIP トランク機能との比較

• Unified CM が帯域幅計算のために Phantom トランクおよび siteID 機能を実装する以前は、発信者の元の IP に応じて正しいトランクを選択できる、Unified CVP によって使用されていた既存の機能がありました。この機能によって、Unified CM は、1 つの Unified CVP トランクを使用する代わりに、TDM ゲートウェイに適したトランクを選択できました。これは、トランク上の着信コールのみに適用されます。この機能を使用すると、単一の Unified CVP トランクの設定に限定されずに、固有の SIP プロファイルおよびトランク設定を各拠点ゲートウェイに使用できます。この機能は、帯域幅の計算には影響しません。

LBCAC でのルータ再クエリー

• 十分な帯域幅がないためにコールが UCM によって拒否された場合、SIP メッセージ「488 Not Acceptable Here」が Unified CVP に返され、これにより GED-125 インターフェイスを介した VRU ペリフェラルへのルータ再クエリーが発生します。再クエリーが適切に設定されている場合、UCCE ルータは別のエージェント ラベルを返すことができます。

設計上の考慮事項

LBCAC の使用時に、次の考慮事項が適用されます。

• MTP 必須で設定されたトランクは、LBCAC siteID 機能では動作しません。その理由は、MTP が挿入されると、メディアはエンド ポイントと MTP リソース間で終了し、2 つのエンド ポイント間では終了しないためです。

• MTP/トランスコーダ/TRP メディア リソースが UCM メディア レイヤによって挿入されると、着信ロケーション情報は使用されません。

• 内部クラスタ コールが同じクラスタに対してヘアピン/ループ バックされない場合は、ロケーション CAC ロジックの以前の動作が適用されます。

• 各サイトは、1 つの siteID によって一意に識別されます。同じサイトの複数のゲートウェイには同じ siteID が割り当てられる必要がありますが、2 つのクラスタが同じロケーション名を使用する場合は、2 つの siteID を同じ物理拠点にマッピングできます。

• 別の Unified CM クラスタは、最初のクラスタと同じロケーションである場合がありますが、Unified CVP で一意の siteID を引き続き使用する必要があります。これらのクラスタのコールを、両方のクラスタによって使用される同じロケーションの共通 VXML ゲートウェイに送信するようにプロキシ サーバのルートを定義できます。

• 各クラスタは、そのクラスタ内のデバイスの帯域幅を管理します。2 つのクラスタが同じ物理ロケーションを使用する場合、各クラスタは、それぞれが管理する電話の帯域幅を個別に管理します。

ハイ アベイラビリティとフェールオーバー

LBCAC の使用時に、次の考慮事項が適用されます。

• CAC の障害時に、Unified CVP は、ルータ再クエリーをトリガーする Unified CCE に障害コードを返します。

• 拠点に VXML ゲートウェイがない場合は、VXML ゲートウェイを中央データセンターで使用することを推奨します。

LBCAC に関する重要な追加情報

前のバージョンの Unified CVP では、CAC を設定する方法が提供されていました。この方法は、ここで示す LBCAC の方法に変更されました。両方の設定方法については、次の URL から入手可能な『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html