Forked from alanmshelly/webrtc_sfu_develop.rst
Last active
June 17, 2021 10:33
Revisions
-
voluntas revised this gist
Nov 6, 2015 . 1 changed file with 277 additions and 494 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -1,675 +1,458 @@ ####################################### WebRTC SFU をフルスクラッチで作ってみた ####################################### I wrote a WebRTC SFU from scratch :Author: @voluntas :Translator: @alanmshelly :Version: 0.0.0 :url: https://voluntas.github.io/ 2015 年 11 月 04 日に行われる `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ 向けの発表資料です。 Presentation materials for `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ on 2015/11/04. 自己紹介 / Self Introduction ======== `時雨堂 <https://shiguredo.jp>`_ という零細企業を経営しています。 twitter は @voluntas -------------------- I run a small company named `Shiguredo <https://shiguredo.jp>`_ twitter account is @voluntas モチベーション / Motivation ============== - 日本だと誰も作ってなさそうだったし、面白そうだと思ったから。 - テレビ会議システムにはあまり興味なく配信システムに興味があった。 - 音声や映像のリアルタイムな共有に興味があった - Erlang による DTLS の実装のめどがついたから。 --------------------- - No one in Japan had done it and it seemed fun. - I didn't have any interest in conference systems but I was interested in broadcasting systems. - I was interested in realtime voice and video sharing. - I had figured out how to implement DTLS in Erlang. 実装の流れ / Development Timeline ================================== DTLS 1.0 を実装する / Implementing DTLS 1.0 ------------------- Erlang には DTLS の実装がまだ公式にないこと、TLS は実装経験があるのでなんとかなると思ってた。前職で UDP 上で TLS を実現する EAP-TLS とかを書いていた。 Chrome がまだ DTLS 1.0 なのでまずは 1.0 から。 UDP なのでシーケンス番号が入ってきたり少しずつ違う。DTLS 1.0 は TLS 1.1 ベース。 CipherSuites は決め打ちした。ECDHE で RSA そして AES-CBC で実装。 実装終わって openssl でテストして動作した。 --------------------------- Erlang doesn't have an official DTLS implementation but I had experience implementing TLS. I'd written EAP-TLS to implement TLS over UDP at my previous job. Chrome still uses DTLS 1.0 so start with 1.0. It's UDP so there are some small differences such as sequence numbers being used. DTLS 1.0 is based on TLS 1.1. CiperSuites is hardcoded. RSA and AES-CBC are implemented using ECDHE. After finishing implementation, I tested with openssl. DTLS 1.2 を実装する / Implementing DTLS 1.2 ---------------------------------------------- 今後考えるとやっておきたい、ということで実装。 ついでに AEAD 認証に対応しておきたい。AES-GCM と CHACHA20 に定める。 実装終わってテスト通った。ただ DTLS 1.0 邪魔だなと思い始める。 全消しして 1.2 のみのコードにする。Chrome は追従するだろうと読む。 Chrome M47 から徐々に DTLS 1.2 になる模様。Firefox はすでに DTLS 1.2 。 SRTP を組み込んだので、ライブラリ的には DTLS-SRTP ライブラリ。 ----------------------------- I implemented it as it will be useful in the future. I also added support for AEAD while I was at it. Decided on AES-GCM and CHACHA20. Tests passed after implementing... but I started to think the DTLS 1.0 code was unnecessary. I deleted all of it and left only the DTLS 1.2 code, predicting Chrome would catch up. It looks like Chrome will start including DTLS 1.2 from M47. Firefox also has DTLS 1.2. It is bundled with SRTP so the library is a DTLS-SRTP library. SDP パーサを実装する / SDP Parser -------------------- 投げるにしても受け取るにしても必要ということで作る。文字列はだるい。 いろいろな SDP をパーサに食べさせてテスト、問題なさそうということで完成。 ------------------------ Needed for both sending and receiving. Handling text is annoying. Tried a bunch of SDP parsers. I found no problems so done. ## STUN ライブラリ すでに実装してたので ICE に対応させて終わり。 RTP ライブラリ -------------- すでに持っていたがいけてなかったのでほぼ書き直し。かなりの頻度で書き直したり機能追加したりした。 SRTP ライブラリ --------------- SRTCP 系の対応が死にそうになる。独自すぎる。一通り退治して実際に WebRTC の SRTP パケットを受け取って無事動く。確認は明らかに変な値じゃないかを確認する。暗号系の怖いところはとりあえず復号はできてしまうところを。 間違ってるかどうかはアプリでしか判断できない。 WebRTC SFU に着手 ----------------- とりあえず作ったライブラリを組み上げてみる。シグナリングサーバーがいないとダメなので組み上げたらシグナリングサーバーの開発へ。 シグナリングサーバーの開発 -------------------------- SkyWay で経験していたが方向が逆向きなので一から設計。WebRTC SFU では SFU から Offer を出す。 さらに接続の認証方式などをあとで考えられるようにしてざっくり実装。 まずは WebSocket だけで対応。XHR へのダウングレードは後回し。 シグナリングサーバーを組み込む ------------------------------ 認証は後回し。動くところまで持っていく。 まずは配信者だけで確認。なんとなくデコードできていそうというところまで持っていく。 次に視聴者を追加。ここで最初に視聴者をつながないと画面が映らないことに気づく。FIR を投げないとダメとアドバイスをいただく。 視聴者の DTLS が完了したタイミングで SFU が FIR を配信者に送る仕組みを入れる。大量接続を踏まえ 500 ms単位で接続を間引きして FIR を送らないようにする仕組みを追加。 無事動作するようになる。 パケットの解析 -------------- RTP/RTCP が生で見られるようになったのでパースできてないのを実装したりする。 いつも通り WS デバッガーをくっつけて流れてるパケットを WS で気軽に閲覧できるようにする。 Firefox と Chrome の Application layer な RTCP に対応数。 Development Timeline ===================== Implementing DTLS 1.0 ----------------------- Erlang doesn't have an official DTLS implementation but I had experience implementing TLS. I'd written EAP-TLS to implement TLS over UDP at my previous job. Chrome still uses DTLS 1.0 so start with 1.0. It's UDP so there are some small differences such as sequence numbers being used. DTLS 1.0 is based on TLS 1.1. CiperSuites is hardcoded. RSA and AES-CBC are implemented using ECDHE. After finishing implementation, I tested with openssl. Implementing DTLS 1.2 ---------------------- I implemented it as it will be useful in the future. I also added support for AEAD while I was at it. Decided on AES-GCM and CHACHA20. Tests passed after implementing... but I started to think the DTLS 1.0 code was unnecessary. I deleted all of it and left only the DTLS 1.2 code, predicting Chrome would catch up. It looks like Chrome will start including DTLS 1.2 from M47. Firefox also has DTLS 1.2. It is bundled with SRTP so the library is a DTLS-SRTP library. SDP Parser ----------- Needed for both sending and receiving. Handling text is annoying. Tried a bunch of SDP parsers. I found no problems so done. ## STUN library I'd already written one so I made it support ICE and I was done. RTP library ----------- The one I had wasn't very good so I rewrote it almost completely. I rewrote it/added new features quite often. SRTP library ------------- Almost died trying to support SRTCP. It's too unique. I eventually got it to accept WebRTC SRTP packets. Confirmed by reading the values and making sure they weren't obviously wrong. The scary part about encryption is you can decrypt anything but not know if its right. You can only test if its working or not using the application. Started on the WebRTC SFU ---------------------------- Started putting together the libraries I'd developed. I needed a signalling server so I went on to develop the signalling server. Signalling Server development ------------------------------- The implementation is the opposite of the one for SkyWay so I had to design from scratch. The WebRTC SFU creates an offer at the SFU. Also quickly implemented an scheme that let me decide on authentication later. First support just WebSockets. Will implement downgrade to XHR later. Integration with the Signalling Server ---------------------------------------- Authentication comes later. Just get it working. Try with just the broadcaster first. Work on it until it looks like the SFU is decoding properly. Next add the receivers. I realized here that if a receiver wasn't connected first, then the stream wouldn't show. I got advice that I need to send FIR. Add logic to send FIR from the SFU to the broadcaster when a receiver's DTLS finishes. In order to handle large numbers of simultaneous connections, I limited the FIRs to send a maximum of once every 500ms. Works properly. Packet Analysis ---------------- I could now see raw RTP/RTCP packets so I decided to parse them. Make it so that I could connect with a WS debugger and see the packets. Supports Firefox and Chrome Application layer RTCP packets. デモ ==== ここで WebRTC SFU のローカルでの起動デモを見せる。 WS デバッガーも見せる。 Demo ==== Show a demo running the WebRTC SFU locally. Show the WS debugger as well. 課題 ==== それといった課題はあまりないが、明示的に解決しなければいけないのは RTCP の代理返信。 RTCP 問題 --------- 今は RR を全部送ってるので間引きする。間引き後は SR->RR は配信者と SFU で閉じる。視聴者からの RR は SFU で集約して SFU の RR 生成時に全体の総意を汲み取りつつ反映する。 Problems ========= No major problems but one part I have to explicitly fix is the RTCP proxy responses. RTCP Problem -------------- Currently all RRs are being sent and being culled. The broadcaster and SFU close SR->RR after culling. The RRs from the receivers are gathered at the SFU, and when the SFU creates an RR it is based on all of the RRs from the receivers. 特徴 ==== **自社製品の宣伝です** アプリとの連携がキモなので連携部分を重要視した。 ステートフル、データレス ------------------------ サーバ自体には一切情報を追加したりせず、起動したらすぐ使える。 接続の認証がしたい、チャネル単位で接続数制限がしたい、時間制限がしたい。 全て WebRTC SFU がデリゲーションしてくるので、アプリ側で実装可能。 データを持たないため、台数さえ増やせばいいのでスケールさせやすい。 ストリーム API -------------- WebRTC SFU に WS で接続することで、クライアントの接続や、一定間隔での接続時間の通知などステートが変化したときにストリームでデータを送ってくる。 リアルタイムにアプリ側で判断が可能。 アクション API -------------- SFU に対して叩く API でチャネル単位での全員切断や、指定した接続の切断。さらにチャネルの接続一覧などがとれる。 アプリはストリーム API でリアルタイムに受け取るステート変化に対してアクションを起こすことが可能になる。 イベント API ------------ 認証などの同期的に判断が必要なのは指定した HTTP API を叩いてくれ、200 だったら OK という動作をする。 全てアプリ側で判断できるため、データベースに悩む必要が無い。 Characteristics =============== **This is advertising for our product** Connecting with apps is fundamental so we focused especially on the API. Stateful, dataless ------------------- The server itself doesn't add any data and can be used as soon as it starts. I want to authenticate connections. I want to limit connections per channel. I want to limit connection time. The WebRTC SFU delegates all of this so it can be implemented in the application. Since it doesn't hold any data, you can easily scale out by adding servers. Stream API ------------- It is possible to get state change information such as clients connecting or connection time by connecting sent to you by connecting via WS. It is possible to make decisions in real time in the application. Action API ------------ It is possible to call an API to disconnect a single, multiple or all clients connected to each channel. You can also get a list of clients connected to a channel. The application can use the information received from the stream API to detect a change in state and take action. Event API ----------- If you need something synchronous such as authentication, call an HTTP API and if the response is 200 then it will proceed as OK. It's all handled in the application so you don't have to worry about a database. 今後 ==== 録画 ---- VP8 であれば WebM 形式での保存を目指す。ただ H.264 がメインになる可能性があるのでまだ様子見。 おもしろい機能ではあるので、対応はしていきたい。 H.264 ----- Chrome が H.264 になると強い。HW が H.264 なのが多いため。 SDP 部分しか影響ないのでそこを接続時に切り替える。 配信者がフォーマットを選べるようにする。 Multistream ----------- 閲覧者が複数の配信を Multistream で同時に見れるようにする。 これは複数カメラの配置に対して需要がありそうなので前倒しで実装していく予定。 音声 ---- 年末までには実装。別に難しくない。 Simulcast --------- Firefox に来たらすぐに対応。 TURN/STUN --------- 自前開発があるので、SFU に組み込む。 主に TCP -> UDP への変換が目的になるが、 SFU に組み込むことで TCP -> TURN -> SFU -> UDP みたいにできる。 わざわざ一回ネットワークを経由しなくて良くなる。 TODO ===== Recording ---------- If it's VP8, I want to write to a WebM file. That being said, H.264 might become the main so I'm still waiting. It's an interesting features so I want to implement it for sure. H.264 ------ It will be good if Chrome supports H.264 since H.264 has a lot of hardware support. It only affects the SDP so I can change it there when connecting. I'll make it so that the broadcaster can choose. Multistream ------------ Make it so that the viewers can receive multiple streams simultaneously using multistream. It looks like it there is a large need to use this with multiple cameras so I will increase priority. Audio -------- By the end of the year. It's not that difficult. Simulcast ---------- I will implement as soon as it comes to Firefox. TURN/STUN ---------- I have an implementation so I will integrate into the SFU. Mostly for converting TCP->UDP but by integrating it into the SFU, you can do TCP->TURN->SFU->UDP. You don't have to add another hop through a network. 参考 ==== - `時雨堂 WebRTC SFU Sora 開発ログ <https://gist.github.com/voluntas/e914aa245fc26f3133c2>`_ Reference ========== - `Shiguredo WebRTC SFU Sora Development log <https://gist.github.com/voluntas/e914aa245fc26f3133c2>`_ -
Nov 6, 2015 . 1 changed file with 499 additions and 224 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -1,400 +1,675 @@ ############################### 時雨堂 WebRTC SFU Sora 開発ログ ############################### :日時: 2015-11-06 :作: `時雨堂 <http://shiguredo.jp>`_ :バージョン: 4.4.0 :url: https://shiguredo.jp/ .. contents:: :depth: 3 概要 ==== `時雨堂`_ で開発中の WebRTC SFU の開発ログです。 興味がある方は contact at shiguredo.jp までご連絡ください `WebRTC SFU Sora <http://sora.shiguredo.jp/>`_ SFU --- SFU は Selective Forwarding Unit の略で、簡単に言えば SFU というサーバが動画を配信者に変わって複数の視聴者に配信してくれる仕組みです。 :: / -> WebRTC -> 視聴者 / -> WebRTC -> 視聴者 配信者 -> WebRTC -> SFU -> WebRTC -> 視聴者 \ -> WebRTC -> 視聴者 \ -> WebRTC -> 視聴者 配信者は Firefox や Chrome (現在条件対応) 、さらには様々な WebRTC クライアントへの対応を目標とします。 目的 ==== 通常の WebRTC はブラウザとブラウザの間で実現する仕組みですが、サーバサイド WebRTC ではブラウザとサーバの間で WebRTC を実現します。 サーバサイドでの録画を行う場合はサーバサイドでの WebRTC スタックが無ければできません。録画以外にもスター型で WebRTC を繋ぐ場合にも必要です。 サーバでの WebRTC 可能性を探るためにフルスクラッチな WebRTC スタックを開発しています。 なぜ SFU なのか =============== **ここでは Data Channel は取り扱わずに説明します** WebRTC SFU は再変換を一切行わないで、複数の視聴者に映像や音声を配信する仕組みです。 再変換を行わないため、マシンリソースを節約することが可能です。 今後 WebRTC には SVC を使った Simulcast といった、再変換なしで視聴者の環境毎に画質などを選択できる仕組みが入ります。 SFU を起点にすることで配信者は SVC 形式の映像を SFU に送る事で SFU が視聴者の環境にあった品質の映像を配信してくれるようになります。 Simulcast --------- Simulcast は視聴者毎に適切な品質の映像を配信する仕組みです。 つまり遅い回線の視聴者には画質を抑えて提供し、早い回線の視聴者には高画質で映像を提供します。 SVC --- SVC は Simulcast を実現するための効率の良い仕組みです。高画質な映像から低画質を切り出せます。 一つの高画質な映像から、低画質な映像、中画質な映像などを切り出せる仕組みです。 これを使う事で、複数の画質のデータを転送したり、中間で再エンコードしたりする必要がなくなります。 ただ SVC 当面は導入されることはありません。まずは Simulcast が主流となっていくはずです。 非力なデバイスでの配信 ---------------------- 非力なデバイスなどから動画を配信する場合は、回線も細いため複数の箇所に配信することはできません。 ただ、 SFU 経由で動画を配信すれば、多くの人に配信が可能となります。 TURN の必要性 ------------- SFU があったとしても通信は UDP になります。そのため UDP がうまく外に抜けられる仕組みが無い場合は TURN の仕組みが必要になります。TURN over TCP を使ってそのあと SFU で配信されるようになります。 デモ ==== **この画像は HD 画質ですが、配信は VGA 画質です** .. image:: https://dl.dropboxusercontent.com/u/89936/momo_hd.png https://sora-demo.shiguredo.jp/down.html に対して Firefox または chrome://flags で DTLS 1.2 を有効にして Chrome Canary M48 以上で接続してください。 もしかすると見えないかもしれませんが、そのときは配信してないか、NAT を超えられていないかどちらかです。 ゴール ====== **SFU (+TURN) を目指します** - 最新版の Chrome と Firefox が繋がる WebRTC サーバを製品として提供します。 - メディアチャネルのみの実装とし、データチャネルのスタックは開発しません - サーバ経由での 1:N でのカンファレンス型データ配信を可能にします - SFU 1 台で 1000 までの配信を可能にします - サーバ経由、P2P 経由両方に対応します - TCP しか繋がらない人向けに TURN を組み込みます 動作環境 ======== OS -- **Linux のみに対応します** - CentOS 6.7 64bit - Ubuntu 14.04 64bit - Ubuntu 16.04 64bit (予定) - CentOS 7.1 64bit (予定) Docker イメージでの提供も検討中です。 ブラウザ -------- - Firefox 42 ~ - Chrome M46 ~ - chrome://flags にて DTLS 1.2 を有効にしてください - Chrome M48~ から DLTS 1.2 がデフォルトで有効になるようです 現状 ==== 動作状況 -------- Firefox 40.0.3 にて最大 1:150 の配信が成功しています。 検証環境はグローバルで、さくら VPS の 8 コア 16 G のサーバを使用してテストしてます。 デフォルトの設定で 1:40 配信のテストを行い、サーバのCPU 使用率は 1% 程度。 メモリは 120 MB 程度使っていました。かなり軽量な方だと思います。 ロードマップ ============ **年内は Firefox 最新版のみの対応とします** 2.0.0 ----- **未定** - [ ] Simulcast への対応 - Chrome と Firefox が実装してくる予定 - a=simulcast にて対応 - [ ] TURN を組み込む - [ ] Multistream に対応する - [ ] H.264 での録画機能を可能とする - [ ] VP8 での録画機能を可能とする 1.0.0 ----- **2015 年内** - [ ] RTP/RTCP 直接収容を可能とする - [ ] RTCP 集約方式に対応する - [ ] Chrome での画質安定化 0.6.0 ----- - [ ] 映像と音声両方に対応する 0.5.0 ----- **2015-11-04 完了** **先行版リリース** - [x] Stream API - 1 分間隔での接続状態 - WebRTC レイヤーでの切断 - WebRTC レイヤーでの接続済み - WebRTC レイヤーでの接続中 - [x] Event API - アクセストークン認証を委譲する - [x] Action API - 指定したチャネル ID の接続一覧を取得する - 指定した接続を切断する - 指定したチャネル ID の接続を全て切断する 0.4.0 ----- **2015-10-21 完了** - [x] ECDSA に対応する - [x] Chrome Canary M48 での動作 - [x] Chrome での安定配信 0.3.0 ----- **2015-10-11 完了** - [x] 高解像度に対応する - [x] 長時間配信に対応する - [x] RTCP 転送方式に対応する 0.2.0 ----- **2015-10-02 完了** - [x] 映像のみの配信に対応する - [x] Chrome M45 で DTLS 1.2 を有効にすれば動作する - [x] Firefox 41 に対応する - [x] VP8 での配信に対応する - [x] クライアントの RTCP を一端クライアントに送る - [x] RTCP-FIR を 500 ミリ秒間隔で間引きする 0.1.0 ----- **2015-09-06 完了** - [x] ある程度のデモが可能なレベルまで持って行く - [x] 映像のみ - [x] サーバ経由での 1:N 接続を可能とする - [x] 接続時に RTCP-FIR を発行する 実装 ==== **Erlang/OTP 18.1 にて実装中** DTLS ---- **フルスクラッチで実装** .. image:: https://dl.dropboxusercontent.com/u/89936/gist/stun_dtls_pcap.png - 実装済 - WebRTC に特化した DTLS を実装 - 機能は少ないが WebRTC の暗号化機能は満たす - 最新の Firefox/Chrome に追従していく - use_srtp 拡張対応済 - DTLS 1.2 のみ対応 - Chrome Canary M48 にて対応済み - Chrome M48-49 や Firefox 43 以降で ECDSA がデフォルトになる - 対応暗号スイート - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - 実装済みだが OpenSSL 非対応 未実装 ^^^^^^ - 再接続 性能試験 ^^^^^^^^ 1 接続、ClientHello から Finsihed まで、 110 ミリセック程度。実運用上特に問題なし。 SRTP/SRTCP ---------- **フルスクラッチで実装** - 実装中 - AES-128-CTR + HMAC-SHA1 での暗号、ハッシュ方式に対応 - SRTP/SRTCP 復号化/暗号化完了 性能試験 ^^^^^^^^ RFC 3711 のテストベクターを使って AES-128-CTR でマイクロベンチマークを取ってみた `B.2. AES-CM Test Vectors <https://tools.ietf.org/html/rfc3711#appendix-B.2>`_ :暗号化: 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 <https://github.com/erlang/otp/pull/880>`_ ICE --- **Offer/Anser** - 実装済 - 当面は WebSocket のみ - 未実装 - type: candidate の追加 - 将来的に XHR へのダウングレードを実装予定 - WS が接続できない場合は XHR だけで処理する仕組み SDP --- **ICE や DTLS-SRTP 対応済み** - 実装済 - 将来的に Unified Plan と PlanB を吸収する Multistream 対応予定 シグナリング ------------ **SFU ではシグナリングが一体化する** - 残念ながらオリジナル仕様 - サーバ側から Offer を出す方式です - JavaScript ライブラリも提供予定 - sora.js を OSS (Apache 2.0) にて提供予定 - https://github.com/shiguredo/sora.js にて公開予定 - 配信者と視聴者で実装が変わる - シグナリングサーバの仕様を公開 その他 ------ - 認証 - 認証の仕組みを用意します - 将来的には認証機能の Proxy も想定しています - 課金 - 時間単位での課金の仕組みを追加するプラグインを提供します TURN/STUN --------- SFU といっても TURN サーバは必要になるため組み込みオプション機能として提供予定。 `時雨堂 TURN/STUN サーバー開発ログ <https://gist.github.com/voluntas/47c041e8644afa2fea8d>`_ シグナリング仕様 ================ **この仕様はまだ確定していません** WebSocket + JSON で実現する。 connect -------- 配信者が upstream で視聴者が downstream です .. code-block:: json { "type": "connect", "role": "upstream", "channelId": "spam", "accessToken": "..." } .. code-block:: json { "type": "connect", "role": "downstream", "channelId": "egg", "accessToken": "..." } offer ----- .. code-block:: json { "type": "offer", "sdp": "...", "clientId": "..." } answer ------ .. code-block:: json { "type": "answer", "sdp": "..." } candidate --------- **未実装** .. code-block:: json { "type": "candidate", "sdp": "..." } API === Stream API ---------- Stream API はアプリケーションが Sora に対して WebSocket を張ります。 そこから Sora の状態の変化を受け取ることができます。 - 切断 (disconnected) - 接続中 (connecting) - 接続成功 (connected) - 経過時間 (elaspedTime) - minutes でその接続の経過時間がわかります :: { channelId: "sora", clientId: "{52f91ff8-e670-407f-8e95-f32b91ea6b50}", datetime: "2015-11-01T14:22:21.586578Z", type: "disconnected" } { channel_id: "sora", client_id: "{02d7235b-72af-41c2-8327-2279697b6323}", connected: 1, datetime: "2015-11-01T14:22:23.649052Z", minutes: 1, role: "downstream", type: "elapsedTime" } { channelId: "sora", clientid: "{02bd776c-46da-4236-b4ad-1952a919fab1}", connected: 1, datetime: "2015-11-01T14:22:28.021175Z", role: "upstream", type: "connecting" } { channelId: "sora", clientid: "{02bd776c-46da-4236-b4ad-1952a919fab1}", connected: 1, datetime: "2015-11-01T14:22:28.099071Z", role: "upstream", type: "connected" } { channel_id: "sora", client_id: "{02d7235b-72af-41c2-8327-2279697b6323}", connected: 1, datetime: "2015-11-01T14:23:23.652149Z", minutes: 2, role: "downstream", type: "elapsedTime" } { channel_id: "sora", client_id: "{02bd776c-46da-4236-b4ad-1952a919fab1}", connected: 1, datetime: "2015-11-01T14:23:28.085810Z", minutes: 1, role: "upstream", type: "elapsedTime" } この状態をリアルタイムに受け取ることにより、アプリ側で好き放題できます。 - 一定時間が経過したら切断する - 10 分ごとに 10 円課金する Event API --------- Event API は Sora がアプリケーションに対してリクエストを発行する API です。 主に同期的な判断が必要なときに使用されます。 auth_url という設定でどこの URL を叩きに行くか指定できます。 たとえば {auth_url, "http://127.0.0.1:5000/auth"} と指定した場合はこの URL に対して POST で以下のような JSON を送ります。 .. code-block:: json { "role": "upstream", "channelId": "ChannelId", "accessToken": "{0ac29f4c-526b-4074-a06a-ec7c87eacf32}", "connected": 6 } アプリケーションはこの JSON を受け取ったら独自で判断をし、認証が成功した場合は 200 OK を返します。 認証が失敗した場合は 200 OK 以外を返してください。 - connected は「現在そのチャネルに接続している接続数」です - role は upstream (配信者) か downstream (視聴者) です - accessToken は認証用の判断材料です Action API ---------- Action API は Sora が持っている HTTP API です。 切断や情報取得などがメインになります。 指定したチャネルの接続をすべて切断する:: $ http POST 127.0.0.1:5002 'x-sora-target:Sora_20151104.DisconnectChannel' channelId=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:5002 User-Agent: HTTPie/0.9.2 x-sora-target: Sora_20151104.DisconnectChannel { "channelId": "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:5002 'x-sora-target:Sora_20151104.Disconnect' channelId=sora 'clientId={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:5002 User-Agent: HTTPie/0.9.2 x-sora-target: Sora_20151104.Disconnect { "channelId": "sora", "clientId": "{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:5002 'x-sora-target:Sora_20151104.ListConnections' 'channelId=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:5002 User-Agent: HTTPie/0.9.2 x-sora-target: Sora_20151104.ListConnections { "channelId": "sora" } HTTP/1.1 200 OK content-length: 221 content-type: application/json date: Sun, 01 Nov 2015 12:09:30 GMT server: Cowboy [ { "clientId": "{cc26da43-efb1-45c3-921e-a1fd08d4a2ea}", "role": "downstream" }, { "clientId": "{0de8e7fd-c9df-4ed4-bff0-16330975fc14}", "role": "downstream" }, { "clientId": "{1744d031-1c23-4167-b85a-9a84fa17acf3}", "role": "upstream" } ] 価格体系 ======== **未定です** 詳しくは contact at shiguredo.jp まで。 サーバライセンス ---------------- SFU ^^^ SFU 自体の費用 - 同時 300 接続 - 1 ライセンス 240 万 / 年 / 台 - 以下の条件にて最大 20% オフ - 会社名開示許可 10% オフ - 案件名開示許可 10% オフ - 100 接続追加ごとに + 60 万円 / 年 - 追加ライセンスは値下げなし - 最大 1000 接続 - 1 チャンネルの最大接続数は 150 プラットフォームライセンス -------------------------- SFU を使ったプラットフォームを自社で持ちたい人向けのプランです。 興味ある方、お問い合わせください。 紹介 ==== - `Real time Media streaming Web technologies <http://www.slideshare.net/bulbulpaul/real-time-media-streaming-web-technologies>`_ - WebRTC SFU Sora を紹介していただきました - `WebRTC SFU をフルスクラッチで作ってみた <https://gist.github.com/voluntas/926bc137181ea208799d>`_ - WebRTC Meetup Japan #1 で発表してきました -
Nov 5, 2015 . 1 changed file with 1 addition and 0 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -393,6 +393,7 @@ You don't have to add another hop through a network. ==== - `時雨堂 WebRTC SFU Sora 開発ログ <https://gist.github.com/voluntas/e914aa245fc26f3133c2>`_ - `WebRTC SFU Sora <http://sora.shiguredo.jp/>`_ ------------ -
Nov 5, 2015 . 1 changed file with 0 additions and 4 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -213,12 +213,8 @@ Supports Firefox and Chrome Application layer RTCP packets. WS デバッガーも見せる。 http://bit.ly/sora-demo ----------------- Show a demo running the WebRTC SFU locally. -
Nov 4, 2015 . 1 changed file with 2 additions and 0 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -213,6 +213,8 @@ Supports Firefox and Chrome Application layer RTCP packets. WS デバッガーも見せる。 http://192.168.10.9:5000/down.html http://bit.ly/sora-demo http://bit.ly/sora-sfu -
Nov 4, 2015 . No changes.There are no files selected for viewing
-
Nov 4, 2015 . 1 changed file with 4 additions and 0 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -213,6 +213,10 @@ Supports Firefox and Chrome Application layer RTCP packets. WS デバッガーも見せる。 http://bit.ly/sora-demo http://bit.ly/sora-sfu ----------------- Show a demo running the WebRTC SFU locally. -
alanmshelly revised this gist
Nov 4, 2015 . 1 changed file with 1 addition and 10 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -235,16 +235,7 @@ RTCP 問題 / RTCP Problem ------------------- Currently all Receiver Reports are being sent so they are thinned. The broadcaster and SFU close SR->RR after thinning. The RRs from the receivers are gathered at the SFU, and when the SFU creates an RR it is based on all of the RRs from the receivers. 特徴 / Characteristics =============== -
Nov 4, 2015 . 1 changed file with 119 additions and 171 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -107,28 +107,47 @@ SDP パーサを実装する / SDP Parser Needed for both sending and receiving. Handling text is annoying. Tried a bunch of SDP parsers. I found no problems so done. STUN ライブラリ / STUN Library ----------------- すでに実装してたので ICE に対応させて終わり。 --------------------- I'd already written one so I made it support ICE and I was done. RTP ライブラリ / RTP Library -------------- すでに持っていたがいけてなかったのでほぼ書き直し。かなりの頻度で書き直したり機能追加したりした。 ------------------------- The one I had wasn't very good so I rewrote it almost completely. I rewrote it/added new features quite often. SRTP ライブラリ / SRTP library --------------- SRTCP 系の対応が死にそうになる。独自すぎる。一通り退治して実際に WebRTC の SRTP パケットを受け取って無事動く。確認は明らかに変な値じゃないかを確認する。暗号系の怖いところはとりあえず復号はできてしまうところを。 間違ってるかどうかはアプリでしか判断できない。 --------------------- Almost died trying to support SRTCP. It's too unique. I eventually got it to accept WebRTC SRTP packets. Confirmed by reading the values and making sure they weren't obviously wrong. The scary part about encryption is you can decrypt anything but not know if its right. You can only test if its working or not using the application. WebRTC SFU に着手 / Started on the WebRTC SFU ----------------- とりあえず作ったライブラリを組み上げてみる。シグナリングサーバーがいないとダメなので組み上げたらシグナリングサーバーの開発へ。 ------------------ Started putting together the libraries I'd developed. I needed a signalling server so I went on to develop the signalling server. シグナリングサーバーの開発 / Developing the Signalling Server -------------------------- SkyWay で経験していたが方向が逆向きなので一から設計。WebRTC SFU では SFU から Offer を出す。 @@ -137,7 +156,15 @@ SkyWay で経験していたが方向が逆向きなので一から設計。WebR まずは WebSocket だけで対応。XHR へのダウングレードは後回し。 ------------------------ The implementation is the opposite of the one for SkyWay so I had to design from scratch. The WebRTC SFU creates an offer at the SFU. Also quickly implemented an scheme that let me decide on authentication later. First support just WebSockets. Will implement downgrade to XHR later. シグナリングサーバーを組み込む / Integration with the Signalling Server ------------------------------ 認証は後回し。動くところまで持っていく。 @@ -150,83 +177,7 @@ SkyWay で経験していたが方向が逆向きなので一から設計。WebR 無事動作するようになる。 -------------------------- Authentication comes later. Just get it working. @@ -238,59 +189,77 @@ Add logic to send FIR from the SFU to the broadcaster when a receiver's DTLS fin Works properly. パケットの解析/ Packet Analysis -------------- RTP/RTCP が生で見られるようになったのでパースできてないのを実装したりする。 いつも通り WS デバッガーをくっつけて流れてるパケットを WS で気軽に閲覧できるようにする。 Firefox と Chrome の Application layer な RTCP に対応数。 --------------------- I could now see raw RTP/RTCP packets so I decided to parse them. Make it so that I could connect with a WS debugger and see the packets. Supports Firefox and Chrome Application layer RTCP packets. デモ / Demo ==== ここで WebRTC SFU のローカルでの起動デモを見せる。 WS デバッガーも見せる。 ----------------- Show a demo running the WebRTC SFU locally. Show the WS debugger as well. 課題 / Problems ==== それといった課題はあまりないが、明示的に解決しなければいけないのは RTCP の代理返信。 ------------------- No major problems but one part I have to explicitly fix is the RTCP proxy responses. RTCP 問題 / RTCP Problem --------- 今は RR を全部送ってるので間引きする。間引き後は SR->RR は配信者と SFU で閉じる。視聴者からの RR は SFU で集約して SFU の RR 生成時に全体の総意を汲み取りつつ反映する。 ------------------- Currently all RRs are being sent and being culled. The broadcaster and SFU close SR->RR after culling. The RRs from the receivers are gathered at the SFU, and when the SFU creates an RR it is based on all of the RRs from the receivers. Problems ========= RTCP Problem -------------- Currently all RRs are being sent and being culled. The broadcaster and SFU close SR->RR after culling. The RRs from the receivers are gathered at the SFU, and when the SFU creates an RR it is based on all of the RRs from the receivers. 特徴 / Characteristics =============== **自社製品の宣伝です** アプリとの連携がキモなので連携部分を重要視した。 ------------------------ **This is advertising for our product** Connecting with apps is fundamental so we focused especially on the API. ステートフル、データレス / Stateful, dataless ------------------------ サーバ自体には一切情報を追加したりせず、起動したらすぐ使える。 @@ -300,76 +269,71 @@ Currently all RRs are being sent and being culled. The broadcaster and SFU close データを持たないため、台数さえ増やせばいいのでスケールさせやすい。 -------------------- The server itself doesn't add any data and can be used as soon as it starts. I want to authenticate connections. I want to limit connections per channel. I want to limit connection time. The WebRTC SFU delegates all of this so it can be implemented in the application. Since it doesn't hold any data, you can easily scale out by adding servers. ストリーム API / Stream API -------------- WebRTC SFU に WS で接続することで、クライアントの接続や、一定間隔での接続時間の通知などステートが変化したときにストリームでデータを送ってくる。 リアルタイムにアプリ側で判断が可能。 ------------------- It is possible to get state change information such as clients connecting or connection time by connecting sent to you by connecting via WS. It is possible to make decisions in real time in the application. アクション API / Action API -------------- SFU に対して叩く API でチャネル単位での全員切断や、指定した接続の切断。さらにチャネルの接続一覧などがとれる。 アプリはストリーム API でリアルタイムに受け取るステート変化に対してアクションを起こすことが可能になる。 -------------------- It is possible to call an API to disconnect a single, multiple or all clients connected to each channel. You can also get a list of clients connected to a channel. The application can use the information received from the stream API to detect a change in state and take action. イベント API / Event API ------------ 認証などの同期的に判断が必要なのは指定した HTTP API を叩いてくれ、200 だったら OK という動作をする。 全てアプリ側で判断できるため、データベースに悩む必要が無い。 ----------- If you need something synchronous such as authentication, call an HTTP API and if the response is 200 then it will proceed as OK. It's all handled in the application so you don't have to worry about a database. 今後 / TODO ==== 録画 / Recording ---- VP8 であれば WebM 形式での保存を目指す。ただ H.264 がメインになる可能性があるのでまだ様子見。 おもしろい機能ではあるので、対応はしていきたい。 ----------- If it's VP8, I want to write to a WebM file. That being said, H.264 might become the main so I'm still waiting. It's an interesting features so I want to implement it for sure. H.264 ----- @@ -379,43 +343,7 @@ SDP 部分しか影響ないのでそこを接続時に切り替える。 配信者がフォーマットを選べるようにする。 --------------- It will be good if Chrome supports H.264 since H.264 has a lot of hardware support. @@ -424,35 +352,55 @@ It only affects the SDP so I can change it there when connecting. I'll make it so that the broadcaster can choose. Multistream ----------- 閲覧者が複数の配信を Multistream で同時に見れるようにする。 これは複数カメラの配置に対して需要がありそうなので前倒しで実装していく予定。 ------------ Make it so that the viewers can receive multiple streams simultaneously using multistream. It looks like it there is a large need to use this with multiple cameras so I will increase priority. 音声 / Audio ---- 年末までには実装。別に難しくない。 -------- By the end of the year. It's not that difficult. Simulcast --------- Firefox に来たらすぐに対応。 ---------- I will implement as soon as it comes to Firefox. TURN/STUN --------- 自前開発があるので、SFU に組み込む。 主に TCP -> UDP への変換が目的になるが、 SFU に組み込むことで TCP -> TURN -> SFU -> UDP みたいにできる。 わざわざ一回ネットワークを経由しなくて良くなる。 ---------- I have an implementation so I will integrate into the SFU. Mostly for converting TCP->UDP but by integrating it into the SFU, you can do TCP->TURN->SFU->UDP. You don't have to add another hop through a network. 参考 / Reference ==== - `時雨堂 WebRTC SFU Sora 開発ログ <https://gist.github.com/voluntas/e914aa245fc26f3133c2>`_ ------------ - `Shiguredo WebRTC SFU Sora Development log <https://gist.github.com/voluntas/e914aa245fc26f3133c2>`_ -
Nov 4, 2015 . 1 changed file with 40 additions and 12 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -13,40 +13,38 @@ I wrote a WebRTC SFU from scratch Presentation materials for `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ on 2015/11/04. 自己紹介 / Self Introduction ======== `時雨堂 <https://shiguredo.jp>`_ という零細企業を経営しています。 twitter は @voluntas -------------------- I run a small company named `Shiguredo <https://shiguredo.jp>`_ twitter account is @voluntas モチベーション / Motivation ============== - 日本だと誰も作ってなさそうだったし、面白そうだと思ったから。 - テレビ会議システムにはあまり興味なく配信システムに興味があった。 - 音声や映像のリアルタイムな共有に興味があった - Erlang による DTLS の実装のめどがついたから。 --------------------- - No one in Japan had done it and it seemed fun. - I didn't have any interest in conference systems but I was interested in broadcasting systems. - I was interested in realtime voice and video sharing. - I had figured out how to implement DTLS in Erlang. 実装の流れ / Development Timeline ================================== DTLS 1.0 を実装する / Implementing DTLS 1.0 ------------------- Erlang には DTLS の実装がまだ公式にないこと、TLS は実装経験があるのでなんとかなると思ってた。前職で UDP 上で TLS を実現する EAP-TLS とかを書いていた。 @@ -59,8 +57,20 @@ CipherSuites は決め打ちした。ECDHE で RSA そして AES-CBC で実装 実装終わって openssl でテストして動作した。 --------------------------- Erlang doesn't have an official DTLS implementation but I had experience implementing TLS. I'd written EAP-TLS to implement TLS over UDP at my previous job. Chrome still uses DTLS 1.0 so start with 1.0. It's UDP so there are some small differences such as sequence numbers being used. DTLS 1.0 is based on TLS 1.1. CiperSuites is hardcoded. RSA and AES-CBC are implemented using ECDHE. After finishing implementation, I tested with openssl. DTLS 1.2 を実装する / Implementing DTLS 1.2 ---------------------------------------------- 今後考えるとやっておきたい、ということで実装。 @@ -73,12 +83,30 @@ Chrome M47 から徐々に DTLS 1.2 になる模様。Firefox はすでに DTLS SRTP を組み込んだので、ライブラリ的には DTLS-SRTP ライブラリ。 ----------------------------- I implemented it as it will be useful in the future. I also added support for AEAD while I was at it. Decided on AES-GCM and CHACHA20. Tests passed after implementing... but I started to think the DTLS 1.0 code was unnecessary. I deleted all of it and left only the DTLS 1.2 code, predicting Chrome would catch up. It looks like Chrome will start including DTLS 1.2 from M47. Firefox also has DTLS 1.2. It is bundled with SRTP so the library is a DTLS-SRTP library. SDP パーサを実装する / SDP Parser -------------------- 投げるにしても受け取るにしても必要ということで作る。文字列はだるい。 いろいろな SDP をパーサに食べさせてテスト、問題なさそうということで完成。 ------------------------ Needed for both sending and receiving. Handling text is annoying. Tried a bunch of SDP parsers. I found no problems so done. ## STUN ライブラリ すでに実装してたので ICE に対応させて終わり。 -
Nov 2, 2015 . 1 changed file with 137 additions and 0 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -186,6 +186,38 @@ You can only test if its working or not using the application. Started on the WebRTC SFU ---------------------------- Started putting together the libraries I'd developed. I needed a signalling server so I went on to develop the signalling server. Signalling Server development ------------------------------- The implementation is the opposite of the one for SkyWay so I had to design from scratch. The WebRTC SFU creates an offer at the SFU. Also quickly implemented an scheme that let me decide on authentication later. First support just WebSockets. Will implement downgrade to XHR later. Integration with the Signalling Server ---------------------------------------- Authentication comes later. Just get it working. Try with just the broadcaster first. Work on it until it looks like the SFU is decoding properly. Next add the receivers. I realized here that if a receiver wasn't connected first, then the stream wouldn't show. I got advice that I need to send FIR. Add logic to send FIR from the SFU to the broadcaster when a receiver's DTLS finishes. In order to handle large numbers of simultaneous connections, I limited the FIRs to send a maximum of once every 500ms. Works properly. Packet Analysis ---------------- I could now see raw RTP/RTCP packets so I decided to parse them. Make it so that I could connect with a WS debugger and see the packets. Supports Firefox and Chrome Application layer RTCP packets. デモ @@ -195,6 +227,13 @@ Started on the WebRTC SFU WS デバッガーも見せる。 Demo ==== Show a demo running the WebRTC SFU locally. Show the WS debugger as well. 課題 ==== @@ -205,6 +244,17 @@ RTCP 問題 今は RR を全部送ってるので間引きする。間引き後は SR->RR は配信者と SFU で閉じる。視聴者からの RR は SFU で集約して SFU の RR 生成時に全体の総意を汲み取りつつ反映する。 Problems ========= No major problems but one part I have to explicitly fix is the RTCP proxy responses. RTCP Problem -------------- Currently all RRs are being sent and being culled. The broadcaster and SFU close SR->RR after culling. The RRs from the receivers are gathered at the SFU, and when the SFU creates an RR it is based on all of the RRs from the receivers. 特徴 ==== @@ -243,6 +293,45 @@ SFU に対して叩く API でチャネル単位での全員切断や、指定 全てアプリ側で判断できるため、データベースに悩む必要が無い。 Characteristics =============== **This is advertising for our product** Connecting with apps is fundamental so we focused especially on the API. Stateful, dataless ------------------- The server itself doesn't add any data and can be used as soon as it starts. I want to authenticate connections. I want to limit connections per channel. I want to limit connection time. The WebRTC SFU delegates all of this so it can be implemented in the application. Since it doesn't hold any data, you can easily scale out by adding servers. Stream API ------------- It is possible to get state change information such as clients connecting or connection time by connecting sent to you by connecting via WS. It is possible to make decisions in real time in the application. Action API ------------ It is possible to call an API to disconnect a single, multiple or all clients connected to each channel. You can also get a list of clients connected to a channel. The application can use the information received from the stream API to detect a change in state and take action. Event API ----------- If you need something synchronous such as authentication, call an HTTP API and if the response is 200 then it will proceed as OK. It's all handled in the application so you don't have to worry about a database. 今後 ==== @@ -287,7 +376,55 @@ TURN/STUN わざわざ一回ネットワークを経由しなくて良くなる。 TODO ===== Recording ---------- If it's VP8, I want to write to a WebM file. That being said, H.264 might become the main so I'm still waiting. It's an interesting features so I want to implement it for sure. H.264 ------ It will be good if Chrome supports H.264 since H.264 has a lot of hardware support. It only affects the SDP so I can change it there when connecting. I'll make it so that the broadcaster can choose. Multistream ------------ Make it so that the viewers can receive multiple streams simultaneously using multistream. It looks like it there is a large need to use this with multiple cameras so I will increase priority. Audio -------- By the end of the year. It's not that difficult. Simulcast ---------- I will implement as soon as it comes to Firefox. TURN/STUN ---------- I have an implementation so I will integrate into the SFU. Mostly for converting TCP->UDP but by integrating it into the SFU, you can do TCP->TURN->SFU->UDP. You don't have to add another hop through a network. 参考 ==== - `時雨堂 WebRTC SFU Sora 開発ログ <https://gist.github.com/voluntas/e914aa245fc26f3133c2>`_ Reference ========== - `Shiguredo WebRTC SFU Sora Development log <https://gist.github.com/voluntas/e914aa245fc26f3133c2>`_ -
Nov 2, 2015 . 1 changed file with 29 additions and 2 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -131,8 +131,8 @@ RTP/RTCP が生で見られるようになったのでパースできてない Firefox と Chrome の Application layer な RTCP に対応数。 Development Timeline ===================== Implementing DTLS 1.0 ----------------------- @@ -161,6 +161,33 @@ It looks like Chrome will start including DTLS 1.2 from M47. Firefox also has DT It is bundled with SRTP so the library is a DTLS-SRTP library. SDP Parser ----------- Needed for both sending and receiving. Handling text is annoying. Tried a bunch of SDP parsers. I found no problems so done. ## STUN library I'd already written one so I made it support ICE and I was done. RTP library ----------- The one I had wasn't very good so I rewrote it almost completely. I rewrote it/added new features quite often. SRTP library ------------- Almost died trying to support SRTCP. It's too unique. I eventually got it to accept WebRTC SRTP packets. Confirmed by reading the values and making sure they weren't obviously wrong. The scary part about encryption is you can decrypt anything but not know if its right. You can only test if its working or not using the application. Started on the WebRTC SFU ---------------------------- デモ ==== -
Nov 2, 2015 . 1 changed file with 40 additions and 1 deletion.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -10,7 +10,8 @@ I wrote a WebRTC SFU from scratch :url: https://voluntas.github.io/ 2015 年 11 月 04 日に行われる `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ 向けの発表資料です。 Presentation materials for `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ on 2015/11/04. 自己紹介 ======== @@ -34,6 +35,14 @@ twitter account is @voluntas - 音声や映像のリアルタイムな共有に興味があった - Erlang による DTLS の実装のめどがついたから。 Motivation ========== - No one in Japan had done it and it seemed fun. - I didn't have any interest in conference systems but I was interested in broadcasting systems. - I was interested in realtime voice and video sharing. - I had figured out how to implement DTLS in Erlang. 実装の流れ ========== @@ -122,6 +131,36 @@ RTP/RTCP が生で見られるようになったのでパースできてない Firefox と Chrome の Application layer な RTCP に対応数。 Implementation =============== Implementing DTLS 1.0 ----------------------- Erlang doesn't have an official DTLS implementation but I had experience implementing TLS. I'd written EAP-TLS to implement TLS over UDP at my previous job. Chrome still uses DTLS 1.0 so start with 1.0. It's UDP so there are some small differences such as sequence numbers being used. DTLS 1.0 is based on TLS 1.1. CiperSuites is hardcoded. RSA and AES-CBC are implemented using ECDHE. After finishing implementation, I tested with openssl. Implementing DTLS 1.2 ---------------------- I implemented it as it will be useful in the future. I also added support for AEAD while I was at it. Decided on AES-GCM and CHACHA20. Tests passed after implementing... but I started to think the DTLS 1.0 code was unnecessary. I deleted all of it and left only the DTLS 1.2 code, predicting Chrome would catch up. It looks like Chrome will start including DTLS 1.2 from M47. Firefox also has DTLS 1.2. It is bundled with SRTP so the library is a DTLS-SRTP library. デモ ==== -
Nov 2, 2015 . 1 changed file with 3 additions and 2 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -1,15 +1,16 @@ ####################################### WebRTC SFU をフルスクラッチで作ってみた ####################################### I wrote a WebRTC SFU from scratch :Author: @voluntas :Translator: @alanmshelly :Version: 0.0.0 :url: https://voluntas.github.io/ 2015 年 11 月 04 日に行われる `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ 向けの発表資料です。 Presentation materials for `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ on 2015/11/04 自己紹介 ======== -
Nov 2, 2015 . 1 changed file with 12 additions and 2 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -1,12 +1,15 @@ ####################################### WebRTC SFU をフルスクラッチで作ってみた I wrote a WebRTC SFU from scratch ####################################### :Author: @voluntas :Translator: @alanmshelly :Version: 0.0.0 :url: https://voluntas.github.io/ 2015 年 11 月 04 日に行われる `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ 向けの発表資料です。 Presentation materials for `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>` on 2015/11/04 自己紹介 ======== @@ -15,6 +18,13 @@ WebRTC SFU をフルスクラッチで作ってみた twitter は @voluntas Self Introduction ======== I run a small company named `Shiguredo <https://shiguredo.jp>`_ twitter account is @voluntas モチベーション ============== -
Oct 30, 2015 . 1 changed file with 1 addition and 1 deletion.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -174,7 +174,7 @@ SFU に対して叩く API でチャネル単位での全員切断や、指定 VP8 であれば WebM 形式での保存を目指す。ただ H.264 がメインになる可能性があるのでまだ様子見。 おもしろい機能ではあるので、対応はしていきたい。 H.264 ----- -
Oct 30, 2015 . 1 changed file with 72 additions and 2 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -121,11 +121,51 @@ WS デバッガーも見せる。 課題 ==== それといった課題はあまりないが、明示的に解決しなければいけないのは RTCP の代理返信。 RTCP 問題 --------- 今は RR を全部送ってるので間引きする。間引き後は SR->RR は配信者と SFU で閉じる。視聴者からの RR は SFU で集約して SFU の RR 生成時に全体の総意を汲み取りつつ反映する。 特徴 ==== **自社製品の宣伝です** アプリとの連携がキモなので連携部分を重要視した。 ステートフル、データレス ------------------------ サーバ自体には一切情報を追加したりせず、起動したらすぐ使える。 接続の認証がしたい、チャネル単位で接続数制限がしたい、時間制限がしたい。 全て WebRTC SFU がデリゲーションしてくるので、アプリ側で実装可能。 データを持たないため、台数さえ増やせばいいのでスケールさせやすい。 ストリーム API -------------- WebRTC SFU に WS で接続することで、クライアントの接続や、一定間隔での接続時間の通知などステートが変化したときにストリームでデータを送ってくる。 リアルタイムにアプリ側で判断が可能。 アクション API -------------- SFU に対して叩く API でチャネル単位での全員切断や、指定した接続の切断。さらにチャネルの接続一覧などがとれる。 アプリはストリーム API でリアルタイムに受け取るステート変化に対してアクションを起こすことが可能になる。 イベント API ------------ 認証などの同期的に判断が必要なのは指定した HTTP API を叩いてくれ、200 だったら OK という動作をする。 全てアプリ側で判断できるため、データベースに悩む必要が無い。 今後 ==== @@ -134,13 +174,43 @@ RTCP 問題 VP8 であれば WebM 形式での保存を目指す。ただ H.264 がメインになる可能性があるのでまだ様子見。 おもしろい機能ではあるので、堂的にやれる。 H.264 ----- Chrome が H.264 になると強い。HW が H.264 なのが多いため。 SDP 部分しか影響ないのでそこを接続時に切り替える。 配信者がフォーマットを選べるようにする。 Multistream ----------- 閲覧者が複数の配信を Multistream で同時に見れるようにする。 これは複数カメラの配置に対して需要がありそうなので前倒しで実装していく予定。 音声 ---- 年末までには実装。別に難しくない。 Simulcast --------- Firefox に来たらすぐに対応。 TURN/STUN --------- 自前開発があるので、SFU に組み込む。 主に TCP -> UDP への変換が目的になるが、 SFU に組み込むことで TCP -> TURN -> SFU -> UDP みたいにできる。 わざわざ一回ネットワークを経由しなくて良くなる。 参考 ==== - `時雨堂 WebRTC SFU Sora 開発ログ <https://gist.github.com/voluntas/e914aa245fc26f3133c2>`_ -
Oct 30, 2015 . 1 changed file with 10 additions and 13 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -18,11 +18,10 @@ twitter は @voluntas モチベーション ============== - 日本だと誰も作ってなさそうだったし、面白そうだと思ったから。 - テレビ会議システムにはあまり興味なく配信システムに興味があった。 - 音声や映像のリアルタイムな共有に興味があった - Erlang による DTLS の実装のめどがついたから。 実装の流れ ========== @@ -36,9 +35,7 @@ Chrome がまだ DTLS 1.0 なのでまずは 1.0 から。 UDP なのでシーケンス番号が入ってきたり少しずつ違う。DTLS 1.0 は TLS 1.1 ベース。 CipherSuites は決め打ちした。ECDHE で RSA そして AES-CBC で実装。 実装終わって openssl でテストして動作した。 @@ -51,16 +48,16 @@ DTLS 1.2 を実装する 実装終わってテスト通った。ただ DTLS 1.0 邪魔だなと思い始める。 全消しして 1.2 のみのコードにする。Chrome は追従するだろうと読む。 Chrome M47 から徐々に DTLS 1.2 になる模様。Firefox はすでに DTLS 1.2 。 SRTP を組み込んだので、ライブラリ的には DTLS-SRTP ライブラリ。 SDP パーサを実装する -------------------- 投げるにしても受け取るにしても必要ということで作る。文字列はだるい。 いろいろな SDP をパーサに食べさせてテスト、問題なさそうということで完成。 ## STUN ライブラリ -
Oct 30, 2015 . 1 changed file with 6 additions and 1 deletion.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -2,11 +2,16 @@ WebRTC SFU をフルスクラッチで作ってみた ####################################### :作: @voluntas :バージョン: 0.0.0 :url: https://voluntas.github.io/ 2015 年 11 月 04 日に行われる `WebRTC Meetup Japan <https://44145dc9ce5b767cd2eb8b7683.doorkeeper.jp/events/33154>`_ 向けの発表資料です。 自己紹介 ======== `時雨堂 <https://shiguredo.jp>`_ という零細企業を経営しています。 twitter は @voluntas -
Oct 30, 2015 . 1 changed file with 0 additions and 0 deletions.There are no files selected for viewing
File renamed without changes. -
Oct 30, 2015 .There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -0,0 +1,144 @@ ####################################### WebRTC SFU をフルスクラッチで作ってみた ####################################### 自己紹介 ======== 時雨堂という零細企業を経営しています。 twitter は @voluntas モチベーション ============== 日本だと誰も作ってなさそうだったし、面白そうだと思ったから。 テレビ会議システムにはあまり興味なく配信システムに興味があった。 Erlang による DTLS の実装のめどがついたから。 実装の流れ ========== DTLS 1.0 を実装する ------------------- Erlang には DTLS の実装がまだ公式にないこと、TLS は実装経験があるのでなんとかなると思ってた。前職で UDP 上で TLS を実現する EAP-TLS とかを書いていた。 Chrome がまだ DTLS 1.0 なのでまずは 1.0 から。 UDP なのでシーケンス番号が入ってきたり少しずつ違う。DTLS 1.0 は TLS 1.1 ベース。 CipherSuites は決め打ちした。 ECDHE で RSA そして AES-CBC 。 実装終わって openssl でテストして動作した。 DTLS 1.2 を実装する ------------------- 今後考えるとやっておきたい、ということで実装。 ついでに AEAD 認証に対応しておきたい。AES-GCM と CHACHA20 に定める。 実装終わってテスト通った。ただ DTLS 1.0 邪魔だなと思い始める。 全消しして 1.2 のみのコードにする。Chrome は追従するだろうと読む。M47 から徐々に DTLS 1.2 になる模様。Firefox はすでに DTLS 1.2 。 SRTP を組み込んだので、ライブラリ的には DTLS-SRTP ライブラリ。 SDP パーサー ------------ 投げるにしても受け取るにしても必要ということで作る。文字列はだるい。 いろいろな SDP を食べさせてテスト、問題なさそうということで完成。 ## STUN ライブラリ すでに実装してたので ICE に対応させて終わり。 RTP ライブラリ -------------- すでに持っていたがいけてなかったのでほぼ書き直し。かなりの頻度で書き直したり機能追加したりした。 SRTP ライブラリ --------------- SRTCP 系の対応が死にそうになる。独自すぎる。一通り退治して実際に WebRTC の SRTP パケットを受け取って無事動く。確認は明らかに変な値じゃないかを確認する。暗号系の怖いところはとりあえず復号はできてしまうところを。 間違ってるかどうかはアプリでしか判断できない。 WebRTC SFU に着手 ----------------- とりあえず作ったライブラリを組み上げてみる。シグナリングサーバーがいないとダメなので組み上げたらシグナリングサーバーの開発へ。 シグナリングサーバーの開発 -------------------------- SkyWay で経験していたが方向が逆向きなので一から設計。WebRTC SFU では SFU から Offer を出す。 さらに接続の認証方式などをあとで考えられるようにしてざっくり実装。 まずは WebSocket だけで対応。XHR へのダウングレードは後回し。 シグナリングサーバーを組み込む ------------------------------ 認証は後回し。動くところまで持っていく。 まずは配信者だけで確認。なんとなくデコードできていそうというところまで持っていく。 次に視聴者を追加。ここで最初に視聴者をつながないと画面が映らないことに気づく。FIR を投げないとダメとアドバイスをいただく。 視聴者の DTLS が完了したタイミングで SFU が FIR を配信者に送る仕組みを入れる。大量接続を踏まえ 500 ms単位で接続を間引きして FIR を送らないようにする仕組みを追加。 無事動作するようになる。 パケットの解析 -------------- RTP/RTCP が生で見られるようになったのでパースできてないのを実装したりする。 いつも通り WS デバッガーをくっつけて流れてるパケットを WS で気軽に閲覧できるようにする。 Firefox と Chrome の Application layer な RTCP に対応数。 デモ ==== ここで WebRTC SFU のローカルでの起動デモを見せる。 WS デバッガーも見せる。 課題 ==== RTCP 問題 --------- 今は RR を全部送ってるので間引きする。間引き後は SR->RR は配信者と SFU で閉じる。視聴者からの RR は SFU で集約して SFU の RR 生成時に全体の総意を汲み取りつつ反映する。 今後 ==== 録画 ---- VP8 であれば WebM 形式での保存を目指す。ただ H.264 がメインになる可能性があるのでまだ様子見。 H.264 対応 ---------- Chrome が H.264 になると強い。HW が H.264 なのが多いため。 SDP 部分しか影響ないのでそこを接続時に切り替える。 配信者がフォーマットを選べるようにする。