Cisco Unified Customer Voice Portal(CVP)ソリューション リファレンス ネットワーク デザイン(SRND)リリース 9.0(1)
ネットワーク インフラストラクチャの考慮事項
ネットワーク インフラストラクチャの考慮事項
発行日;2012/11/27   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

目次

ネットワーク インフラストラクチャの考慮事項

 

この章では、Unified CVP ネットワークの展開特性およびプロビジョニング要件について説明します。 WAN を介したリモート コンポーネント間のネットワーク トラフィック フローに関するプロビジョニング ガイドラインを示します(WAN トラフィック フローに適切な Quality of Service(QoS)を適用するための推奨事項など)。

ネットワークの考慮事項に関する最新情報については、次の URL から入手可能な最新バージョンの『Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND)』で説明している導入モデル、帯域幅、および QoS の項を参照してください。

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1844/​products_​implementation_​design_​guides_​list.html

この章では、次のトピックについて取り上げます。

新規または変更された章の情報

次の表に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

 
表 1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック

説明

この章には、SRND の 2012 年 7 月 6 日のバージョンに関する新規トピックはありません。

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

多くの Unified CVP 展開では、すべてのコンポーネントが集中化されているため、考慮する WAN ネットワーク トラフィックはありません。 一般に、Unified CVP 環境で WAN ネットワーク構造を考慮する必要があるのは次の 2 つの場合だけです。

  • WAN によって入力ゲートウェイが Unified CVP Server から分離されている、分散型 Unified CVP 展開。
  • 入力ゲートウェイおよびエージェントが WAN を介して分離されている、Unified CVP 展開。 エージェントは、TDM ACD エージェントまたは Unified CCE エージェントです。

Unified ICM とは異なり、Unified CVP での QoS の考え方は、次のように非常に単純です。

  • Unified CVP には、プライベート WAN ネットワーク構造という概念がありません。 すべての WAN アクティビティは、コンバージされた WAN ネットワーク構造で必要に応じて実行されます。
  • Unified CVP では、高いまたは低いプライオリティ トラフィック用に個別の IP アドレスを使用しません。

Unified CVP 展開を適切に行うには、適切な帯域幅プロビジョニングを行うことが重要です。 必要な帯域幅のプロビジョニングに役立つように、この章では帯域幅のガイドラインおよび例を示します。


(注)  


RSVP は、コール アドミッション制御に使用されるプロトコルであり、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。 RSVP は、SIP の Unified CVP コール サーバを介したコール制御シグナリングには適していません。 コール アドミッション制御のソリューションとして、CVP および UCM でロケーション コンフィギュレーションを採用することを推奨します。 拡張位置のコール アドミッション制御を参照してください。


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

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 サーバと通信します。 このプロトコルは、現在、リアルタイム ストリーミング プロトコル(RTSP)と連携して機能して、ASR/TTS サーバ(Nuance や Scansoft など)への制御接続の確立を支援しています。接続は、WAN または LAN を介して確立できます。

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 サービス
  • IP Phone
  • メディア サーバ
  • 出力ゲートウェイ
  • ASR または TTS サーバ

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

帯域幅のサイジング

Unified CVP ソリューションにおけるほとんどの帯域幅要件は、分散型 Unified CVP トポロジで発生します。これは、主に、入力ゲートウェイや VoiceXML ゲートウェイが、メディア ファイル、VoiceXML ドキュメント、およびコール制御シグナリングを提供するサーバと分離されているためです。 次の説明では、拠点へのすべてのコールが、1 分間の IVR 処理の後、エージェントへの単一転送のために同様に 1 分間経過してから開始されると仮定しています。 各拠点には 20 のエージェントが存在し、各エージェントは 1 時間当たり 30 コールを処理するため、拠点ごとに 1 時間当たり合計 600 のコールが処理されます。 したがって、コールの平均速度は、各拠点で 1 秒当たり 0.166 コールとなります。

これらの変数が少し変わっただけでも、サイジングには大きく影響する可能性があることに注意してください。 1 時間全体で 1 秒当たり 0.166 コールが平均となります。 通常、コールは 1 時間全体で均一に到着するわけではなく、ビジーな時間帯で山と谷があります。 最もビジーなトラフィック期間を検出し、最悪ケースのシナリオに基づいてコールの到着率を計算するようにします。

VoiceXML ドキュメント タイプ

VoiceXML ドキュメントは、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/拠点

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

 
表 2 VoiceXML ドキュメント タイプの概算サイズ

VoiceXML ドキュメント タイプ

VoiceXML ドキュメント サイズ(概算)

ルート ドキュメント(コールの開始時に必要)

19,000 バイト

Subdialog_start(コールの開始時、少なくともコールごとに 1 つ必要)

700 バイト

Call-ID および GUID のゲートウェイのクエリー(コールごとに必要)

1,300 バイト

メニュー(メニュー選択肢の数によりサイズが増加)

1,000 バイト + 2,000 バイト/メニュー選択肢

通知の再生(単純な .wav ファイル)

1,100 バイト

クリーンアップ(コールの終了時に必要)

4,000 バイト

メディア ファイルの取得

メディア ファイル(プロンプト)は、各ルータのフラッシュ メモリにローカルに保存できます。 この方法では、帯域幅を考慮する必要がなくなりますが、プロンプトを変更するときに、プロンプトをルータごとに置き換える必要があるため、保守性が問題となります。 一方、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/拠点

SIP シグナリング

SIP はテキスト ベースのプロトコルです。 通常の 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 マーキングでタグ付けされていないため、アクセス コントロール リスト(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 X 5.3 kbps)= 32 平均 kbps/ブランチとなります。

ASR または TTS 対応のコールの最大数の制限

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

voice translation-rule 3 rule 3 /5559000/ /5559001/
!
voice translation-profile change
 translate called 3
!
!Primary dial-peer is ASR or TTS enabled DNIS in ICM script
dial-peer voice 9000 voip
 max-conn 6
 preference 1
 destination-pattern 55590..
 ...
!
!As soon as 'max-conn' is exceeded, next preferred dial-peer will change 
the DNIS to a DTMF prompt & collect ICM script
dial-peer voice 9001 voip
 translation-profile outgoing change
 preference 2
 destination-pattern 55590..
 ...
!

(注)  


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

コール アドミッション制御

コール アドミッション制御は、RTP ストリームを伝送できる十分な帯域幅がネットワーク上にあるかどうかを識別するメカニズムです。 Unified CM では、独自のロケーション メカニズム、または RSVP を使用して、入力ゲートウェイと宛先 IP 電話のロケーション間の帯域幅を追跡します。

コール アドミッション制御の詳細については、分散型導入の章を参照してください。


(注)  


リソース予約プロトコル(RSVP)は、コール アドミッション制御に使用されるプロトコルであり、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。 RSVP は、SIP の Unified CVP コール サーバを介したコール制御シグナリングには適していません。 コール アドミッション制御のソリューションとして、Unified CVP および Unified CM でロケーション コンフィギュレーションを採用することを推奨します。


RSVP の詳細については、次の 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

拡張位置のコール アドミッション制御

Unified CVP 9.0(1) では、クラスタ内の拡張位置のコール アドミッション制御(ELCAC)を使用したトポロジのモデリングがサポートされます。 クラスタ間の拡張位置の CAC はサポートされません。 Location Bandwidth Manager はクラスタ内の CAC でイネーブルですが、クラスタ間の CAC ではディセーブルです。 ELCAC トポロジ モデリングの詳細については、http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​products_​implementation_​design_​guides_​list.html から入手可能な『Cisco Unified Communications SRND based on Cisco Unified Communications Manager』を参照してください。

Unified CVP クラスタ内の拡張位置 CAC モデルの導入を使用している場合、ブランチ オフィスに対する WAN リンクを経由するコール数を制御する必要があります。 コールを許可する決定は、コールに使用される帯域幅を表す CAC の計算に基づきます。 これらの計算は、コールが Cisco Unified Communications Manager 内の 2 台の電話機間の IP コールか、SIP トランクを介したコールか、または TDM-IP GW から発信されたコールかに関係なく有効です。

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

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



queue-at-the-edge によるブランチ オフィス導入モデル

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

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

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

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

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

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

ELCAC の概念の定義

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

  • Phantom ロケーション:帯域幅が無制限のデフォルトのロケーション。帯域幅を正確に計算するために、SIP トランクを介してヘアピンされたコールを計算する場合や、SIP コールがローカル ブランチでキューに入れられる場合に使用します。 Phantom ロケーションは、CVP のゲートウェイまたはトランクに割り当てる必要があります。
  • siteID:siteID は、特定の宛先(ブランチ VXML ゲートウェイ、出力ゲートウェイ、UCM ノードなど)にコールをルーティングするようにダイヤル プランを設定できるように、Unified ICM からのラベルに付加される数値ストリングです。 siteID は、ラベルの先頭または末尾に付加したり、付加しないこともできます。 このコンフィギュレーションは、Unified CM ロケーション コンフィギュレーションとは別になっており、Unified CVP に固有のものです。 siteID を使用してコールの実際のロケーションを示し、正しいロケーションから帯域幅を推測できるようにします。 siteID は、複数の Unified CM クラスタにわたって一意です。 一意の siteID をプロキシ ルートの同じブランチ ゲートウェイにマッピングすることで、複数の siteID を引き続き同じブランチ オフィスにルーティングできます(必要な場合)。
  • シャドウ ロケーション: この新しい位置は 2 台の Cisco Unified Communications Manager クラスタ間のクラスタ間トランクに使用されます。 このロケーションは、クラスタ間 ELCAC が Unified CVP 9.0(1) でサポートされていないため、使用されません。

拡張位置のコール アドミッション制御機能の重要点および比較

拡張位置のコール アドミッション制御(ELCAC)機能は、以前の CAC 機能の 2 つの重要な問題に対処します。

  1. IP からの発信者、およびエージェントからのポスト転送に関する CAC での帯域幅の計算間違い。
  2. 問い合わせでの 2 つのコール間に相関関係がないため、エージェントからのウォーム転送時に拠点での VRU 処理用のローカル VXML GW を確定的に選択できないこと。

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

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

ELCAC でのルータ再クエリー

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

設計上の考慮事項

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

  • Unified CVP と Unified CM の間で設定されている SIP トランクは Phantom ロケーションに関連付けられます。 シャドウ ロケーションという新しいロケーションが、内部クラスタ ELCAC のために Unified CM 9.0 に追加されますが、Unified CVP 9.0(1) ではサポートされません。
  • MTP 必須で設定されたトランクは、ELCAC siteID 機能では動作しません。 その理由は、MTP が挿入されると、メディアはエンド ポイントと MTP リソース間で終了し、2 つのエンド ポイント間では終了しないためです。
  • MTP/トランスコーダ/TRP メディア リソースが Unified CM メディア レイヤによって挿入されると、着信ロケーション情報は使用されません。
  • 内部クラスタ コールが同じクラスタに対してループバックされない場合は、ロケーション CAC ロジックの以前の動作が適用されます。
  • 各サイトは、1 つの siteID によって一意に識別されます。 同じサイトの複数のゲートウェイには同じ siteID が割り当てられる必要がありますが、2 つのクラスタが同じロケーション名を使用する場合は、2 つの siteID を同じ物理拠点にマッピングできます。
  • 別の Unified CM クラスタは、最初のクラスタと同じロケーションである場合がありますが、Unified CVP で一意の siteID を使用する必要があります。 これらのクラスタのコールを、両方のクラスタによって使用される同じロケーションの共通 VXML ゲートウェイに送信するようにプロキシ サーバのルートを定義できます。
  • 各クラスタは、そのクラスタ内のデバイスの帯域幅を管理します。 2 つのクラスタが同じ物理ロケーションを使用する場合、各クラスタは、それぞれが管理する電話の帯域幅を個別に管理します。

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

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

  • CAC の障害時に、Unified CVP は、ルータ再クエリーをトリガーする Unified CCE に障害コードを返します。
  • ブランチに VoiceXML ゲートウェイがない場合は、VXML ゲートウェイを中央データセンターで使用することを推奨します。

追加の ELCAC 情報

前のバージョンの Unified CVP では、CAC を設定する方法が提供されていました。 この方法は、ここで示す ELCAC の方法に変更されました。 両方の設定方法については、次の 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

推奨されるポートの使用および QoS 設定

Unified CVP コール サーバは、SIP メッセージの QoS DSCP のみにマーキングします。 WAN を介した Unified CVP シグナリングおよびデータ トラフィックに QoS が必要な場合は、次の表で推奨するように、トラフィックを分類およびマーキングするために、IP アドレスとポートを使用して QoS 用のネットワーク ルータを設定します。

CVP- データ キューおよびシグナリング キューのいずれも、Cisco IOS ルータの用語で説明されているようなプライオリティ キューではありません。 プライオリティ キューは、音声またはその他のリアル タイム トラフィックに使用されます。一方、コール シグナリングおよび Unified CVP トラフィックでは、コール ボリュームに基づいて特定の量の帯域幅が予約されます。



表 3 推奨されるポートの使用および QoS 設定
コンポーネント ポート キュー PHB DSCP 最大遅延(ラウンド トリップ)

メディア サーバ

TCP 80

CVP- データ

AF11

10

1 秒

Unified CVP コール サーバ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ミリ秒

Unified CVP IVR サービス

TCP 8000

CVP- データ

AF11

10

1 秒

Unified CVP VXML Server

TCP 7000

CVP- データ

AF11

10

1 秒

入力ゲートウェイ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ミリ秒

VoiceXML ゲートウェイ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ミリ秒

SIP プロキシ サーバ

TCP または UDP 5060

コール シグナリング

CS3

24

200 ミリ秒

MRCP

TCP 554

コール シグナリング

CS3

24

200 ミリ秒

ネットワーク遅延

適切なアプリケーション帯域幅および QOS ポリシーを設定した後、分散型 CVP 展開で重要となるもう一つの考慮事項は、ネットワーク遅延です。 十分なネットワーク帯域幅がある場合、遅延の主な原因は、VoiceXML ゲートウェイとコール サーバ/VXML Server 間の距離です。分散型 CVP 導入では、遅延を最小限に抑え、ソリューションのパフォーマンスへの影響を理解することが重要です。

CVP コンポーネント間のネットワーク遅延は、主にエンド ユーザのコーリング エクスペリエンスに影響します。 SIP での CVP コール サーバと音声ゲートウェイ間のコール シグナリング遅延は、コール設定時間に影響し、設定時に無音期間が追加される場合があります。 これには、最初のコール設定、最終的なコール フローの一部である後続の転送や会議などがあります。 VoiceXML アプリケーション ドキュメントのダウンロード時間もネットワーク遅延により大きく影響を受け、最終的に発信者エクスペリエンスに著しく影響します。

VXML ゲートウェイと CVP VXML Server 間の地理的分離の影響を最小限に抑えるために、いくつかの推奨事項を次に定義しています。 ただし、顧客コール フローの業務上のニーズによっては、CVP VXML Server を引き続きリモート VXML ゲートウェイと共存させる必要がある場合があります。

ソリューションでは、HTTP プロトコルを頻繁に使用して、発信者に最終的に再生される VoiceXML ドキュメントおよびその他のメディア ファイルを転送します。 エンド ユーザのコーリング エクスペリエンスを最適なものとするために、この HTTP トラフィックは、企業ネットワークでの標準 HTTP トラフィックのプライオリティよりも高いプライオリティで処理する必要があります。 可能な場合はこの HTTP トラフィックを CVP コール シグナリング トラフィックと同じように処理することを推奨します。 遅延の問題を回避するために使用できる方法として、VoiceXML Server を VXML ゲートウェイと同じローカル エリアに移動することや、Wide Area Application Services(WAAS)を使用する方法があります。

または、次の箇条書きで示すシステム コンフィギュレーションの変更が、WAN による遅延に有用な場合があります。

  1. 無音期間中に音声を発信者に提供する 次の設定は、無音期間中に呼び出し音および音声を提供することで、発信者による切断を回避します。
    • 存続可能性サービスでは、「wan-delay-ringback」を 1 に設定して、IVR での標準コール設定時間よりも長いときに呼び出し音を追加できます。
    • IVR.FetchAudioDelay および IVR.FetchAudioMinimum の IVR サブシステム設定が追加されました。 これらは、WAN リンクを介したルート ドキュメント取得で遅延が発生した場合のための WAN 遅延設定です。
    • IVR.FetchAudio の値を IVR.Fetchaudio= flash:holdmusic.wav のように指定します。 デフォルトを空のままにして、標準のシナリオでは何も再生されないようにします。

    (注)  


    • デフォルト設定の 2 は、標準のネットワーク シナリオでピッという音を回避するために必要です。
    • WAN 遅延をゼロに設定すると、すぐに holdmusic.wav が再生され、少なくとも約 5 秒間再生されます。
    • ECC 変数(user.microapp.fetchdelay、user.microapp.fetchminimum、user.microapp.fetchaudio など)を使用して、getSpeechExternal マイクロアプリケーションの呼び出しについてこれらの値をオーバーライドできます。

  2. VoiceXML ゲートウェイでのパス MTU ディスカバリの有効化 VoiceXML ゲートウェイで、ip tcp path-mtu-discovery コマンドを追加します。 パス MTU ディスカバリは、TCP 接続のエンドポイント間のネットワークで使用可能な帯域幅を最大限使用するための方法です。
  3. VXML Server と ICM スクリプト間のラウンドトリップの最小化 実行中の VXML Server アプリケーションから ICM スクリプトに制御が戻されると、大幅な WAN 遅延が発生します。 VXML Server アプリケーションが実行された後には、ICM スクリプトに戻る回数を最小限に抑えることがベスト プラクティスです。 VoiceXML Server と ICM スクリプト間の各ラウンドトリップでは、新しい 2 つの TCP 接続の確立、および複数の VXML ドキュメント(VXML Server のルート ドキュメントを含む)の HTTP 取得によって遅延が発生します。
  4. VMXL Server のルート ドキュメントのサイズの削減 VXML Server で、特定のゲートウェイ アダプタの plugin.xml ファイルの内容を次のように変更します。 変更前: <setting name="vxml_error_handling">default</setting> 送信先 <setting name="vxml_error_handling">minimal</setting> たとえば、CISCO DTMF 1 GW アダプタの plugin.xml ファイルは、次の場所にあります。 Cisco\CVP\VXMLServer\gateways\cisco_dtmf_01\6.0.1\plugin.xml

Unified CVP、音声ゲートウェイ、および VoiceXML ゲートウェイで使用される TCP/UDP ポート

ファイアウォールまたは ACL を使用してネットワーク セキュリティを設定する場合は、Unified CVP、音声ゲートウェイ、VoiceXML ゲートウェイで使用される TCP/UDP ポートに関する情報について次の表を参照してください。 Unified CVP によって使用されるポートの詳細リストについては、『Unified CVP Port Utilization Guide』を参照してください。


(注)  


Unified CVP Operations Console Server は、他のコンポーネントとの通信にダイナミック ポートを使用するため、残りの Unified CVP コンポーネントがファイアウォール内にある場合は、ファイアウォールの外側に展開できません。


 
表 4 Unified CVP、音声ゲートウェイ、および VoiceXML ゲートウェイで使用される TCP/UDP ポート

送信元および宛先コンポーネント

宛先ポート

音声ゲートウェイからメディア サーバ

TCP 80

音声ゲートウェイから Unified CVP コール サーバ SIP

TCP または UDP 5060

音声ゲートウェイから Unified CVP コール サーバ

TCP 8000(非 SSL の場合)、TCP 8443(SSL の場合)

音声ゲートウェイから Unified CVP VXML Server

TCP 7000(非 SSL の場合)、TCP 7443(SSL の場合)

音声ゲートウェイから MRCP サーバ

TCP 554

Unified CVP コール サーバから出力音声ゲートウェイ SIP

TCP または UDP 5060

Unified CVP コール サーバから VoiceXML ゲートウェイ SIP

TCP または UDP 5060

Unified CVP コール サーバから SIP プロキシ サーバ

TCP または UDP 5060