Cisco MediaSense ユーザ ガイド リリース 10.5(1)
MediaSense の概要
MediaSense の概要

目次

MediaSense の概要

MediaSense について

MediaSense は、Cisco Unified Communications のメディア キャプチャ プラットフォームです。 シスコおよびシスコ以外のコンタクト センターのコールを録音するために使用できます。ただし、シスコ以外のコンタクト センターは、入力点として Cisco Unified Border Element を使用する必要があります。

MediaSense は、すべてのセッションの録音と保管が要求される規制環境に準拠する録音会社で使用できます。 これらの録音は、コンプライアンス担当オーディタまたはコンタクト センターのスーパーバイザがお客様の問題の解決またはトレーニングのために後で使用することができます。 録音は、音声分析サーバまたはトランスクリプション エンジンでも使用できます。

MediaSense は、Unified Communications Manager を使用して、ユーザ認証サービスを提供します。 また、サードパーティのお客様がカスタム アプリケーションを作成できるように、Web 2.0 アプリケーション プログラミング インターフェイス(API)を使用して、お客様に機能を公開します。 この製品は、Microsoft Windows 7 および Apple Mac OS でサポートされます。

ネットワーク サービス

MediaSense では次のネットワーク サービスを使用できます。

  • Cisco MediaSense Administration:グラフィカル ユーザ インターフェイスを使用して MediaSense を設定できます。
  • Cisco MediaSense Serviceability Administration:グラフィカル ユーザ インターフェイスを使用して MediaSense Serviceability アプリケーションを設定できます。
  • システム サービス:MediaSense クラスタ内のサービスの動作を制御できます。 このサービスは、セカンダリ サーバと拡張サーバのクラスタリングとセットアップ機能を管理します。
  • Perfmon エージェント:MediaSense Serviceability Administration インターフェイス内のパフォーマンス モニタリング インフラストラクチャを制御できます。 アプリケーションおよびその他のシステム オブジェクトを管理およびモニタできる Java Management Extensions(JMX)テクノロジーは、Managed Beans(MBeans)と呼ばれるオブジェクトによって表されます。 Perfmon エージェントは JMX MBeans からカウンタ値を取得し、それらを Unified Communications Manager データベースに書き込みます。
  • 診断サービス:MediaSense をトラブルシューティングし、デバッグできます。 このサービスは、すべての MediaSense サーバで使用できます。

MediaSense および Unified OS ユーザ インタフェースでは、各 MediaSense サービス名の前に製品名が付きます。 このマニュアルでの重複を避けるため、前に製品名を付けずにサービス名が参照される場合があります。

ネットワーク サービスは、クラスタ内の各サーバのインストール後に自動的に起動します。 シスコのサポート担当者が推奨した場合、ネットワーク サービスを停止することができます。

機能サービス

MediaSense には、次の機能サービスが含まれています。

  • コンフィギュレーション サービス:MediaSense コンフィギュレーション データベースに加えられたすべての変更を保存し、更新します。 各サーバ クラスタには、コンフィギュレーション サービスの 2 つのインスタンスのみがあります。1 つのインスタンスはプライマリ サーバにあり、他のインスタンスはセカンダリ サーバにあります。 クラスタ内に 2 台以上のサーバがある場合、拡張サーバはサービス コンフィギュレーションを設定できません。

  • API サービス:API 要求を処理し、ユーザ インターフェイスとサーバ間の通信をイネーブルにします。 データベース サービスをイネーブルにした後で、API サービスをイネーブルにできます。 各複数サーバ クラスタには、API サービスの 2 つのインスタンスのみがあります。1 つのインスタンスはプライマリ サーバにあり、他のインスタンスはセカンダリ サーバにあります。 クラスタ内に 2 台以上のサーバがある場合、拡張サーバには API サービスは含まれません。

  • データベース サービス:メタ データベースとコンフィギュレーション データベースを含み、制御します。 各複数サーバ クラスタには、データベース サービスの 2 つのインスタンスのみがあります。1 つのインスタンスはプライマリ サーバにあり、他のインスタンスはセカンダリ サーバにあります。 各サーバは、ローカル データベースにのみデータを書き込みます。 プライマリ サーバとセカンダリ サーバは、データを同期するために対話します。

  • ストレージ管理エージェント(SM エージェント):クラスタ内の各サーバのストレージ全体をモニタし、ディスク使用率に基づくしきい値イベントを生成します。 このサービスは、すべてのサーバで使用可能であり、メディア サービスおよびコール制御サービスの前にアクティブにする必要があります。

  • メディア サービス:メディアを受信、保存、および再生します。 メディア サービスは、コール制御サービスの前にイネーブルにする必要があります。 このサービスは、クラスタ内のすべてのサーバで使用できます。

  • コール制御サービス:コールの受信と記録を調整します。 コール制御サービスは、メディア サービスがイネーブルになっている場合にのみイネーブルにできます。 このサービスは、クラスタ内のすべてのサーバで使用できます。 コール制御サービスは、Unified Communications Manager ユーザ インタフェースおよび Unified Communications Manager マニュアルでは SIP トランクと呼ばれています。

すべての機能サービスがクラスタ内のプライマリおよびセカンダリ ノード(サーバ)にインストールされます。 拡張ノードには、メディア サービス、コール制御サービス、および SM エージェントのみがあります。

検索と再生

MediaSense をインストールおよび設定したら、検索と再生アプリケーションを使用して、特定のメディア ファイルを検索し、それらを再生し、またはデスクトップにダウンロードします。

検索と再生アプリケーションにアクセスするには、次のいずれかを実行します。
  • Mozilla Firefox または Windows Internet Explorer を使用して、https://<hostname>:8440/mediasense に移動します。

    または

  • http://<MediaSense hostname> のメイン MediaSense アクセス ウィンドウから [Cisco MediaSense Search and Play] リンクをクリックします。


(注)  


検索と再生を起動する前に、32 ビットの Windows マシンに JDK の 32 ビット バージョン、64 ビットの Windows マシンに JDK の 64 ビット バージョン、および Mac コンピュータに 64 ビット バージョンをインストールする必要があります。 また、JDK7 Update 25 以降がインストールされていることを確認します。


MediaSense メディア プレーヤーはダウンロード可能な Java アプリケーションとして実装されます。 Java の最近のセキュリティ強化により、Java アプリケーションが実行されるたびに、ユーザはポップアップ セキュリティ警告を受け入れる必要があります。つまり、録音が再生されるたびに、ユーザはセキュリティ警告を受け入れる必要があります。

アプリケーションは実行可能なブラウザの一部としては動作しないため、ブラウザのセキュリティ要件ではなく、ユーザのコンピュータにインストールされている Java 仮想マシン(JVM)のセキュリティ要件に対応する必要があります。 トラブルシューティングのヒントは、検索と再生が実行される各クライアント デスクトップをセットアップして、警告を回避するための手順を提供します(http:/​/​docwiki.cisco.com/​wiki/​Administration:_​Search_​and_​Play_​application_​users_​encounter_​security_​warning_​before_​each_​playback#Search_​and_​Play_​application_​users_​encounter_​security_​warning_​before_​each_​playback)。


(注)  


メディア プレーヤーは、Mozilla Firefox で起動するよりも Windows IE で起動する方が時間がかかります。 IE ユーザには、ダウンロードされた jnlp ファイルを開くためのオプションが表示されることがあります。

ログイン クレデンシャルの入力が要求された場合は、管理アプリケーションの [MediaSense API User Configuration] ページで定義された API ユーザのクレデンシャルを使用します。


(注)  


セッションの状態が 30 分間アイドル状態になると、検索と再生アプリケーションからログアウトされます。

録音されたコールの検索、再生、またはダウンロード

[Search and Play] ウィンドウでは、録音したメディア ファイルを検索するいくつかの方法があります。

手順
    ステップ 1   まず検索と再生アプリケーションにアクセスすると、[Recent Calls] デフォルト検索の結果(直前 7 日以内のすべてのコール)ページが開きます。 これらのタブをいつでもクリックして、[Recent Calls] または [Active Calls] 検索を選択できます。
    ステップ 2   簡単な検索を実行するには、参加者 ID またはタグを検索ボックスに入力し、[Search] をクリックします。

    参加者 ID に、ID の完全な値を入力します。 複数の参加者を検索するには、スペースを使用して各エントリを区切ります。デリミタは OR 演算子と見なされます。

    タグには、完全な値は必要ないため、1 つまたは 2 つの文字を入力できます。 詳細については、詳細検索(ステップ 3)の「Tag」を参照してください。

    各エントリを区切るにはスペースを使用します。デリミタは OR 演算子と見なされます。 デフォルトでは、簡単な検索は 7 日内のコールを返します。

    ステップ 3   詳細検索の場合、[Search Recordings] ドロップ ダウン メニューから任意の検索パラメータに値を入力します。

    検索プロパティは次のとおりです。

    • Session ID:1 つ以上のトラックが関連付けられた録音セッションの ID。 テキスト ボックスにセッション ID を入力します。 一度に 1 つの Session ID のみを検索できます。

    • Participant(s):録音セッション参加者の ID(内線番号)。 テキスト ボックスに参加者 ID を入力します。 カンマを使用して ID を区切ることで、複数の参加者を検索できます。 複数の参加者が定義されている場合、検索は参加者全員が含まれるコールのみ返します(デリミタは AND 演算子と見なされます)。

    • Tag:任意のテキストを入力します。 タグの検索は CONTAINS と見なされます。このため、1 つの文字を入力すると、その文字を含むすべてのタグの結果を出力します。 検索ボックスで使用するスペースは、デリミタとしてではなく、検索対象の値の一部と見なされます。 したがって、スペースで区切られた 2 つの語を検索すると、スペースで区切られた両方の語を含むタグを持つコールのみが返されます。

    • XRefCI:録音セッション ID。 テキスト ボックスに録音セッション ID を入力します。 一度に 1 つの XRefCI のみ検索できます。

    • CCID:録音セッション内の個々のトラックの ID。 テキスト ボックスにトラック ID を入力します。 一度に 1 つの CCID のみ検索できます。

    • Range:録音セッションを開始した日付。 特定の時間枠または日付の範囲の間で検索するように選択します。 時間枠を選択しない場合、システムはデフォルトで直前 7 日以内に設定します。

      時間範囲を選択する場合は、短い期間を選択します。 大量の録音が出力される検索では、処理に並外れた時間がかかる可能性があり、システム パフォーマンスに影響を与えます。

    • Duration:時間単位を選択し、スライド バーを使用して、秒、分、または時間単位で、録音されたセッションの間隔を選択します。

    • Show:このチェックボックスを使用して、完了したコール、アクティブ コール、または録音エラーを含むコールを検索するかどうかを指定します。

    ステップ 4   [Search] をクリックします。
    • [Sort by] ドロップダウン メニューをクリックして、経過時間または持続期間によってファイルをソートします。

    • [download] アイコンをクリックして、録音をダウンロードします。

    • [Expand Call] アイコンをクリックして、[Associated Session] ボックスに表示される関連性の強い録音セッションを確認します。 関連性の強いセッションには、共通する xRefci 値が少なくとも 1 つあります。 表示されたリストの各セッションは、個別に再生またはダウンロードできます。

      (注)      MediaSense 10.5 は、ビルトイン ブリッジ録音のコール関連付けをサポートしています。
    • [play] アイコンをクリックして、録音を再生します。

    • [Previous] ボタンと [Next] ボタンを使用して、結果ページを介して各ページとステップに表示する検索結果の数を選択できます。

    (注)     

    メディア プレーヤーを終了すると、「MediaSense player quit unexpectedly while using the lib... plug-in」という警告が表示される場合があります。 この警告はエラーとして報告される場合がありますが、エラーではないので無視することができます。


    メディア プレーヤー

    MediaSense の検索と再生アプリケーションには、録音を再生するためのメディア プレーヤーが組み込まれています。 メディア プレーヤーを実行するには、最新の Java バージョンが必要です(Java のバージョンについては、『Cisco MediaSense Design Guide』の「Web ブラウザ」の項 http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-implementation-design-guides-list.html を参照してください)。 トラック スライダは、オーディオ録音の進行状況を表示します。 スライダを右にドラッグすると再生中の録音を早送りでき、左にドラッグすると巻き戻しできます。

    録音の終了後に再生する場合は、スライダを開始点にドラッグします。ただし、これは 30 秒以内に実行する必要があります。 30 秒後には再生セッションが終了し、プレーヤーが閉じられます。


    (注)  


    ビデオ録音では、トラック スライダはサポートされません。 ただし、ビデオ録画の進行状況を示すタイマーが表示されます。


    [Volume] バーのスライダをドラッグして音量を上げ下げできます。

    メディア プレーヤーの制限:

    • スライダをドラッグして早送りまたは巻き戻ししている間、時間は表示されません。
    • [Pause] ボタンは、録音の終了後に [Play] ボタンへ自動的に変換されません。
    • スライダが再生ストリームの終わりに達した後に [Play] および [Pause] ボタンを 2 回以上クリックすると、メディア プレーヤー セッションが中断されます。
    • 再生セッション中、巻き戻し/早送りのために任意のポイントをクリックすると、トラック スライダはクリックされたポイント自体ではなくその周辺に移動します。

    アーキテクチャ

    MediaSense は Unified Communications ソリューションの一部であり、Cisco Unified Operating System リリース 9.0 で動作します。

    MediaSense アーキテクチャには、次のコンポーネントが含まれています。

    • アプリケーション層:

      • 検索と再生アプリケーションを使用して、録音を再生できます。

      • API は、をサポートするサードパーティ製アプリケーションに対するリアルタイムの録音制御(保留、一時停止と再開など)。

      • プリケーションおよびメディア API は、さまざまな業界パートナーの要件を組み込み、サードパーティ製アプリケーションで使用するために公開されています。

      • API サービスは、録音および関連セッションの履歴とメタデータを検索および取得するためにアプリケーションをイネーブルにする Web サービス インターフェイスを備えています。 このメタデータ情報は、Meta データベースに保存されます。

    • メディア処理層:

      • メディア サービスは、アーカイブと再生のためにローカル ディスクに保存されたメディア ストリームを終端します。

      • 拡張されたすべてのサーバ上でメディア サービスを実行することにより、ロード バランシングが可能になります。

    • ネットワーク層:

      • ゲートウェイおよびセッション ボーダー コントローラ(SBC)のメディア分岐とエンドポイントでのメディア分岐。

      • オーディオ レコーディング用の Cisco Unified Communications Manager(Unified Communications Manager)との統合。

      • オーディオおよびビデオ レコーディング用の Cisco Unified Border Element(Unified Border Element)との統合。

    Cisco Unified Communications Manager のネットワークベースの録音

    Unified Communications Manager のネットワークベースの録音(NBR)を使用すると、ゲートウェイを使用して通話を録音できます。 NBR によって、Unified Communications Manager はデバイス、場所、地域に関係なく、通話録音をルート指定できます。

    NBR では、通話録音のメディア ソースは、IP 電話または SIP トランクを介して Unified Communications Manager に接続されたゲートウェイから提供されます。 Unified Communications Manager は、コール フローおよびコール参加者に基づいて、動的に適切なメディア ソースを選択します。

    個別の録音設定が必要ないため、Integrated Services Router(ISR)が利用できない場合、NBR はビルトインブリッジ(BiB)に自動フォールバックを提供します。 これは、Unified Border Element でコンサルト コールを録音できず、BiB を別途有効にする必要があるため、お客様がエージェント対エージェントのコンサルト コールを録音ポリシーに含める必要がある場合に便利です。

    Unified Communications Manager NBR の詳細については、『Features and Services Guide for Cisco Unified Communications Manager』(http:/​/​www.cisco.com/​c/​en/​us/​support/​unified-communications/​unified-communications-manager-callmanager/​products-maintenance-guides-list.html )を参照してください。

    コールの相関関係

    Unified Communications Manager JTAPI から入手可能な xRefci を使用して、NBR および BiB コールの両方を関連付けることができます。CISCO-GUID は必須ではないため、CTI サーバや CTIOS 接続も必要ありません。 単一の相関 ID が存在するため、コンポーネント間の相関関係はさらに強力になり、コール フローに関係なく同じ方法で実行できます。 NBR を使用すると、直接およびダイヤラにより開始された発信コールを他のソリューションのコンポーネントのアピアランスに関連付けることができます。 NBR を使用すると、ルータの容量を分割せずに TDM ゲートウェイの録音が自動的に使用されます。


    (注)  


    MediaSense 10.5(1) は TDM ゲートウェイの録音をサポートしていません。

    Unified Communications Manager の展開

    Unified Communications Manager は、MediaSense 録音サーバに録音を指示するように適切に設定される必要があります。 設定には、録音プロファイルとさまざまな SIP パラメータの設定が含まれます。 MediaSense はユーザの認証に Administrative XML Layer(AXL)を使用するため、少なくとも 1 台のサーバ上で Unified Communications Manager AXL サービスをイネーブルにする必要があります。

    MediaSense の基本的な Unified Communications Manager 展開では、電話機の 1 台を録音用に設定する必要があります。 両方の電話機が録音用に設定されている場合、2 つの独立した録音セッションがキャプチャされます。 電話機によって分岐されたメディアが録音デバイスに送信され、そこで分岐されたストリームがキャプチャされます。 詳細については、『Cisco MediaSense Design Guide』を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​implementation_​design_​guides_​list.html [英語] から入手できます。

    MediaSense がサポートするすべての Cisco IP Phone には、着信および発信メディア ストリームを分岐できる組み込みブリッジ(BIB)が装備されています。 MediaSense は、この機能を利用して分岐された着信および発信メディアを録音します。 メディア分岐の詳細については、Unified Communications Manager のマニュアルを参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​prod_​maintenance_​guides_​list.html [英語] から入手できます。

    Cisco Unified Border Element の展開

    Cisco Unified Border Element(Unified Border Element)は、ある IP ネットワークから別の IP ネットワークへの SIP、H.323、VoIP、およびビデオ会議コールをイネーブルにすることにより、独立した VoIP ネットワーク間の接続を容易に行えるようにするシスコ セッション ボーダー コントローラ(SBC)ゲートウェイです。

    MediaSense は、Unified Border Element と連動してエンドポイントのタイプに関係なく録音をイネーブルにします。 この機能により、MediaSense は、Unified Border Element を使用して着信メディアと発信メディアを録音できます。

    Unified Border Element の詳細については、Unified Border Element のマニュアルを参照してください。

    次の図は、Unified Border Element を使用した MediaSense の展開を示しています。 Unified Border Element の展開においても、MediaSense は Unified Communications Manager によって認証サービスを提供します。

    図 1. Unified Border Element による MediaSense の展開



    前の図では、Real-Time Protocol(RTP)は、エンドポイントと Unified Border Element 間で音声データを伝送します。 Session Initiation Protocol(SIP)は、エンドポイントと Unified Border Element 間でコール シグナリング情報を伝送します。 2 つの RTP 単方向ストリームは、Unified Border Element から MediaSense へ分岐される 2 つのオーディオ ストリームを表します。 Unified Border Element だけが MediaSense にデータを送信するため、Unified Border Element から MediaSense へのストリームは単方向です。MediaSense は Unified Border Element にメディアを送信しません。 Unified Border Element には 3 種類のダイヤルピア(着信、発信、分岐)があります。 (詳細については、ダイヤルピア レベルの設定を参照してください)。

    通常、Unified Border Element は SIP 間のコールのみを分岐できます。 ただし、必要なライセンスと適切な Cisco IOS バージョンがある場合、コール録音に TDM-to-IP ゲートウェイとメディア分岐デバイスの両方と同じ Cisco ルータを使用できるので、着信 TDM またはアナログ コールを録音することもできます。 (詳細については、http:/​/​www.cisco.com/​go/​cube から入手できる Unified Border Element のマニュアルを参照してください)。

    この機能を使用するには、デバイスのゲートウェイと border-element 機能の両方をイネーブルにする必要があります。 ゲートウェイが TDM またはアナログ コールを受信し、別の着信番号を使用して SIP コールとしてそれ自体にコールバックするように設定できます。 このループを設定すると、ルータは実際には各コールを 2 回処理することになります (これにより、ルータの容量が半分に削減され、Unified Border Element が処理できるコールの数が半減します)。詳細については、『Cisco MediaSense Developer Guide』の「Media forking on a TDM gateway」セクション(http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​programming_​reference_​guides_​list.html [英語] から入手可能)、および http:/​/​docwiki.cisco.com/​wiki/​FAQs_​for_​Cisco_​MediaSense#How_​to_​Configure_​a_​TDM_​Gateway_​for_​Media_​Forking に掲載された MediaSense FAQ の記事を参照してください。

    Cisco Unified Communications Manager および Cisco Unified Border Element シナリオの違い

    Unified Communications Manager は MediaSense で録音プロファイルおよびコール制御サービス接続(SIP トランク)を設定するために使用されます。 同様に、Unified Border Element では、ダイヤルピアとメディア クラス設定により MediaSense との通信が決まります。


    (注)  


    Unified Border Element のメディア分岐および UC エンドポイントのメディア分岐の詳細については、『Cisco MediaSense Design Guide』を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​implementation_​design_​guides_​list.html [英語] から入手できます。

    MediaSense が Unified Communications Manager で展開されているか、Unified Border Element で展開されているかに関係なく、イベント、応答コード、パラメータ定義は両方のシナリオで同じです。 すべてのイベント、応答コード、およびパラメータは、『Cisco MediaSense Developer Guide』に記載されています。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​programming_​reference_​guides_​list.html から入手できます。



    表 1 Unified Communications Manager と Unified Border Element シナリオの違い

    MediaSense の機能

    Unified Communications Manager を使用する場合(ビルトイン ブリッジまたはネットワークベースの録音)

    Unified Border Element のダイヤル ピアを使用する場合

    録音の開始

    クライアントが startRecording API を呼び出したときに開始される direct outbound 録音シナリオは、Unified Communications Manager 展開によってサポートされます。

    クライアントが startRecording API を呼び出したときに開始される direct outbound 録音シナリオは、Unified Border Element 展開によってサポートされません。

    記録

    2 つのメディア ストリーム(Track 0 およびトラック 1 と呼ばれる)が MediaSense に送信されます。 録音には、少なくとも 1 台の電話機がメディア分岐機能を備えた 2 台の電話機が必要です(2 台が SIP 招待)。

    録音は SIP デバイス(Unified Border Element の SIP ユーザ エージェントと呼ばれる)を使用します。 コールが Unified Border Element によって SIP コールとして処理されている限り、あらゆるタイプのエンドポイントが可能です。 2 つのメディア ストリームが MediaSense に送信されます。 これら 2 つのストリームは、トラック 0 とトラック 1 を区別することなく、最終的に 2 つのトラックに送信されます。

    発信側と着信側のトラックの識別

    MediaSense の Web サイトの FAQ(How do you determine which track has the calling and which has the called party?)を参照してください。

    小さい数値の xRefCi パラメータは、通常発信側のトラックを指します。

    トラック 0 には、メディア録音プロファイルが設定されダイヤルピアに対応するメディア ストリームが含まれます。

    録音セッション

    録音セッションおよび保留/再開、一時停止/再開、転送/会議コマンドに関する詳細については、『Cisco MediaSense Developer Guide』を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​programming_​reference_​guides_​list.html から入手できます。

    コールが保留になっている場合、論理録音セッションは終了します。 参加者がコールを再開すると、新しい録音セッションが作成されます。

    SIP セッションは、対応するメディア追跡イベントによって複数回更新される場合があります。 コールが複数回保留および再開された場合でも、録音セッションは 1 回だけ行われます。

    キャプチャされた録音データの相違

    Cisco MediaSense Design Guide』を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​implementation_​design_​guides_​list.html [英語] から入手できます。

    元の発信番号、着信番号、コールのタイプなどの詳細を確認するには、『Unified Communications Manager Call Detail Records Administration Guide』の「Call Detail Records」の項を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​prod_​maintenance_​guides_​list.html [英語] から入手できます。

    Unified Border Element は、AAA - RADIUS と呼ばれる外部データベースにコールを保存できます。 コールは、MediaSense セッション データの CCID に対応する Cisco GUID によって検索できます。

    コール中のコーデック変更

    コール中のコーデック変更を生成しません。

    新しいセッションを開始します。

    エンドポイントの MAC アドレス

    キャプチャされます。

    キャプチャされません。

    録音メディア ソース

    エンドポイントには、分岐されたメディアが含まれています。

    Unified Border Element には、分岐されたメディアが含まれています。

    サポートされる展開

    MediaSense は次の展開をサポートしています。

    • 1 サーバ展開:1 台のアクティブ サーバ。

    • 2 サーバ展開:ハイ アベイラビリティを実現する 2 台のアクティブ サーバ。

    • 3 サーバ展開:追加の録音容量を提供するため、ハイ アベイラビリティを実現し 1 台の拡張サーバを提供する 2 台のアクティブ サーバ。

    • 4 サーバ展開:追加の録音容量を提供するため、ハイ アベイラビリティを実現し 2 台の拡張サーバを提供する 2 台のアクティブ サーバ。

    • 5 サーバ展開:追加の録音容量を提供するため、ハイ アベイラビリティを実現し 3 台の拡張サーバを提供する 2 台のアクティブ サーバ。


    (注)  


    UCS-E のインストールと 7 つ以下の vCPU を持つすべてのインストールは、1 サーバおよび 2 サーバの展開に限定されます。


    すべての展開で、プライマリ サーバのインストールと設定は、同じ展開内の他のサーバのインストールと設定と異なります。 MediaSense 展開でサーバを設定する場合は、プラットフォーム管理者が MediaSense アプリケーション管理者のユーザ名とパスワードを設定することに注意してください(プラットフォームおよびセキュリティのパスワードに加えて)。 詳細については、MediaSense と Unified OS のインストールを参照してください。


    (注)  


    アプリケーション管理者のユーザ名とパスワードは MediaSense 展開内のすべてのサーバで同じにする必要があります。 次の CLI コマンドを使用してアプリケーション管理者のユーザ名とパスワードをリセットできます。
    • utils reset_application_ui_administrator_name
    • utils reset_application_ui_administrator_password.

    MediaSense クラスタの展開

    MediaSense 展開では、サーバごとに一連のサービスが搭載されたサーバのセットがクラスタに含まれています。 クラスタ アーキテクチャでは、ハイ アベイラビリティ(録音可能、ただし再生不可)とフェイルオーバー(プライマリ サーバに障害が発生した場合、セカンダリ サーバに自動的にフェイルオーバーされる)が提供されます。

    MediaSense はローカル エリア ネットワーク(LAN)でのみ動作します。 ワイドエリア ネットワーク(WAN)はサポートされません。 MediaSense サーバと Unified Communications Manager サーバは、すべて同じ LAN に設置する必要があります。 LAN 内では、任意の 2 台のサーバ間の最大ラウンドトリップ遅延は 2 ミリ秒未満である必要があります。

    MediaSense 展開のプライマリ サーバとセカンダリ サーバは、いずれかのサーバで管理上の変更が行われると同期されます。 データベース レプリケーションでは、プライマリ サーバからセカンダリ サーバにデータが自動的にコピーされ、その逆も同様です。

    次のクラスタ展開のルールが、インストールおよび設定手順によって適用されます。

    • 同じクラスタ内のすべてのサーバは、同じバージョンの MediaSense を実行する必要があります。

    • MediaSense 展開は、1 ~5 台の MediaSense サーバから構成できます。 クラスタ内の各サーバは、常にコール制御サービス、メディア サービス、SM エージェントを備えている必要があります。

    • MediaSense は、次のどのサーバの組み合わせもサポートします。
      • 1 台のプライマリ サーバ
      • 1 台のプライマリ サーバと 1 台の拡張サーバ
      • 1 台のプライマリ サーバ、1 台のセカンダリ サーバ、および 1 ~ 3 台の拡張サーバ
    • UCS-E のインストールと 7 つ以下の vCPU を持つすべてのインストールは、1 サーバおよび 2 サーバの展開に限定されます。

    単一サーバ展開

    単一サーバ展開には、Unified Communications OS プラットフォーム上に 1 つの MediaSense サーバがあります。 すべてのネットワーク サービスがデフォルトでイネーブルになります。

    単一サーバ展開では、プライマリ サーバに次の機能サービスがあります。
    • API サービス

    • コンフィギュレーション サービス

    • コール制御サービス

    • メディア サービス

    • データベース サービス

    • SM エージェント

    図 2. Cisco MediaSense の単一サーバ展開



    単一サービス展開では、冗長性の問題への対応、ハイ アベイラビリティの提供、ストレージ容量の拡大、同時録音容量の増加のために、後でさらにサーバを追加することができます。 展開モデルの詳細については、次の URL にある『Cisco MediaSense Design Guide』を参照してください。

    http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-implementation-design-guides-list.html

    デュアルサーバ展開

    デュアルサーバ展開には、Unified Communications OS(Unified OS)プラットフォームに 2 つの MediaSense サーバがあります。 最初のサーバをプライマリ サーバと呼びます。 2 つ目のサーバをセカンダリ サーバと呼びます。 すべてのネットワーク サービスは、両方のサーバでイネーブルになります。

    プライマリ サーバとセカンダリ サーバの両方が次の機能サービスを備えています。
    • API サービス

    • コンフィギュレーション サービス

    • コール制御サービス

    • メディア サービス

    • データベース サービス

    • SM エージェント

    図 3. デュアルサーバ展開. デュアル サーバ展開では、ハイ アベイラビリティが提供されます。 録音の負荷は、すべてのサービスが両方のサーバで常にアクティブであるため、プライマリ サーバとセカンダリ サーバで自動的に均等化されます。




    (注)  


    MediaSense には、API サービスまたはコンフィギュレーション サービスでの自動ロード バランシング機能はありません。 これらのサービスの両方がプライマリ サーバとセカンダリ サーバでイネーブルになっている場合、これらのサービスの いずれかに ブラウザまたはサーバベースの API をポイントする必要があります。


    サポートされる同時録音、再生、モニタリング セッションの最大数については、『Cisco MediaSense Design Guidehttp:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-implementation-design-guides-list.html を参照してください。

    3 サーバ展開

    3 サーバ展開には、プライマリ サーバ、セカンダリ サーバ、および 1 台の拡張サーバが含まれます。 すべてのネットワーク サービスは、デフォルトでクラスタ内のすべてのサーバでイネーブルになります。

    プライマリ サーバとセカンダリ サーバは、次の機能サービスを備えています。
    • API サービス

    • コンフィギュレーション サービス

    • コール制御サービス

    • メディア サービス

    • データベース サービス

    • SM エージェント

    拡張サーバは、次の機能サービスを備えています。
    • コール制御サービス

    • メディア サービス

    • SM エージェント

    図 4. 3 サーバ展開. 3 サーバ モデルは、冗長性を提供し、ストレージ容量、同時録音および再生容量を増加します。 録音の負荷は、それぞれのサーバでサービスが常にアクティブであるため、サーバ間で自動的に均等化されます。




    (注)  


    MediaSense は、プライマリ サーバとセカンダリ サーバでの API サービスとコンフィギュレーション サービスの自動ロード バランシング機能を備えていません。 これらのサービスがイネーブルになっている場合、これらのサービスの 1 つにのみブラウザまたはサーバベースの API をポイントする必要があります。

    サポートされる同時録音セッション、再生セッション、モニタリング セッションの最大数に関する詳細については、『Cisco MediaSense Design Guide』http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-implementation-design-guides-list.htmlを参照してください。

    4 サーバおよび 5 サーバ展開

    4 サーバおよび 5 サーバ展開には、1 台のプライマリ サーバ、1 台のセカンダリ サーバ、および 2 ~ 3 台の拡張サーバが含まれます。 すべてのネットワーク サービスは、デフォルトでクラスタ内のすべてのサーバでイネーブルになります。

    プライマリ サーバとセカンダリ サーバは、次の機能サービスを備えています。
    • API サービス

    • コンフィギュレーション サービス

    • コール制御サービス

    • メディア サービス

    • データベース サービス

    • SM エージェント

    拡張サーバと呼ばれる残りのサーバには、次の機能サービスだけが用意されています。
    • コール制御サービス

    • メディア サービス

    • SM エージェント

    図 5. 5 サーバ展開. この展開モデルは、冗長性を提供し、ストレージ容量を拡大し、同時録音および再生セッション用に容量を増やすことができます。 録音の負荷は、それぞれのサーバでサービスが常にアクティブであるため、サーバ間で自動的に均等化されます。




    (注)  


    MediaSense は、プライマリ サーバとセカンダリ サーバでの API サービスとコンフィギュレーション サービスの自動ロード バランシング機能を備えていません。 これらのサービスがイネーブルになっている場合、これらのサービスの 1 つにのみブラウザまたはサーバベースの API をポイントする必要があります。


    サポートされる同時録音セッション、再生セッション、モニタリング セッションの最大数に関する詳細については、『Cisco MediaSense Design Guidehttp:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-implementation-design-guides-list.htmlを参照してください。

    MediaSense のハイ アベイラビリティ配置

    一部のある配置では、使用可能なすべてのメディアを記録する必要があります。 配置がハイ アベイラビリティをサポートしていない場合、コール制御サービスの障害によって録音が行われない場合があります。 Unified Communications Manager が MediaSense サーバの 1 台に接続できない場合、Unified Communications Manager または Unified Border Element が必要な接続を行えるように、代替サーバを使用可能にする必要があります。

    詳細については、『Cisco MediaSense Design Guide』を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​implementation_​design_​guides_​list.html [英語] から入手できます。

    データ レプリケーションの考慮事項

    MediaSense 配置のデータベースのハイ アベイラビリティ サポートは、メタ データベースとコンフィギュレーション データベースの両方に対して Informix Enterprise Replication(ER)を使用して提供されます。 MediaSense クラスタは、最大 5 台のサーバを持つことができますが、データ レプリケーションはプライマリ サーバとセカンダリ サーバの間でのみイネーブルになります。

    インストール時に、インストールするサーバがセカンダリ サーバとして識別される場合、次の考慮事項が適用されます。

    • このサーバは、プライマリ サーバのデータ サイズの制約なしにプライマリ サーバから自動的にオンテープ バックアップが適用されます。
    • データ レプリケーションはプライマリ サーバとセカンダリ サーバの間で行われます。 プライマリ サーバに書き込まれるデータはセカンダリ サーバに複製され、その逆も同様です。

    プライマリおよびセカンダリ MediaSense サーバ間のレプリケーション動作は、レプリケーションを行う時点により異なります。

    • アクティベーション時:サービス アクティベーション プロセス時、Informix ER はプライマリ サーバとセカンダリ サーバ間のレプリケーションを自動的に開始します。 両方のサーバ間の差分データは、プライマリ サーバからセカンダリ サーバに複製されます。
    • 実行時:実行時のデータ レプリケーションは双方向です。 何らかの理由で、いずれかの MediaSense サーバがシャット ダウンするか、障害状態になった場合、データは引き続き生き残ったサーバに書き込まれます。 シャット ダウンしたり、障害が発生したサーバが回復すると、Informix ER は 2 台のサーバ間で自動的に再起動し、データを同期します。 データ サイズに応じて、同期時間が変動する場合があります。 保持期間は、データが生き残ったサーバにレプリケーションの分割なしで保存できる日数を指します。 データベースの保存期間の推奨事項に関する詳細については、『Cisco MediaSense Design Guidehttp:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-implementation-design-guides-list.html を参照してください。

    プライマリまたはセカンダリ ノードでのデータ レプリケーションとリカバリ

    プライマリ サーバまたはセカンダリ サーバのいずれかがアウト オブ サービスになった場合、データベース レプリケーション プロセスは、次のように行われます。

    • MediaSense は、記録データベースへのデータの書き込みを続行します。 データはアウト オブ サービス状態のノードにレプリケートできないため、Informix は引き続き動作しているノードの ora_ersb レプリケーション バッファにデータを保存します。 ora_ersb が一杯になる前にアウト オブ サービスになっているノードが復旧した場合、レプリケーションが自動的に復元され、ora_ersb 内のデータは両方のノード間で同期されます。

    • あるノードが長期間にわたりアウト オブ サービスになると、稼働中のノードの ora_ersb バッファが一杯になる場合があります。 ora_ersb がその容量の 90% に到達すると、システムは稼働中のノードのレプリケーションを自動的に停止します(その結果、単一ノードのように動作します)。 これは、ora_ersb が一杯になりすぎてシステムが機能不全になるのを防止するためです。

    • レプリケーションが稼働中のノードで停止した場合、アウト オブ サービス状態のノードのサービスが復旧すると、レプリケーションは自動的に復元されます。 ユーザの介入は不要です。 レプリケーションの復元後、データ同期ジョブが起動し、両方のノードでメタ データと設定データの両方を比較し、このデータを同期します。

    いずれか一方のノードで、次の CLI コマンドを実行して、データ同期ジョブのステータスを確認できます。

    show db_synchronization status [db_ora_meta|db_ora_config]

    ハイ アベイラビリティの展開の考慮事項

    ハイ アベイラビリティの展開を実現し、データ レプリケーションを提供するには、次のガイドラインに従ってください。

    • API サービスがイネーブルになり、実行されていることを確認します。 API サービスは、内部パフォーマンスをモニタし、過負荷防止機能を提供します。 過負荷状態が検出された場合、API サービスは、自動的にサードパーティ要求の拒否を開始します。 クライアント アプリケーションは、拒否を受信すると代替 API サービス上で要求を再試行できます。
    • 展開には、クラスタ内に最大の 5 つの可能なコール制御サービスを含めることができます。

    次の表は、考えられる MediaSense のハイ アベイラビリティ シナリオを示します。

    MediaSense のシナリオ

    Unified Communications Manager を使用する場合(ビルトイン ブリッジまたはネットワークベースの録音)

    Unified Border Element ダイヤルピア録音を使用する場合

    通常のシナリオ

    Unified Communications Manager は、ラウンドロビン方式を使用して使用可能なコール制御サービスに到達して、アウトバウンド コールを発信し、直前のコール制御サービスへのアクセスを試行した後でも失敗した場合はタイムアウトします。

    Unified Border Element は、メディア録音リストの最初の MediaSense サーバに常にコールを送信します。

    障害が発生したサーバのシナリオ

    Unified Communications Manager は、リスト内の次に使用可能な MediaSense サーバを使用します。

    Unified Border Element は、メディア録音リスト内の次に使用可能な MediaSense サーバを使用します。

    障害状態の考慮事項

    何らかの理由で MediaSense プライマリ サーバまたはセカンダリ サーバに障害が発生した場合、生き残ったサーバはメタ データベースと MediaSense Enterprise Replication Smart Binary Large Object を引き続きメタデータに書き込みます。 この大きなオブジェクトは ora_ersb と呼ばれます。

    ora_ersb が容量の 90% に達すると、生き残ったサーバのレプリケーションは、生き残ったサーバがデータの書き込みを続行できるように停止します。 ora-ersb が容量を超えた場合、システムは機能を停止します。

    リカバリ時間とは、障害が発生した MediaSense サーバがサービス状態に復旧した後に生き残ったサーバとデータを同期するのにかかる時間です。 障害が発生したサーバのリカバリ時間の長さは、次の要因によって異なります。

    • 1 台のサーバがダウンした場合に、残存するサーバに書き込まれるデータ量

    • 2 台のサーバ間のデュプレックス ネットワーク接続の速度

    • リカバリの進行中に実行されるコール負荷のレベル

    • 残存するサーバでレプリケーションが停止しているかどうか

    障害が発生した MediaSense システムは、次の 2 つのレベルで機能が低下する可能性があります。

    • ora_ersb が 90% 未満の場合。 障害が発生したサーバが、生き残ったサーバ上で ora_ersb が 90% に達する前の状態に復帰する場合、メタデータは失われません。

    • ora_ersb が 90% 以上の場合。 障害が発生したサーバが復元される前に ora_ersb が生き残ったサーバの 90% に達した場合、生き残ったサーバ上のレプリケーションが停止します。 これにより、生き残ったサーバは、メタデータを失わずにデータの書き込みを続行することができます。 障害が発生したサーバがサービス状態に復帰したときに、レプリケーションを再確立する必要があり、サービスの準備が整うまでに時間がかかる場合があります。 また、障害が発生したサーバがサービス状態に復帰した後に、データを同期するためにかなり長い時間がかかる場合があります。

    いずれの場合も、障害が発生したサーバが復帰し、使用可能な状態になると、レプリケーションは自動的に再開します。 手動による作業は必要ありません。

    障害復旧期間の詳細については、『Cisco MediaSense Design Guide』を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​implementation_​design_​guides_​list.html [英語] から入手できます。

    MediaSense の要件

    ここでは、MediaSense の要件を確認します。

    メディア ストレージの要件

    シスコは、プライマリおよびセカンダリ サーバ、拡張サーバ、および小規模設定用のオプションを備える Virtualization Archive(OVA)仮想マシン(VM)テンプレートを提供します。 これらのテンプレート オプションは、MediaSense サーバに対してサポートされる VM の設定を指定します。 これらのテンプレート オプションは、わけても特定のサーバで使用可能な CPU のメモリ フットプリントと要件を指定します。 すべての MediaSense サーバで、このシスコ提供のテンプレートを使用する必要があります。

    複数の MediaSense サーバを持つ環境でハイ アベイラビリティを確保するには、異なる物理ホスト上にプライマリ サーバとセカンダリ サーバをインストールする必要があります。

    詳細については、『Cisco MediaSense Design Guide』を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​implementation_​design_​guides_​list.html [英語] から入手できます。

    ハードウェア要件

    MediaSense には、シスコが開発したアプライアンス モデルである Linux ベースの Unified Communications Operating System(OS)が同梱されています。

    MediaSense 用に認定されたサーバは、次のハードウェア要件を満たす必要があります。

    ハードウェアの制限に関する詳細については、Cisco.com(CDC)(http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​prod_​release_​notes_​list.html [英語])から入手できる『Cisco MediaSense Release Notes』を参照してください。

    ソフトウェア要件

    MediaSense は、次のソフトウェア要件を満たしている必要があります。

    ライセンス要件

    MediaSense のプライマリ ライセンシングと機能アクティベーション方式は、信頼ベースのライセンシングであるため、MediaSense のライセンスをインストールする必要はありません。

    その他の要件

    MediaSense は、電源障害による予測できない動作を防ぐために、常に無停電電源を装備している必要があります。

    ポートの使用

    このセクションでは、MediaSense で使用される TCP ポートと UDP ポートについて説明します。


    (注)  


    ユーザは、これらのポートを設定できません。 次の表に、MediaSense をインストールする際に、それを設定する方法を示します。

    次の表の列は、以下の情報を提供します。

    • サーバまたはアプリケーション プロトコル:オープンまたはプライベート アプリケーション プロトコルの名前。

    • サーバ プロトコルおよびポート:サーバとして機能する際の着信接続要求用の IP アドレスとともに、サーバまたはアプリケーションがリッスンする TCP または UDP ポート。

    • リモート プロトコルおよびポート:サーバとして機能する際の着信接続要求用の IP アドレスとともに、リモート サービスまたはアプリケーションがリッスンする TCP または UDP ポート。

    • リモート デバイス:サーバまたはサービスに接続するリモート アプリケーションまたはデバイス。

    • 使用元:各ポート(複数可)を使用するサービス(複数可)またはエージェント。

    サーバまたは

    アプリケーション プロトコル

    Server

    プロトコルとポート

    Remote

    プロトコルとポート

    Remote Device

    使用者

    HTTPS

    TCP 443、8443

    いずれか(Any)

    Web ブラウザ

    管理、サービスアビリティ

    HTTPS

    TCP 8440

    いずれか(Any)

    クライアント アプリケーション

    API アクセス

    HTTPS

    TCP 9443

    いずれか(Any)

    クライアント アプリケーション

    認証された要求をリダイレクトするためにメディア デバイスによって使用される。

    HTTPS

    TCP 8446

    いずれか(Any)

    Web ブラウザ、API クライアント

    コール制御サービス

    HTTPS

    TCP 9081

    いずれか(Any)

    クライアント アプリケーション

    認証された要求をリダイレクトするためにメディア デバイスによって使用される。

    HTTP

    TCP 80、8080

    いずれか(Any)

    Web ブラウザ

    管理、サービスアビリティ

    HTTP

    TCP 8081

    いずれか(Any)

    Web ブラウザ、API クライアント

    コール制御サービス

    HTTP

    TCP 8085

    いずれか(Any)

    別の CMS のノード

    コール制御サービス

    HTTP

    TCP 8087

    いずれか(Any)

    CMS クラスタ ノードのみ

    システム サービス

    HTTP

    TCP 8088

    いずれか(Any)

    CMS クラスタ ノードのみ

    コンフィギュレーション サービス

    RTSP

    TCP 554、8554

    いずれか(Any)

    RTSP メディア プレーヤー

    SM エージェント

    RTSP

    TCP 9554

    いずれか(Any)

    クライアント アプリケーションまたはメディア プレーヤー

    認証された要求をリダイレクトするためにメディア デバイスによって使用される。

    SIP

    TCP/5060

    UDP 5060

    TCP/5060

    UDP 5060

    Unified Communications Manager または Unified Border Element

    コール制御サービス

    TCP/IP

    TCP 1543

    いずれか(Any)

    CMS クラスタ ノードのみ

    プライマリ サーバとセカンダリ サーバ間の接続を確立するために Informix ER によって使用される。

    JDBC を Informix と接続するために API サービスまたはコンフィギュレーション サービスによって使用される。

    キープアライブ ハートビート

    UDP 8091

    UDP 8091

    CMS クラスタ ノードのみ

    他のコール制御サービスのアベイラビリティを検出するためにコール制御サービスによって使用される。

    JMS

    TCP 61610

    いずれか(Any)

    CMS クラスタ ノードのみ

    API サービス

    JMS

    TCP 61612

    いずれか(Any)

    CMS クラスタ ノードのみ

    コール制御サービス

    JMS

    TCP 61616

    いずれか(Any)

    CMS クラスタ ノードのみ

    SM エージェント

    エフェメラル ポート範囲

    UDP 32768 ~ 61000

    いずれか(Any)

    RTP メディア ストリームを送信する電話機またはゲートウェイ。

    RTP メディア ストリームを受信するためにメディア サービスによって使用されるポート範囲。

    エフェメラル ポート範囲

    UDP 1024 ~ 65535

    いずれか(Any)

    アーカイブ済みの録音またはライブ録音を聞くのに使用される RTSP メディア プレーヤー。

    RTP メディア ストリームを送信するためにメディア サービスによって使用されるローカル ポートの範囲。