applideveloper/shiguredo_webrtc_sfu_log.rst

## shiguredo_webrtc_sfu_log.rst

      
    Raw
  

              shiguredo_webrtc_sfu_log.rst
            
          
    時雨堂 WebRTC SFU Sora 開発ログ


日時
2016-05-22

作
時雨堂

バージョン
10.8.0

url
http://sora.shiguredo.jp/


depth
3


概要

時雨堂 で開発/販売中の WebRTC SFU の開発ログです。
WebRTC SFU Sora
興味がある方は sora at shiguredo.jp までご連絡ください
リアルタイム配信

WebRTC はその名の通り、リアルタイムが強みです。リアルタイムとは遅延が 1 秒未満を想定しています。 もちろん、回線性能に寄って異なりますができる限り遅延を抑えた配信方式です。
リアルタイム動画配信コトハジメ
SFU

SFU は Selective Forwarding Unit の略で、簡単に言えば SFU というサーバが動画を配信者に変わって複数の視聴者に配信してくれる仕組みです。
/ -> WebRTC -> 視聴者 
/ -> WebRTC -> 視聴者 


配信者 -> WebRTC -> SFU -> WebRTC -> 視聴者
-> WebRTC -> 視聴者 -> WebRTC -> 視聴者


配信者は Firefox や Chrome (現在条件対応) 、さらには様々な WebRTC クライアントへの対応を目標とします。
SFU は動画を再変換せず配信するため、サーバを経由したとしても遅延をほとんど感じることはありません。
SFU をもっと詳しく知りたい方向け

WebRTC SFU コトハジメ
目的

WebRTC は映像と音声をリアルタイムに配信する仕組みです。ただ P2P の場合は大量の配信を行うことは難しくなります。 そこでサーバを経由することで遅延が少ない状態での配信を 500 人といった規模に対して配信が可能になります。
通常の WebRTC はブラウザとブラウザの間で実現する仕組みですが、サーバサイド WebRTC ではブラウザとサーバの間で WebRTC を実現します。
サーバサイドでの録画を行う場合はサーバサイドでの WebRTC スタックが無ければできません。録画以外にもスター型で WebRTC を繋ぐ場合にも必要です。
サーバでの WebRTC 可能性を探るためにフルスクラッチな WebRTC スタックを開発しています。
なぜ SFU なのか

ここでは Data Channel は取り扱わずに説明します
WebRTC SFU は再変換を一切行わないで、複数の視聴者に映像や音声を配信する仕組みです。 再変換を行わないため、マシンリソースを節約することが可能です。
また、サーバを中継することでサーバ側で録画を行えます。
今後 WebRTC には Simulcast といった、再変換なしで視聴者の環境毎に画質などを選択できる仕組みが入ります。
SFU を起点にすることで配信者は Simulcast を使って複数の画質の映像を SFU に送る事で SFU が視聴者の環境にあった品質の映像を配信してくれるようになります。
また配信は低画質で、録画は高画質でなどの選択も可能になってきます。
マルチストリーム

対応済
WebRTC では複数の映像を 1 本のセッションで束ねる マルチストリーム が Firefox/Chrome には採用されています。 この マルチストリーム を使うことで複数人からの映像を 1 本にまとめられます。
SFU を使った場合は配信は 1 つですが、視聴は複数になる事があるため、 マルチストリーム と SFU の相性はよく、今後は マルチストリーム が主流になっていくと考えています。
SFU で マルチストリーム を使うと DTLS セッションを 1 本だけ張れば良くなります。WebRTC API の onaddstream/onremovestream イベントを活用することで、参加者の通知を気軽に行えます。
動的にクライアント側の実装がとてもシンプルになります。
実際に Firefox と WebRTC SFU を使った マルチストリーム のデモを動画にしてみました。
Firefox 45 と WebRTC SFU Sora を使った マルチストリーム のデモ - YouTube
視聴者参加機能

対応中
マルチストリーム を上手く使う事で途中参加を 1 本の接続だけで実現することができるようになります。
例えば配信者が 1 名、視聴者が 50 名いたとします。その中で視聴者から配信者に対して質問をしたいという場合、 その質問している情報は配信者にも視聴者にも伝わる必要があります。
つまり一時的に配信者になり、質問が終わったら視聴者へと戻る機能です。
これを使う事で遠隔での教育がかなり行いやすくなります。
サーバ録画

対応済
WebRTC SFU は映像の暗号化をいったんほどいてから配信しているため、サーバ側で映像を保存することが可能になります。つまり好きなタイミングで配信している映像を保存可能です。さらに変換せずその流れている映像そのままの画質で保存が可能です。
非力なデバイスでの配信

対応済
非力なデバイスなどから動画を配信する場合は、回線も細いため複数の箇所に配信することはできません。 ただ、 SFU 経由で動画を配信すれば、多くの人に配信が可能となります。
Simulcast

対応予定
Firefox 46 にて対応が始まりました
Simulcast は視聴者毎に適切な品質の映像を配信する仕組みです。 つまり遅い回線の視聴者には画質を抑えて提供し、早い回線の視聴者には高画質で映像を提供します。
サンプル

これは WebRTC Gateway Momo と WebRTC SFU Sora を使った場合のサンプル画像です。
ラズパイにつないだ Web カメラから WebRTC SFU 経由で配信してブラウザで閲覧しています。

配信映像を録画したものを Youtube に公開しておりますので、是非ご覧ください。
WebRTC Gateway を使った WebRTC SFU 経由での映像配信 - YouTube
また、遅延のなさを実感して貰えるように、実際に WebRTC SFU Sora を簡単に使えるようにした WebRTC SFU as a Service Anzu でのサンプル動画も公開しております。
WebRTC SFU が気軽に使える Anzu のリアルタイム配信 - YouTube
この動画は Chromebook flip で再生している動画をウェブカメラで取りサーバ経由の WebRTC で配信しているところです。
遅延がほとんど無いところが理解してもらえると思います。
録画サンプル

WebRTC SFU で録画した WebM 形式のファイルで、 映像コーデックは VP8 で音声コーデックは Opus を使用しています。
Firefox または Chrome で録画した WebM ファイルを見ることができます。このサンプルには音声は含まれておりません。
https://dl.dropboxusercontent.com/u/89936/sora_recording.webm
また Youtube に上記の WebM ファイルをアップロードしたものもあります。
WebRTC SFU Sora 録画ファイルサンプル - YouTube
ゴール

SFU (+TURN) 機能を持った WebRTC Live Broadcast サーバを目指します


最新版の Chrome と Firefox が繋がる WebRTC サーバを製品として提供します

今後 Edge や WebKit が WebRTC 1.0 に対応しだい、対応していきます

サーバ経由での 1:N での映像配信を可能にします

SFU 1 台で 1000 までの配信を可能にします

マルチストリーム を使用した N:N の映像配信を可能にします

常に マルチストリーム 前提で動作させます

常に組み込みでの TURN 経由アクセスを行います

Username/Credential な認証の仕組み自体は組み込みます
ただし認証 API 経由での ok/error は別の仕組みとします
TURN/STUN 機能もサーバ側に盛り込みます

録画機能を組み込みます

VP8, VP9, H.264 の録画に対応
WebM または MKV 形式での出力が可能

WebM 配信機能

Simulcast を使った複数画質を WebM 形式で録画可能
WebM を配信する機能です

JS や iOS 、 Android への SDK を OSS として公開します

優先度が低い機能


サーバ経由、P2P 経由両方に対応します
クラスタリングを使用し、同時 10000 接続に対し遅延を 1 秒以内を目指します

実装しない機能


メディアチャネルのみの実装とし、データチャネルのスタックは実装しません

データチャネルに QUIC が来た場合は検討します

HLS 配信機能
トランスコード機能
映像合成機能
ファイルアップロード機能
WebM や MKV/MKA 形式以外のファイルの出力機能
独自の認証機能

動作環境

OS

Linux のみに対応します

Ubuntu 14.04 64bit
Ubuntu 16.04 64bit
CentOS 6.7 64bit
CentOS 7.2 64bit

ブラウザ

常に最新のブラウザに追従しています

Firefox 46 ~
Chrome M51 ~

最新から 1 つ前のブラウザまで動作を保証しますが、可能なかぎり最新のブラウザを使うことをお勧めします。
要求スペック


コア数
100 ユーザで 2 コア以上

メモリ
100 ユーザで 1G 以上


800Kbps の映像を配信する場合、暗号化/復号化の処理に最低でも 1 ユーザあたり 1 コアを 100% として 1-2% を使用します
Generic NACK という再送機能のため、サーバ側で RTP パケットをキャッシュしているため、ユーザが増える分だけメモリが必要です

1 パケット 1400 バイトで 1 ユーザあたり 1000 パケットキャッシュしています。
1 ユーザあたり 14M 程度キャシュにメモリを使用します


現状

動作状況

Firefox 42 にて最大 1:600 の配信が成功しています。
検証環境はグローバルで、さくら VPS の 8 コア 16 G のサーバを使用してテストしてます。
連続稼働

連続した安定的な配信を可能にします。
パケットロストした RTP パケットを再取得する Generic-NACK 機能に対応しているため画質を安定して配信することが可能です。
ロードマップ

年内は Firefox 最新版のみの対応とします
Future


[ ] 組み込み TURN へ対応

a=simulcast にて対応

[ ] STUN サーバ機能の追加
[ ] RTCP の統計機能を追加する
[ ] Simulcast への対応

Chrome と Firefox が実装してくる予定

[ ] 管理ダッシュボードの追加

サーバの統計情報や状態が Web から確認可能
Chrome/Firefox にのみ対応

[ ] SRTP の AES-GCM 対応

RFC 7714 - AES-GCM Authenticated Encryption in the SRTP

[ ] ALPN 対応
[ ] RTP/RTCP 直接収容を可能とする
[ ] H.264 での録画機能を可能とする
[ ] スクリーンシェア機能用の Chrome/Firefox 拡張の公開
[ ] 指定した映像や音声のみの配信を SFU 側で行う

スマートフォンなどの帯域や電源があるものにたいしては、映像配信を行わず音声のみにするなど

[ ] RTCP goog-remb の集約に対応する

3.0.0

2.x.0


[ ] RTCP-RR の動的生成の精度を上げる
[x] VP9 での録画機能を可能とする

実験的機能

[x] 視聴者参加機能の追加

実験的機能
Firefox 限定


2.1.0


[x] マルチストリーム の整理
[x] 録画失敗時のウェブフックの追加

2.0.0

2016-05-02 完了

[x] Opus での録音機能を可能とする
[x] Webhook の採用

stream API の削除

[x] API の JSON を camelCase から snake_case へ変更する

1.2.0

2016-03-16 完了

[x] Generic-NACK への対応
[x] VP8 での録画機能を可能とする

StartRecording/StopRecording


1.1.0

2016-02-09 完了

[x] Firefox の マルチストリーム に実験的に対応する
[x] RTCP-RR の動的生成を行う
[x] DTLS 1.2 のみに対応する
[x] ECDHE-ECDSA-AES-GCM のみに対応する

1.0.0

2015-12-16 完了

[x] ログの充実
[x] DTLS 1.0 に対応

Chrome M47 ~ にデフォルトで対応

[x] ECDSA を一端無効化

DTLS 1.2 がデフォルトになったタイミングで有効予定

[x] fingerprint のチェックを追加
[x] 実験機能として配信者のコーデック選択機能を追加

VP8 / VP9 / H264 に対応

[x] ping/pong の間隔を 30 秒に変更する
[x] Chrome での画質安定化
[x] RTCP 集約方式に対応する

FIR と PLI を集約する

[x] type: candidate による Tricle ICE への対応
[x] AES-CTR EVP 対応による高速化
[x] 映像と音声両方に対応する

0.5.0

2015-11-04 完了
先行版リリース

[x] Stream API

1 分間隔での接続状態
WebRTC レイヤーでの切断
WebRTC レイヤーでの接続済み
WebRTC レイヤーでの接続中

[x] Event API

アクセストークン認証を委譲する

[x] Action API

指定したチャネル ID の接続一覧を取得する
指定した接続を切断する
指定したチャネル ID の接続を全て切断する

[x] ECDSA に対応する
[x] Chrome Canary M48 での動作
[x] Chrome での安定配信
[x] 高解像度に対応する
[x] 長時間配信に対応する
[x] RTCP 転送方式に対応する
[x] 映像のみの配信に対応する
[x] Chrome M45 で DTLS 1.2 を有効にすれば動作する
[x] Firefox 41 に対応する
[x] VP8 での配信に対応する
[x] クライアントの RTCP を一端クライアントに送る

[x] RTCP-FIR を 500 ミリ秒間隔で間引きする

[x] ある程度のデモが可能なレベルまで持って行く
[x] 映像のみ
[x] サーバ経由での 1:N 接続を可能とする
[x] 接続時に RTCP-FIR を発行する

実装

Erlang/OTP 18.3 + 暗号化 EVP 対応パッチにて実装中
19 で EVP 対応が標準で入るので、 19 以降はパッチは適用しない予定。
DTLS

フルスクラッチで実装


実装済
WebRTC に特化した DTLS-SRTP を実装
機能は少ないが WebRTC の暗号化機能は満たす

最新の Firefox/Chrome に追従していく

use_srtp 拡張対応済
DTLS 1.2 のみに対応

Chrome M48 にて DTLS 1.2 に対応

対応暗号スイート

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

実装済みだが OpenSSL 非対応


未実装


再接続
SessionTicket
ALPN

性能試験

1 接続、ClientHello から Finsihed まで、 110 ミリセック程度。実運用上特に問題なし。
SRTP/SRTCP

フルスクラッチで実装

実装中
AES-128-CTR + HMAC-SHA1 での暗号、ハッシュ方式に対応
SRTP/SRTCP 復号化/暗号化完了

性能試験

RFC 3711 のテストベクターを使って AES-128-CTR でマイクロベンチマークを取ってみました。
B.2. AES-CM Test Vectors

暗号化
31 マイクロ秒

復号化
39 マイクロ秒


Erlang/OTP で書いているので、残念ながらそんなに性能は出ないが、そこそこ出ている。
Erlang/OTP は AES-GCM や AES-CTR が EVP 非対応なため、現在は AES-NI を使用できていません。 そのため性能が落ちています。すでに EVP 対応に着手しており、両方とも PR 済です。

Use EVP for AES-GCM by mururu · Pull Request #880 · erlang/otp
Use EVP for AES-CTR by mururu · Pull Request #891 · erlang/otp

Erlang/OTP 18.3 に上の二つのコミットを反映したバージョンを以下のリポジトリにて公開してあります。
https://github.com/shiguredo/otp/tree/shiguredo-otp-18.3
WebRTC Sora では二つの修正を反映した Erlang/OTP を使用しております。
ICE

Offer/Anser

実装済

当面は WebSocket のみ
type: candidate の追加

未実装

ICE-TCP
将来的に XHR へのダウングレードを実装予定

WS が接続できない場合は XHR だけで処理する仕組み


SDP

ICE や DTLS-SRTP 対応済み

実装済
Unified Plan マルチストリーム 対応済

Chrome が 2016 年中に Unified Plan へ移行するらしいため、当面は Plan B への対応予定はありません


シグナリング

SFU ではシグナリングが一体化する

残念ながらオリジナル仕様
サーバ側から Offer を出す方式です
JavaScript ライブラリも提供予定

sora-js-sdk を OSS (Apache 2.0) にて提供
https://github.com/shiguredo/sora-js-sdk にて公開
配信者と視聴者で実装が変わる

シグナリングサーバの仕様を公開

マルチストリーム

現時点では Firefox にしか対応していません
1 つのポートで複数の映像や音声を送受信する仕組み。
SFU を経由することで配信コストを一つだけにすることができます。 また、 SFU は映像を変換せず、転送するだけなので CPU リソースは暗号化のみにかかります。 5 人の会議が 8 コアのサーバで 10 以上が同時に SFU を経由して可能になります。
録画

マルチストリームには現在非対応です、今後対応していきます
API 経由で指定したチャネルを録画することが可能です。
WebRTC SFU Sora 録画機能の特徴は一切変換を行わないため CPU を使わないことにあります。 実際に流れている映像や音声を WebM や MKV 形式にマッピングしてファイルを作成します。

録画開始 (実装済)
録画停止 (実装済)
録画したファイルの一覧
録画したファイルのダウンロード

この 3 種類の API を提供します。
WebRTC SFU で録画したサンプル動画を置いておきます。
https://dl.dropboxusercontent.com/u/89936/sora9.webm
AS=800 で録画した映像で、変換は一切行っておりません。ノートランスコードです。
認証

認証の仕組みを用意しています、ただ SFU はほかのところへ API を叩きに行くだけです。
認証が成功ならば HTTP Status Code 200 を、失敗ならそれ以外を。
戻り値に JSON を入れることで、クライアントにまで好きな値を渡すことが可能です。
クライアントには metadata: 戻した JSON という形で返ります。
組み込み TURN

Sora は常に組み込まれた TURN 経由で認証を前提とした仕組みを採用する予定です。
Client -> TURN -> SFU -> TURN -> Client という感じになります。
ただ普通に TURN を立てるのでは無く SFU の入り口がそもそも TURN という仕組みを採用します。
基本は TURN/UDP が採用されますが、 TURN/TCP や TURN/TLS が採用される場合もあります。 それも全て SFU に組み込みます。
以前に STUN/TURN サーバを自前実装しており、それをライブラリ化して組み込みます https://gist.github.com/voluntas/47c041e8644afa2fea8d
STUN

SFU といっても STUN サーバは必要になるため組み込みオプション機能として提供予定。
シグナリング仕様

WebSocket + JSON で実現する。
connect

配信者が upstream で視聴者が downstream です
{
    "type": "connect",
    "role": "upstream",
    "channel_id": "spam",
    "access_token": "..."
}
{
    "type": "connect",
    "role": "downstream",
    "channel_id": "egg",
    "access_token": "..."
}
offer

{
    "type": "offer",
    "sdp": "...",
    "client_id": "...",
    "metadata": "..."
}
answer

{
    "type": "answer",
    "sdp": "..."
}
candidate

{
    "type": "candidate",
    "candidate": "..."
}
Web フック

Sora は状態の変化などを全て Web フック経由でアプリケーションに通知します。
詳細は Sora のドキュメント をご覧ください。
webhook_url に設定された URL に対して POST で以下のようなタイミングで JSON を送ります。

シグナリング接続完了時
シグナリング状態更新時
シグナリング切断時
シグナリング失敗時
録画ファイル保存完了時
クライアントとの通信部分の暗号完了時

これらのフックを使う事でアプリ側で柔軟な対応を行うことができます。
認証

Sora 自体は認証機能を持っていません。ただし、認証の処理を外部のアプリに委譲することができます。
詳細は Sora のドキュメント をご覧ください。
auth_url

auth_url という設定でどこの HTTP API を叩きに行くか指定できます。
たとえば {auth_url, "http://127.0.0.1:5000/auth"} と指定した場合はこの URL に対して POST で以下のような JSON を送ります。
{
    "role": "upstream",
    "channel_id": "Spam",
    "access_token": "0AC29F4C526B4074A06AEC7C87EACF32",
    "channel_connections": 6,
    "upstream_connections": 1,
    "downstream_connections": 5
}
アプリケーションはこの JSON を受け取ったら独自で判断をし、認証が成功した場合は 200 OK を返します。 認証が失敗した場合は 200 OK 以外を返してください。

connected は「現在そのチャネルに接続している接続数」です
role は upstream (配信者) か downstream (視聴者) です
access_token は認証用の判断材料です
channel_connections はそのチャネルに接続している数です
upstream_connections はそのチャネルの配信している数です
downstream_connections はそのチャネルで視聴している数です

auth_response_with_metadata

この設定を有効にすることで、認証を委譲した先からの戻り値をクライアントに配信することができます。
認証の戻り値に含まれている JSON を Sora はクライアントへの Offer 時の JSON に metadata: 送られてきた JSON として返します。
例えばサーバから {"username": "spam"} という JSON が送られてきた場合 {"type": "offer", metadata: {"username": "spam", ...} が送られます。
API

API は Sora が持っている HTTP API です。 切断や情報取得などがメインになります。
詳細は Sora のドキュメント をご覧ください。
指定したチャネルの接続をすべて切断する:
$ http POST 127.0.0.1:6000 'x-sora-target:Sora_20151104.DisconnectChannel' channel_id=sora -vvv
POST / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 21
Content-Type: application/json
Host: 127.0.0.1:6000
User-Agent: HTTPie/0.9.2
x-sora-target: Sora_20151104.DisconnectChannel

{
    "channel_id": "sora"
}

HTTP/1.1 200 OK
content-length: 0
content-type: application/json
date: Sun, 01 Nov 2015 11:46:09 GMT
server: Cowboy
指定したクライアント ID の接続を切断する:
$ http POST 127.0.0.1:6000 'x-sora-target:Sora_20151104.Disconnect' channel_id=sora 'client_id={2996e293-7b4c-400b-b94b-1785c10af024}' -vvv
POST / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 75
Content-Type: application/json
Host: 127.0.0.1:6000
User-Agent: HTTPie/0.9.2
x-sora-target: Sora_20151104.Disconnect

{
    "channel_id": "sora",
    "client_id": "{2996e293-7b4c-400b-b94b-1785c10af024}"
}

HTTP/1.1 200 OK
content-length: 0
content-type: application/json
date: Sun, 01 Nov 2015 11:57:32 GMT
server: Cowboy
指定したチャネルの接続一覧を取得する:
$ http POST 127.0.0.1:6000 'x-sora-target:Sora_20151104.ListConnections' 'channel_id=sora' -vvv
POST / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 21
Content-Type: application/json
Host: 127.0.0.1:6000
User-Agent: HTTPie/0.9.2
x-sora-target: Sora_20151104.ListConnections

{
    "channel_id": "sora"
}

HTTP/1.1 200 OK
content-length: 221
content-type: application/json
date: Sun, 01 Nov 2015 12:09:30 GMT
server: Cowboy

[
    {
        "client_id": "{cc26da43-efb1-45c3-921e-a1fd08d4a2ea}",
        "role": "downstream"
    },
    {
        "client_id": "{0de8e7fd-c9df-4ed4-bff0-16330975fc14}",
        "role": "downstream"
    },
    {
        "client_id": "{1744d031-1c23-4167-b85a-9a84fa17acf3}",
        "role": "upstream"
    }
]
指定したチャネルの録画を開始する:
$ http POST 127.0.0.1:6000/ "x-sora-target:Sora_20151104.StartRecording" channel_id=sora -vvv
POST / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 21
Content-Type: application/json
Host: 127.0.0.1:6000
User-Agent: HTTPie/0.9.2
x-sora-target: Sora_20151104.StartRecording

{
    "channel_id": "sora"
}

HTTP/1.1 200 OK
content-length: 0
content-type: application/json
date: Wed, 09 Mar 2016 13:53:35 GMT
server: Cowboy
指定したチャネルの録画を停止する:
$ http POST 127.0.0.1:6000/ "x-sora-target:Sora_20151104.StopRecording" channel_id=sora -vvv
POST / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 21
Content-Type: application/json
Host: 127.0.0.1:6000
User-Agent: HTTPie/0.9.2
x-sora-target: Sora_20151104.StopRecording

{
    "channel_id": "sora"
}

HTTP/1.1 200 OK
content-length: 0
content-type: application/json
date: Wed, 09 Mar 2016 13:53:53 GMT
server: Cowboy
現在録画中の状態を取得する:
$ http POST 127.0.0.1:6000/ "x-sora-target:Sora_20151104.ListRecording" -vvv
POST / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 0
Host: 127.0.0.1:6000
User-Agent: HTTPie/0.8.0
x-sora-target: Sora_20151104.ListRecording


HTTP/1.1 200 OK
content-length: 94
content-type: application/json
date: Sat, 30 Apr 2016 04:17:54 GMT
server: Cowboy

[
    {
        "audio": {
            "codec_type": "OPUS"
        },
        "channel_id": "sora",
        "seconds": 1,
        "video": {
            "codec_type": "VP8"
        }
    }
]
開発

WebRTC SFU Sora を使用したサービスの開発を承ります。まずはお問い合わせください。
sora at shiguredo.jp
参考


WebRTC SFU をフルスクラッチで作ってみた

WebRTC Meetup Japan #1 の発表資料です

WebRTC SFU コトハジメ

WebRTC Conference Japan 2016 の発表資料です