2021 年 6 月 23 日 (水) に WebRTC SFU Sora 2021.1 をリリース予定です。より繋がり続ける仕組みと、よりクライアントとサーバに優しくなる仕組みの二つを追加しています。この二つの仕組みを紹介していきます。
要約
- 繋がり続ける
- パケット量が減る
- 独自機能
より繋がり続ける仕組み
Sora は今までシグナリングのやりとりに WebSocket を利用してきました。実際、ほとんどの WebRTC SFU が WebSocket を利用しています。ただ、WebSocket は「一度詰まるとリカバーが難しい」という問題があります。
シグナリングはサーバからのプッシュ通知が必須なため、WebSocket のような仕組みを採用せざるを得ません。ただ、もう WebSocket に依存するのは良い製品と言えなくなってきています。
不安定な回線では先に WebSocket が詰まる
音声や映像は詰まりにくいため、WebSocket が先に詰まってしまいます。そのため、シグナリングのやりとりや通知などが送れない状態になってしまうためです。
WebSocket はかなり詰まります。実際お客様から頂くログでも WebSocket が詰まってしまっているログが多く見られました。思った以上にインターネットというのは不安定だということです。
WebSocket から DataChannel への切り替え
そこで今回 Sora 2021.1 では最初の接続だけを WebSocket を利用し、その後は DataChannel を利用する事で、詰まることを減らし、つながり続けやすくするという仕組みを導入しました。
実際検証したところ、パケロス 40% でも運が悪くない限りはつながり続けました。WebSocket ちょっとした不安定なネットワークで詰まってしまい timeout になります。
DataChannel に切り替えた効果は色々な場面で発揮されていくと思います。
以下は Sora 搭載してあるデモ機能のデバッグタイムラインを表示したモノです。WebSocket で接続を開始してから、DataChannel に切り替わるまで、250 ミリ秒しかかかっていません。
over TURN なので TCP も TLS も利用可能
DataChannel は UDP ベースではありますが、WebRTC の仕組みに組み込まれているため、TURN を利用できます。そのため TURN-TCP や TURN-TLS が利用できるため、UDP が繋がらないところでも安心です。
WebSocket から DataChannel に切り替えたから繋がりにくくなるということはありません。
WebRTC SFU に合わせた DataChannel 実装
時雨堂ではこのために DataChannel の実装を 1 から書き起こしています。usrsctp といったライブラリは一切利用していません。そのため必要最低限の実装にしてメンテナンスコストも減らしています。
さらに DataChannel は P2P を想定しているため、かなり自由がきく仕組みなのですが、それをプロトコルスタックレベルで WebRTC SFU に合わせています。クライアント側から自由に操作できないような仕組みです。
WebRTC SFU を利用する場合は「サーバ主導」であるべきだと考えているので、DataChannel の利用も同じようにサーバ主導で実装しています。
DataChannel を活用したリアルタイムメッセージング
今回は今まで WebSocket を利用していた部分を DataChannel に置き換えましたが、2021 年 12 月にリリース予定の Sora では、メッセージング機能を追加予定です。
これは DataChannel に切り替えた場合、クライアントからクライアントへリアルタイムにメッセージを送れるようにする仕組みです。
Sora では今まで音声や映像のみに対応してきましたが、それとは別にメッセージングにも積極的に対応していく予定です。
クライアントと Sora に優しい仕組み
Sora は WebRTC の機能を組み合わせたスポットライト機能という仕組みを持っています。この仕組みは「話をしている人」にスポットライトでフォーカスするというイメージから来ています。
機能としてはとてもシンプルで、話をしている人は「高画質＋音声あり」話をしていない人は「低画質＋音声なし」という仕組みです。
パケット量を減らす
そもそもなぜ優しいのかというと、Sora からのパケットを減らすというのを積極的に行っているからです。パケット量を減らすということは Sora 側の暗号化する負荷もさがります、クライアント側の受信するパケットが減り、復号する負荷も下がり、さらに音声や映像をデコードする負荷も下がります。
とにかくパケット量を減らすというのは一番効率がよいということになります。ただパケット量を減らすだけでは実際に利用していて「音が聞こえにくい」「映像が見づらい」など発生してしまいます。そのため「快適に使える」と「パケット量を減らす」を同時に成り立たせる仕組みが必要になります。
それが Sora が持つスポットライト機能です。
スポットライト機能
スポットライト機能は前述したとおり「話をしている人」にフォーカスを当てる仕組みです。話しをしていない人の音声は送らず、映像は画質を下げることでパケットを減らします。
ただ、この場合だとフォーカスされていないと音声が配信されないため、会話に違和感を感じてしまいます。
そのため、違和感を減らす仕組みを追加しました。それが遅延フォーカスとフォーカスなし音声配信機能です。
遅延フォーカス機能
遅延フォーカスは名前の通りフォーカスされるタイミングを少し遅くする仕組みです。
この機能を有効にすることで、うなずきは物音などでフォーカスされなくなります。そのため映像が高画質切り替えを減らすことができます。
フォーカスなし音声配信機能
フォーカスなし音声配信機能は「フォーカスされていない状態でも音声を配信する」機能です。この機能と遅延フォーカス機能を利用することで、フォーカスされていない状態でも音声を届けることができます。
この二つの機能のおかげでスポットライトの数を減らしても会話に違和感がなくなりました。スポットライトの数を減らせるということはパケットを減らせるということになります。
実際これらの機能を有効にした状態で、5 名で話しをしていてもスポットライトは1 つあれば十分過ぎるほどです。フォーカスなし音声配信機能を利用することで音声が途切れたりすることはありません。
自動アンフォーカス機能
さらに「一定時間話しをしていないとフォーカスが外れる」自動アンフォーカス機能を追加しています。
これはスポットライト数が 1 より大きい場合に効果的です。一人しか話しをしていないときにフォーカスを減らして、パケットを減らすことができます。
フォーカスなし音声配信 -> 遅延フォーカス -> 自動アンフォーカスの例
実際の例です。動画にしてあります。スクリーンショットで解説していきます。紺色に注目してください。右のバーが音量バーです。
https://i.gyazo.com/4ccc7bd2cea16fa45c6439763589cd74.mp4
まだ音声なしの状態なのでフォーカスも当たっておらず音量バーもありません。
音声ありになりました。アンフォーカス時の音声配信機能により音声は配信されていますが、遅延フォーカス機能の影響でフォーカスは当たっていません。
一定時間経過してフォーカスされました。解像度が QQVGA から VGA に、フレームレートが 5 から 30 に変わっています。
音声がなくなりましたが、まだフォーカスされています。
音声がなくなり、一定時間経過したのでアンフォーカスされました。
今回はわかりやすく解像度を変えていますが、実際は全員同じ解像度になるので、フォーカスが当たっていない場合は画質が荒くなります。
すべての処理を Sora で行っている
このスポットライト機能ですが、すべての処理を Sora で判断を行っているため、クライアントは特に何かする必要はありません。
そのため、組み込むことも特に難しくありません。普通の多人数で話をする仕組みを簡単に置き換えることができます。
WebRTC SFU メーカーだからこそできる
今回紹介した二つの機能は RFC で決められている仕組みではなく、時雨堂が独自に追加した機能です。WebRTC SFU を自前で 1 から開発しているからこそ実現できた機能です。
今後も WebRTC の仕組みを使い、より使いやすく、導入しやすい WebRTC SFU を提供していきます。
