シェア:
){kind=small}
エンリコはVonageの元チームメンバーです。ソリューション・エンジニアとして、技術的な専門知識で営業チームをサポートした。 クラウド、スタートアップ、新技術に情熱を注ぐ。イタリアのWebRTCスタートアップの共同設立者。仕事以外では、旅行とできるだけ多くの奇妙な食べ物を味わうのが好き。
ビデオAPIとセッション監視を使用したユーザー接続の追跡
所要時間：1 分
ここ数年、ユーザーがチケットを購入し、ブラウザからイベントやコンサート、講師とのプライベートレッスンに参加するオンラインイベントプラットフォームが驚くほど増加しています。これらのプラットフォームは、許可されたユーザーだけがイベントやレッスンに参加できるようにする必要があり、ユーザーが特定のセッションに接続している時間を細かく制御する必要があります。これを実装する最善の方法は、リアルタイムのウェブフックの形で、セッションに公開された接続とストリームをアプリケーションサーバーに通知するメカニズムを持つことです。
セッション監視は、Vonage Video API アプリケーションの接続を監視する信頼性の高い安全な方法を提供します。セッション監視を追加することで、開発者はサーバサイドからクライアントのアクティビティを監視し、ビデオセッションへの各接続を検証し、コンプライアンス上の理由から各アクションをログに記録することができます。
セッション・モニタリングWebhooksを使用することで、開発者はリアルタイムでセッション・イベント・コールバックを受信し、アプリ・サーバーからセッションのアクティビティを監視することができます。OpenTok インフラストラクチャは、すべての接続の作成 (および破棄) とストリームの作成 (および破棄) に対して HTTP リクエストを送信できます。
利用可能なイベントの内訳を見てみよう：
connectionCreated: クライアントがセッションに接続したときに発生connectionDestroyedクライアントがセッションから切断されたときに発生します。streamCreatedクライアントがストリームをセッションに発行したときに発生します。streamDestroyed: クライアントがセッションからストリームをアンパブリッシュしたときに発生します。
各イベントにはペイロードがある。例として connectionCreatedイベントを分析してみよう：
{
"sessionId": "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
"projectId": "123456",
"event": "connectionCreated",
"timestamp": 1470257688309,
"connection": {
"id": "c053fcc8-c681-41d5-8ec2-7a9e1434a21e",
"createdAt": 1470257688143,
"data": "TOKENDATA"
}
}イベントペイロードには、プラットフォームが必要とするビジネスロジックを作成するために使用できるデータが含まれている。例えば connectionIdと timestampを使って特定のユーザーの接続時間を計算することができる。次のセクションでは、より詳細な例について説明します。
生徒が教師との1時間のレッスンにお金を払う教育サイトがあるとします。時間経過後、ユーザはセッションから切断される必要があります。セッションモニタリングを使って、どのようにこれを実装できますか?
このユースケースでは connectionCreatedそして connectionDestroyedイベントをリッスンする必要がある。ロジックは次のようになる：
接続数が2以上の場合のみセッションタイマーを開始する。
経過時間を5秒ごとにチェックする
時間切れになったら、強制的にユーザーを切断する。
コードを見てみよう：
app.post('/session-monitoring', async (req, res) => {
const { sessionId, projectId, event, timestamp, connection } = req.body;
const roomName = sessions[sessionId];
switch (event) {
case "connectionCreated":
// There are at least 2 users
if (session.connections && session.connections.length > 1) {
session.interval = setInterval(() => {
const now = new Date().getTime();
session.connections.sort((x, y) => { return y.timestamp - x.timestamp }) // Make sure they are ordered by latest connections;
if ((now - session.connections[0].timestamp) > limitedTimeRoomMinutes * 60 * 1000) {
// time has expired, let's disconnect them
for (let i = 0; i < session.connections.length; i += 1) {
opentok.forceDisconnect(sessionId, session.connections[i].connection.id);
}
clearInterval(session.interval)
}
}, roomInterval.intervalValue)
}
break;
case "connectionDestroyed":
break;
case "streamCreated":
break;
case "streamDestroyed":
break;
default:
console.warn("Not handled case, this should not happen");
})
例えば、セッションのサイズを1対1に制限したいとしよう。もし他の人が接続したら、コードはその人を追い出してしまう。コードを見てみよう：
switch (event) {
case "connectionCreated":
session.connections = [...session.connections, { connection, timestamp }];
break;
case "connectionDestroyed":
if (session && session.connections) {
for (let i = 0; i < session.connections.length; i += 1) {
if (session.connections[i].connection.id === connection.id) {
session.connections.splice(i, 1);
break;
}
}
}
break;
}
if (session.connections && session.connections.length > 2) {
opentok.forceDisconnect(sessionId, connection.id);
}
この場合、コードはセッション内の接続数を追跡している。もし接続数が2より多ければ、接続しようとしたユーザーを切断する。このアプローチに従うと、3番目の接続は数秒間接続することができ、サーバーが connectionCreatedフックを受け取ると、ユーザは追い出される。この動作を改善するために、3番目のユーザーをセッションに接続させないようにすることも可能である。3人目のユーザーが参加するために認証情報を要求するとき、サーバーはセッションの接続数をチェックすることができる。すでに2つの接続がある場合、サーバーは3番目のユーザーに認証情報を送信せず、エラーメッセージを表示します：
app.get('/room/:room', (req, res) => {
const roomName = req.params.room;
if (sessions[roomName]) {
if (sessions[roomName].connections.length >= 2) {
renderRoom(res, null,null,null, roomName);
} else {
const sessionId = sessions[roomName].sessionId;
const dataToken = opentok.generateToken(sessionId);
renderRoom(res, dataToken.apiKey, sessionId, dataToken.token, roomName);
}
} else {
setSessionDataAndRenderRoom(res, roomName);
}
});
セッション監視の2つの主な使用例を見てきましたが、許可されたユーザーのみがセッションに参加できるようにしたり、ユーザーが公開できるストリームの種類を制限したりするなど、他にも多くの使用例があります。
オンライン・イベントでは、承認されたユーザーだけがイベントに参加できるようにすることが重要です。例えば、チケット所有者だけが特定の会議に参加できます。イベント参加費を支払い、参加が許可されているユーザーのリストがあります。
セッションに参加するためのトークンを作成する際に メタデータ.メタデータは接続イベントウェブフックで利用できるようになります。この connectionCreatedイベントを受信すると、その接続が誰であるかをチェックし、データベース内の許可されたユーザーとデータを検証することができます。ユーザがセッションに参加する権限がない場合、サーバはそのユーザを強制的に切断します。
これまで、接続の作成と破棄のイベントの使い方しか見てきませんでしたので、ストリームの作成と破棄のイベントを活用する例を作ってみましょう。ストリーム・イベントには nameと videoTypeなどの追加データがあります。後者を使用すると、許可されたユーザーだけが画面を共有できるユースケースを実装できます。例えば、金融コンサルタント会社で、顧客ではなくファイナンシャル・アドバイザーのみが画面を共有できるようにしたい場合を考えてみましょう（機密情報の共有を避けるため）。サーバーが streamCreatedイベントを受け取ると videoTypeが画面であるかどうか、そしてユーザが画面の共有を許可されているかどうかをチェックすることができます。もしそうでなければ、セッションからストリームをアンパブリッシュすることができる。
セッション・イベントやアーカイブ・ステータスの更新情報はすべて、サーバー内の HTTP エンドポイントに登録できます。登録されたアクティビティが発生するたびに、OpenTok インフラストラクチャからエンドポイントに HTTP リクエストが発行されます。
コールバックを登録する：
Vonage Video API アカウントページにアクセス
コールバックを登録したい OpenTok プロジェクトを選択します。
セッション・モニタリング・セクションでコールバックURLを設定する。
非常に重要なこととして、30分以内に50回以上のイベント配信の失敗（コールバックURLにHTTPリクエストを送信した際に200の成功レスポンスを受け取らない）があった場合、セッション監視のイベント転送を無効にします。この場合、Eメールを送信します。
ビデオ ビデオAPIセッション監視のサンプル・アプリケーションは、上記の例のうちの2つを示しています：
locahost:5000/room/limited-time-roomのページで、セッション中のユーザーの接続時間を制限すると、サーバーは少なくとも2つの接続（2人のユーザー）があるときにタイマーを開始します。タイマーは5秒ごとにセッションの残り時間をチェックします。時間切れになると、サーバーはセッションからユーザーを強制的に切断します。 forceDisconnect関数を使用してセッションからユーザーを強制的に切断します。
セッションのサイズを制限する。
locahost:5000/room/one-to-oneこのページでは、サーバーは2人のユーザー(コネクション)だけにルームへの接続を許可します。もし3つ目の接続があった場合、サーバーは即座にその接続を切断します。
セッションモニタリングは、ビデオアプリケーションにセキュリティを追加し、サーバーサイドのチェックを実装するためのスイスナイフのような機能です。このブログ記事で説明されている例のいくつかを実際に見るには、Github リポジトリをご覧ください： https://github.com/nexmo-se/video-api-session-monitoring.このブログ記事では、セッション監視ウェブフックを使って実装された使用例をいくつか紹介します。サーバーサイドに接続とストリームに関するデータを持つことで、開発者はリアルタイムでイベントを監視、保存、反応する柔軟性を得ることができます。
この機能を試された方で、ご質問のある方は、ぜひ私たちの VonageコミュニティSlackにご参加いただくか ツイッター.