Cisco MediaSense 設計ガイド リリース 11.0(1)
メタデータ データベースと MediaSense API
メタデータ データベースと MediaSense API

メタデータ データベースと MediaSense API

メタデータ データベース

MediaSense は、記録されたセッションに関する大量の情報を含むデータベースを保持します。 データベースは、プライマリ サーバとセカンダリ サーバに冗長的に保存されます。 データには次のものがあります。

  • 各種トラック、参加者、コールおよびセッション ID
  • タイム スタンプと期間
  • リアルタイムのセッション状態
  • さまざまな形式の録音をストリーミングおよびダウンロードするための URI
  • 録音済みファイルが保存されるサーバ アドレス

タグ

上記の情報とともに、MediaSense は各セッションのタグを保存します。

タグは、クライアントが Web 2.0 API を使用して指定して個別のセッション、また任意でそれらのセッション内の特定のタイム オフセットに関連付けることができる簡潔な任意のテキスト文字列です。 時限セッション タグは、何か重大事が起こった場合、たとえば発信者が感情的になったりエージェントが誤った情報を与えたときなどに、時間内にポイントを特定する場合に役立ちます。 非時限セッション タグは、コンタクト センターのエージェント ID などのセッション全体に適用できる注記を添付したり、一部のセッションを他のセッションに対しマークを付けたり分類するために使用できます。

MediaSense は、特定のアクションがセッション中(一時停止や再開など)に発生したり、メディアの非アクティビティ状態が SIP シグナリングによって報告されたとおりに変化した場合にマークを付けるタギング機能も使用します。 これらはシステム定義のタグと呼ばれます。

ほとんどのタグがセッション全体に関連付けられる一方で、メディアの非アクティビティ状態変更タグはセッションの特定のトラックに関連付けられます。

MediaSense API

MediaSense API はメタデータ データベース内の情報を検索、取得するための多数の手段を提供します。 認証されたクライアントは、自動プルーニング機能によって削除されたすべてのセッションや、特定の文字列でタグ付けされた特定時間範囲内のすべてのセッションを検索するなどの単純な照会を実行します。 API は、結果セットのうちから選択されたサブセットだけ返すソートおよびページング方式を含めて、より複雑なクエリーもサポートしています。

API は、MediaSense のその他の多数の機能へのアクセスも提供します。 イベントのサブスクライブ、ディスク ストレージの管理、進行中の録音セッションの操作、不要な非アクティブ セッションの削除とそのリソースの回収、.mp4 や.wav への変換などの処理の呼び出しに API を使用します。 時間のかかる処理は、リモート バッチ ジョブ制御機能によってサポートしています。 API については、次の URL にある『Cisco MediaSense Developer Guide』で詳細に説明しています。http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-programming-reference-guides-list.html

MediaSense API によるやるとりは、すべて HTTPS 上で実行されるため、クライアントは認証される必要があります。 要求のタイプによって、クライアントは POST または GET メソッドを使用します。 応答本文は、常に JSON 形式で送信されます。 HTTP バージョン 1.1 が使用され、要求と要求の間も TCP リンクの接続状態を維持できます。 最適なパフォーマンスを得るため、クライアントもそのように作成する必要があります。

API 要求はプライマリ サーバまたはセカンダリ サーバを宛先とすることができますが(クライアントは各サーバに個別に認証を受ける必要あり)、サーバから取得した HTTP セッション ID を指定する必要があります。

Event

MediaSense のイベント機能は、サーバベースのクライアントに対し、それらに関連したアクションが実行されるとただちに通知します。 次のタイプのイベントがサポートされます。

  • セッション イベント:録音セッションが開始、終了、更新、削除、またはプルーニングされた場合。
  • タグ イベント:録音されたセッションにタグが付加または削除された場合。
  • ストレージしきい値イベント:ディスクの占有領域が事前設定された特定のしきい値をまたいで増加または減少した場合。

セッション イベントは、セッションの現在の状態に関する重要な情報を提供します。 たとえば、クライアントはこれらのイベントで提供される URI を使用して、監査役またはコンタクト センターのスーパーバイザにリアルタイム モニタリングおよび制御ボタンを提供できます。 クライアントは、録音する必要がないと判断したセッションを(事後的に)削除して、(コンプライアンス レコーディングと対照をなす)一種の選択的録音を実行する場合もあります。

タグ イベントは、一種のクライアント間通信として使用されます。セッションにあるクライアントがタグ付けすると、他のすべてのサブスクライブしているクライアントにそのことが通知されます。

ストレージのしきい値イベントを利用して、サーバベースのクライアント アプリケーションでディスク使用率を管理することができます。 そのクライアントは、これらのイベントをサブスクライブしておき、独自のルールに照らして(必要に応じて)選択的に古い録音を消去します。 たとえば、クライアントは、選択したセッションに保存用としてタグ付けしておき、しきい値イベントを受信したときに、その保存用タグ付けしたもの以外で、特定の日付より古いセッションを削除することができます

イベントは、JSON 形式のペイロードが書き込まれ、Symmetric Web Services プロトコル(SWS)を使用してクライアントに送信されます。これは、本質的には事前定義された HTTP 要求のセットで、MediaSense からクライアントに送信されます(HTTPS はイベント送信では現在サポートされていません)。

クライアントは、イベント通知にサブスクライブする場合、目的のイベントのタイプまたはカテゴリのリストと、MediaSense がイベントの通知先とすべき URL を渡します。 任意の数のクライアントがサブスクライブでき、他の受信者に代わってサブスクライブすることも可能です(つまり、サブスクライブするクライアントはイベント受信者として自身以外のホストを指定する場合があります)。 唯一の制限は同じ URL に複数のサブスクライブを行えないことです。

イベントは常に、プライマリ サーバかセカンダリ サーバによって生成されます。 両方が配置される場合、各イベントはどちらか片方のサーバでのみ生成され、両方で生成されることはありません(ハイ アベイラビリティに影響するため)。 お客様はイベント送信の 2 種類のモード(信頼性を優先するか利便性を優先するか)から 1 つを選択する必要があります。

Unified Border Element と Unified Communications Manager のメタデータの違い

全体レベルとして、MediaSense によってキャプチャされたメタデータは、コール コントローラ に依存しません。 それぞれのレコーディングは、1 つ以上のセッションで構成され、各セッションはセッション ID を持っています。また、セッションは、関連したトラック、参加者、タグ、URI を持つことができます。 ただし、MediaSense との SIP レベルの対話の詳細は、いくつかに分かれています。それはコールが Unified Border Element ダイヤル ピアまたは Unified Communications Manager レコーディング設定のどちらによって制御されているかに依存しています。 この相違のため、MediaSense クライアントが監視するメタデータ内およびそれらが受信するリアルタイム イベント内でいくつかの差異が生じます。

  • 1 つ目の差異は、トポロジにあります。 Unified Communications Manager レコーディングの場合、録音用の SIP ダイアログは、Unified Communications Manager から取得されます。 Unified Border Element ダイヤル ピア レコーディングの場合、録音用の SIP ダイアログは Unified Border Element 自身から取得されます。 そのため、参加者が特定される方法と、参加者がメディア トラックに関連付けられる方法は異なります。

  • メタデータのより大きな違いはコール中のアクティビティから生じます。 たとえば、保留と再開によって、Unified Communications Manager が管理するコール用に新しいセッションが開始されますが、Unified Border Element ダイヤル ピアが管理するコール用にはトラック レベルのタグが挿入されます。 分岐電話の転送は、Communications Manager レコーディング上の レコーディング セッションを終了しますが、そのような動作は、Unified Border Element コールでは不可能です。

  • 会議の検出も、大きく異なります。 Unified Communications Manager では、このアクションは参加者が更新されているコンファレンス ブリッジへの転送として見なされ、メタデータ フラグはそれをコンファレンスとして識別します。 Unified Border Element ダイヤル ピア レコーディングでも、そのアクションは転送として見なされますが、メタデータ フラグはサポートされず、参加者のデータは不安定で、信頼性がありません。

  • もう 1 つの違いは、コールの相関関係に関連します。 Unified Communications Manager と Unified Border Element はコールを識別するために異なる方式を使用します。

シンプルなアプリケーションのクライアントは、コール コントローラの種類に依存しませんが、より高度なクライアントは通常、コールが Unified Border Element よって管理されているのか、それとも Unified Communications Manager よって管理されているのかを確認する必要があります。

次の URL にある『Cisco MediaSense Developers Guide』には、Unified Border Element 導入と Unified Communications Manager 導入の違いに関する詳細な説明があります。 http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​mediasense/​products-programming-reference-guides-list.html