Cisco MediaSense ユーザ ガイド リリース 10.0(1)
MediaSense の機能とサービス
MediaSense の機能とサービス

目次

MediaSense の機能とサービス

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

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

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

ネットワーク サービス

ネットワーク サービスには次のものがあります。

  • 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 CM データベースに書き込みます。
  • 診断サービス:MediaSense をトラブルシューティングし、デバッグできます。 このサービスは、すべての MediaSense サーバで使用できます。

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

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

機能サービス

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

  • コンフィギュレーション サービス:MediaSense コンフィギュレーション データベースに加えられたすべての変更を保存し、更新します。 各サーバ クラスタには、コンフィギュレーション サービスの 2 つのインスタンスのみがあります。1 つのインスタンスはプライマリ サーバにあり、他のインスタンスはセカンダリ サーバにあります。 クラスタ内に 2 台以上のサーバがある場合、拡張サーバはサービス コンフィギュレーションを設定できません。
  • API サービス:API 要求を処理し、ユーザ インターフェイスとサーバ間の通信をイネーブルにします。 データベース サービスをイネーブルにした後で、API サービスをイネーブルにできます。 各複数サーバ クラスタには、API サービスの 2 つのインスタンスのみがあります。1 つのインスタンスはプライマリ サーバにあり、他のインスタンスはセカンダリ サーバにあります。 クラスタ内に 2 台以上のサーバがある場合、拡張サーバには API サービスは含まれません。
  • データベース サービス:メタ データベースとコンフィギュレーション データベースを含み、制御します。 各複数サーバ クラスタには、データベース サービスの 2 つのインスタンスのみがあります。1 つのインスタンスはプライマリ サーバにあり、他のインスタンスはセカンダリ サーバにあります。 各サーバは、ローカル データベースにのみデータを書き込みます。 プライマリ サーバとセカンダリ サーバは、データを同期するために対話します。
  • ストレージ管理エージェント(SM エージェント):クラスタ内の各サーバのストレージ全体をモニタし、ディスク使用率に基づくしきい値イベントを生成します。 このサービスは、すべてのサーバで使用可能であり、メディア サービスおよびコール制御サービスの前にアクティブにする必要があります。
  • メディア サービス:メディアを受信、保存、および再生します。 メディア サービスは、コール制御サービスの前にイネーブルにする必要があります。 このサービスは、クラスタ内のすべてのサーバで使用できます。
  • コール制御サービス:コールの受信と録音を調整します。 コール制御サービスは、メディア サービスがイネーブルになっている場合にのみイネーブルにできます。 このサービスは、クラスタ内のすべてのサーバで使用できます。 コール制御サービスは、Unified CM ユーザ インタフェースおよび Unified CM マニュアルでは SIP トランクと呼ばれています。

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

検索と再生

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


(注)  


検索と再生を起動する前に、JDK の 32 ビット バージョンを Windows OS にインストールし、64 ビット バージョンを MAC にインストールする必要があります。 また、JDK7 Update 25 がインストールされていることを確認します。


以下の方法で、検索と再生アプリケーションにアクセスします。
  • Firefox または IE9 ブラウザで URL https://<hostname>:8440/mediasense からアクセスするか、 または
  • URL http://<MediaSense hostname> のメイン MediaSense アクセス画面から Cisco MediaSense Search and Play リンクをクリックします。

(注)  


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

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

次の表に、Windows と Mac オペレーティング システムの検索と再生メディア プレーヤーによってサポートされるコーデックを示します。

コーデック Windows Mac
g.711 aLaw サポート サポート
g.711 µLaw サポート サポート
g.729 サポート  
g.722   サポート

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

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

手順
    ステップ 1   まず検索と再生アプリケーションにアクセスすると、[Recent Calls] デフォルト検索の結果(直前 7 日以内のすべてのコール)ページが開きます。 これらのタブをいつでもクリックして、[Recent Calls] または [Active Calls] 検索を選択できます。
    ステップ 2   簡素検索の場合、検索ボックスに参加者の ID とタグの組み合わせを入力し、[Search] をクリックします。 各エントリを区切るにはスペースを使用します。デリミタは OR 演算子と見なされます。 簡易検索では、デフォルトで直前 7 日以内のコールが検索されます。
    ステップ 3   詳細検索の場合、[Search Recordings] ドロップ ダウン メニューから任意の検索プロパティに値を入力します。

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

    • SessionId:1 つ以上のトラックが関連付けられた録音セッション識別子。 テキスト ボックスにセッション ID を入力します。 一度に 1 つの SessionId のみを検索できます。
    • Participants:録音セッションの参加者の ID。 参加者は内線番号によって識別されます。 テキスト ボックスに参加者 ID を入力します。 カンマを使用して ID を区切ることで、複数の参加者を検索できます。 複数の参加者が定義されている場合、検索は参加者全員が含まれるコールのみ返します(デリミタは AND 演算子と見なされます)。
    • Tags:テキストを入力します。 タグの検索は CONTAINS と見なされます。このため、1 つの文字を入力すると、その文字を含むすべてのタグの結果を出力します。 検索ボックスで使用するスペースは、デリミタとしてではなく、検索対象の値の一部と見なされます。 したがって、スペースで区切られた 2 つの語を検索すると、スペースで区切られた両方の語を含むタグを持つコールのみが返されます。
    • XRef CI:録音セッションの ID。 テキスト ボックスに録音セッション ID を入力します。 一度に 1 つの XRefCI のみ検索できます。
    • CCID:録音セッション内の個々のトラックの ID。 テキスト ボックスにトラック ID を入力します。 一度に 1 つの CCID のみ検索できます。
    • Range:録音セッションを開始した日付。 特定の時間枠または日付の範囲の間で検索するように選択します。 時間枠を選択しない場合、システムはデフォルトで直前 7 日以内に設定します。 時間範囲を選択する場合は、短い期間を選択します。 大量の録音が出力される検索では、処理に並外れた時間がかかる可能性があり、システム パフォーマンスに影響を与えます。
    • Duration:時間単位を選択し、スライド バーを使用して、秒、分、または時間単位で、録音されたセッションの間隔を選択します。
    • Show:このチェックボックスを使用して、完了したコール、アクティブ コール、または録音エラーを含むコールを検索するかどうかを指定します。
    ステップ 4   [Search] をクリックします。
    • [Sort by] ドロップ ダウン メニューをクリックして、経過時間または持続期間によってファイルをソートをします。
    • ダウンロード アイコンをクリックして、録音をダウンロードします。
    • 再生アイコンをクリックして、録音を再生します。
    • [Previous] ボタンと [Next] ボタンを使用して、結果ページを介して各ページとステップに表示する検索結果の数を選択できます。
    (注)     

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


    アーキテクチャ

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

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

    • アプリケーション層:
      • 検索と再生アプリケーションを使用して、録音を再生できます。
      • API は、をサポートするサードパーティ製アプリケーションに対するリアルタイムの録音制御(保留、一時停止と再開など)。
      • プリケーションおよびメディア API は、さまざまな業界パートナーの要件を組み込み、サードパーティ製アプリケーションで使用するために公開されています。
      • API サービスは、録音および関連セッションの履歴とメタデータを検索および取得するためにアプリケーションをイネーブルにする Web サービス インターフェイスを備えています。 このメタデータ情報は、Meta データベースに保存されます。
    • メディア処理層:
      • メディア サービスは、アーカイブと再生のためにローカル ディスクに保存されたメディア ストリームを終端します。
      • 拡張されたすべてのサーバ上でメディア サービスを実行することにより、ロード バランシングが可能になります。
    • ネットワーク層:
      • ゲートウェイおよびセッション ボーダー コントローラ(SBC)のメディア分岐とエンドポイントでのメディア分岐。
      • オーディオ レコーディング用の Cisco Unified Communications Manager(Cisco Unified CM)との統合。
      • オーディオおよびビデオ レコーディング用の Cisco Unified Border Element(CUBE)との統合。

    Unified Communications Manager の展開

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

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

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

    Cisco Unified Border Element の展開

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

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

    CUBE に関する詳細については、CUBE のマニュアルを参照してください。

    次の図は、CUBE を使用する MediaSense 展開を示しています。 CUBE を展開する場合でも、MediaSense は Unified CM に依存して認証サービスを提供します。



    上図で、リアルタイム プロトコル(RTP)は、エンドポイントと CUBE の間で音声データを伝送します。 セッション開始プロトコル(SIP)は、エンドポイントと CUBE の間のコール シグナリング情報を伝送します。 2 つの RTP 単方向ストリームは、CUBE から MediaSense 分岐される 2 つのオーディオ ストリームを表します。 CUBE のみが MediaSense にデータを送信し、MediaSense は CUBE にメディアを送信しないため、CUBE から MediaSense へのストリームは単方向です。 CUBE には、着信、発信、および分岐の 3 つダイヤルピアがあります (詳細については、ダイヤルピア レベルの設定を参照してください)。

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

    この機能を使用するには、デバイスのゲートウェイと border-element 機能の両方をイネーブルにする必要があります。 ゲートウェイが TDM またはアナログ コールを受信し、別の着信番号を使用して SIP コールとしてそれ自体にコールバックするように設定できます。 このループを設定すると、ルータは実際には各コールを 2 回処理することになります (これにより、ルータの容量が半分に削減され、CUBE は同じ数のコールを半分で処理できるようになります)。詳細については、『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 の記事を参照してください。

    Unified CM と CUBE シナリオの相違

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


    (注)  


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

    コール シグナリングに関連しないほとんどが、MediaSense を使用した Unified CM シナリオと CUBE のシナリオで同じです。

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



    表 1 Unified CM と CUBE シナリオの相違

    MediaSense の機能

    Unified CM を使用

    CUBE を使用

    録音の開始

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

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

    記録

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

    録音は SIP デバイス(CUBE の SIP ユーザ エージェントと呼ばれる)を使用します。 コールが CUBE によって 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 Solution Reference Network Design』を参照してください。このマニュアルは、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 から入手できます。

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

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

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

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

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

    キャプチャされます。

    キャプチャされません。

    録音メディア ソース

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

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

    サポートされる展開

    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 CM サーバは、すべて同じ LAN に設置する必要があります。 LAN 内では、任意の 2 つのサーバ間の最大ラウンドトリップ遅延は 2 ms 未満である必要があります。

    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 エージェント

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



    各単一サーバ展開では、最大 300 の同時セッションおよび 1 時間あたり 9000 セッションの Busy Hour Call Completions (BHCC)レート(平均接続時間 2 分のコールごと)がサポートされます。 単一サービス展開では、冗長性の問題への対応、ハイ アベイラビリティの提供、ストレージ容量の拡大、同時録音容量の増加のために、後でさらにサーバを追加することができます。

    デュアルサーバ展開

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

    プライマリ サーバとセカンダリ サーバの両方が次の機能サービスを備えています。
    • API サービス
    • コンフィギュレーション サービス
    • コール制御サービス
    • メディア サービス
    • データベース サービス
    • SM エージェント
    図 2. デュアルサーバ展開. デュアル サーバ展開では、ハイ アベイラビリティが提供されます。 録音の負荷は、すべてのサービスが両方のサーバで常にアクティブであるため、プライマリ サーバとセカンダリ サーバで自動的に均等化されます。




    (注)  


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


    サポートされる同時録音、再生、モニタリング セッションの最大数については、『Cisco MediaSense Solution Reference Network Design Guide』ガイドを参照してください。

    3 サーバ展開

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

    プライマリ サーバとセカンダリ サーバは、次の機能サービスを備えています。
    • API サービス
    • コンフィギュレーション サービス
    • コール制御サービス
    • メディア サービス
    • データベース サービス
    • SM エージェント
    拡張サーバは、次の機能サービスを備えています。
    • コール制御サービス
    • メディア サービス
    • SM エージェント
    図 3. 3 サーバ展開. 3 サーバ モデルは、冗長性を提供し、ストレージ容量、同時録音および再生容量を増加します。 録音の負荷は、それぞれのサーバでサービスが常にアクティブであるため、サーバ間で自動的に均等化されます。




    (注)  


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

    サポートされる同時録音セッション、再生セッション、モニタリング セッションの最大数に関する詳細については、『Cisco MediaSense Solution Reference Network Design Guide』を参照してください。

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

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

    プライマリ サーバとセカンダリ サーバは、次の機能サービスを備えています。
    • API サービス
    • コンフィギュレーション サービス
    • コール制御サービス
    • メディア サービス
    • データベース サービス
    • SM エージェント
    拡張サーバと呼ばれる残りのサーバには、次の機能サービスだけが用意されています。
    • コール制御サービス
    • メディア サービス
    • SM エージェント
    図 4. 5 サーバ展開. この展開モデルは、冗長性を提供し、ストレージ容量を拡大し、同時録音および再生セッション用に容量を増やすことができます。 録音の負荷は、それぞれのサーバでサービスが常にアクティブであるため、サーバ間で自動的に均等化されます。




    (注)  


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


    サポートされる同時録音セッション、再生セッション、モニタリング セッションの最大数に関する詳細については、『Cisco MediaSense Solution Reference Network Design Guide』を参照してください。

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

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

    詳細については、『Cisco MediaSense Solution Reference Network 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 Solution Reference Network Design Guide』を参照してください。

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

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

    • 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 CM を使用

    CUBE を使用

    通常のシナリオ

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

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

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

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

    CUBE は、メディア録音リスト内の次に使用可能な 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 Solution Reference Network 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 Solution Reference Network Design Guide』を参照してください。このマニュアルは、http:/​/​www.cisco.com/​en/​US/​products/​ps11389/​products_​implementation_​design_​guides_​list.html から入手できます。

    ハードウェアの要件

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

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

    ソフトウェア要件

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

    ライセンス要件

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

    その他の要件

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

    ポートの使用方法

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


    (注)  


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

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

    • サーバまたはアプリケーション プロトコル:オープンまたはプライベート アプリケーション プロトコルの名前。
    • サーバ プロトコルおよびポート:サーバとして機能する際の着信接続要求用の IP アドレスとともに、サーバまたはアプリケーションがリッスンする TCP または UDP ポート。
    • リモート プロトコルおよびポート:サーバとして機能する際の着信接続要求用の IP アドレスとともに、リモート サービスまたはアプリケーションがリッスンする TCP または UDP ポート。
    • リモート デバイス:サーバまたはサービスに接続するリモート アプリケーションまたはデバイス。
    • 使用元:各ポート(複数可)を使用するサービス(複数可)またはエージェント。

    サーバまたは

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

    サーバ

    プロトコルとポート

    リモート

    プロトコルとポート

    リモート デバイス

    使用されるアプリケーション

    HTTPS

    TCP 443、8443

    Any

    Web ブラウザ

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

    HTTPS

    TCP 8440

    Any

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

    API アクセス

    HTTPS

    TCP 9443

    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 CM または CUBE

    コール制御サービス

    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 メディア ストリームを受信するためにメディア サービスによって使用されるポート範囲。