WebRTC SFU Sora の今後
2021 年 6月版です。1 ヶ月前のをアップデートしていくという書き方をしていますので、先月と重複箇所が多くあります。
リリース
リリース方針
Sora は毎年 6 月と 12 月に大きめのリリースを行います。それ以外はバグ修正などがメインとなります。ただ実験的機能を中心としたリリースを行う事もあります。
2021 年 6 月リリース
2021 年 6 月 に 2021.1 のリリースしました。大きな機能は今のところ 1 つ位で、基本的には既存機能の改善です。
- スポットライト機能改善
- DataChannel 対応
- DataChannel シグナリング機能
2021 年 12 月リリース予定
2021 年 12 月に 2021.2 のリリースを予定しています。DataChannel のメッセージング機能に対応予定です。
- 統計情報ウェブフック機能
- DataChannel 部分信頼対応
- DataChannel 順不同対応
- DataChannel オーディオレベル通知機能
- DataChannel メッセージング機能
- 音声 RED 対応
- SDP 再利用
- AV1 録画
- CPU 負荷削減
今後のリリース予定機能
- AV1 / VP9 Simulcast 対応
- インターコネクト機能
- シグナリング WebTransport (HTTP/3) 対応
- シグナリング WebSocket (HTTP/2) 対応
開発版の提供
開発環境用ライセンスをご契約いただいているお客様向けに Sora の開発版を提供していきたいと考えています。
開発版の新しい機能を気軽に試してもらうことが目的です。まだどのように提供するか検討中です。
DataChannel メッセージング機能に対応した開発版を提供したいなと考えています。
インターコネクト機能
まだ検討段階ですが、Sora と Sora を接続できるような仕組みを用意しようと考えています。副産物として大規模配信がついてきます。
目的としては東京にある Sora とアメリカにある Sora をプライベートネットワークで繋ぐことで、近場の Sora に繋ぐという仕組みを導入していきたいと考えています。複数拠点に Sora を置きたいという要望がすでにあるためです。
スポットライト機能
スポットライト機能は Sora が独自に実装しているサイマルキャスト機能を活用した仕組みです。
最近ではさらにサービス毎に色々設定を変えられるように作り込んでいます。
パケット削減
WebRTC SFU の課題は「サーバで合成しないためクライアントへの負荷が高まる」という点です。時雨堂ではこの課題に対してスポットライト機能を提供して解決を図っています。
本来 WebRTC SFU は送られてきたパケットを転送するというのが目的のため、クライアントの負荷を削減するという事はできません。ただ、実際は全員のパケットを送る必要があるのかという疑問もあります。
これを Sora ではまず「直近で話をした N 人だけの音声と映像を転送する」という実装を行いました。ただ、これだと全員の顔が見えず、話をしている人だけしか映像が見えないという問題がありました。
そこで実装したのがサイマルキャストを活用し、複数画質を Sora に送って貰い、話している人は高画質、話をしていない人は低画質という機能を実現しました。これが現在のスポットライト機能です。
この機能を実装することでスポットライトでフォーカスされている人は高画質の映像と音声、フォーカスされていない人は低画質の映像のみを実現しました。これは全員の高画質の映像と音声を受け取っていた時よりかなりクライアントの負荷が下がります。
時雨堂ではこのスポットライト機能を軸に Sora を改善していきます。サーバ側でできる事はなんでもやるという方針です。
ちなみにサイマルキャストを採用することで、パケットが増えるのではないか？とお思いの方がいると思います。それは間違いありません。ただ多くのクラウドではクラウドへのインバウンドパケットは無料なことが多く、サイマルキャストを採用した事によりクラウドの転送費用が増加することは少ないと考えています。
CPU 負荷削減
スポットライト利用時にフォーカスされていない人が配信しているフォーカス用の映像は誰も見ないわけですから、復号する必要がありません。音声も誰にも配信されていなければ復号する必要がありません。
そこで誰にも配信されていない音声や映像を復号しないことで CPU 負荷を下げる仕組みを導入予定です。
チューニング
時雨堂ではスポットライト機能をさらに踏み込んでいくつかの機能追加しました。
- 一定期間話さない場合フォーカスが外れる機能（パケット削減対応）
- ちょっとした物音ではフォーカスが切り替わらないようにする遅延フォーカス機能（フォーカス奪い合い対応）
- 接続毎にフォーカス時とアンフォーカス時の受信画質を指定できる機能(モバイルで映像は不要だったり、全員高画質にしたいなどの環境対応）
- フォーカスからアンフォーカスに切り替わっても音声を配信し続けられる機能 (スポットライト数が少ない場合の奪い合い対応)
これらは全て設定で細かに指定可能です。これは「サービス毎に求められる内容が異なる」という考えからです。時雨堂では Sora をサービス毎にチューニングできるのはとても重要と考えています。
例えばローカル 5G を利用して特定の場所で 4K@30 の映像を 100 箇所に配信する場合と、企業と学生間の面接で利用する場合では、WebRTC という技術は同じですがそれ以外は大きく変わると思います。環境毎に細かいチューニングができる製品を目指します。
シグナリング
WebRTC のキモといっていいシグナリングですが、WebSocket をから、 DataChannel に切り替えるの仕組みを追加しました。最初だけは WebSocket を利用しますが、その後は DataChannel を利用します。
サーバからのプッシュを遅延なく実現する場合、WebSocket が詰まるという問題はどうしても解決が難しいため、DataChannel の採用に踏み切りました。
シグナリングの DataChannel への切り替え
WebSocket は、不安定な環境では Head of Line Blocking が発生してしまい詰まってしまうため、今後 push / notify / signaling / e2ee / stats などのサーバプッシュ系はすべて DataChannel を利用するという方針に切り替えていきます。DataChannel は over TURN で動作する事もあり、フォールバックも問題ありません。
WebSocket ベースも今後も残り続けますのでご安心ください。ユーザは SDK と Sora をアップデートするだけで動作します。
シグナリングを DataChannel へ切り替えるかはクライアント単位で選択可能です。
2021 年 6 月のリリースには実験的機能として導入しました。
default_data_channel_signaling = trueシグナリング切断条件を選択可能にする
現在 WebRTC SFU Sora では WebSocket の切断をシグナリング切断条件としています。ただ、WebSocket は詰まることがあり Ping/Pong がうまくいかなくなり意図しないタイムアウトでの切断が行われることがしばしばあります。
そのため WebSocket から DataChannel へシグナリングを切り替える仕組みを開発しています。ただ完全に DataChannel だけにした場合、切断検知がとても難しくなります。DataChannel は UDP 上に作られているため相手が切断を通知してくれない場合は相手への ping/pong のタイムアウトを待ってからしか気付く事ができないためです。早くても 5 秒、遅いと30 秒以上終了に気付くのが時間がかかります。
WebSocket の切断はシステム側で担保してくれるため、ブラウザをいきなり落としても検知してくれます。
つまり DataChannel の切断検知は会議など「退出」したことを重視する仕組みを採用する場合は向いていません。
それとは逆に Momo を使って一方向で配信する場合などは WebSocket の切断検知は必要がなく、DataChannel をつかって WebSocket が切断されるような不安定な回線でも繋がっているべきです。
そのため Sora では切断検知を Websocket の切断か、DataChannel の切断 (タイムアウト) かを選べるようにしました。
詳細は以下でまとめておりますので、興味がある方は是非。
DataChannel における切断検知
DataChannel は正常終了以外はうまい事、切断検知をしてくれません。そのため Sora では SCTP レイヤーで切断検知できる仕組みを追加しました。
SCTP に用意されているエンドポイント障害検知を組み込みました。SCTP レイヤーの Heartbeat / Heartbeat Ack を利用して、指定した回数応答がなければ、SCTP エンドポイント (ここでは Sora クライアント) で障害が起きていると判断しています。切断検知の値はカスタマイズできるようにしてあります。
DataChannel の統計機能
Sora の DataChannel 機能は何かライブラリを利用しているわけでは無く 1 から実装しています。そのためかなり細かい統計情報もとれるようになっています。
DataChannel の Label 単位での統計情報がとれます。
"data_channel": {
"e2ee": {
"total_received_data_channel_message": 1,
"total_received_data_channel_message_byte_size": 1,
"total_sent_data_channel_message": 1,
"total_sent_data_channel_message_byte_size": 16
},
"notify": {
"total_received_data_channel_message": 1,
"total_received_data_channel_message_byte_size": 1,
"total_sent_data_channel_message": 1,
"total_sent_data_channel_message_byte_size": 18
},
"push": {
"total_received_data_channel_message": 1,
"total_received_data_channel_message_byte_size": 1,
"total_sent_data_channel_message": 1,
"total_sent_data_channel_message_byte_size": 16
},
"signaling": {
"total_received_data_channel_message": 1,
"total_received_data_channel_message_byte_size": 1,
"total_sent_data_channel_message": 1,
"total_sent_data_channel_message_byte_size": 21
},
"stats": {
"total_received_data_channel_message": 1,
"total_received_data_channel_message_byte_size": 1,
"total_sent_data_channel_message": 1,
"total_sent_data_channel_message_byte_size": 17
}
},さらに DataChannel の下回りである SCTP に関してもかなり細かく統計情報をとれるようにしました。基本的に問題が起きたときの解析用ですが、パフォーマンスの改善などにも利用できればと考えています。
"sctp": {
"total_received_invalid_sctp": 0,
"total_received_sctp": 11,
"total_received_sctp_byte_size": 372,
"total_received_sctp_chunk_abort": 0,
"total_received_sctp_chunk_asconf": 0,
"total_received_sctp_chunk_asconf_ack": 0,
"total_received_sctp_chunk_auth": 0,
"total_received_sctp_chunk_cookie_ack": 0,
"total_received_sctp_chunk_cookie_echo": 1,
"total_received_sctp_chunk_cwr": 0,
"total_received_sctp_chunk_data": 5,
"total_received_sctp_chunk_ecne": 0,
"total_received_sctp_chunk_error": 0,
"total_received_sctp_chunk_forward_tsn": 0,
"total_received_sctp_chunk_heartbeat": 0,
"total_received_sctp_chunk_heartbeat_ack": 0,
"total_received_sctp_chunk_i_data": 0,
"total_received_sctp_chunk_i_forward_tsn": 0,
"total_received_sctp_chunk_init": 2,
"total_received_sctp_chunk_init_ack": 0,
"total_received_sctp_chunk_pad": 0,
"total_received_sctp_chunk_reconfig": 0,
"total_received_sctp_chunk_sack": 3,
"total_received_sctp_chunk_shutdown": 0,
"total_received_sctp_chunk_shutdown_ack": 0,
"total_received_sctp_chunk_shutdown_complete": 0,
"total_received_sctp_chunk_unknown": 0,
"total_received_unknown_sctp": 0,
"total_sent_sctp": 0,
"total_sent_sctp_byte_size": 0,
"total_sent_sctp_chunk_abort": 0,
"total_sent_sctp_chunk_asconf": 0,
"total_sent_sctp_chunk_asconf_ack": 0,
"total_sent_sctp_chunk_auth": 0,
"total_sent_sctp_chunk_cookie_ack": 0,
"total_sent_sctp_chunk_cookie_echo": 0,
"total_sent_sctp_chunk_cwr": 0,
"total_sent_sctp_chunk_data": 0,
"total_sent_sctp_chunk_ecne": 0,
"total_sent_sctp_chunk_error": 0,
"total_sent_sctp_chunk_forward_tsn": 0,
"total_sent_sctp_chunk_heartbeat": 0,
"total_sent_sctp_chunk_heartbeat_ack": 0,
"total_sent_sctp_chunk_i_data": 0,
"total_sent_sctp_chunk_i_forward_tsn": 0,
"total_sent_sctp_chunk_init": 0,
"total_sent_sctp_chunk_init_ack": 0,
"total_sent_sctp_chunk_pad": 0,
"total_sent_sctp_chunk_reconfig": 0,
"total_sent_sctp_chunk_sack": 0,
"total_sent_sctp_chunk_shutdown": 0,
"total_sent_sctp_chunk_shutdown_ack": 0,
"total_sent_sctp_chunk_shutdown_complete": 0,
"total_sent_sctp_chunk_unknown": 0
},WebRTC において細かい統計情報は取って損はありません。
デモ機能の DataChannel 対応
デモ機能にも DataChannel を利用する場合の機能を追加しました。
デバッグ画面には Timeline というタブを追加しました。
統計機能やデモ機能のデバッグ画面で DataChannel がどのように動いているかを確認することができるようになりました。
シグナリング経由での音量通知
ずっと要望を頂いていたものの、WebSocket 経由だと他の通信の邪魔になってしまうという事から採用を見送っていました。DataChannel 化することでストリームを分けて配信できるようになるため、対応していく予定です。
End to End Encryption
Sora のリリースに向けて少し優先度が下がっています。
ACME-SSO 対応
Cisco が発表した ACME-SSO を利用した証明書の信頼性チェック機能を導入したいと考えています。これは完全にSora から切り離される仕組みなので、OSS として公開していく予定です。
ACME-SSO については詳細は別途まとめていますので興味のある方は是非。
Sora E2EE の Rust 化
優先度は低いですが Sora E2EE を Rust 化する事を検討しています。
Messaging Layer Security + SFrame
今後は MLS にも手を出していこうと考えています。2021 年 12 月のリリースに向けて少しずつ準備をしています。
安全性検証
クライアント側は OSS として公開しますが、Sora 側はクローズドソースのため「悪意あるサーバ管理者」によって情報が盗み見られない事を保証する必要があります。
こちらは暗号と E2EE の専門家である五十部さんを技術顧問として招聘いたしました。2021 年も継続して技術顧問を願いしています。
既存実装の懸念事項はほぼ潰せており、ACME-SSO + MLS + SFrame に対応したタイミングで安全性評価をお願いする予定です。
Momo / iOS / Android / Unity SDK の E2EE 対応
libwebrtc には E2EE 用のインターフェースがあることがわかったため、なんとかできればと考えています。
メッセージング機能
E2EE 経由でメッセージング機能を実装しようか検討中です。現在 Double Ratchet は Sender Key の配送にのみ利用していますが、 E2EE メッセージの配送にも利用できるようにしたいと考えています。
e2ee_messaging = trueDataChannel メッセージング
Sora は今まで音声と映像のみに特化してきましたが、今後はリアルタイムメッセージング機能も対応していこうと考えています。理由としては WebSocket ではなく DataChannel を利用してシグナリングとは別の経路を用意できるようになるためです。
部分信頼性や順不同への対応
Sora 2021.1に実装されている DataChannel は到達保証と順序保証がありますが、DataChannel の魅力である部分信頼性（再送回数や再送時間を指定できる）や順不同を利用できるようにします。
Publish / Topic / Subscribe / Unsubscribe
メッセージングでよく使われるのが MQTT ですが、これに似たような仕組みをまずは DataChannel 上に実装予定です。
最初のリリースでは同一チャネル全員に配信する仕組みを用意する予定です。Topic ベースの場合は Subscribe / Unsubscribe =の仕組みが必要になるため焦らず良い設計を考えていく予定です。
将来的には DataChannel の Label を動的に生成したり、部分信頼性や順不同なども指定できるようにしていく予定です。
default_data_channel_messaging = true録画
出力ファイルの MP4 対応を考えていましたが、一番の問題児だった Safari が WebM 対応を始めたので、優先順位がかなり下がりました。
AV1 録画対応
Chrome M90 で AV1 への対応をしたこともあり、AV1 での録画に対応していく予定です。
統計機能
Sora は多くの統計情報を Sora の中にため込んでいます。特にクライアントから送られてきている統計情報は最新の情報しか見られないという問題がありました。
統計ウェブフック機能
これをウェブフック化して、どこかのエンドポイントに定期的に投げ込む仕組みを検討しています。基本的には HTTP/2 を想定していますが、現在検討中です。後述する Kohaku との連携も想定しています。
stats_webhook_url = https://example.com/sora/webhook/stats廃止機能
upstream / downstream ロール
2021 年 6 月リリース予定の Sora で廃止します。ロールは sendrecv / sendonly / recvonly のみになります。
Ubuntu 16.04 対応
2021 年 4 月いっぱいで終了しました。
CentOS 8 対応
2021 年 12 月いっぱいで終了します。
スポットライトレガシー機能
2021 年 12 月リリース予定の Sora で廃止します。
client_id 指定設定の廃止
常時有効になりました。
その他
AV1 / VP9 サイマルキャスト対応
Chrome で AV1 / VP9 のサイマルキャストへ対応が予定されているため、そちらにも対応予定です。
音声 RED 対応
ブラウザがまだ対応していませんが、音声の冗長化に対応したいと考えています。RTX と RED を映像だけでは無く音声にも対応していく予定です。
SDP 再利用
現在 SDP はマルチストリームを利用した場合増え続けるばかりですが、再利用できるように変更する予定です。
Sora SDK
Sora SDK も継続的に開発しています。またコミュニティからのフィードバックを可能な範囲で取り入れています。全ての SDK でサイマルキャストとスポットライト機能、データチャネル機能が利用できるようにできればと思っております。
Sora JavaScript SDK
DataChannel に対応済みです。
Sora Unity SDK
DataChannel へ対応済みです。M92 へアップデートしたらリリース予定です。
Sora iOS SDK
サイマルキャストとスポットライト機能に対応しました。次のリリースではマイクやカメラ利用の改善、その後 DataChannel 対応を予定しています。
libwebrtc M92 にアップデート予定です。
Sora Android SDK
DataChannel への対応を予定しています。libwebrtc M92 にアップデート予定です。
Sora C++ SDK
新しく C++ SDK を開発予定です。この SDK は iOS / Android / Unity / Momo / Zakuro のベースとなる SDK になります。
そのため多くのプラットフォームに対応していきます。これは 2021 年 12 月までには公開できればと考えています。
WebTransport (over HTTP/3)
いったん Sora とは別に独立したサーバとして実装中です。将来的には Sora に組み込んで利用できるようにします。
まずはブラウザから利用できるようにして、WebCodecs と組み合わせて色々と実験していければと考えています。WebTransport サーバ自体も Sora Labo で公開して、誰でも気軽に触れるようにできればと思っています。
2021 年 11 月頃に本格的に Chrome で利用可能になるため、そのあたりから手を付けられればと思います。
Sora を採用したくなる OSS
時雨堂の今期の方針として「Sora を採用したくなる OSS の提供」をかかげています。Sora や Sora SDK をより良くしているのはもちろん、それ以外の部分で「あ、このツールがあるなら Sora 採用しよう」と思えるものを提供していこうと考えています。
それらのツールは Sora 専用ですが、Sora はそれらのツールに依存するものではなく、他の OSS などでも実現可能です。
詳細は以下に書いてありますので、興味ある方は読んでみてください。
Sora 向け負荷試験ツール Zakuro
かなり力を入れており、多くの機能を追加しています。WebRTC フェイクネットワークや、新しく入った dcsctp を利用する機能などが追加されています。今後も積極的に改善していきます。
Sora 向け録画合成ツール Hisui
音声や映像のフィルターなど、いくつか大きめの機能追加を予定しています。
Sora 向け統計解析ツール Kohaku
Sora にすでにあるリモート統計機能で取得しているクライアントの統計情報をウェブフック経由を用意し、それを受け取って TSDB に突っ込みリアルタイムな解析ができるようにするというものです。
Sora からクライアントとサーバの統計情報を受け取り、それをアグリゲーションして TimescaleDB に入れ込む Kohaku (aggregator) を提供します。Kohaku で加工なども行います。現在は Python で色々プロトタイプを実装しています。
統計情報をどのようにデータベースにため込むか、どうやって集計していくのかはとても難しい課題のため、そのまま使え、さらにカスタマイズも自由に行える仕組みを提供できればと思います。
ブラウザの際も全て Kohaku で吸収していきます。
この仕組みは JavaScript / iOS / Android / Unity の SDK や Momo にも対応していく予定で、全て Apache License 2.0 で公開予定です。
TSDB には TimescaleDB 、可視化には Grafana を採用しています。
Canaria (仮名)
Sora と Zakuro と Kohaku を連携したサービスを提供予定です。まだ企画段階中ですが気軽にキャパシティプランニングできるサービスを用意します。
自分が想定しているシナリオをセットすると CPU 負荷やメモリーなどが確認できる仕組みです。
タスクを用意して、負荷をかけて、レポートが見れる仕組みです。ここで検証した結果はログインしている誰もが見ることができるようにする予定です。
Sora や Sora SDK 向けドキュメントテーマ
自社製品向けの Sphinx テーマを自作しています。Sora の開発ドキュメントに適用しています。是非見てみてください。
2020 年 5月版は以下からどうぞ
