この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章では、Unified CVP ネットワークの展開特性およびプロビジョニング要件について説明します。 WAN を介したリモート コンポーネント間のネットワーク トラフィック フローに関するプロビジョニング ガイドラインを示します(WAN トラフィック フローに適切な Quality of Service(QoS)を適用するための推奨事項など)。
ネットワークの考慮事項に関する最新情報については、次の URL から入手可能な最新バージョンの『Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND)』で説明している導入モデル、帯域幅、および QoS の項を参照してください。
次の表に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
説明 |
|
---|---|
多くの Unified CVP 展開では、すべてのコンポーネントが集中化されているため、考慮する WAN ネットワーク トラフィックはありません。 一般に、Unified CVP 環境で WAN ネットワーク構造を考慮する必要があるのは次の 2 つの場合だけです。
Unified ICM とは異なり、Unified CVP での QoS の考え方は、次のように非常に単純です。
Unified CVP 展開を適切に行うには、適切な帯域幅プロビジョニングを行うことが重要です。 必要な帯域幅のプロビジョニングに役立つように、この章では帯域幅のガイドラインおよび例を示します。
(注) |
RSVP は、コール アドミッション制御に使用されるプロトコルであり、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。 RSVP は、SIP の Unified CVP コール サーバを介したコール制御シグナリングには適していません。 コール アドミッション制御のソリューションとして、CVP および UCM でロケーション コンフィギュレーションを採用することを推奨します。 拡張位置のコール アドミッション制御を参照してください。 |
音声コールは、実際の音声サンプルが含まれた、Real-Time Transport Protocol(RTP; リアルタイム転送プロトコル)パケットで構成されています。 RTP パケットは、次の場合に送信されます。
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 コーデックの混在サポートを参照してください。
Unified CVP ソリューションには、複数のタイプの呼制御トラフィックがあります。 呼制御機能には、コールの設定、維持、破棄、またはリダイレクトに使用される機能が含まれます。
Unified CVP は、現在、3 つのタイプの VoIP エンドポイント(Cisco IOS 音声ゲートウェイ、Cisco Unified Communications Manager(Unified CM)、および呼制御モードまたはシグナリング モードの PGW)で認定されています。 呼制御トラフィック フローは、次のエンドポイント間で発生します。
(注) |
現在承認されている展開設計では、PGW および Unified CVP 間の相互運用性のための SIP をサポートしていません。 この機能が設計で必要な場合は、Cisco Assessment to Quality(A2Q)チームに問い合わせてください。 |
Unified CVP コール サーバおよび Unified ICM VRU PG は、GED-125 プロトコルを使用して通信します。 GED-125 プロトコルには、次が含まれます。
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
データ トラフィックには、VoiceXML ゲートウェイによって実行された HTTP 要求の結果として返される VoiceXML ドキュメントおよび録音済みのメディア ファイルが含まれます。 具体的には次のとおりです。
この章では主に、リモート入力ゲートウェイと、リモート入力ゲートウェイがインターフェイスしている次のコンポーネントとの間で使用されるデータ フローおよび帯域幅のタイプについて説明します。
必要な帯域幅の見積もりに役立ち、必要に応じてこれらのネットワーク セグメントの QoS をプロビジョニングするためのガイドラインおよび例を示します。
Unified CVP ソリューションにおけるほとんどの帯域幅要件は、分散型 Unified CVP トポロジで発生します。これは、主に、入力ゲートウェイや VoiceXML ゲートウェイが、メディア ファイル、VoiceXML ドキュメント、およびコール制御シグナリングを提供するサーバと分離されているためです。 次の説明では、拠点へのすべてのコールが、1 分間の IVR 処理の後、エージェントへの単一転送のために同様に 1 分間経過してから開始されると仮定しています。 各拠点には 20 のエージェントが存在し、各エージェントは 1 時間当たり 30 コールを処理するため、拠点ごとに 1 時間当たり合計 600 のコールが処理されます。 したがって、コールの平均速度は、各拠点で 1 秒当たり 0.166 コールとなります。
これらの変数が少し変わっただけでも、サイジングには大きく影響する可能性があることに注意してください。 1 時間全体で 1 秒当たり 0.166 コールが平均となります。 通常、コールは 1 時間全体で均一に到着するわけではなく、ビジーな時間帯で山と谷があります。 最もビジーなトラフィック期間を検出し、最悪ケースのシナリオに基づいてコールの到着率を計算するようにします。
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 ゲートウェイの間で測定されます。
メディア ファイル(プロンプト)は、各ルータのフラッシュ メモリにローカルに保存できます。 この方法では、帯域幅を考慮する必要がなくなりますが、プロンプトを変更するときに、プロンプトをルータごとに置き換える必要があるため、保守性が問題となります。 一方、HTTP メディア サーバ(または HTTP キャッシュ エンジン)にプロンプトが保存されている場合、ゲートウェイは、最初にプロンプトを取得すれば、音声プロンプトをローカルにキャッシュできます。 HTTP メディア サーバを適切に設定すると、プロンプトの数およびサイズに応じて(すべてではなくても)多数のプロンプトをキャッシュできます。 プロンプトの更新期間は HTTP メディア サーバで定義されます。 したがって、使用される帯域幅は、各ゲートウェイでのプロンプトの初期ロード、および更新間隔の失効時の定期更新に限定されます。
ゲートウェイでプロンプトをキャッシュしない場合は、帯域幅が余分に使用されるだけでなく、Cisco IOS のパフォーマンスが大幅に低下します(35 ~ 40%)。 ゲートウェイでのプロンプト キャッシングの設定の最新情報については、次の URL から入手可能な最新バージョンの『Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP)』を参照してください。
合計で 50 のプロンプトがあり、平均サイズが 50 kB で、更新間隔が 15 分であるとします。 この場合、帯域幅の使用量は次のようになります。
(50 プロンプト)*(50,000 バイト/プロンプト)*(8 ビット/バイト)= 20,000,000 ビット
(20,000,000 ビット) / (900 秒)= 平均 22.2 kbps/拠点
SIP はテキスト ベースのプロトコルです。 通常の SIP コール フローでは、コールごとに約 17,000 バイトが使用されます。 1 秒ごとのコールに基づいた前述の帯域幅の数式を使用すると、平均の帯域幅使用量は次のようになります。
(17,000 バイト/コール)*(8 ビット/バイト)= 136,000 ビット/コール
(0.166 コール/秒)*(136 キロビット/コール)= 平均 22.5 kbps/拠点
集中型 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 対応のコール数を制限し、制限に達した場合にはコールをすべて拒否するのではなく、標準の 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』を参照してください(ログイン認証が必要です)。 |
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』を参照してください。
コール アドミッション制御は、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』を参照してください。
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 ゲートウェイにルーティングされる必要があります。 つまり、可能な場合は必ずローカル拠点エージェントを選択してください。
単一のクラスタ 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)機能は、以前の CAC 機能の 2 つの重要な問題に対処します。
Unified CM での ELCAC と OrigIP トランク機能との比較:
前のバージョンの Unified CVP では、CAC を設定する方法が提供されていました。 この方法は、ここで示す ELCAC の方法に変更されました。 両方の設定方法については、次の URL から入手可能な『Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP)』を参照してください。
コンポーネント | ポート | キュー | PHB | DSCP | 最大遅延(ラウンド トリップ) |
---|---|---|---|---|---|
適切なアプリケーション帯域幅および 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 による遅延に有用な場合があります。
ファイアウォールまたは ACL を使用してネットワーク セキュリティを設定する場合は、Unified CVP、音声ゲートウェイ、VoiceXML ゲートウェイで使用される TCP/UDP ポートに関する情報について次の表を参照してください。 Unified CVP によって使用されるポートの詳細リストについては、『Unified CVP Port Utilization Guide』を参照してください。
(注) |
Unified CVP Operations Console Server は、他のコンポーネントとの通信にダイナミック ポートを使用するため、残りの Unified CVP コンポーネントがファイアウォール内にある場合は、ファイアウォールの外側に展開できません。 |