• スポンサードリンク

WebRTCのオフィシャルプレビルドライブラリを使うサンプルを公開した(後編)〜janus-gatewayへ繋ぐのじゃ(パート2)〜

Android WebRTC アプリ

公式ドキュメントとか

janus-gatewayの公式ドキュメントはここにあります。目次的なのは無いこともなくは無いけど基本文章中に散りばめられたリンクを踏んづけると説明が出てくるだけなのでちょっと見にくいかなぁ(。・_・。)
REST風API関係はここ

または各プラグインのソースコードの先頭に説明が入っています。例えばn:nの複数でのビデオチャットのvideoroomプラグインはこれ。なお今回作ったのはvideoroomプラグインのみの対応です。

基本は公式ドキュメント通りですが、返ってくる内容とかタイミングとかドキュメントに書いていないこともいっぱいありました。

janus-gatewayとの接続手順の概要なのだ

  1. ルートurlへアクセスしてサーバー情報を取得する。
    これは必須ではないけど接続確認も兼ねて呼び出しておこう。
  2. ルートurlへアクセスしてセッションを作成する。
    セッションIDが返ってくるので以降の処理はこのセッションIDを使って行う。
  3. long pollでサーバーからの応答を待機する。これ大事🌟
    janus-gatewayのAPIではPOST/GETに対するレスポンスとして直ぐに処理結果が返ってくるものと、POST/GETした時点では単に受け付けましたというACKが返ってくるだけで実際の応答はlong pollで返すものの2種類があるのだ。
  4. セッションIDを使ってvideoroomプラグインにattachする。
    この時はpublisherとしてのattach=音声(+必要であれば映像)を送るための接続(SendOnly)を行う。attachが成功するとプラグインへアクセスするためのプラグインID(プラグインハンドル)が返ってくる。以降のpublisherとしての処理は先程のセッションIDとプラグインID(プラグインハンドル)を使って行う。なお、attachの結果は即座に返ってくる。
  5. セッションIDとプラグインID(プラグインハンドル)を使ってビデオチャットルームにjoinする。
    join要求に対する応答はACKで、実際のjoin処理結果はlong pollで返ってくる。
  6. long pollでjoin結果が返ってくると、その中に他のpublisherに関する情報がある。
  7. 他のpublisherが既にjoinしていればそのpublisherに対してsubscribe=音声(+映像)を受け取るための接続を行う。するとそのパブリッシャーからの音声(+映像)を受け取ることができるようになる。
  8. 自分がjoinしたあとで同じビデオチャットルームへ他のパブリッシャーがjoinすると、そのたびにlong pollでパブリッシャー更新の通知がくるので必要に応じてsubscribeする
  9. 自分がjoinしている間に他のパブリッシャーがvideoroomプラグインからdetachすると、leaveイベントが届くのでsubscriberを解除する
  10. ビデオチャットを終了するにはvideoroomからdetachする(^.^)/~~~

でな感じなのでアール。酔っているのでアール🍻

大事なこと

janus-gatewayと接続を行う上で大事なこと・気を付けないといけないことががいくつか有ります。

  • シッポはケモミミより素晴らしい😍
  • サーバー側でのlong pollのタイムアウトはデフォルトでは30秒で、30秒間新たなイベントが発生しない場合にはkeepliveイベントを送ってくる
  • 通常のPOST/GETリクエストとlong pollはタイムアウト時間が異なるので、別々のOkHttpClientインスタンスを生成した方がよい。ただしOkHttpClientインスタンスはシングルトンにすべきらしいので、初回はOkHttpClient#Builderを使って生成したBuilderインスタンスから生成、2回目以降は初回のOkHttpClientインスタンスからOkHttpClient#newBuilderメソッドを呼び出して生成したBuilderインスタンスから生成する。
  • POST/GETリクエスト時にはどのリクエストに対するレスポンスかを区別するためのtransactionと呼んでいる任意のid文字列を送信する必要がある。リクエスト時に送ったtransactionは(即応またはlong pollで)レスポンスが返ってくる時のレスポンスボディに含まれて返ってくる。transactionは一意に区別可能な文字列であればなんでも良い(ランダムuuidの文字列表現や乱数で生成した文字列などを使う)
  • リモート側で他のパブリッシャーがルームにjoinした時あるいはleaveした時にはlong pollでイベント通知が来るが、このときにはtransactionフィールドは存在しない。代わりにpublisherとしてattachした時に受け取ったプラグインIDがsenderフィールドに設定されてく送られてくる
  • 通常のp2pでの接続であれば一回のシグナリングで音声(+映像)の双方向のPeerConnectionを張ることができるのに対し、janus-gatewayを経由する場合には、まずjanus-gatewayに対して送信専用(SendOnly)のPeerConnectionを張る(パpublisher)。次いでリモートの他のパブリッシャー毎にsubscriberとして受信専用(RecvOnly)のPeerConnectionを張る。つまり、送信用としてPeerConnectionが1つとリモートユーザー(他のパブリッシャー)毎に1つの合計1+nのPeerConnectionを張る必要がある。

普通にRESTFulなAPIへOkHttp3+Retrofit2でアクセスする場合にはレスポンスのフォーマットがある程度絞り込まれていて、想定されるレスポンスに対するPOJOオブジェクトに変換して受け取ることが多いと思う(というかそこまでが自動的に処理されるからこそOkHttp3+Retrofit2を使うメリットがあると思う)。

janus-gatewayのREST風なAPIへのアクセスにおいても、即応でレスポンスが返ってくるAPIについては同じように扱うことができるのであるが、問題はlong poll(。・_・。)long pollで受け取るレスポンスである。long pollで返ってくるレスポンスはその内容に応じて様々にフォーマットが変化するのでアール😨。つまりlong pollの結果を直接POJOで受け取ってはいけない。普通にJSONとして受け取った上である程度仕分けしてからGSON等でPOJOに変換するほうがよいということであーる。

酔っているので文体が安定しなくてごめんm(__)m
続く…

« »

  • スポンサードリンク

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

%d人のブロガーが「いいね」をつけました。