top of page

4. コールサービス

【コールサービス機能仕様】

  1. 顔加工フィルター・美顔機能:

    • ユーザーの顔を自然に美化する機能。

    • よりプロフェッショナルなビデオ通話体験を提供。

  2. カスタム壁紙機能:

    • ユーザーが背景を自分好みにカスタマイズ可能な機能。

    • 視覚的な体験を一段と豊かにする。

  3. 有料通話管理機能:

    • ユーザーが有料通話を簡単に管理できる機能。

    • 収益化の機会を最大化し、適切な料金設定と収益追跡を可能にする。

  4. オートチャージ機能:

    • 自動的に通話クレジットを補充する機能。

    • 通話が中断されることなく、円滑なコミュニケーションを維持する。

 

これらの機能は、通話体験を最適化するため組み合わせて使用され、主要なコミュニケーションの品質と利便性を向上させます。

第4章では上記の機能をサーバ連携を介して上記機能を利用するためのAPIに関して記載されています。


4.1. コールサービスリクエスト概要

コールサービスの要求は既定のクラスをJSONにシリアライズし、さらにそのシリアライズテキストをURLエンコードしたものをPOSTにより連携先サーバに要求する。尚、C#によるクラス定義のサンプルは

https://dl.stream-works.biz/download/sample/LinkSite.txt 及び

https://dl.stream-works.biz/download/sample/LinkCallService.txt を参照のこと。


リクエストは以下の形式で実行される。

https://test.com/CallService?siteKey= test.key

https://test.com/CallService」はI/F設定仕様書に基づくURLとなる。

Query文字列siteKeyは連携先システムでPOSTデータのパース前に、要求の事前承認を行うために使用する。また要求の本体はPOSTされるので、連携先システムの使用するシステムに合わせて取得を行う。

4.1.1. コールサービス要求クラス概要

① クラス階層図

コールクラス階層図

➁ クラス用途概要

4.1.2. コールサービスリクエスト一覧

以下のリクエストがNexmileサーバから連携先サーバにリクエストされる。
連携先サーバは全ての要求に対してレスポンスを生成する必要がある。

但し、表中の応答コード有効が「ー」のリクエストについては、Nexmileサーバ側でレスポンスを

参照した実装は存在しないため、HTTPステータス200応答のみとする。

仮にレスポンスを生成した場合には不要なトラフィックが発生しているため考慮する必要がある。

表中の応答コード有効が「〇」のリクエストについては3.3.1連携先サーバレスポンス方法①または➁により

レスポンスを生成する必要がある。

レスポンスの「result」が0以外の場合、リクエストは拒否されたとして、Nexmileサーバにより

Nexmileクライアントに向けてレスポンスが生成される。

Nexmileクライアントは連携先サーバが設定したメッセージを表示しリクエストを終了する。

① リクエスト一覧

➁レスポンスタイムアウトと再送

各リクエストに対するレスポンスタイムアウトはシステム標準で8秒間に設定されている。

レスポンスタイムアウトの場合、Nexmileクライアントは処理を終了し、タイムアウトしたことをユーザに表示する。

通話終了リクエストに関しては再送に対応しており、

タイムアウト後も一定の間隔で200OK応答を受信するまで再送を行う。

再送は1、2、4、8、16、32、64,以降128秒毎に実行され、6時間を経過した時点で破棄される。

4.2 シーケンス図

4.2.1. 荷電開始から終話までのシーケンス

架電シーケンス図1
架電シーケンス図2

4.2.2. 入電開始から終話までのシーケンス

入電シーケンス図1
入電シーケンス図2

4.3 コールサービスリクエスト詳細

4.3.1. 架電準備

​① リクエスト

caller

callee

​➁ レスポンス

callService

​③ コールオプション設定値

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を

日付型として再度通話時間を計算する必要がある。

bottom of page