この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
(注) |
Unified CVP コール サーバ、メディア サーバ、および Unified CVP VXML Server は、同じサーバで共存します。 |
Unified CVP コール サーバ、メディア サーバ、および Unified CVP VXML Server が同じハードウェア サーバ上に存在し、複数の共存サーバがある場合、Unified CVP はコール制御、VXML、およびメディア ファイル サービスに同じ物理サーバを自動的には使用しません。 コンポーネントが共存していても、1 つのコンポーネントが他の共存コンポーネントを使用することは強制されず、別のサーバに置かれているコンポーネントを使用する可能性と同程度になります。
デフォルトでは、コンポーネントはすべての物理サーバ間でロード バランシングされ、すべてのサービスに同じサーバを使用しようとはしません。 数千のコールではすべてのサーバ上のすべてのコンポーネントがロード バランシングされ、均等に利用されますが、ある特定のコールに対して複数の異なる物理サーバが使用される可能性があります。 このため、ある特定のコールに対して 1 台のサーバで SIP コール制御を使用し、別のサーバで VoiceXML を使用し、さらに別のサーバでメディア ファイルを使用できます。
コールごとにこれらすべての機能に対して同じ物理サーバを使用するように Unified CVP を設定することにより、管理とトラブルシューティングを単純化できます。 システム内にサーバが 1 台しかない場合、このことは問題になりません。 次の手順は、ロードバランシングを行って各コンポーネントにランダムなサーバを使用する代わりに、同じ物理サーバ上のコンポーネントを使用するように Unified CVP を設定する方法を示しています。
次の手順を実行して、Cisco Unified Call Studio 内の共存メディア サーバを選択します。
Micro-Apps を Unified CVP VXML Server とともに使用している場合は、ICM スクリプトの media_server ECC 変数に特に注意してください。Unified CVP VXML Server とメディア サーバの両方を指定するために同じ変数が使用されますが、変数の内容では指定するサーバに応じて異なる形式が使用されるためです。 media_server ECC 変数は、プロンプトに Micro-App を使用する場合には必ず次に示すように使用してください。 後で Unified CVP VXML Server を使用する場合は、前述の手順に従ってこの変数をリライトします。
プロンプトが HTTP メディア サーバに保存される場合は、プロンプトの更新期間がそのサーバで定義されます。 プロンプトによって消費される帯域幅は、各ゲートウェイでのプロンプトの初期ロードと、更新間隔の失効時の定期更新から構成されます。
プロンプトで消費される帯域幅を決定する例として、展開に 50 個のプロンプトがあり、それぞれの平均サイズが 50 kB(50,000 バイト)であると想定します。 また、プロンプトの更新期間が HTTP メディア サーバで 15 分(900 秒)として定義されていることも想定します。 この展開のプロンプトに必要な WAN 帯域幅は次のように計算できます。
(50 プロンプト) * (50,000 バイト/プロンプト) * (8 ビット/バイト) = 20,000,000 ビット
(20,000,000 ビット) / (900 秒) = 22.2 kbps/拠点
Cisco IOS VoiceXML Browser では、Cisco IOS の一部である HTTP クライアントが使用されます。 クライアントは、VoiceXML ドキュメント、オーディオ ファイル、およびその他のファイル リソースをフェッチします。 オーディオ プロンプトの再生に関連して、キャッシングおよびストリーミングという 2 つの主要なプロパティがあります。 この 2 つのプロパティは相互に密接に関連しており、ルータのロード時のシステム パフォーマンスに大きく影響することがあります。
非ストリーミング モードでは、Media Player でプロンプトの再生を開始する前に、オーディオ ファイル全体を HTTP サーバからルータにダウンロードする必要があります。 これは、発信者側で遅延が発生することを意味します。 小さなファイルのダウンロードには数ミリ秒しかかからないため、オーディオ ファイルが比較的小さければ発信者は遅延に気付きません。 大きなファイルのロードの遅延は、キャッシングまたはストリーミング モードを使用することで克服できます。
ストリーミング モードでは、Media Player は HTTP サーバから発信者にオーディオを「メディア チャンク」で「ストリーミング」します。 最初のチャンクがサーバからフェッチされるとすぐに、Media Player は再生を開始できます。 ストリーミング モードの利点は、オーディオ プロンプトのサイズに関係なく、発信者側に顕著な遅延がないことです。 ストリーミング モードの欠点は、メディア ファイルからのフェッチのやりとりがすべてチャンクで行われるため、パフォーマンスが低下することです。 また、ファイルをメモリにキャッシュする機能により、HTTP サーバから大きなファイルを直接ストリーミングする利点が低減します。
Unified CVP VoiceXML ゲートウェイでは、プロンプトの非ストリーミング モードをキャッシングと組み合わせて使用することを推奨します。 非ストリーミング モードを設定するための Cisco IOS コマンドは、次のとおりです。
ivr prompt streamed none
メディア ファイルの保存に関連するキャッシュには、IVR Media Player キャッシュと HTTP クライアント キャッシュの 2 種類があります。 HTTP クライアント キャッシュは、HTTP サーバからダウンロードされるファイルの保存に使用されます。 非ストリーミング モードでは、メディア ファイル全体が HTTP クライアント キャッシュの内部に保存されます。 ストリーミング モードでは、メディア ファイルの最初のチャンクが HTTP クライアント キャッシュと IVR キャッシュに保存され、その後のすべてのファイルのチャンクは IVR キャッシュにのみ保存されます。
非ストリーミング モードのみを使用するという前述の推奨により、IVR プロンプト キャッシュは使用されず、HTTP クライアント キャッシュがプライマリ キャッシュになります。 HTTP クライアント キャッシュには、100 MB のプロンプトを保存できるという利点もありますが、IVR キャッシュは 16 MB に制限されています。
HTTP クライアント キャッシュを設定するには、次の IOS コマンドを使用します。
http client cache memory file <1-10000>
<1-10000> は、キロバイト単位でのファイル サイズです。 デフォルトの最大ファイル サイズは 50 kB ですが、推奨されるファイル サイズは 600 kB です。 設定された HTTP クライアント メモリ ファイル サイズよりも大きいファイルはキャッシュされません。
http client cache memory pool <0-100000>
<0-100000> は、すべてのプロンプトに使用可能な合計メモリ サイズ(キロバイト単位)です。 ゼロの値は HTTP キャッシングを無効にします。 HTTP クライアント キャッシュのデフォルトのメモリ プール サイズは 10 Mb です。 推奨されるメモリ プール サイズは、メディア サーバに保存されているすべてのプロンプトの合計サイズで、最大 100 MB です。
クエリーは、疑問符(?)の後に 1 つ以上の「name=value」属性のペアが続く URL です。 Unified CVP VXML Server は、発信者にレンダリングされる動的 VoiceXML ページの生成時にクエリー URL を多用します。 各コールは一意であるため、クエリー URL から取得されるデータはキャッシュ メモリを浪費し、クエリー URL にはアカウント番号や PIN などの情報を含めることができるためセキュリティ リスクが発生します。
クエリー URL のキャッシングは、Cisco IOS ではデフォルトで無効になっています。 無効になっていることを確認するには、Cisco IOS で show run コマンドを発行し、次の Cisco IOS コマンドが表示されないことを確認します。
http client cache query
TCP ソケット接続を開く、および閉じるためのオーバーヘッドは、アプリケーションが多くの小さな要求を次々に発行する場合には特に、システム パフォーマンスを低下させることがあります。 このソケット接続のオーバーヘッドを低減するために、クライアントは前回のアプリケーション要求を処理した後で、次のアプリケーションが同じ接続を再利用できるようにソケットを開いたままにできます。 これは、2 つの接続が同じホスト IP アドレスとポート番号を持つ限り実現可能です。 この種の接続を永続接続と呼びます。 名前が示すように、接続は長期間シャットダウンせずに存続できます。
永続接続を確立するには、クライアントとサーバの両方が、接続を永続的にすることに合意する必要があります。 Cisco IOS HTTP クライアントがサーバからの永続接続を要求するように設定するには、次のコマンドを設定します。
http client connection persistent
HTTP クライアントは、キャッシュされた各エントリの「鮮度」によってそのキャッシュを管理します。 キャッシュされたエントリが新鮮であるか古いかは、Age と FreshTime の 2 つの数値に依存します。 Age は、ファイルがサーバから最後にダウンロードされてからの経過時間です。 FreshTime は、ファイルが最後にダウンロードされてから、HTTP クライアント キャッシュ内で新鮮であると予想される期間です。
サーバからの HTTP メッセージ ヘッダーや、コマンドライン インターフェイス(CLI)を使用して設定されたキャッシュ更新値など、ファイルの FreshTime に影響を与える可能性のある変数は複数あります。
ファイルの FreshTime は、次のシーケンスで決定されます。
http client cache refresh <1-864000>デフォルトの更新値は 86400 秒(24 時間)です。 設定された HTTP クライアント キャッシュ更新は、手順 1 ~ 3 のいずれのメッセージ ヘッダーも存在しない場合にはファイルに影響しません。 ただし、CLI コマンド計算の結果の FreshTime がシステム デフォルト(86400 秒)未満になる場合、FreshTime はデフォルト値(86400 秒)に設定されます。 また、このコマンドには遡及効果がありません。 つまり、新規に設定した更新値は新規の着信ファイルにのみ適用され、すでにキャッシュ内にあるエントリには影響を与えません。
古いファイルは、必要な場合にのみ更新されます。 つまり、キャッシュされた古いエントリは、キャッシュ内のメモリ空間を必要とする同じファイルまたは別のファイルの新しいコピー用の空間を確保するために削除されるまで、長期間キャッシュ内に残ることができます。
キャッシュされた古いエントリは、次のすべての条件が満たされると、必要に応じて削除されます。
Age が FreshTime を超過し、ファイルを再生する必要がある場合、HTTP クライアントはファイルが更新されたかどうかを判断するためにメディア サーバをチェックします。 HTTP クライアントは、GET 要求をサーバに送信するときに、条件付き GET を使用してネットワーク トラフィックへの影響を最小化します。 GET 要求では、サーバに送信されるヘッダーに If-Modified-Since が含まれます。 このヘッダーがあると、サーバは 304 応答コード(未修正)を返すか、ファイルが最近更新された場合にはファイル全体を返します。
この条件付き GET は非ストリーミング モードにのみ適用されます。 ストリーミング モードでは、HTTP クライアントは常に条件なし GET を発行します。つまり、GET 要求に If-Modified-Since ヘッダーは含まれないため、ストリーミング モードでは各 GET に対して条件なし再ロードが行われます。
次のコマンドを発行することで、個々のファイルをキャッシュに再ロードできます。
test http client get http://10.0.0.130/en-us/sys/1.wav reload
ブランチ オフィスに Unified CVP を実装する場合、導入では、ローカル メディア サーバではなくハードウェア用に小規模のフットプリントが必要です。
G.711 mu-law 形式で記録される場合、平均的な持続時間の通常のプロンプトのサイズは約 10 ~ 15 kB です。 このような実装でゲートウェイをサイジングする場合は、プロンプト数とそのサイズを考慮してフラッシュ メモリをサイジングし、Cisco IOS イメージを保存するためのスペースも残しておきます。