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

目次

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

この章の新規情報

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

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

音声トラフィック

呼制御トラフィック

データ トラフィック

帯域幅のサイジング

VoiceXML ドキュメント

メディア ファイルの取得

H.323 シグナリング

SIP シグナリング

ASR および TTS

音声トラフィック(G.711 および G.729)

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

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

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

LBCAC の概念の定義

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

設計上の考慮事項

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

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

QoS マーキング

ネットワーク遅延

最初の G.711 メディア バーストのブロック

ファイアウォールを使用したネットワーク セキュリティ

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

この章では、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

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

「この章の新規情報」

「帯域幅のサイジング」

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

「QoS マーキング」

「ネットワーク遅延」

「最初の G.711 メディア バーストのブロック」

「ファイアウォールを使用したネットワーク セキュリティ」

この章の新規情報

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

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

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

「音声トラフィック」

G729 と G711 コーデックの利点

帯域幅プロビジョニングおよび 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 では、SIP パケットの QoS DSCP にマーキングします。H.323 トラフィックは、Access Control List(ACL; アクセス コントロール リスト)を使用して、ネットワーク内のルータまたはスイッチによってマーキングされます。

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


) RSVP。Cisco Unified CM 5.0 では、クラスタ内のエンドポイント間における Resource Reservation Protocol(RSVP; リソース予約プロトコル)のサポートが導入され、8.0 Unified CM では SIP トランク上の RSVP が導入されています。RSVP は、コール アドミッション制御に使用されるプロトコルであり、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。8.0(1) リリースの SIP または H.323 では、Unified CVP コール サーバを介した呼制御シグナリングに RSVP は使用できません。コール アドミッション制御のソリューションとして、CVP および UCM でロケーション コンフィギュレーションを採用することを推奨します。「ローカル拠点のコール アドミッション制御(LBCAC/queue-at-the-edge)」を参照してください。


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 をプロビジョニングするためのガイドラインおよび例を示します。

帯域幅のサイジング

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

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

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 ゲートウェイへの場合で測定されています。

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

VXML ドキュメント タイプ
VXML ドキュメント サイズ(概算)

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

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/拠点

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 ロード制限を実行するように入力ゲートウェイを設定できます。

voice translation-rule 3
rule 3 /5559000/ /5559001/
!
voice translation-profile change
translate called 3
!
!Primary dial-peer is ASR/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。Cisco Unified CM 5.0 では、クラスタ内のエンドポイント間における Resource Reservation Protocol(RSVP; リソース予約プロトコル)のサポートが導入され、Unified CM Release 8.0 では SIP トランク上の RSVP が導入されています。RSVP は、コール アドミッション制御に使用されるプロトコルであり、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。8.0(1) リリースの SIP または H.323 では、Unified CVP コール サーバを介した呼制御シグナリングに RSVP は使用できません。コール アドミッション制御のソリューションとして、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

ローカル拠点のコール アドミッション制御(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

QoS マーキング

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

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

コンポーネント
ポート
キュー
PHB
DSCP
最大遅延
(ラウンド トリップ)

メディア サーバ

TCP 80

CVP- データ

AF111

101

1 秒

Unified CVP コール サーバ、H.323

TCP 1720

コール シグナリング

CS3

24

200 ミリ秒

Unified CVP コール サーバ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ミリ秒

Unified CVP IVR サービス

TCP 8000

CVP- データ

AF111

101

1 秒

Unified CVP VXML Server

TCP 7000

CVP- データ

AF111

101

1 秒

入力ゲートウェイ、H.323

TCP 1720

コール シグナリング

CS3

24

200 ミリ秒

入力ゲートウェイ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ミリ秒

VoiceXML ゲートウェイ、H.323

TCP 1720

コール シグナリング

CS3

24

200 ミリ秒

VoiceXML ゲートウェイ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ミリ秒

H.323 ゲートキーパー

UDP 1719

コール シグナリング

CS3

24

200 ミリ秒

SIP プロキシ サーバ

TCP または UDP 5060

コール シグナリング

CS3

24

200 ミリ秒

MRCP

TCP 554

コール シグナリング

CS3

24

200 ミリ秒

1.CVP- データ トラフィックの DSCP(または PHB)値は単なる推奨値です。必要に応じてトラフィックのマーキングに使用する実際の DSCP 値を選択できます。

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

ネットワーク遅延

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

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

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

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

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

1. 無音期間中に音声を発信者に提供する

次の設定は、無音期間中に呼び出し音および音声を提供することで、発信者による切断を回避します。

存続可能性サービスでは、「wan-delay-ringback」を 1 に設定して、IVR での標準コール設定時間よりも長いときに呼び出し音を追加できます。

IVR.FetchAudioDelay および IVR.FetchAudioMinimum の IVR サブシステム設定が追加されました。これらは、WAN リンクを介したルート ドキュメント取得で遅延が発生した場合のための WAN 遅延設定です。

IVR.FetchAudio の値を fetchaudio="flash:holdmusic.wav" のように指定します。デフォルトを空のままにして、標準のシナリオでは何も再生されないようにします。


) • デフォルト設定の 2 は、標準のネットワーク シナリオでピッという音を回避するために必要です。

WAN 遅延をゼロに設定すると、すぐに holdmusic.wav が再生され、少なくとも約 5 秒間再生されます。

ECC 変数(user.microapp.fetchdelay、user.microapp.fetchminimum、user.microapp.fetchaudio など)を使用して、getSpeechExternal マイクロアプリケーションの呼び出しについてこれらの値をオーバーライドできます。

2. Microsoft TCP Chimney 設定の無効化

CVP Server での TCP オフロード(Chimney)の無効化は、http://www.cisco.com/en/US/ts/fn/632/fn63215.html で示すように行われます。

http://support.microsoft.com/kb/948496 にある Microsoft 社のパッチを CVP Server ボックスに適用します。

Windows 2003 SP2 では、NIC から CPU への一部の TCP トラフィックのオフロードに役立つ TCPChimney スタックがデフォルトでオンになっています。

TCP オフロード/Chimney を無効化する手順を次に示します。ステップ 2 ~ 4 は、上記のリンクの「回避策」セクションで説明されています。

パッチを適用します(上記のリンクの「解決方法」セクションにリストされています。適切なパッチを選択します)。

NIC のプロパティ ウィンドウでオフロードを無効にします。

レジストリで変更を確認します。

3. VXML ゲートウェイでのパス MTU 探索の有効化

VXML ゲートウェイで、ip tcp path-mtu-discovery コマンドを追加します。

パス MTU 探索は、TCP 接続のエンドポイント間のネットワークで使用可能な帯域幅を最大限使用するための方法です。

4. VXML Server と ICM スクリプト間のラウンドトリップの最小化

実行中の VXML Server アプリケーションから ICM スクリプトに制御が戻されると、大幅な WAN 遅延が発生します。

VXML Server アプリケーションが実行された後には、ICM スクリプトに戻る回数を最小限に抑えることがベスト プラクティスです。VXML Server と ICM スクリプト間の各ラウンドトリップでは、新しい 2 つの TCP 接続の確立、および複数の VXML ドキュメント(VXML Server のルート ドキュメントを含む)の HTTP 取得によって遅延が発生します。

5. 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

最初の G.711 メディア バーストのブロック

ゲートウェイは、最初にコールを受信すると、呼制御の責任をハンドオフするために H.323 を使用して Unified CVP コール サーバ(コール サーバ)に信号を送信します。この最初のコールを確立するために、短いメディア ストリームがゲートウェイとコール サーバ間で確立されます。このメディア ストリームは、ゲートウェイからコール サーバへの一方向のみです。このメディア ストリームは、Unified CM のロケーションベースのコール アドミッション制御の対象ではないため、プライオリティ キューのオーバーサブスクライブを回避するために、このメディア ストリームが帯域幅制約リンクを通過しないようにすることを推奨します。この予防措置は、H.323 展開の場合にのみ必要です。SIP 展開では考慮する必要はありません。

次の IOS コンフィギュレーションでは、Voice Browser との RTP 接続の確立が失敗した場合に、ネットワークでの不要な接続試行および ICMP 宛先への到達不能応答が回避されます。この回避策を使用しない場合、「show proc cpu」出力で示される CPU スパイクが高くなり、「IP Input」と呼ばれるプロセスの CPU 使用率が 10% を超えます。

access-list 100 deny udp host 10.0.0.1 host 10.10.0.100 range 16384 65535
access-list 100 permit ip any any
 
interface serial0/0
ip access-group 100 out
 

上記の例では、10.0.0.1 が音声ゲートウェイの H.323 による IP アドレスであり、10.10.0.100 はコール サーバです。複数のコール サーバが存在する場合は、各サーバに 1 つの ACL エントリを追加します。インターフェイス serial0/0 は、コール サーバをホスティングしている中央サイトに接続する WAN インターフェイスです。


) 上記の回避策では、RTP 接続の失敗が原因で発生する ICMP「到着不能」メッセージの送信も回避されます。


ファイアウォールを使用したネットワーク セキュリティ

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


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


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

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

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

TCP 80

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

TCP 1720

音声ゲートウェイから 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 コール サーバから出力音声ゲートウェイ H.225

TCP 1720

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

TCP または UDP 5060

Unified CVP コール サーバから VoiceXML ゲートウェイ H.225

TCP 1720

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

TCP または UDP 5060

Unified CVP コール サーバから H.323 ゲートキーパー

UDP 1719

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

TCP または UDP 5060