Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）Release 8.0(x)
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月26日
章のタイトル： メディア ファイル オプション
メディア ファイル オプション
•
「Unified CVP コール サーバ、メディア サーバ、および Unified CVP VXML Server の共存」
• 「Cisco IOS でのキャッシングとストリーミングの設定」
展開と実行中の管理
この場合は、ゲートウェイはプロンプト用の .wav ファイルを取得する必要がないため、WAN 帯域幅は影響を受けません。ただし、プロンプトを変更する必要がある場合は、すべてのゲートウェイで変更する必要があります。エラー メッセージや WAN がダウンしているときに使用できるその他のメッセージなど、クリティカルなプロンプトのみフラッシュに保存することを推奨します。
この場合は、プロンプトの数とサイズに応じて、各ローカル ゲートウェイ（正しく設定されている場合）が多数またはすべてのプロンプトをキャッシュできます（最大 100 MB のプロンプト）。メディア サーバがメディア ファイルを適切に処理しているかどうかをテストする最適な方法は、Internet Explorer などの通常の Web ブラウザを使用し、メディア サーバ上のプロンプトの URL（http://10.4.33.130/en-us/sys/1.wav など）を指定することです。Web ブラウザでは、認証を必要とせずに .wav ファイルをダウンロードして再生できる必要があります。
Unified CVP コール サーバ、メディア サーバ、および Unified CVP VXML Server の共存
Unified CVP コール サーバ、メディア サーバ、および Unified CVP VXML Server が同じハードウェア サーバ上に存在し、複数の共存サーバがある場合、Unified CVP は呼制御、VXML、およびメディア ファイル サービスに同じ物理サーバを自動的には使用しません。コンポーネントが共存していても、1 つのコンポーネントが他の共存コンポーネントを使用することは強制されず、別のサーバに置かれているコンポーネントを使用する可能性と同程度になります。
デフォルトでは、コンポーネントはすべての物理サーバ間でロード バランシングされ、すべてのサービスに同じサーバを使用しようとはしません。数千のコールではすべてのサーバ上のすべてのコンポーネントがロード バランシングされ、均等に利用されますが、ある特定のコールに対して複数の異なる物理サーバが使用される可能性があります。このため、ある特定のコールに対して 1 台のサーバで H.323/SIP 呼制御を使用し、別のサーバで VoiceXML を使用し、さらに別のサーバでメディア ファイルを使用できます。
コールごとにこれらすべての機能に対して同じ物理サーバを使用するように Unified CVP を設定することにより、管理とトラブルシューティングを単純化できます。システム内にサーバが 1 台しかない場合、このことは問題になりません。次の手順は、ロードバランシングを行って各コンポーネントにランダムなサーバを使用する代わりに、同じ物理サーバ上のコンポーネントを使用するように Unified CVP を設定する方法を示しています。
次の手順を実行して、ICM スクリプト エディタで共存 Unified CVP VXML Server を選択します。
1. ICM スクリプトで Unified CVP VXML Server を指定する media_server ECC 変数を設定する場合は、式エディタを使用して media_server ECC 変数を concatenate("http://",Call.RoutingClient,":7000/CVP") に設定します。ここで、 Call.RoutingClient は ICM によって自動的に設定される組み込みコール変数です。ICM 内のルーティング クライアント名は、必ずしも Unified CVP Server のホスト名と同じである必要はありません（通常は同じではありません）。
2. VXML ゲートウェイでルーティング クライアント名をホスト名として使用できます。ただし、ルータはアンダースコアなどの非準拠文字が含まれている場合にホスト名を IP アドレスに変換できないため、非準拠文字をホスト名の一部として使用しないでください。ホスト名に無効な文字が使用されないように、ルータで ip hostname strict コマンドを使用することも推奨します。これにより、ホスト名は Unified CVP で確実に受け入れられます。
3. すべての Unified CVP Server Routing Client のルーティング クライアント ホスト名を設定します。
次の手順を実行して、Cisco Unified Call Studio 内の共存メディア サーバを選択します。
1. ICM スクリプトで、 ToExtVXML[] 配列型変数の 1 つに "ServerName=call.routingclient" などの call.routingclient データを設定します。この変数は Unified CVP VXML Server に渡され、変数は変数名 ServerName でセッション データに保存されます。
2. Cisco Unified Call Studio で、置換を使用してデフォルト オーディオ パスを読み込みます。見つかった Application_Modifier 要素を Context フォルダに追加し、[Settings] タブにデフォルト オーディオ パスを次の形式で指定します。
http://{Data.Session.ServerName}
Micro-Apps を Unified CVP VXML Server とともに使用している場合は、ICM スクリプトの media_server ECC 変数に特に注意する必要があります。Unified CVP VXML Server とメディア サーバの両方を指定するために同じ変数が使用されますが、変数の内容では指定するサーバに応じて異なる形式が使用されるためです。 media_server ECC 変数は、プロンプトに Micro-App を使用する場合には必ず次に示すように使用する必要があります。後で VXML Server を使用する場合は、前述の手順に従ってこの変数をリライトする必要があります。
1. ICM スクリプトでメディア サーバを指定する media_server ECC 変数を設定する場合は、式エディタを使用して media_server ECC 変数を concatenate("http://",Call.RoutingClient) に設定します。ここで、 Call.RoutingClient は ICM によって自動的に設定される組み込みコール変数です。ICM 内のルーティング クライアント名は、必ずしも Unified CVP Server のホスト名と同じである必要はありません（通常は同じではありません）。
2. VXML ゲートウェイでルーティング クライアントの名前をホスト名として使用できます。ただし、ルータはアンダースコアなどの非準拠文字が含まれている場合にホスト名を IP アドレスに変換できないため、非準拠文字をホスト名の一部として使用しないでください。ホスト名に無効な文字が使用されないように、ルータで ip hostname strict コマンドを使用することも推奨します。これにより、ホスト名は Unified CVP で確実に受け入れられます。
3. すべての Unified CVP Server Routing Client のルーティング クライアント ホスト名を設定します。
プロンプト取得の帯域幅計算
プロンプトが HTTP メディア サーバに保存される場合は、プロンプトの更新期間がそのサーバで定義されます。プロンプトによって消費される帯域幅は、各ゲートウェイでのプロンプトの初期ロードと、更新間隔の失効時の定期更新から構成されます。
プロンプトで消費される帯域幅を決定する例として、展開に 50 個のプロンプトがあり、それぞれの平均サイズが 50 kB（50,000 バイト）であると想定します。また、プロンプトの更新期間が HTTP メディア サーバで 15 分（900 秒）として定義されていることも想定します。この展開のプロンプトに必要な WAN 帯域幅は次のように計算できます。
Cisco IOS でのキャッシングとストリーミングの設定
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 Media Player キャッシュと HTTP クライアント キャッシュの 2 種類があります。HTTP クライアント キャッシュは、HTTP サーバからダウンロードされるファイルの保存に使用されます。非ストリーミング モードでは、メディア ファイル全体が HTTP クライアント キャッシュの内部に保存されます。ストリーミング モードでは、メディア ファイルの最初のチャンクが HTTP クライアント キャッシュと IVR キャッシュに保存され、その後のすべてのファイルのチャンクは IVR キャッシュにのみ保存されます。
非ストリーミング モードのみを使用するという前述の推奨により、IVR プロンプト キャッシュは使用されず、HTTP クライアント キャッシュがプライマリ キャッシュになります。HTTP クライアント キャッシュには、100 MB のプロンプトを保存できるという利点もありますが、IVR キャッシュは 16 MB に制限されています。
HTTP クライアント キャッシュを設定するには、次の IOS コマンドを使用します。
<1-10000> は、キロバイト単位でのファイル サイズです。デフォルトの最大ファイル サイズは 50 kB ですが、推奨されるファイル サイズは 600 kB です。設定された HTTP クライアント メモリ ファイル サイズよりも大きいファイルはキャッシュされません。
<0-100000> は、すべてのプロンプトに使用可能な合計メモリ サイズ（キロバイト単位）です。ゼロの値は HTTP キャッシングを無効にします。HTTP クライアント キャッシュのデフォルトのメモリ プール サイズは 10 Mb です。推奨されるメモリ プール サイズは、メディア サーバに保存されているすべてのプロンプトの合計サイズで、最大 100 MB です。
クエリー URL のキャッシング
クエリーは、疑問符（ ? ）の後に 1 つ以上の "name=value" 属性のペアが続く URL です。Unified CVP VXML Server は、発信者にレンダリングされる動的 VoiceXML ページの生成時にクエリー URL を多用します。各コールは一意であるため、クエリー URL から取得されるデータはキャッシュ メモリを浪費し、クエリー URL にはアカウント番号や PIN などの情報を含めることができるためセキュリティ リスクが発生します。
クエリー URL のキャッシングは、Cisco IOS ではデフォルトで無効になっています。無効になっていることを確認するには、Cisco IOS で show run コマンドを発行し、次の Cisco IOS コマンドが表示されないことを確認します。
TCP ソケットの永続性
TCP ソケット接続を開く、および閉じるためのオーバーヘッドは、アプリケーションが多くの小さな要求を次々に発行する場合には特に、システム パフォーマンスを低下させることがあります。このソケット接続のオーバーヘッドを低減するために、クライアントは前回のアプリケーション要求を処理した後で、次のアプリケーションが同じ接続を再利用できるようにソケットを開いたままにできます。これは、2 つの接続が同じホスト IP アドレスとポート番号を持つ限り実現可能です。この種の接続を 永続接続 と呼びます。名前が示すように、接続は長期間シャットダウンせずに存続できます。
永続接続を確立するには、クライアントとサーバの両方が、接続を永続的にすることに合意する必要があります。Cisco IOS HTTP クライアントがサーバからの永続接続を要求するように設定するには、次のコマンドを設定します。
キャッシュ エージング
HTTP クライアントは、キャッシュされた各エントリの「鮮度」によってそのキャッシュを管理します。キャッシュされたエントリが新鮮であるか古いかは、Age と FreshTime の 2 つの数値に依存します。Age は、ファイルがサーバから最後にダウンロードされてからの経過時間です。FreshTime は、ファイルが最後にダウンロードされてから、HTTP クライアント キャッシュ内で新鮮であると予想される期間です。
サーバからの HTTP メッセージ ヘッダーや、Command Line Interface（CLI; コマンド ライン インターフェイス）で設定されたキャッシュ更新値など、ファイルの FreshTime に影響を与える可能性のある変数は複数あります。
ファイルの FreshTime は、次のシーケンスで決定されます。
1. ファイルが HTTP サーバからダウンロードされたときに、HTTP メッセージ ヘッダーの 1 つに次の内容が含まれる場合：
Cache-Control：max-age = <value in seconds>
この場合は、max-age がこのファイルの FreshTime として使用されます。
2. 手順 1 が適用されず、次の 2 つのヘッダーが HTTP メッセージに含まれる場合：
Expires： <expiration date time>
この場合は、差（Expires - Date）がこのファイルの FreshTime として使用されます。
3. HTTP/1.1 仕様 RFC 2616（HyperText Transport Protocol）では、前述の手順 1 または 2 で説明したいずれかの HTTP メッセージ ヘッダーが存在することが推奨されています。サーバが HTTP 応答で 1 と 2 のどちらも送信できない場合は、次のメッセージ ヘッダーから Date と Last-Modified の差の 10% が取得されます。
Last-Modified： <last-modified date time>
このため、このファイルの FreshTime は次のように計算されます。
FreshTime = 10% ∗ ((Date) - (Last-Modified))
4. CLI では、手順 1 ～ 3 のいずれのメッセージ ヘッダーも存在しない場合に、ユーザは FreshTime 値を暫定値としてファイルに割り当てることができます。
デフォルトの更新値は 86400 秒（24 時間）です。設定された HTTP クライアント キャッシュ更新は、手順 1 ～ 3 のいずれのメッセージ ヘッダーも存在しない場合にはファイルに影響しません。ただし、CLI コマンド計算の結果の FreshTime がシステム デフォルト（86400 秒）未満になる場合、FreshTime はデフォルト値（86400 秒）に設定されます。また、このコマンドには遡及効果がありません。つまり、新規に設定した更新値は新規の着信ファイルにのみ適用され、すでにキャッシュ内にあるエントリには影響を与えません。
古いファイルは、必要な場合にのみ更新されます。つまり、キャッシュされた古いエントリは、キャッシュ内のメモリ空間を必要とする同じファイルまたは別のファイルの新しいコピー用の空間を確保するために削除されるまで、長期間キャッシュ内に残ることができます。
キャッシュされた古いエントリは、次のすべての条件が満たされると、必要に応じて削除されます。
• 更新カウントがゼロ（0）である。つまり、キャッシュされたエントリが使用されていない。
• 他のエントリ用の空間を確保するために、そのメモリ空間が必要である。
Age が FreshTime を超過し、ファイルを再生する必要がある場合、HTTP クライアントはファイルが更新されたかどうかを判断するためにメディア サーバをチェックします。HTTP クライアントは、GET 要求をサーバに発行するときに、条件付き GET を使用してネットワーク トラフィックへの影響を最小化します。GET 要求では、サーバに送信されるヘッダーに If-Modified-Since が含まれます。このヘッダーがあると、サーバは 304 応答コード（未修正）で応答するか、ファイルが最近更新された場合にはファイル全体を返します。
この条件付き GET は非ストリーミング モードにのみ適用されます。ストリーミング モードでは、HTTP クライアントは常に条件なし GET を発行します。つまり、GET 要求に If-Modified-Since ヘッダーは含まれないため、ストリーミング モードでは各 GET に対して条件なし再ロードが行われます。
次のコマンドを発行することで、個々のファイルをキャッシュに再ロードできます。
拠点オフィスとの関係
ほとんどの場合、Unified CVP を拠点オフィス展開で実装する顧客は、ハードウェアの占有スペースが小さくなることを期待して、ローカル メディア サーバは配置しません。したがって、エラー メッセージや、WAN がダウンしたときに発信側に再生されるその他のメッセージなどの一部のクリティカル プロンプトをフラッシュに保存する必要があります。
G.711 mu-law 形式で記録される場合、平均的な持続時間の通常のプロンプトのサイズは約 10 ～ 15 kB です。このような実装でゲートウェイをサイジングする場合は、プロンプト数とそのサイズを考慮してフラッシュ メモリをサイジングし、Cisco IOS イメージを保存するためのスペースも残しておきます。
フィードバック