5. ライブ配信・視聴サービス
【ライブサービス機能仕様】
-
投銭機能:
-
視聴者が配信者へ直接的なサポートを示せる新たな収益源となる機能。
-
利便性とエンゲージメントを高める。
-
-
顔加工フィルター・美顔機能:
-
ユーザーの顔を自然に美化する機能。
-
よりプロフェッショナルなビジュアル体験を提供。
-
-
カスタム壁紙:
-
配信者が背景を自分好みにカスタマイズ可能な機能。
-
視覚的な体験を一段と豊かにする。
-
-
管理者モニタリング機能:
-
ライブ配信の全過程を管理、追跡、モニタリングできる機能。
-
信頼性と安全性を向上させる。
-
-
サイマルキャスト(同時配信)機能:
-
一つのライブ配信を複数のプラットフォームやデバイスに同時に配信可能な機能。
-
視聴者の範囲を広げ、アクセシビリティを向上。
-
-
有料配信管理機能:
-
ユーザーが有料のライブ配信を簡単に管理できる機能。
-
収益化の機会を増やし、事前課金またはPPV(視聴者が特定の配信を見るために支払う)モデルをサポート。
-
これらの各機能は、ライブパフォーマンス、オンラインセミナー、教育・研修などあらゆる種類のライブ配信に活用可能です。
最適な視聴体験を提供し、強化された視聴者エンゲージメントを実現します。
第5章では上記の機能をサーバ連携を介して上記機能を利用するためのAPIに関して記載されています。
5.1. ライブサービスリクエスト概要
ライブサービスの要求は既定のクラスをJSONにシリアライズし、さらにそのシリアライズテキストをURLエンコードしたものをPOSTにより連携先サーバに要求する。尚、C#によるクラス定義のサンプルは
https://dl.stream-works.biz/download/sample/LinkSite.txt 及び
https://dl.stream-works.biz/download/sample/LinkLiveService.txt を参照のこと。
リクエストは以下の形式で実行される。
https://test.com/liveService?siteKey= test.key
「https://test.com/liveService」は設定仕様書に基づくURLとなる。
Query文字列siteKeyは連携先システムでPOSTデータのパース前に、要求の事前承認を行うために使用する。また要求の本体はPOSTされるので、連携先システムの使用するシステムに合わせて取得を行う。
5.1.1. ライブサービス要求クラス概要
① クラス階層図
➁ クラス用途概要
5.1.2. ライブサービスリクエスト一覧
以下のリクエストがNexmileサーバから連携先サーバにリクエストされる。連携先サーバは全ての要求に対してレスポンスを
生成する必要がある。
但し表中の応答コード有効が「ー」のリクエストについては、Nexmileサーバ側でレスポンスを参照した実装は存在しない
ため、HTTPステータス200応答のみとする。
仮にレスポンスを生成した場合には不要なトラフィックが発生しているため考慮する必要がある。
表中の応答コード有効が「〇」のリクエストについては3.3.1連携先サーバレスポンス方法①または➁によりレスポンスを
生成する必要がある。
レスポンスの「result」が0以外の場合、リクエストは拒否されたとして、Nexmileサーバにより
Nexmileクライアントに向けてレスポンスが生成される。
Nexmileクライアントは連携先サーバが設定したメッセージを表示しリクエストを終了する。
① リクエスト一覧
※網掛け部について 1.2.4 Nexmileクライアントでは未実装の機能を参照
➁レスポンスタイムアウトと再送
4.2.2 ①と同様
5.3 ライブサービスリクエスト詳細
5.3.1. 配信準備
アプリリンクにより配信開始を選択した時点で発生するリクエスト。
① リクエスト
➁ レスポンス
③ コールオプション設定値
liveService
※網掛け部について 1.2.4 Nexmileクライアントでは未実装の機能を参照
4.3.2. 架電開始
Nexmileクライアントが架電を開始した時点(Nexmileサーバへ通信を開始した時点)での発生するリクエスト。
連携先システムにより通話を許可または不許可であることを判断する最終リクエストとなる。
通話の許可または不許可は架電準備リクエストへのレスポンスで行うことが望ましいが、連携先システム側の仕様により、
架電開始以降に切断したい場合に使用する。
① リクエスト
callServiceTpを除き、架電準備リクエストと同様
但し、calleeに下記の情報が補完されたリクエストとなる。
➁ レスポンス
3.3.1連携先サーバレスポンス方法に従う。
「resultのみをレスポンスとする場合」、「リクエストに対して拒否応答である場合」を参照
4.3.3. 呼出開始
受電側が公衆網の場合は、受電側が呼出しの鳴動開始した時点でのリクエスト。
受電側がアプリの場合は、受話のボタンを押下した時点でのリクエスト。
アプリの場合は「4.3.4通話接続」と近傍で発生するため、連携先システムが公衆回線を用いない場合はこの要求に対して
特段の処理は不要である。
① リクエスト
callServiceTpを除き、架電準備リクエストと同様
➁ レスポンス
HTTP STATUS応答のみ
4.3.4. 通話接続
通話が成立した時点でのリクエスト。
① リクエスト
callServiceTpを除き、架電準備リクエストと同様
➁ レスポンス
HTTP STATUS応答のみ
4.3.5. 通話接続
通話終了・話中・未応答等により通話サービスが終了した時点でのリクエス。
① リクエスト通話
概況情報が付加される。その他はcallServiceTpを除き、架電開始リクエストと同様
callOverview
通話切断理由コード一覧
➁ レスポンス
HTTP STATUS応答のみ
③ talkingSecの再計算
Nexmileサーバ内では全ての時刻がミリセカンド単位で保持されている。秒単位での通話時間を算出する際に
500msでの四捨五入が発生する。インターフェースのために秒表記に変更されたterminateTimeからconnectTimeを
減算した結果と最大1秒の差異が発生する。
連携先システムが秒単位の精度により切上げや切捨ての処理を行う必要がある場合にはterminateTime、connectTimeを
日付型として再度通話時間を計算する必要がある。