Cisco MediaSense 設計ガイド リリース 11.0(1)
ソリューション環境
ソリューション環境

目次

ソリューション環境

一般的なフロー:Unified Communications Manager(BiB)コール

コンプライアンス レコーディング アプリケーションの場合、通話録音は最初の通話が 2 者間で確立された後に Unified Communications Manager から MediaSense への一対の SIP 招待を介して開始されます。 Unified Communications Manager は、コール セットアップに関与しますが、メディアは Unified Communications Manager からではなく、電話機の 1 つから MediaSense に流れます。

インバンド ブログ録音は、同様の方法で開始されます。 SIP 招待は、Unified Communications Manager から MediaSense に送信されます。 アウトバウンド ブログ録音は、MediaSense への API 要求(「startRecording」)から開始され、MediaSense から Unified Communications Manager へのアウトバウンド SIP 招待がトリガーされます。 いずれの場合も、招待の処理によって録音されている電話機と MediaSense 間に確立されている 1 つ以上の RTP メディア ストリームが発生します。 これらのコール フローを次の図に示します。


(注)  


これらの図は、説明のみを目的としており、詳細なメッセージ フローを示してはいません。


Unified Communications Manager(BiB)コールのコンプライアンス レコーディング
Unified Communications Manager コールの直接インバウンド録音
Unified Communications Manager コールの直接アウトバウンド録音

一般的なフロー:Unified Communications Manager(ネットワークベースの録音)コール

コンプライアンス レコーディング アプリケーションの場合、コールの録音は、初期化コールが 2 者間に確立された後、Unified Communications Manager から MediaSense への一組の SIP インビテーションを使用して開始されます。 Unified Communications Manager はコールのセットアップに関与しますが、メディアは Unified Communications Manager からではなく、ISRG2 ルータから MediaSense に流れます。

表 1 コール フロー - Unified Communications Manager NBR
Unified Communications Manager NBR コールのコンプライアンス レコーディング

一般的なフロー:Unified Border Element ダイヤル ピア コール

Unified Border Element ダイヤル ピア録音では、アプリケーションが同様のフローを処理しますが、重要な相違があります。 コールの録音は、それぞれが 1 つの「m」行を含んだ 2 つの別個のインビテーションとは異なり、Unified Border Element から MediaSense に送信される、2 つの「m」行を含んだ、単一の SIP インビテーションで開始されます。 Unified Communications Manager の場合と同様に、招待は最初のコールが 2 者間に確立された後にだけ送信されます。 ただし、MediaSense へ流れるメディアは Unified Communications Manager NBR の場合と同様に Unified Border Element から発し、Unified Communications Manager BiB の場合のようにエンドポイントの 1 つから発するわけではありません。

インバウンド ブログ レコーディングは、エンドポイントから Unified Border Element を介して MediaSense へコールを直接的にダイヤルすることによって開始されます。 いずれの場合も、MediaSense へのインビテーションの処理によって、Unified Border Element と MediaSense の間に 1 つ以上の RTP メディア ストリームが確立されます。 これらのコール フローを次の図に示します。


(注)  


これらの図は、説明のみを目的としており、詳細なメッセージ フローを示してはいません。 また、アウトバウンド ブログ レコーディングは Unified Border Element 配置ではサポートされません。


Unified Border Element コールのコンプライアンス レコーディング
Unified Border Element コールの直接インバウンド録音

一般的なフロー:ストリーミング メディア

ライブ モニタリングは、ストリーミング メディア プレーヤーを実行中のワークステーションが MediaSense に RTSP:// URI の送信でアクティブなメディア アドレスを指定し、RTP メディア ストリームが MediaSense とプレーヤー間に確立されることで開始されます。 このストリームは、実際には MediaSense が電話機から受信しているストリームの 1 つのコピーです。ディスク上にあるものではありません。

再生は、ストリーミング メディア プレーヤーを実行しているワークステーションが RTSP:// URI を MediaSense に送信してアーカイブ メディアのアドレスを指定したときに開始されます。 これで発生する、MediaSense とプレーヤーの間のメディア ストリームは、ディスクから読み取られたものです。

ライブ モニタリングと再生のコール フローを次の図に示します(認証の行われ方を示していますが、詳細なメッセージ フローを表すものではありません)。 MediaSense Media Service は、ストリーミング メディアの処理を担う各ノード内のソフトウェア コンポーネントです。

表 2 ライブ モニタリングと再生のコール フロー
ライブ モニタリング
再生
認証チャレンジを示す再生

MediaSense API はサーバ ベースまたはブラウザ ベースのクライアントからアクセスされます。 サーバ ベースのクライアントは非同期イベントに対してもサブスクライブできます。

ソリューションレベルの導入モデル

この項では、MediaSense をソリューションの一部として導入できる多数の方法をまとめて紹介します。

BiB 分岐のための Unified Communications Manager の展開

これらの配置モデルは、Cisco IP Phone がメディア分岐用に設定されるシナリオを対象にしています。 2 つのバージョンがカバーされます。

  • 基本的な Unified Communications Manager の展開:内部から外部へ
  • 基本的な Unified Communications Manager の展開:内部から内部へ

MediaSense の観点からすれば、実際には 2 つの基本的な Unified Communications Manager のバージョンに違いはありません。 いずれの場合も、電話機によって分岐されたメディアが録音デバイスに送信され、そこで分岐されたストリームがキャプチャされます。 これらは、ソリューション レベルで機能に大きな違いがあるので、ここで区別されます。

Unified Communications Manager の展開:内部から外部へ

上記の図は、BiB 分岐のための基本的な Unified Communications Manager の展開を示し、社外の関係者との通話が録音されます。 この導入は、内部の電話機が適切な録音プロファイルで設定されていれば、着信コールと発信コールの両方に適用されます。

接続がシグナリングの観点から確立されると、メディアは分岐電話機から録音サーバへ直接流れます。

コールがこの電話機から転送される場合、録音セッションは終了します。 コールを受ける電話機が録音用に設定されている場合に限り、コールの次のセグメントがキャプチャされます。

Unified Communications Manager の展開:内部から内部へ

この図は、BiB 分岐のための基本的な Unified Communications Manager の展開を示し、通話は社内の関係者と行われます。 電話機のうち 1 台は、録音用に設定される必要があります。 両方の電話機が録音用に設定されている場合、2 つの独立した録音セッションがキャプチャされます。

Unified Communications Manager Session Management Edition の展開

Unified Communications Manager Session Management Edition(Unified CM SME)環境では、特定の MediaSense クラスタで録音されるすべての電話機が同じ SME リーフ クラスタに含まれている必要があります。 異なるリーフ クラスタの電話機を録音する必要がある場合は、次に示すように別個の独立した MediaSense クラスタを展開する必要があります。

図 1. Unified CM SME の展開

この図は、MediaSense クラスタが Unified CM SME Manager クラスタではなく Unified CM SME リーフ クラスタにどのように接続される必要があるかを示します。 この図は、サポートされる配置である別個の MediaSense クラスタに接続しているリーフ クラスタも示しています。

ネットワークベースの録音のための Unified Communications Manager の展開

次の図は、ネットワークベースの録音(NBR)を使用した録音コールが、メディアが電話機からでなく音声ルータから MediaSense に流れるという点を除き、BiB を使用した録音コールに似ていることを示します。 いずれの場合も、SIP シグナリングは Unified Communications Manager から取得されます。

図 2. ネットワークベースの録音のための Unified Communications Manager の展開

BiB 録音と同様に、会話の録音がされている電話機からコールが転送された場合は、メディアが同じ音声ルータから流れ続けていても録音セッションは終了します。 コールを受ける電話機が録音用(BiB または NBR)に設定されている場合に限り、コールの次のセグメントがキャプチャされます。


(注)  


NBR は、Unified CCE への着信コールについてはまだサポートされていません。

ダイヤル ピア分岐のための基本的な Unified Border Element の展開

上記の図は、ダイヤル ピア分岐のための非常に基本的な Unified Border Element の展開を示し、ここではコールが PSTN から SIP トランクに着信し、社内の SIP 電話機に接続されます。 メディア分岐は、1 つ以上のダイヤル ピアに接続されているレコーダ プロファイル設定を使用した Unified Border Element デバイスによって実行されます。

コールは Unified Border Element(または Cisco ルータ)を通過するときに、2 つのダイヤル ピア、つまりコールが Unified Border Element に入る時点と抜け出る時点のピアを照合します。 Unified Border Element システムでは、これらは着信ダイヤル ピアと発信ダイヤル ピアと呼ばれます。 これらの用語は、コールの方向に関連しています。 着信コールでは、着信ダイヤル ピアは社外を表し、発信ダイヤル ピアは社内を表します。 割り当ては発信コールに逆行します。 このマニュアルでは、内部ダイアル ピアと外部ダイアル ピアをそれぞれ社内と社外を表す用語として使用します。

いくつかの例外はありますが、録音プロファイルを外部のダイアル ピア(着信コールの場合は着信ダイヤル ピア、発信コールの場合は発信ダイヤル ピア)に適用することがベスト プラクティスです。 これは、コールの外部レッグが一般的に非常に安定している一方で、内部レッグは頻繁にさまざまなコンサルティング、会議、転送などの複雑な呼び出し操作の対象となるためです。 これらの操作のいずれかにより Unified Border Element が新しいダイヤル ピア照合をトリガーすると、録音セッションが早く終了することがあります (このような操作により現行のコーデックが変更されると、録音セッションが終了して新規セッションが開始されます)。

この図は、Unified Communications Manager コンポーネントも示しています。 現在は Unified Border Element の展開で必要ですが、Unified Communications Manager はコール シグナリング、メディア、または記録保持を実行しません。 単一の Unified Communications Manager サーバは MediaSense API ユーザを管理し認証する必要があります。 これは、リリース 8.5(1)以降の既存のまたは特別にインストールされている Unified Communications Manager サーバにできます。 理想的には、選択するサーバはコールがロードされていないサーバにするべきです。

Unified Communications Manager サーバは、コール処理において役割を果たさないので、残りの Unified Border Element 配置モデルの図から省略されます。

基本的な Unified Border Element の展開は、実稼働環境で使用されることはほとんどありません。 より一般的に、Unified Communications Manager、他の構内交換機(PBX)、または自動着信呼分配(ACD)は Unified Border Element の内側に接続され、電話機は Unified Border Element に直接ではなくそこに接続されます。 ただし、すべての Unified Border Element の展開には根本的にこの設定が含まれます。 Unified Border Element と MediaSense の厳密な観点から、他のすべてのモデルはこれと変わりません。

ダイヤル ピア録音のためのさまざまな PBX による基本的な Unified Border Element の展開

メディアを分岐するために Unified Border Element を使用する大きな利点の 1 つは、コールが社内のどこに行っても発信者の視点から会話全体をキャプチャする機能です。 これには、コンタクト センター エージェント、コンタクト センター以外の社員、IVR システム、およびシスコ以外の ACD および PBX システムのユーザが含まれます。

上記の図は、MediaSense と Unified Border Element を異機種混在のエンタープライズ環境に導入できる 3 つの方法を示します。 特定のコールは 1 つのフローまたはこれらのフローの組み合わせを経験する可能性があり、発信者の経験すべてが記録されます。 追加の組み合わせも可能です。たとえばコールは IP ベースまたは TDM ベースの IVR システムによって処理される場合があります。

ダイヤル ピア録音のための TDM 入力を使用した Unified Border Element 展開のバリエーション

メディアを分岐するため、Unified Border Element は SIP 対 SIP のコールを処理している必要があります。 コールが TDM によって到着している場合、図に示すように別の TDM ゲートウェイがプロビジョニングされます。 分岐はその後、Unified Border Element の外部のダイヤル ピアで通常どおりに設定されます。

PSTN 制御された転送(別名 *8 Transfer Connect)を実行するためなどに、アプリケーションが DTMF 信号を PSTN に送信するように設計されている場合、Unified Border Element と TDM ゲートウェイの両方が DTMF シグナリングに同じ方式を使用するように設定されていることを確認する必要があります。 両方のデバイスで接続しているダイヤル ピアに同じ dtmf-relay 設定を追加することで確認できます。 リレー タイプ rtp-nte は最も標準で推奨される方式です。 CVP に向かうダイヤル ピアも、rtp-nte に設定する必要があります。

Unified CVP によるダイヤル ピア録音のための Unified Border Element の展開

Unified Border Element を Unified Customer Voice Portal(Unified CVP)に接続すると、MediaSense をコンタクト センターで通話を録音するために使用できます。 次のサブセクションでこれらのモデルについて説明します。

  • Unified CVP による Unified Border Element の展開:一元化された SIP トランクで、存続可能性はありません
  • Unified CVP による Unified Border Element の展開:一元化された SIP トランクで、存続可能性があります
  • Unified CVP による Unified Border Element の展開:一元化された TDM トランク
  • Unified CVP による Unified Border Element の展開:一元化された送信ダイヤラ

Unified CVP の展開では、VXML 機能と、オプションで TDM から IP への変換機能が通常伴います。 Unified CVP 展開の推奨事項では、同じ ISR でのそれら 2 つの機能の組み合わせが時々規定されます。 また、TDM 回線よりも着信 SIP トランクを伴う Unified CVP 導入もあります。 これらの導入では、Unified Border Element ルータを使用でき、VXML 機能をホストすることもできます。 Unified CVP には、オプションのコンポーネント、コール存続可能性も含まれます。これにより、ルータと Unified CVP 間の WAN 接続が稼働していなくても、ブランチ ルータは低下したサービス レベルを発信者に提供し続けることができます。 このコンポーネントは、各ゲートウェイに直接インストールされ、ダイヤル ピアに関連付けられた TCL-IVR アプリケーションとして実装されます。

Unified Border Element メディア分岐による Unified CVP 展開では、最大 4 つの明確なアクティビティを管理する必要があります。

  • TDM から IP への変換
  • コール存続可能性
  • メディア分岐
  • VXML ブラウジング

これらのアクティビティの一部は、ダイヤル ピア レベルで競合するので、相互にうまく作用できるようにいくつかの手順を実行する必要があります。 たとえば、同じダイヤル ピアにメディア分岐と TCL または VXML アプリケーションの両方を設定してはいけません。 各アクティビティはルータでリソースを使用するので、それらすべてのサイジングを考慮する必要があります。 1 台のルータが 4 つの機能すべてを提供するように設定することは技術的に可能であり、これは低いコール ボリュームのシナリオに適しています。 しかし、コール音量が上がるので、VXML ブラウジングまたはメディア分岐を別個のデバイスに移動する必要があります。 この 2 つの機能は同じ場所に配置しないでください。

分離する機能は、ニーズによって異なります。 VXML はルータ リソースの大半を取り(特に自動音声認識が使用されている場合)、そのサイズ計算は他のアクティビティとは異なる(通常はそれより少ない)コール数に基づいて行われます。 サイズ計算の利便性と簡易化のために、VXML を分離することが最適です。

ただし、コールのエージェントの部分のみを録音にキャプチャすることが目的の場合(追加導入オプションと考慮事項を参照)、単独のルータでメディア分岐を行うのであれば、設定はより簡単になります。 この設定は、TDM/IP、コール存続可能性、および VXML ブラウジングを単一のルータ上で同じ場所に配置することが Unified CVP 導入におけるブランチ オフィスの最も一般的な設定であるという点でさらなる利点があります。

マルチサイト イングレス導入(特にブランチ オフィスでの導入)では、コールが不注意に WAN リンクを通過することを防止するために、Unified CVP のコール ルーティング設定で Significant Digits 機能と Send To Originator 機能の組み合わせを使用する必要があります。

これらの方法に関する詳細については、Unified CVP のマニュアルを参照してください。


(注)  


SIP メッセージの通常の処理中に、Unified CVP は、複式ボディとして SIP コンテンツに任意のデータを挿入します。 この形式は、MediaSense では現在サポートされておらず、MediaSense にとって興味深いコンテンツもサポートされていません。 Unified Border Element の録音ダイヤル ピアは、コマンド「signaling forward none」を録音ダイヤル ピアに追加することでこのコンテンツが MediaSense に転送されるのを防ぐように設定される必要があります。

同じ物理ルータが MediaSense と Unified CVP の両方で使用されている場合は、両方の製品によって認定されている IOS のバージョンを実行している必要があります。

最も簡単なシナリオを除き、キャパシティ プランニングについては ISR セールス チームに問い合わせてください。


Unified CVP によるダイヤル ピア録音のための Unified Border Element の展開:SIP トランク、存続可能性なし

このシナリオでは、Unified CVP は、保留音または他の処理のための VXML ゲートウェイへの最初の配信、Unified Contact Center Enterprise(Unified CCE)エージェントへのその後の配信、および他のエージェントおよびデバイスへの予想される追加のネットワーク転送を含むすべてのコール制御操作を管理します。 コールのすべてのセグメントが録音されます。

適切に設定されると、Unified CVP は Unified Border Element ではなく宛先デバイスへの SIP 招待を発行することによってこれらの転送に影響を及ぼします。 これにより、Unified Border Element で新しいダイヤル ピア照合をトリガーすることなくメディアが効果的に再ルーティングされます。

ほとんどのシナリオと同様に、メディア分岐は外部のダイヤル ピアで設定されます。

Unified CVP によるダイヤル ピア録音のための Unified Border Element の展開:SIP トランク、存続可能性あり

このシナリオは、上記のものと同一です。ただし、お客様が通話障害と時刻ルーティングの管理に Unified CVP 存続可能性スクリプトを使用することを選択している場合を除きます。 Unified CVP 存続可能性スクリプトを使用するには、それを Unified Border Element の外部のダイヤル ピアに配置します。 Cisco IOS は、スクリプトとメディア分岐が同じダイヤル ピアで発生することを許可していないため、メディア分岐には(図に示すように)内部のダイヤル ピアを使用します。 呼び出し操作によって新しいダイヤル ピア照合操作を開始する Cisco IOS が不注意にトリガーされる可能性があるので、内部のダイヤル ピアで録音設定することは危険を伴います。 この操作によって、現在の録音セッションが終了します。

適切に設定されると、Unified CVP は Unified Border Element ではなく宛先デバイスへの SIP 招待を発行することによってこれらの転送に影響を及ぼします。 この転送により、Unified Border Element が新しいダイヤル ピア照合をトリガーするのを防ぎます。


(注)  


存続可能性がいかなる種類の通話中障害に対処するように作動する場合、そのスクリプトによって再生される音声(「技術的な問題」のメッセージなど)は MediaSense で録音できません。 しかし、スクリプトがローカル電話にコールを転送する場合、ローカル電話のダイヤル ピアがメディア分岐用に設定されていれば、この会話は録音できます。


REFER 転送の詳細については、「追加導入オプションと考慮事項」を参照してください。

Unified CVP によるダイヤル ピア録音のための Unified Border Element の展開:TDM トランク

Unified CVP 用の TDM MediaSense Unified Border Element の展開は、論理的に別個の TDM ゲートウェイが Unified Border Element よりも先に配置されるという点を除き、SIP トランクの導入と同様です。 Unified Border Element はまだ外部のダイヤル ピアでメディア分岐を行い、Unified Border Element はまだ Unified CVP が相互作用するルータとして機能します。

存続可能性が使用されている場合、それは Unified Border Element ではなく TDM ゲートウェイの POTS ダイヤル ピアに配置されます。 この配置により、Unified Border Element の外部ダイヤル ピアでメディア分岐が維持されます。

Unified CVP が(「*8 Transfer Connect」転送などの場合に)DTMF トーンを PSTN に発行している場合は、TDM ゲートウェイと Unified Border Element 間のコール接続の両端で dtmf-relay sip-kpml または dtmf-relay sip-notify を設定します。

Unified CVP によるダイヤル ピア録音のための Unified Border Element の展開:送信ダイヤラ

Unified CCE SIP 送信ダイヤラを使用した送信キャンペーンは、TDM ゲートウェイに転送先の電話番号を呼び出すように直接指示するように設定されます。 関係者が応答して、留守番電話検出アルゴリズムが応答した関係者が実在の人物であることを確認すると、ダイヤラは TDM ゲートウェイに Unified Border Element を使用してコールを Unified CVP に接続するように指示します。 Unified Border Element と MediaSense の観点からは、これは他の着信コールと同じように見えます。

送信ダイヤラは TDM ゲートウェイに接続され、Unified Border Element には接続されません。

追加導入オプションと考慮事項

Unified Border Element ダイヤル ピアを使用した冗長メディア分岐

通常は、外部ダイヤル ピアに録音プロファイルを適用します。つまり、企業の外部にあるコールの側を表すものです。 特定のコールで、両方のダイヤル ピア上にメディア分岐を設定することもできます。この場合、2 つの独立した録音セッションになります。 この両方のダイヤル ピアは、2 つの別個の独立した MediaSense クラスタに録音を配信するように設定して、録音の真の冗長性を実現する必要があります。 ただし、これは Unified Border Element のパフォーマンスに重大な影響を及ぼします。 サイジングの目的で、Unified Border Element コール伝送容量を半分に分けることを想定します。

パーセンテージ録音

コンプライアンス レコーディングは、定義により、すべてのコールが録音されることを意味します。 ただし、アプリケーションによってはコールの 100 % を録音する必要がない場合もあります。場合によっては、スポット チェックで十分です。

Unified Border Element を使用すれば、コールを疑似ランダム サンプリングして録音することができます。 これは、複数の同一ダイヤル ピアを設定し、同じプリファレンス値を割り当てたうえで、メディア分岐用にそのサブセットのみを設定することで実現されます。 たとえば、3 つの同一インバウンド ダイヤル ピアをプリファレンス レベル 5 に設定し、そのうちの 1 つだけにメディア分岐を設定すると 3 コールに約 1 コールの割合で録音できます。

録音の VRU セグメントの省略

これは、コール ルーティングに Unified CVP が使用されるコンタクト センターの録音に適用されます。

Unified Border Element からの分岐メディアでは、発信者のエクスペリエンス全体を記録できます。 これには、1 つ以上のエージェントとの会話だけでなく、コールがエージェントに配信される前に発生することがある VRU またはコール キューイングのアクティビティもすべて含まれます。 Unified Border Element からの分岐メディアは、エージェントがコールに含まれていない場合の VRU アクティビティの記録にも使用できます。

一部のお客様は、事前エージェント VRU アクティビティを録音から省略することを希望することがあり、これは特に主に保留中の音楽で構成される場合に当てはまります。 これを行う 1 つの方法は、Unified Border Element からではなくエージェントの電話機からメディア分岐することです。 しかし、他の理由で Unified Border Element からメディア分岐することが必要な場合は、Unified CVP にコールのエージェント セグメントを Unified Border Element を介してルーティングさせれば実現できます。 そのためには、受信機能とメディア分岐機能を相互に分離する必要があり、これは、コールを受信側ルータに再度通すか、または 2 台目のルータを使用することで、ルーティングしなければならないことを意味します。

どちらのルーティングのアプローチでも、追加のハードウェアが必要になりますが、2 台目のルータを使用すれば設定は著しく簡単になります。 PSTN 接続が TDM ベースの場合は、やはりコールをルータに再度通して(または、2 台目のルータで)ルーティングする必要があります。 したがって、この項の後半では、メディア分岐ルータと受信側ルータが別々であること、受信側ルータを TDM ゲートウェイか IP 専用の Unified Border Element とすることができること、VXML 機能が受信側ルータで実行されていることを前提とします。

Unified CVP の通常の設定では、エージェントが使用可能になると、そのエージェントの電話機を制御する Unified Communications Manager に Unified CVP が、SIP インビテーションを送信します。 Unified Communications Manager は、受信側ルータとネゴシエーションして、ルータからのメディア ストリームをエージェントの電話に接続します。 受信側ルータ自体は、選択されたエージェントの内線をどの IP アドレスが処理するかを把握する必要がないため、そのコール セグメントのルーティングには関わりません。

この場合の配置を次の図に示します。

Unified CVP は、エージェントセグメント インビテーションが Unified Communications Manager ではなく受信側ルータに送信されるように設定することもできます。 この設定は、[Local Static Routes]、[Outbound Proxy Server] または [Locally Resolved DNS SRV] を使用して行うことができます。 Unified CVP の [Dialed Number Pattern Configuration] の [Enable Send Calls to Originator] ボックスをオンにして、インビテーションの送信を設定することはできません。その設定は、エージェントへの配信中ではなく、SendToVRU 動作時にのみ表示されます。 Unified CVP を設定すると、特にエージェントの内線へのルートの場合に、受信側ルータ内でダイヤル ピアを定義できます。Unified Communications Manager が宛先ターゲットになっています。

この場合の配置を次の図に示します。

メディア分岐を追加するには、次の図に示すように、メディア分岐をする 2 台目のルータ(Unified Border Element)を挿入します。

複数の受信側サイトがある場合は状況はさらに複雑になりますが、その場合でも Unified CVP の「Send Call to Originator」と「Significant Digits」の機能を組み合わせて使用し、WAN でのヘアピン コールを避けることで目標は達成可能です。 「Send Call to Originator」によって、Unified CVP は、任意のコールの受信側ルータが VXML アクティビティの実行される場所に存在することを保証できます。 「Significant Digits」を使用すれば、コールがエージェントに送信されるときに、コールの受信側ルータと同じサイトにある Unified Border Element をパス スルーすることを保証できます。 「Significant Digits」は、VXML アクティビティをその受信側ルータ自体に限定されず、受信側ルータのサイトにある任意の VXML 対応ルータに割り当てるするためにも使用できます。 次の図に、複数の受信側サイトでの最終的な配置を示します。 1 つのサイト内に、2 つのイングレス ゲートウェイと 1 つのメディア分岐用 Unified Border Element があります。 2 つのイングレス ゲートウェイは同一で、どちらも TDM/IP 変換と VXML の機能を実行しています。 他のサイトには、同数のルータがありますが、1 台は TDM-to-IP 変換、2 台目のルータは VXML アクティビティ専用にそれぞれ使用されています。.

設定に関係なく、帯域幅の使用量は常に考慮する必要があります。 図に示す設計では、メディアが WAN 経由で 2 回流れます(1 回目はエージェントの電話機での送受信、2 回目はメディア分岐する Unified Border Element から MediaSense クラスタに対して)。 MediaSens を Unified Border Element と同じ場所に配置する場合は問題はありません。 ただし、共有型データセンター内に一元化した MediaSense を配置しなければならない場合は、この追加の帯域幅使用量を考慮しなければなりません。 余分な WAN トラフィックの発生を避けるため、メディア分岐する Unified Border Element を MediaSense があるデータセンターへ移動することもできます。 この移動は、Unified Communications Manager クラスタとエージェントの電話機がすべて同じ WAN の場所にある場合にのみ有効です。 そうなっていない場合、選択されたエージェントの電話機と同じ場所にある Unified Border Element をコールが通過するように強制できないため、WAN のトラフィックを減らすどころか増やすことになります。 メディア ストリームは多くの場合、最初にエージェントのない場所に配置された Unified Border Element をヘアピン通過します。 この手法では、Unified Communications Manager のコール アドミッション制御(CAC)アルゴリズムを混乱させる可能性があります。

REFER 転送

デフォルトでは、Unified Border Element は、REFER 転送を Unified CVP から次のアップストリームのユーザ エージェントに渡します。 その転送が成功すると、Unified Border Element はもうシグナリングまたはメディア パスに存在しないため、それ以上コールを録音できません。 導入環境によっては、REFER 転送を渡すのではなく「コンシューム」するように Unified Border Element を設定できます。 コンシュームにより、Unified Border Element 自体が転送を実行し、Unified CVP をループ外に出して、Unified Border Element 自体はシグナリングおよびメディア パス内に残ってコールを録音します。 これは、Unified Border Element の設定に「voice service voip; no supplementary-service sip refer」を追加することによって実現できます。


(注)  


内部のダイヤル ピアがメディア分岐を実行すると、Cisco IOS に強制的に新しいダイヤル ピアの照合処理をさせるため REFER は常に録音を終了させます。


導入モデルの組み合わせ

このマニュアルで説明する導入モデルは互いに排他的ではありません。 標準インストールには、

  • 着信コール

  • 発信コール

  • Unified CVP を使用するコール

  • コンタクト センターに属していないコール

  • TDM トランクを使用するコール

  • SIP トランクを使用するコール

  • Unified Border Element でメディアを分岐するコール

  • 電話機でメディアを分岐するコールが含まれることがあります。

概して言えば、ここでのモデルは、他のコールが他の導入モデルに含まれるパスを通るのに対して、ある特定のコールが通る可能性があるパスを記述したものと見なすべきです。 その意味では、どの単一のコールも単一のモデル内にとどまることが一般的ですが、これらのモデルすべてを無差別に組み合わせることが可能です。

TDM to IP 変換とダイヤル ピア メディア分岐の組み合わせ

定義上、SIP to SIP コールだけが Unified Border Element 内でメディア分岐できます。 ただし、Unified Border Element ソフトウェアを実行している ISRG2 に T1/E1 カードを挿入できない理由はありません。 TDM ポートに到達したコールは、そのデバイスを 2 回(1 回は TDM to SIP コールとして、もう 1 回は SIP to SIP コールとして)通過するようにルーティングすることで録音ができます。 TDM ポートに到達したコールの録音は、デバイスの TDM to SIP コールのアウトバウンド ダイヤル ピアの設定で、セッション ターゲット パラメータに自身を指定することで実現できます。 コールの番号操作、またはコールを適格化するその他の方法を使用することで、コールが 2 回目に到達したときには異なる(VOIP)ダイヤル ピアに一致して、SIP to SIP コールのように見えます。 この 2 回目のルータ通過の際に、メディア分岐をイネーブルにできます。

このフローでは、コールがルータで 2 回処理されるため、容量の観点からは 2 コールとしてカウントします。 逆の言い方をすれば、このフローに従うコールはルータの所定の容量を確実に半減させるので、同数のコールに対して倍のルータ容量が必要になります。 コールにルータの全容量を使用する場合は、2 台のルータが必要になります。 ルータ数を 2 倍にすると、すべてのルータに両方のジョブ(TDM と分岐)を割り当てるか、または半数のルータに各ジョブを割り当てることが可能です。 適切に設計すれば、どちらのアプローチも使用できます。

ISR の設定に関する詳細については、 https:/​/​supportforums.cisco.com/​docs/​DOC-23115. [英語] を参照してください。

VXML と Unified Border Element メディア分岐との組み合わせ

MediaSense のない Unified CVP 配置では、Unified Border Element と同じルータ上で VXML の音声ブラウザ機能を実行できますが、シスコは同じルータ上でのメディア分岐と VXML アクティビティの共有をサポートしません。 VXML は、特に自動音声認識を使用した場合、ルータのリソースを多く使用します。 VXML については、キューまたは IVR スクリプトに入ると想定される同時発生コール数を考慮するだけですが、メディア分岐のために処理する同時発生コールの総数を考慮する必要があるため、サイジングの課題は残ります。

マルチサイト イングレス導入(特にブランチ オフィスでの導入)では、コールが不注意に WAN リンクを通過することを防止するために、Unified CVP のコール ルーティング設定で Significant Digits 機能と Send To Originator 機能の組み合わせを使用する必要があります。

これらの方法に関する詳細については、Unified CVP のマニュアルを参照してください。

他のソリューション コンポーネントの構成要件

ここでは、特定の展開を設計する方法またはコンポーネントの発注方法に影響する可能性がある設定要件を示します。 詳細な設定手順については、『Cisco MediaSense User Guide』を参照してください。

Unified Communications Manager

Unified Communications Manager は、MediaSense 録音サーバに録音を指示するように適切に設定される必要があります。 これを行うには、録音プロファイルおよびさまざまな SIP パラメータを設定する必要があります。 電話ゾーンは、iLBC、G.722.1 または iSAC コーデックの使用を回避するように設定する必要があり、Unified Communications Manager AXL サービスはサーバの少なくとも 1 台で有効になっている必要があります(MediaSense はユーザの認証に AXL を使用するため)。


(注)  


UDP 経由の SIP は、MediaSense ではサポートされていません。


Cisco Unified Border Element

メディア分岐を伴う Unified Border Element ソフトウェアは、Cisco ISRG2 ルータでのみ動作します。 異なるモデルには異なる拡張性の仕様がありますが、これらのルータを使用可能なメモリの最大容量で常にプロビジョニングすることが推奨されます。 3945E には最低 2 GB のメモリが必要です。4 GB が推奨されます。 メディア分岐は ASR ルータではサポートされていません。

すべての MediaSense Unified Border Element の展開では、コールを処理していない場合でも、認証のために Unified Communications Manager への AXL 接続が必要です。 接続は、すでにインストールされていて他の目的に使用中の Unified Communications Manager か、または MediaSense で使用するために特別にインストールされている Unified Communications Manager に行うことができます。 管理者は、1 つ以上の Unified Communications Manager のエンド ユーザを設定し、MediaSense API ユーザとして MediaSense にインポートします。

ストリーミング メディア プレーヤー

市販のメディア プレーヤーの例は次のとおりです。

  • VLC version 2.1.3 1
  • QuickTime
  • RealPlayer

これらのメディア プレーヤーはそれぞれ特有のメリットとデメリットがあります。 たとえば VLC は、一度にメディア トラックを 1 つしか再生できません。 QuickTime は、必要な認証済み RTSP のリダイレクトを処理できない場合があります。 また、これらのメディア プレーヤーはいずれも、無音状態を処理するようには設計されていないことに注意してください。 無音セグメントを含む録音を再生すると、予期しない挙動が発生することがあります。

これらのプレーヤーはいずれも AAC-LD、g.729 または g.722 のコーデックをサポートしていません。 これらのコーデックを使用して録音されたメディアを再生するには、カスタム メディア プレーヤーが必要です。 検索と再生アプリケーションからアクセス可能な、組み込み MediaSense メディア プレーヤーは、AAC-LD を除くこれらのオーディオ コーデックすべてを再生することができます。

シスコは、これらのメディア プレーヤーを製造しておらず、これらのメディア プレーヤーまたは他のサードパーティ製メディア プレーヤーの使用を推奨またはサポートしていません。 シスコがサポートする唯一のメディア プレーヤーは、内蔵式の MediaSense により提供されるものです。

SIP プロキシ サーバ

SIP プロキシ サーバは、MediaSense と Unified Communications Manager または Unified Border Element との間では現在サポートされていません。

Cisco Unified Communications Manager Session Management Edition

Cisco Unified Communications Manager Session Management Edition(Unified CM SME)の導入では、MediaSense は Unified Communications Manager リーフ クラスタ レベルでのみ配置できます。 これは、集中型 Unified CM SME レベルでは現在サポートされていません。 これは、複数のリーフ クラスタが同じ MediaSense クラスタを共有する可能性があっても、各リーフ クラスタに独自の MediaSense クラスタが必要であることを意味します。

コンタクト センターの環境

  • MediaSense は、Unified Contact Center Enterprise(Unified CCE)または Unified Contact Center Express(Unified CCX)と明示的に相互に作用しておらず、それらをサポートしていません。 これらの製品のエージェントおよびスーパーバイザ デスクトップのクライアントで使用可能な録音機能では、録音の開始とキャプチャに異なる方式が使用され、独自に確立された録音ソリューションが必要です。
  • ウィスパー アナウンスメント機能では、MediaSense はエージェントとスーパーバイザ間のウィスパー コールを録音しません。これは、エージェントの電話機のビルトインブリッジは通常、レコーダに配信する分岐されたメディア ストリームにスーパーバイザとエージェント間のウィスパーを含めないためです。 スーパーバイザの電話機が分岐用に設定されている場合、ウィスパー アナウンスメントはスーパーバイザの電話録音に含まれます。
  • SPAN ポート出力をリッスンしてエージェントの電話機の MAC または IP アドレスでフィルタリングすることでエージェントの会話をモニタする機器は、電話機が録音のためにメディアを分岐しているときは正しく動作しない場合があります。 これは、すべての RTP パケットが電話機から 2 回 放出され、リッスンするデバイスが録音サーバ行きのパケットをキャプチャから除外しない場合があるためです。 これにより、アプリケーションが同時に録音もされている会話のモニタリングを要求する場合は、リスナーにはエコーが聞こえ、サイレント モニタリングを考慮する必要があります。
1 一部の VLC バージョンには既知の不具合があるため、使用するバージョンを選択する前に VideoLan Web サイトのドキュメントを確認してください。