Cisco MediaSense 開発者ガイド リリース 10.5(1)
MediaSense API の概要
MediaSense API の概要

目次

MediaSense API の概要

MediaSense API 規則

すべての REST 応答にエラー コードがあります。 MediaSense API のエラー コードはすべて、「パート 2: API の一覧、パラメータ、応答コードの一覧」に記載されています。

MediaSense API は camelCase 表記法を使用します。 API URI では大文字と小文字が区別されます。 API ごとに識別される厳密な URI を使用します。 パラメータでは大文字と小文字が区別されません。

HTTPS の使用

MediaSense API は HTTPS のみをサポートします。 安全でない HTTP はほとんどの MediaSense API で受け入れられません。 getAPIVersion API が唯一の例外です。HTTPS ではなく、HTTP が使用されるためです。

MediaSense は HTTPS バージョン 1.1 を使用し、連続する要求を処理し、クライアント接続を維持します。 特にイベント配信の場合にパフォーマンスを向上させるには、必ず同様の動作が実行されるように、サードパーティ製のアプリケーションを構築してください。

POST 要求または GET 要求の使用

MediaSense API は、POST 要求と GET 要求に次の表記法を使用します。

HTTP 要求タイプ 説明 Action
POST サーバでアクションを実行し、MediaSense サーバの状態を変更する要求(開始または停止要求)。 このパラメータの構造はクエリー パラメータで指定するには複雑すぎます。 たとえば、getSessions API は、それが安全な方法でも POST を使用します(サーバの状態を変更しません)。 パラメータは POST データ ブロックで渡されます。 データ ブロックは JSON 構文を使用します。
{
"requestParameters":{
   "param1":"value1",
   "param2":"value2"
    }
}
GET MediaSense システムに情報を問い合わせるか、情報を読み取るだけの要求(情報取得だけが目的であり、サーバの状態を変更しない、安全な方法)。 パラメータはクエリー パラメータとして URL で渡されます。 クエリー パラメータを指定するとき、疑問符「?」を最初のパラメータに付け、アンパサンド「&」を各後続パラメータに付けます。
[http://cisco.com/abc
/xyz?param1=value1
&param2=value2]

API バージョン

MediaSense API は次のバージョン表記法に従います。

  • MediaSense リリース 10.5(1)の API バージョン番号はバージョン 1.6 です。
  • API バージョン番号は 1.0 から始まり、製品バージョンと結び付いていません。
  • API バージョン番号は x.y.z ではなく x.y(例:1.0)です。

getAPIVersion API を使用して、システムで実行されている API の現在のバージョンを取得します。 この API は、MediaSense 展開で動作する API のバージョン番号を返します。 この API を使用するためにサインインする必要はありません。

応答の JSON 形式

MediaSense では JSON がサポートされます。 API 応答とイベントは JSON 形式です。 MediaSense API を使用するサードパーティ アプリケーションで使用される形式に関係なく、これらの規則に従ってください。

  • 各 API リクエスト の HTTP の accept ヘッダーで必要な形式を指定します。
  • ヘッダーが欠落している場合、データはデフォルトの JSON 形式で返されます。

(注)  


JSON 形式は、キーと値のペアです。 キーと値のペアの順序は、各応答内で同じではない場合があります。


MediaSense API の重要な要素

ここでは、MediaSense API 内の重要な要素とパターンを識別します。

MediaSense API のサンプル URI:

https://<host>:<port>/ora/<sampleService>/<sample>/<sampleMethod>

このサンプル URI の要素を次の表に示します。

要素 説明
https:// MediaSense API が使用するセキュアなプロトコル。
  • サーバ間の通信は常に HTTPS を使用する必要があります。
  • クライアント/サーバ間の通信では認証に HTTPS を使用する必要があります。
  • HTTPS は、ほとんどすべての MediaSense API に必要です。 1 つの例外が getAPIVersion API で、HTTP を必要とします。
<host>:<port> <host> をホスト名に、<port> をポート番号に置き換えます。 これら 2 つの要素は、各 API のコンテキスト ルートの一部です。
ora MediaSense API の製品名仕様です。 この要素はすべての MediaSense API を通して一定です。
sampleService または sample

この MediaSense API によって指定されたサービスの名前。 利用可能なサービスはユーザ認証、イベント サブスクリプション、セッション照会、セッション管理などです。

MediaSense API に関する詳細情報については、API リストを参照してください。 この要素では、sampleService はインターフェイスで、sample がその実装です。

sampleMethod API の名前。 各 API 名は動詞で始まり、実行されるアクションを示します。

次の URI は、上記の表で説明されている重要な各要素を使用した、MediaSense subscribeRecording API 用の URI の実例です。

https://<host>:<port>/ora/eventService/event/subscribeToEvents

API 応答スキーマ

すべての MediaSense API 応答にこれらの重要な要素があります。

JSON スキーマ:

{
"responseCode": <replace with your integer> //{
        Numeric code for the response
    }"responseMessage": <replace with your string> //{
        “A Textual Description of the result”
    }"responseBody": {
        //optional .. ..
    }
}

(注)  


responseMessage パラメータは変更される場合があり、プログラム上の比較の目的で使用するものではありません。 その目的には、responseCode パラメータを使用してください。


非同期イベントのスキーマ

すべての MediaSense API 応答にこれらの重要な要素があります。

JSON の例:

{
    "eventType": <replacewithyourstring>,
    //typeoftheeventsuchasSESSION_EVENT,
    TAG_EVENT,
    STORAGE_THRESHOLD_EVENT "eventAction": <replacewithyourstring>,
    //possibleactionsforagiveneventsuchasSESSION_STARTED,
    TAG_ADDED,
    "forwardedEvent": <replacewithyourstring>,
    //Indicatesthattheeventisnotlocallygenerated,
    butisforwardedfromanotherCiscoMediaSenseserver.Foreventswhicha
    regeneratedlocallyonaCiscoMediaSenseserverforthisfieldisomitted
    asforwardingisdisabled.
    "eventBody": //otherdetailswhicharespecifictoagivenevent
}

応答コード

次の分類は、HTTP 応答コードと同様にモデル化されています。 ただし、MediaSense の応答コードは周到に 4 桁(xxxx)に制限されているため、HTTP コードと区別できます。

MediaSense はすべてのカテゴリを使用するわけではありませんが、将来使用する必要が生じたときのために分類が実施されます。

コードの分類 説明
2xxx 成功: 操作が正常に受信され、理解され、受け入れられました。
3xxx リダイレクト: 要求を完了するには、クライアントは追加アクションを実行する必要があります。
4xxx クライアント エラー: 要求に不正な構文が含まれているか、要求を実行できません。
5xxx サーバ エラー: サーバは有効と思われる要求を実行できませんでした。

(注)  


MediaSense エラー コードの詳細については、「API Response Codes(API 応答コード)」を参照してください。


応答メッセージ

応答メッセージでは、以下のタイプの値を使用できます。

  • 肯定応答の場合:「Success(成功)」または「Partial success(一部成功)」。
  • 否定応答の場合:「Failure: <text indicating reason for failure>(エラー: <エラーの理由を示すテキスト>」。

Response Body

API 応答には、要件に基づいてオプションの本文を含めることもできます(responseBody)。 responseBody 内には、前述の 2 つのキー以外にも情報を入れる必要があります。

JSON スキーマ:

"responseBody": {//one or more optional elements within the 
 responseBody depending on the request specifications.
		        ..
                        ..
		      }

(注)  


List of APIs(API のリスト)」ページに、各 API の応答スキーマを示します。 ただし、すべてのパラメータが応答本文にはない可能性があります。これは状況によって異なります。 このような場合は、適切なパラメータのみが関連 API の応答本文に示されます。 たとえば、getSessions API の応答本文では、アクティブ セッションに duration パラメータの詳細は含まれません。


Encoding

すべての URL は URL エンコードである必要があります(パーセントエンコード)。

テキスト文字列の特殊文字

すべてのテキスト文字列に対して(パスワードを含む)、ユーザは http:/​/​www.json.org/​ の仕様に従います。また前にバックスラッシュを付けることで、特殊文字をエスケープする必要があります。

要求と応答パラメータの定義

MediaSense API で使用される要求および応答パラメータのリストについては、「API パラメータ」の項を参照してください。

2 台の MediaSense Server 間のフェールオーバー

MediaSense クラスタが複数のサーバを含んでいる場合、それらのサーバの内の 2 台だけが API を処理する API サービスを提供します。 MediaSense はノード間のクライアント要求の内部リダイレクションをサポートしないため、フェールオーバーはサポートされません。 これらの REST 要求を処理する MediaSense API サービスが何らかの理由で休止中である場合、サードパーティのクライアントを示す応答コードを送信し、このサービスを提供する他の MediaSense サーバに要求をリダイレクトします。 クライアントはこの応答コードを解釈し、それに応じて要求をリダイレクトします。

MediaSense API サービスがダウンしているか、サーバ自体がダウンしている場合、クライアントは HTTP タイムアウトを処理し、他の MediaSense サーバに要求を適宜リダイレクトする必要があります。

セキュリティの考慮事項

すべての MediaSense API は HTTPS に基づいており、自己署名証明書を使用します。 API を使用するたびにセキュリティ例外が表示されることがあります。

セキュア サーバは証明書を使用して、Web ブラウザが識別できるようにします。 独自の証明書(自己署名証明書と呼ばれる)を生成したり、認証局(CA)から証明書を取得できます。 詳細については、http:/​/​en.wikipedia.org/​wiki/​Certificate_​authority または Web ブラウザのマニュアルを参照してください。


(注)  


ポスターまたは他の類似するアプリケーションを使用して API 要求を発行する場合、まず Web ブラウザで次の URL を開いて、証明書を取得する必要があります。https://<Cisco MediaSense IP address>>:8440


ユーザ認証 API

MediaSense を利用すると、サードパーティの開発者は、サードパーティ製アプリケーションにそれ自体の認証を許可するアプリケーション ユーザを構成できます。 MediaSense API へのすべてのアクセスで認証が必要です。 アプリケーションの最初の手順はそれ自体を認証することです。 認証が成功すると、JSESSION トークンが返されます。 このトークンは、アプリケーションがサインアウトするまで、すべての後続要求で渡す必要があります。 JSESSIONID も signOut API 要求で必要です。

サードパーティ製のアプリケーションがプライマリ サーバとセカンダリ サーバの両方に API 要求を発行するように設計されていれる場合、各ノードに個別にサインインする必要があり、対応する JSESSIONID と要求を返したサーバを常に使用します。

このカテゴリの API に関する詳細については、「ユーザ認証」を参照してください。


(注)  


クライアントがサードパーティ製クライアントにログインし、MediaSense プラットフォームを使用するとき、サードパーティ製ソフトウェアは、そのソフトウェア アプリケーションが指図する認証を実行する必要があります。


ジョブ管理 API

ジョブは 1 つ以上のオペレーションを含むことができ、完了に時間がかかります。 各結果は各オペレーションごとに返されます。 ジョブの目的は、ジョブが完了するまでの間クライアントからサーバへの永続的な接続を必要とせずに、システムがジョブ要求を受け入れ、実行できるようにすることです。

deleteSessions API を使用して MediaSense ジョブを作成できます。deleteSessions API は、複数のセッションを同時に削除できる、一括削除オペレーションに応じてジョブを作成します。

すでに完了した、キャンセルされた、またはエラー状態のジョブだけが削除できます。 ジョブが RUNNING 状態にある場合は、最初に cancelJob API を使用してジョブを停止し、次にそのジョブを削除するために deleteJob API を使用します。

ジョブは処理中に拒否される可能性があるため、最終的に実行できない場合があります。 ジョブ ステータスとオペレーション結果を取得するには、Job Query API を使用します。

ジョブ クエリー API

ジョブ 管理 API を使用して作成されたジョブの状態および結果を取得するにはジョブ クエリー API を使用します。

getJobsById API は jobId パラメータを使用して既存のジョブを取得できるようにします。 この API への 2 回目以降のコールはジョブが進行中であるため、異なる値を返すことがあります。

getJobs API では、検索基準に基づいた結果を得るために、特定のパラメータを指定できます。

有効なジョブ状態が指定されていない場合、MediaSense は要求を処理できないことがあります。 この場合、ジョブ状態を確認し、要求を再度発行します。 すべてのジョブ状態は「ジョブの状態」の項に記載されています。

録音制御 API

MediaSense が提供する録音制御 API により、サードパーティ製クライアントがセッションの録音を制御できるようになります。

サードパーティ製クライアントは、現在進行中(アクティブ)のセッションの録音を一時停止したり、再開したりできます。次の条件がこれらの API に適用されます。

  • アクティブなセッションの録音でのみこの API を使用できます。
  • 一時停止中の録音だけを再開できます。

MediaSense は、別の種類の制御も提供します。これにより、サードパーティ製クライアントは MediaSense から電話機へのコールをトリガーし、コールが応答されたらすぐに録音を開始できます。 これは Direct Outbound Recording と呼ばれます。 対応する API はこの方法で開始された録音を停止できます。 これらの API を使用して、ブログやビデオ メッセージを録音できます。


(注)  


Direct Outbound Recording は、Unified Communications Manager 電話機でのみサポートされます。

録音を開始するには、デバイス参照で startRecording API によって開始されたコールに応答する必要があります。 電話を切るか、そのデバイス参照で stopRecording API を呼び出すことにより、録音を停止できます。


このカテゴリの使用可能な API のリストについては、「録音制御」を参照してください。

セッション クエリー API

MediaSense クエリー API を利用すると、アプリケーションは柔軟な方法でセッションに関する問い合わせを実行できます。

  • 複雑でも柔軟性のある getSessions API を利用すると、複雑なクエリーを実行できます。 この API を使用し、検索条件にさまざまな論理演算やその他のソート パラメータ、ページング パラメータを指定できます。
  • 単純で柔軟性の低いクエリー API の場合、一部の基本的なよく使用されるクエリー(getAllActiveSessions など)のみを実行できます。

このカテゴリの使用可能な API の一覧については、「セッション クエリー」を参照してください。

同時検索要求

システム パフォーマンスに影響しないように、MediaSense はセッション クエリ API 要求に対して次のルールを実行します。

  • MediaSense システムは、15 の着信セッション クエリ API 要求を受け入れ、さらに要求 10 件の待機リストを作成します。 これら 25 件の要求を超える他のすべての要求は、システムが拒否します。
  • セッション クエリ API 要求が送信後 2 分以内に MediaSense システムによって完了されない場合、その要求はタイムアウトしてドロップされます。 その場合、要求は後で再送信する必要があります。

スケーラブルなクエリーとスケーラブルでないクエリー

getSessions API により、クライアントはセッションごとに収集されたメタデータのカスタム クエリーを実行できます。 この API により、クライアントはセッションのメタデータ内にある複数の重要なデータ フィールドでのフィルタリングを可能にする、カスタム クエリーを形成できます。 また、これらのクエリーを組み合わせた柔軟な方法で、パワフルなメタデータ検索を実行できます。


(注)  


このカスタム クエリー機能は、正しく使用しないと、クエリー自体だけでなく MediaSense システム全体のパフォーマンスに重大な影響を与えることがあります。 システム上のトラフィックや使用中の保持機能に応じて、大量のセッション記録を保存するのは通常行われることですが、クエリーが大量のデータを処理する場合は完了までに数分かかる場合があります。 また、新しい記録とメタデータの処理に使用するシステム上のリソースに影響する可能性があります。同時に実行される他の大きなクエリーについては言うまでもありません。 たとえば、 2 つの同時クエリーの両方が実行のために大量の一時データベース領域を必要とする場合、そのうちの 1 つが容量不足でエラーとなる可能性があり、どちらがエラーになるかについての保証はありません。

この問題を回避するため、クライアントはスケーラブル なクエリーを形成することが重要です。 スケーラブル クエリーとは、データベースにどの程度データがあるかに関係なく、パフォーマンスが一定となるクエリーです。 スケーラブル クエリーの一例を次に示します。「開始日時が本日の 4 ~ 5 時の間であるセッションをすべて検索する」。データベース内にどれだけ多くのセッションが存在する場合でも、4 ~ 5 時の間のセッション数は、かなり安定して少ないままです。 スケーラブルでないクエリーの一例を次に示します。「すべてのセッションを検索する」。返されるセッション数は、データベース内のセッション数に比例します。 大量のセッションが保存されている場合、結果は膨大な数になります。 そのため完了するまでに相当な時間がかかり、MediaSense システムの他の機能が必要とするリソースに影響を及ぼします。

該当するラッパー API の minSessionStartDate および maxSessionStartDate パラメータを使用することによって、膨大な数の結果を返すクエリーからシステムを保護できます。 これらのパラメータの具体的使用方法については、該当するセッション クエリー API を参照してください。

詳細については、「スケーラブルでないクエリー」の項を参照してください。

セッション管理 API

コンタクト センターまたは音声分析環境では、スーパーバイザ、エージェント、音声分析システムは、場合によっては、記録中の、またはすでに記録されているセッションにタグを追加する必要があります。 あるいは、一部のセッションを削除したり、保存して削除を防いだりすることで、セッション録音を効率的に管理する必要があります。

MediaSense はセッション管理 API を利用し、こうした管理機能を提供します。 これらの API を使用し、サードパーティ クライアントは 1 回に 1 つずつ、または一括でセッションにタグを追加したり、セッションからタグを削除したりできます。 クライアントはまた、mp4 や wav などのサポートされる形式にセッションを変換し、事前に指定した場所に移動できます(MediaSense システムで)。


(注)  


アクティブなセッション録音と完了したセッション録音の両方でタグを追加したり、削除したりできますが、セッション録音自体は完了しているものだけ削除できます。 同様に、アクティブまたはエラー状態にあるセッションは変換できません。


このカテゴリの使用可能な API の一覧については、「セッション管理」を参照してください。

通知のサブスクライブ

MediaSense イベント サブスクリプション API を利用すれば、サードパーティ製アプリケーションで次のイベント通知をサブスクライブできます。

Event Category このカテゴリに含まれるイベント
ALL_EVENTS クライアントはすべてのイベントをサブスクライブします。
RECORDING_EVENTS
  • SESSION_STARTED_EVENT
  • SESSION_UPDATED_EVENT
  • SESSION_ENDED_EVENT
CLEANUP_EVENTS
  • SESSION_DELETED_EVENT
  • SESSION_PRUNED_EVENT
TAG_EVENTS
  • TAG_ADDED_EVENT
  • TAG_DELETED_EVENT
  • TAG_UPDATED_EVENT
STORAGE_EVENTS
  • ENTER_LOW_STORAGE_SPACE_EVENT
  • EXIT_LOW_STORAGE_SPACE_EVENT
  • ENTER_CRITICAL_STORAGE_SPACE_EVENT
  • EXIT_CRITICAL_STORAGE_SPACE_EVENT
  • ENTER_EMERGENCY_STORAGE_SPACE_EVENT
  • EXIT_EMERGENCY_STORAGE_SPACE_EVENT

イベント サブスクリプション API を利用すれば、クライアントはこれらのイベント通知をサブスクライブし、サブスクリプションを確認し、サブスクリプションを解除できます。 サブスクリプション要求に対する MediaSense の応答には識別子(subscriptionId)が含まれています。この識別子に基づき、クライアントは後に(サブスクリプションの有無を確認する目的で)このサブスクリプションを参照できます。

tagEvents パラメータには tagName パラメータ(タグの簡単な説明)が常に付属します。 tagEvents をサブスクライブしているクライアントは、付加的に、tagNameRegEx と呼ばれる Java 正規表現ベースのパラメータを指定することがあります。このパラメータを指定すると、必要なタグをさらに選択できます。 クライアントが tagEvents をサブスクライブしていない場合、tagNameRegEx パラメータには効果がありません。 Java 正規表現の詳細情報については、http:/​/​download.oracle.com/​javase/​tutorial/​essential/​regex/​ を参照してください。

イベント通知を受信するようにアプリケーションを登録すると、あらゆる種類のイベント通知を受信します(sessionEvent、tagEvent、storageThresholdEvent、その他のイベントなど)。 MediaSense には、イベントのサブセットの通知を受信するためのオプションがあります。 subscribeToEvents API を使用し、録音が開始または終了したとき、録音データが更新されたとき、録音にタグを追加するとき、録音からタグを削除するときにイベント通知を受信します。

すべてのイベント、特定のカテゴリのイベント、特定の種類のイベントをサブスクライブできます。

MediaSense サブスクリプションは subscriptionUri パラメータに基づきます。 特定の subscriptionUri に対してサブスクリプションが 1 件だけ許可されます。 subscriptionUri が一意の場合、MediaSense はそのサブスクリプションを個別のサブスクライブ要求として扱います。

MediaSense はサーバ ベースのクライアントの HTTP を使用して非同期イベントの通知をサポートします。

MediaSense API は 2 台のメイン サーバ(プライマリとセカンダリ)を持つことができますが、クライアント アプリケーションは両方のサーバをサブスクライブする必要はありません。 アプリケーションは両方のメイン サーバ(サブスクライブしているサーバとサブスクライブしていないサーバ)で生成されたイベントを受信します。 このような場合、イベントの FORWARDED_EVENT フィールドが TRUE に設定されます。

ただし、MediaSense 管理は、MediaSense クラスタ内のプライマリ サーバとセカンダリ サーバ間のイベント転送を有効または無効にするクラスタ全体のプロパティを提供します。 デフォルトでは、転送は Cisco MediaSense 展開で無効になっています。この機能を明示的に有効にして、すべてのイベントの通知を受信する必要があります。 この機能を有効にすると、両方のサーバで生成されたイベントを受信します。2 つのサーバのそれぞれを明示的にサブスクライブする必要はありません。

イベント転送を有効にする場合、プライマリまたはセカンダリ サーバだけをサブスクライブし、両方のサーバのイベント通知受信を開始します。


(注)  


MediaSense クラスタのプライマリ サーバとセカンダリ サーバ間のイベント転送を有効にするには、Cisco MediaSense のユーザ ガイドに記載されている手順に従ってください。


MediaSense API サービスは最新の storageThresholdEvent をバッファします。 これらのバッファされたイベントは、サブスクリプション時に、他のメイン サーバで新しくサブスクライブした API クライアントまたは MediaSense API サービスに送信されます。

このカテゴリの使用可能な API の一覧については、「イベント サブスクリプション」を参照してください。

セッションのプルーニングと削除

状況によっては、MediaSense で自動的に古い記録をプルーニングして、新しい記録に必要な容量を解放できます。 セッションをプルーニングすると、そのセッションに関連付けられたメタデータはデータベースに残りますが、「プルーニング済み」とマークされます。このメタデータは記録そのものに比べるとそれほど大きいストレージ容量を占めませんが、ある程度は消費するので、定期的にクリーンアップしないと長期的には無限に増加します。 これらのプルーニング済み記録は不要なオーバーヘッドも生じさせます。たとえば、データベースと API クライアントの両方における、リソースのデータ ソート、検索、フィルタリングなどです。 そのような記録は、不要になったら削除してください。

変換済みの .mp4 や .wav ファイルは、プルーニング プロセスでは自動的に削除されません。 クライアントは、長期ストレージにオフロードされた後、またはそれらの保存が不要になったときに削除する必要があります。

両方のアクティビティを支援するため、クライアントはプルーニング済みセッション(getAllPrunedSessions)の API 要求を定期的に発行したり、セッションによってプルーニングされたイベントを受信するようにして、不要なセッションを明示的に削除できます。

詳細については「セッションのプルーニングと削除の違い(What is the difference between Pruned and Deleted sessions?)」 (Cisco MediaSense Web サイトの FAQ に記載)を参照してください。

認証のための API Inter-Dependencies

MediaSense API はすべてのセッションを維持するために JSESSIONID を使用しています。そのため、(認証を必要とする)他の API を使用できるようにするには、事前にユーザを認証するために JSESSIONID が必要です。

JSESSIONID を取得するために MediaSense SignIn API を使用します。 SignIn API からの応答は次のようになります。

Header Name: Set-Cookie
Header Value: JSESSIONID=SomeRandomAlphaNumericString

認証が必要な MediaSense API を使用するたびに、SignIn API から返された JSESSIONID の値にヘッダーを設定する必要があります。

cookie の設定に関する詳細については、http:/​/​en.wikipedia.org/​wiki/​HTTP_​cookie を参照してください。

JSESSIONID は、ユーザがログアウトしたときか、または非アクティブになってから 30 分後(いずれか早いほう)に期限切れになります。

ポスター

すべての MediaSense API は、URI によるアクセスが可能で、要求応答パラダイムに従います。 ポスターは、Web サービスおよび Web リソースと連携する Firefox のアドオンです。これにより、Web サービスとやり取りし、結果を調べます。

ポスターを Firefox に追加する方法:

  • MediaSense API ユーザを設定します(有効なユーザ名とパスワードを使用)。

  • Firefox からポスター アドオンをダウンロードします。 https:/​/​addons.mozilla.org/​en-US/​firefox/​addon/​2691/​ から無料でダウンロードできます。

  • Firefox にポスターを追加したら、Ctrl + Alt + P を押して起動します。

ポスターの API をテストする方法:

  • この開発者ガイドからテキスト エディタに API 要求の URI をコピー アンド ペーストします。 たとえば、サインインの URI を入力するには、signIn API から URI をコピーします。

  • 貼り付けたコードの大文字と小文字の区別や形式を調べ、キャリッジ リターンをすべて削除します。

  • MediaSense サーバの IP アドレスとポートを使用して URI を更新します。

  • 要求の必須パラメータを追加します。

  • コンテンツ タイプ ヘッダーに適切な値を設定します。

  • 適切なアクションをクリックします(GET または POST)。

ポスターを使用した Cisco MediaSense API 要求

ポスターを使用した Cisco MediaSense API 応答ステータス