############################# WebRTC コトハジメ ############################# :更新: 2021-05-02 :作者: @voluntas :バージョン: 2021.2 :URL: https://voluntas.github.io/ .. image:: https://img.shields.io/badge/License-CC%20BY--NC--ND%204.0-lightgrey.svg :target: https://creativecommons.org/licenses/by-nc-nd/4.0/ **この記事が良いと思ったらこの記事に Star をお願いします。** 著者 ==== `株式会社時雨堂 `_ で 多くの商用環境で利用されている WebRTC SFU を 1 から設計/開発している。WebRTC スタックは暗号ライブラリの利用している部分以外はすべて自前実装。 著者が書いた資料 ---------------- - `WebRTC を今から学ぶ人に向けて `_ - `WebRTCの裏側 `_ - `WebRTC Conference Japan で話してきた `_ - `WebRTC スタックコトハジメ `_ - `WebRTC の未来 `_ - `WebRTC SFU コトハジメ `_ - `WebRTC SFU をフルスクラッチで作ってみた `_ - `リアルタイム動画配信コトハジメ `_ - `詳解 WebRTC `_ - `仕事で WebRTC `_ 間違いや質問について ------------------------ この Gist へのコメントではなく @voluntas まで Twitter にてリプライを飛ばして欲しい。 目的 ==== WebRTC は闇が深く、変化が早い技術だ。そのため公開されている情報はすぐ古くなってしまう。 それらの古い情報を参照して不幸になる開発者を減らすために書いている。 できるだけ最新情報に追従するようにしている。 概要 ==== **ブラウザ同士でリアルタイムコミュニケーションを実現するための仕組み** WebRTC は P2P を利用したブラウザ同士を前提とした技術として作られている。もちろん、WebRTC 自体はプロトコルの組み合わせでしかないため、 P2P を使わなかったり、ブラウザ以外を使ったりすることもできる。 WebRTC の通信プロトコルには TCP ではなく、 UDP が採用されている。これは音声や映像のデータを扱う以外にも、大量のデータを高速に送ることができるようにするためである。 通信はデフォルトで暗号化されており、データグラム向けの TLS である DTLS が採用されている。 直接相手とやりとりをする P2P を実現する機能が含まれており、 NAT 越えを実現する仕組みが含まれる。 NAT 越えをするためのプロトコルには STUN/TURN そしてそれら２つの技術を組み合わせた ICE と呼ばれる仕組みを採用した。 実際に NAT 越えを実現するためには STUN サーバや TURN サーバが必要となる。 通常は TURN/STUN サーバとして 1 台で提供される。 - `WebRTC 1.0: Real-Time Communication Between Browsers `_ - `WebRTC API - Web API | MDN `_ WebRTC という単語について ========================= WebRTC という単語が音声や映像を送受信するプロトコルとして使われることが多くなってきているように感じているので、 整理しておきたい。 まず WebRTC はその名の通り Web でリアルタイムなコミニュケーションをやり取りする技術である。 具体的に定義されたプロトコルの名前ではない。 Web でリアルタイムなコミニュケーションをやりとりするには多くの技術が必要になる。 そのため、 WebRTC を実現するためには数多くのプロトコルが利用されている。 WebRTC は実はデバイス管理やスクリーンキャプチャという概念も含んでいる。 これはリアルタイムなコミニュケーションにはマイクやカメラが必要なためである。 カメラやマイクを使うにはデバイス認識、デバイス選択という機能が必要になる。これも WebRTC の一部だ。 そしてそれらのデバイスから取得した音声や映像をそのまま送ると転送量が大変なことになってしまうため圧縮して送る技術が必要になる。これも WebRTC の一部だ。主にコーデックと呼ばれる技術だ。 さらに、コミニュケーションということは相手が存在するため、 その相手と直接やり取りをするための P2P の技術が必要になる。これも WebRTC の一部だ。 そして最後に、その相手との通信を実現する技術が必要になる。これも WebRTC の一部になる。 WebRTC は沢山の技術の集合体と考えてもらって問題ない。 それらをブラウザから簡単に使えるようにした仕組みが WebRTC API となる。 上記の複雑な仕組みを意識することなく、 JavaScript を 100 行も書かずに実現できるようになっている。 ここで大事なのは WebRTC は用意された API を利用するだけなら難しい技術ではない。 むしろとてもシンプルになっており、使いやすい API だ。 ただその用意されている部分から少しでも逸脱するとハードルが突然あがる。 例えばブラウザ以外で行いたいとか、 用意されているコーデック以外を使いたいとか、内部で利用するプロトコルを変えたいとかだ。 WebRTC はリアルタイムなコミニュケーションを実現するために、 とてつもないめんどくさい技術を利用した技術で、それをブラウザから簡単に使えるようにした技術である。 二つのチャネル ============== WebRTC を説明する際、チャネルの種類が曖昧に説明されてることが多い。 WebRTC にはメディアチャネルとデータチャネルの二つがある。 - 映像と音声のデータ通信方式がメディアチャネル - 好きなデータを放り込めるのがデータチャネル WebRTC とメディアチャネルが同一と表現されることが多いので要注意。 SDP (Session Description Protocol) ------------------------------------- メディアだろうがデータだろうが、お互いの通信を統一するためのプロトコルとして SDP が採用されている。 簡単に言えばメディアでいえば自分は音声をこの形式で送るなどだ。 メディアチャネル ---------------- メディア、つまり映像と音声を送り合う仕組みである。 実態は RTP/RTCP と呼ばれるリアルタイムに映像や音声を配信するプロトコルが採用されている。 RTP はとても古いプロトコルであるが、かなり拡張されており、新しい仕組みが積極的に採用されている。 データチャネル -------------- データチャネルは SCTP をベースとしているため、映像や音声だって取り扱える。むしろ何でもよい。 SCTP は TCP と UDP のいいところ取りをしたプロトコルだと思ってもらってよい。SCTP もなり古いプロトコルだが、残念ながら流行っているとはいえない。SCTP over DTLS over UDP という多重構造になっている。 分散ファイル共有系だと `WebTorrent - Streaming browser torrent client `_ が WebRTC データチャネルを利用している。 CDN 系だと `Peer5 - The Serverless P2P CDN For Video Live Streaming `_ や `Streamroot | Distributed Network Architecture for OTT Video Delivery `_ がサーバレス CDN を提供している。 CDN といっても今回紹介した P2P CDN は全て **動画配信** を前提としている。HLS や MPEG-DASH の配信を CDN と P2P で補完していくという仕組みだ。 また P2P でデータをリアルタイムにやり取りできるという強みから、 ロボットへの組み込みなどでも利用される事もでてきている。 シグナリング ============ WebRTC はよく P2P の技術と呼ばれるがこれは正しい。 ブラウザ同士でデータのやりとりを実現することができる。 ただし、シグナリングと呼ばれる仕組みが必須になる。 シグナリングというのはあまり聞き慣れない言葉だとおもうが、 P2P でやり取りする前に必要な情報をサーバを経由してやり取りする仕組みだ。 実はシグナリングにはいろいろな仕組みがあるのだが、 WebRTC では定義されていないため、ここでは大まかに定義する。 - 通信しようとする相手の IP アドレスの解決 - 相手の名前から IP アドレスを取得するなど。つまりこれから通話する相手の IP アドレスを取得することができるようになる仕組み - 相手がその通信を許可するかどうか - そもそも誰にでも繋がってはいけないので、拒否されているかどうかを判断する仕組み - 通信状態（セッションと呼ぶ）において使用するパラメータの合意 - メディアチャネルであれば、お互いの映像に使うコーデックや最大フレームレートなどの合意をとる仕組み - 証明書のフィンガープリント情報の交換 このいくつかの仕組みをまとめてシグナリングと呼ぶことが多い。 これらのを P2P の接続をする前にやりとりするにはシグナリングサーバが必要になる。 つまりセッションを確立する前に判断しなければいけないため、ブラウザ同士が直接やりとりすることができないからだ。 シグナリングは本来はセッションの終了まで管理すべきであろう。 このあたりは **仕様が決められていない** ため、実装側に任されている。 MCU と SFU ========== WebRTC の世界は P2P を前提として入るが、それとは別に MCU と SFU という世界がある。 これは P2P でやりとりをするのではなく、クライアント・サーバモデルでやりとりをする。 MCU や SFU は WebRTC の標準的な考え方からすると異端ではあるが、一定以上の品質や数を担保する場合は必須となる。 理解を深めたい場合は以下の記事が参考になる。 `WebRTCにおいてP2P/SFU/MCUでビデオ通話品質の差があるか｜tnoho｜note `_ MCU (Multipoint Control Unit) ----------------------------- 昔からある技術で、3 拠点以上でテレビ会議をする場合に使われている。MCU の特徴はサーバによる合成だ。 つまりそれぞれの音声や映像が別に送られてくるのではなく、サーバで合成されて 1 つの音声や映像として送られてくる。 100 人が参加する会議があったとしても、サーバで 1 つに合成される。 良いことだらけだが、合成するためサーバ側のリソースを恐ろしく使うため、最近は MCU から SFU が主軸になっていっている。 また End to End Encryption (E2EE) が MCU では実現できないという問題もある。 SFU (Selective Forwarding Unit) ------------------------------- SFU という単語が出てきたのはここ数年。ただ概念自体は前からある。 以前だとメディアルーターと呼ばれていた。最近でも SFU と呼ばずメディアルーターと呼ぶ場合もある。 SFU は MCU だと CPU リソースを使われてしまうことから考え出された仕組みだ。 クライアントが配信する音声や映像をサーバが代理で他のクライアントやサーバに送るという仕組み。 そのため、クライアントは 10 人参加者がいた場合でもサーバに映像を送るだけで済む。 P2P の場合のフルメッシュと MCU の間の技術でバランスが良い事もあり WebRTC でクライアント・サーバモデルの場合は SFU が選択されることが多い。 SFU の場合は E2EE が採用できる。実際 Google Duo は 3 人以上の場合は WebRTC SFU を利用しながら、E2EE を実現している。 SFU なのか MCU なのか ------------------------ 現時点ではほぼ SFU 一択となる。MCU の場合、高圧縮な映像技術を利用した場合の合成コストが高くなりすぎている。現時点の主要なサービスは SFU のような転送が主体なサーバを利用していると考えてよい。 SFU の課題 ------------------------ よく言われる WebRTC SFU の課題をどう解決しているかをまとめておいたので参考にしてほしい。 全員に同一ビットレートを配信する必要がある Simulcast や SVC を利用することで解決している 大規模配信ができない 多段 (Origin - Edge) にすることで解決している 同時に多くのユーザを視聴できない 話をしている人だけを高画質にするなどの負荷を下げる機能を独自に実装することで解決している 録画ファイルが一つにならない 録画合成の仕組みを別途用意することで解決している よくありそうな質問 ================== 使えるのか ---------- すでに Chrome に搭載されてから 7 年以上が過ぎており、普通に安定して使える。 むしろ既存の技術よりも新しい仕組みが多く取り入らられている。 `Chromium Blog: Celebrating 10 years of WebM and WebRTC `_ 不安定とか繋がらないとかはネットワークの問題がほとんどで、 WebRTC という技術自体はとても良くできており、大変安定している。 2021 年 1 月に WebRTC が W3C と IETF 標準となった。 `WebRTC is now a W3C and IETF standard `_ 仕事で使いたい -------------- 宣伝記事にはなるが、以下に仕事で WebRTC を利用する話をまとめておいたので見てもらいたい。 `仕事で WebRTC `_ 何が大変か ---------- - 最新ブラウザへの追従 - 繋がらない人へのサポート対応 主にこの2点。両方ともこちらで事前に予測は難しい。ブラウザへの追従はメーリングリストやコミットログを見ておいて実際に検証していく必要がある。 つながらない人へのサポート対応は、ネットワーク環境などなど、いろいろなものに依存してしまうのでなんともいえない。実際に運用してノウハウをためるしかない。 基本的にクライアント側で頑張る必要があるので JavaScript が複雑になっていく。 また、ブラウザ同士の仕様差吸収という問題もある。これは全てのブラウザが WebRTC 1.0 の仕様を満たしているわけではない。 そのため Chrome 、Firefox 、Edge 、Safari といったブラウザの差を吸収しなければならない。 どんな技術なのか ---------------- WebRTC は映像や音声、そしてデータを **不安定な回線** でも超低遅延で送受信する仕組み。 超低遅延というのはどのくらいかというと 200 ミリから 300 ミリ程度。 人と人が映像や音声でやり取りする際に、違和感を感じなく話をすることができるようになると考えてもらって問題ない。 いままでの技術とどう違うのか ---------------------------- 注意してほしいのは今使われている WebRTC は新しくできた技術ではなく、既存技術をいろいろ組み合わせてできた技術。 音声や映像のやりとりには RTP (Real-time Transport Protocol) という歴史のある(1996 年)プロトコルが利用されている。 またデータのやり取りには SCTP (Stream Control Transmission Protocol) というこちらも歴史のある(2000 年)プロトコルが利用されている。 暗号部分には SRTP (2004 年) や DTLS (2006 年) 、ハンドシェイクには SDP (1998 年) 、NAT 超えには STUN/TURN (2003 年) が利用されている。 つまり、今まで使われてきた技術をうまくまとめ、ブラウザ上で使えるようにした技術と考えてもらって問題ない。 何がすごいのか -------------- ブラウザというよく使われるものに、標準で実装されているということがとても大きい。 ブラウザさえあればリアルタイムで音声や映像のやり取りを行えることになる。 今まで音声や映像をリアルタイムにやり取りするためには専用のクライアントが必要になることがほとんどだった。 それがブラウザさえあれば、よくなった。 さらに WebRTC はベースとしている既存の技術を今の時代の要求に合うように改良が行われている。 - 暗号化が前提とされている - 最新の音声や映像の圧縮技術が採用されている - 最新の再送、輻輳制御技術が採用されている - ノイズキャンセラーやエコーキャンセラーが標準で搭載されている - 日々改善されていっている また、いまや WebRTC はブラウザだけの技術ではない。 iOS や Android だけでなく、組み込み製品にも利用が可能になり、 リアルタイムな意思伝達の技術としては WebRTC が圧倒的シェアを誇っている。 そしてさらに、それらのコアとなる技術はオープンソースとして公開されており、 ライセンスの下であれば自由に利用することができる。 Safari では動作するのか？ --------------------------- 2021 年 5 月時点の最新版である Safari 14.1 はとても安定して動作する。 Edge では動作するのか？ --------------------------- 2021 年 5 月時点の最新版である Edge 90 はとても安定して動作する。 HLS や MPEG-DASH とどう違うのか ------------------------------- その辺の話はこの資料にまとめたので読んでみてほしい。 `リアルタイム動画配信コトハジメ `_ iOS には Chrome や Firefox があるがそれでもダメなのか --------------------------------------------------------- iOS 14.3 で WKWebView が getUserMedia に対応したため、 Chrome や Firefox でも動作するようになった。 iOS や Android のアプリはどうやって開発すればいいのか ------------------------------------------------------ 一応ドキュメントは公開されている。ただ情報は少ない。 - `WebRTC iOS development `_ - `WebRTC Android development `_ 以下は `時雨堂` の CTO が書いている解説書。定期的に更新されるため以下を買うのが一番よい。 `WebRTC ネイティブライブラリガイド for iOS and Android `_ WebRTC の P2P はどんな技術なのか ----------------------------------- WebRTC はブラウザとブラウザで直接やり取りをするため、 P2P (Peer to Peer) という技術を利用している。 少し勘違いされやすいのが P2P なのであれば、サーバは不要だという思われてしまう。 WebRTC 残念ながら完全な P2P ではない。 お互いに直接やり取りするにしてもお互いの情報がまったくわからなければやりとりしようがないため、 最初だけお互いを仲介してくれるシグナリングサーバと呼ばれるものが必要になる。 シグナリングサーバという響きは聞き慣れないと思うが、 難しい話ではなく自分の IP アドレスを始め自分がどんな状況にいるのかを「どこにいるのかもわからないやり取りしたい相手」に情報を伝達してくれるサーバである。 つまりシグナリングサーバさえ知っていればなんとかなる。 シグナリングサーバでやりとりする情報は、 WebRTC では SDP (Session Description Protocol) というプロトコルを利用する。 これも実は古くからあるプロトコル。 このプロトコルをシグナリングサーバ経由でやりとりをすることで P2P でのやり取りをする準備を行う。 やり取りが終わったらシグナリングサーバは不要でお互い直接やり取りするだけでよくなる。 遅延はどのくらいなのか ---------------------- 環境や回線やマシンパワーに依存する。好条件であれば 200 ミリ秒程度の遅延で配信が可能。 この辺りの 1 秒未満の遅延については超低遅延 (Sub-second latency) と呼ばれている。 超低遅延、つまり 200-300 ミリ秒で双方のやり取りが可能になる。ただこれ勘違いをしてはいけないのは WebRTC 以外でも実現可能。 WebSocket を利用したとしても 200-300 ミリでのやり取りは可能。 WebRTC と WebSocket の大きな違いは UDP か TCP か。 つまり WebRTC では再送や輻輳の制御を独自に行なっている。 WebSocket では TCP に乗っかっているので TCP お任せ。 そのため不安定な回線で大きな差がでる。 WebSocket を利用した場合、回線が不安定になったら HoL ブロッキング (Head-of-line blocking) が発生する。 WebRTC の場合は発生しない。そのため音声や映像、データの遅延が発生しにくくなる。 WebRTC では音声や映像に特化した再送や輻輳制御を行っているため。 また WebRTC はデータを送りつける技術のため待ちが発生しない。 ただこれは WebRTC だからとかではなく TCP でもデータを送りつける方式であれば遅延は少なくなる。 ここは方式の違いであり TCP や UDP の差ではない。 なぜ UDP なのか ------------------ - P2P で NAT 超えをしたいから - UDP ホールパンチング - 再送を独自で行いたいから - NACK (Negative ACKnowledgement) 基本的にはこの 2 点。 低回線で配信したい ------------------ ビットレートを下げることで実現は可能。 WebRTC では帯域推定と呼ばれる機能を利用して、低回線の場合は解像度を自動で下げて、ビットレートを抑える仕組みが入っている。 ちなみに 50kbps でも映像は配信可能。 WebRTC は難しいという話をよく聞くが実際どうなのか ------------------------------------------------- 趣味で触る程度なら特に難しくはない。TURN/STUN サーバを立てるのが少し難易度が高めなくらいだろうか。 ただ、WebRTC 自体をビジネスにする場合かなり難しいといって問題ないと思う。 そもそもリアルタイムが NAT 越えやらで難しい。さらに映像や音声は複雑な仕組みが使われている。 WebRTC の仕組み自体は今後もっともっと複雑になっていく。 ただ、WebRTC を利用するだけであれば難しくはない。お勧めは自力ではなくサービスやパッケージを利用することだ。 WebRTC を使うためには STUN サーバは必要なのか --------------------------------------------- P2P を前提とするならば、必要と認識もらってかまわない。NAT 越えをするために最低限必要なサーバだ。 WebRTC を使うためには TURN サーバは必要なのか --------------------------------------------- 特になくてもよい。ただし特定のネットワーク環境では P2P で通信ができないため、接続確率を上げるためには TURN サーバは必要だ。 実際繫がらないを減らすためには TURN サーバは必須。 80 % は TURN が無くても繋がり、 10 % は TURN-UDP があれば繋がり、のこり 10 % は TURN-TCP と TURN-TLS があれば繋がるという話がある。 TURN-TCP や TURN-TLS とはなんなのか ----------------------------------- 通常の UDP で繋がらず、TURN の UDP が繋がらないときに TURN の TCP 、 そして TURN の TCP が繋がらないときに TURN の TLS にフォールバックしていく仕組み。 TURN-TLS までフォールバックしてつながらない時は諦めるしか無い。 シグナリングの仕組みは何でもいいのか ------------------------------------ 仕様として決められていないので何でもよい。 よくあるのは WebSocket と JSON の組み合わせだが、 XMPP も使われたりする。オリジナルの場合もあり、様々なライブラリやサービスでのシグナリングの互換性はないと割り切って良い。 セッション確立後の通信は暗号化されているのか -------------------------------------------- メディアチャネルであれば DTLS-SRTP で、データチャネルであれば DTLS によって暗号化される。 - `Datagram Transport Layer Security - Wikipedia `_ - データグラム向けの TLS とおぼえてもらえればいい。 - `Secure Real-time Transport Protocol - Wikipedia `_ - RTP というプロトコルのセキュア版と覚えてもらえばいい - RTP はリアルタイムプロトコルの略で音声や映像をリアルタイムにやり取りするプロトコルの１つ - `Real-time Transport Protocol - Wikipedia `_ DTLS の証明書検証はどう行われているのか --------------------------------------- シグナリングを利用して交換する SDP の中身の a=fingerprint に書いてあるフィンガープリントの値を利用した仕組みを使っている。 DTLS の証明書検証時にこの fingerprint の値と送られてきた証明書を検証している。 TURN サーバで通信を見られてしまうのではないか --------------------------------------------- TURN サーバは **暗号化された状態のまま** データをリレーするため、通信状態をみることはできない。 ブラウザ同士の互換性はあるのか ------------------------------ 実はすごく複雑なため簡単な回答が出来ない。基本的なものは互換性があるが、それ以外は非互換なものは少なくない。 興味がある人は `WebRTC 1.0 Interoperability Tests Results `_ これを買えば解決する。12 万円と高額だが、一つ買えば幸せになれるので本当におすすめ。 1-4 名、程度向けでもこれを買えば問題ない。 `YVC-200 特長 `_ スクリーンシェア機能を使いたい ------------------------------------- getDisplayMedia を利用することで利用可能。 この機能は Chrome と Firefox と Edge と Safari 主要ブラウザの全てに搭載されており、利用することができる。 WebRTC の技術を勉強したい ------------------------- API の勉強であれば W3C を見てもらうのが早い、ただブラウザごとに実装が異なるので注意。 `WebRTC 1.0: Real-time Communication Between Browsers `_ MDN もお勧めしておきたい。 `WebRTC API - Web APIs | MDN `_ プロトコルスタックの勉強は一筋縄ではいかない。以下にまとめてあるので見てほしい。 `WebRTC 資料まとめ `_ もう少し踏み込んだ情報が知りたい ------------------------------------ 今後の WebRTC について定期的に更新しているので見てもらえれば。 `WebRTC の未来 `_ YouTube の WebRTC を使った仕組みについて知りたい ------------------------------------------------ YouTube が専用のツール不要で Chrome からすぐに配信可能になったが、あれは WebRTC と HLS/MPEG-DASH 技術の組み合わせだ。 日本では `pixiv Sketch Live `_ が実現している技術で、簡単に言うとブラウザからサーバに WebRTC で音声や映像を送り、サーバ側でリアルタイムに HLS/MPEG-DASH 形式に変換して配信する方式だ。 この技術を使うことで気軽な配信と大規模な配信の２つを実現できるようになる。今後とても注目される技術の１つだ。 詳細について知りたい場合は以下を見てほしい。 `YouTube が WebRTC 配信に対応した – V – Medium `_ AV1 は WebRTC で利用可能なのか ----------------------------------------------- 利用可能。すでに Chrome Canary M90 で利用できるようになっている。 `AV1 Encoder - Chrome Platform Status `_ WebRTC における E2EE について知りたい ------------------------------------------------ - P2P であればデフォルトで E2EE を利用している。 - MCU は仕組み上利用できない - 別途まとめているので参考にしてもらえれば - `Sora E2EE ドキュメント `_ WebCodecs や WebTransport はどうなのか ----------------------------------------------- クライアント・サーバ経由の DataChannel の代わりとして WebTransport を利用するのは可能。 ただし、MediaChannel の代わりは現時点では RTP/RTCP 部分を完全に自前で実現する必要があるため、体力のある企業限定。 さらに、 2021 年 5 月の時点で WebTransport は TURN のように TCP / TLS へのフォールバックがまだ確定していない。 WebRTC の仕組み自体はなくならず、そのまま継続すると考えてよい。あせって WebTransport を試す必要はない。 WebRTC の歩き方 =============== WebRTC はどうも難しいというイメージを持たれていることが多いが、それは正しい。 実際リアルタイムなデータを P2P でやり取りをするのはとても難しい。 ただ WebRTC の Web API 自体はとてもそれらを簡単にしてくれているし、 多くのフレームワークも提供されており、それを使うことでかなり難易度は下がる。 ここでは目的別の WebRTC の歩き方を書いていこうと思う。 WebRTC に詳しくなりたい --------------------------- WebRTC という技術は様々な集合体ということもあり、全てに詳しくなるのはおそらく無理だと思って良い。 そのため、どの部分について詳しくなるのかを決めて、進めるといいだろう。 参考書などは一切ないし、どこから始めるとかはない。 やるかやらないかだけの世界なのでコツコツやってみてほしい。 プロトコル部分だけであれば、自分でまとめた資料があるんで参考にしてもらえれば。 `WebRTC 資料まとめ `_ WebRTC API に詳しくなりたい --------------------------- WebRTC API を理解したい場合は W3C を読むのが一番早い、 ただブラウザごとに実装が異なるため、 MDN を参考にするのも良い。 - `WebRTC 1.0: Real-time Communication Between Browsers `_ - `Media Capture and Streams `_ - `WebRTC API - Web APIs | MDN `_ 書籍であればまずは `O'Reilly Japan - ハイパフォーマンス ブラウザネットワーキング `_ の WebRTC を読むことをオススメしたい。 WebRTC API はあくまで WebRTC のプロトコル部分を API にしたものなので、 プロトコルを理解できれば API の理解も早い。 プロトコルを理解する、というのは別にプロトコルを実装する必要はなく、 利用してるプロトコルの概要を理解すれば良い。 そのため、プロトコルから説明しているハイパフォーマンスブラウザネットワーキングはとても良い。 WebRTC の API はバージョン 1.0 に向けて変わっているが、プロトコルの基本的な部分は大きく変わらないので安心してほしい。 そのため最低限のプロトコルの知識を得ておくところから入ると良い。 libwebrtc に詳しくなりたい -------------------------- ソースコードをひたすら追いかけるしかない。 `external/webrtc - Git at Google `_ 6 週間に一回ブランチが切られる、さらにブランチ自体も前に進む。 最新版に追従しなければいいのでは？と思うかもしれないが、そもそもブラウザが前に進んでいるのに追従しないという選択肢はない。 WebRTC API を使えるようになりたい --------------------------------- 使うだけであれば無理にプロトコルを学んだりする必要はない。 一番良いのは動くサンプルを試してみることだろう。 サンプルを触ってみてさえすれば WebRTC API が何しているかどうかが学べる。 基本的には以下の２つの API を理解すれば良くなる。 - getUserMedia - RTCPeerConnection このあたりはお作法で使えば良いので、とにかくサンプルを読むと良い。 手前味噌だが AppRTC という webrtc.org が公開しているサンプルに合わせたシグナリングサーバとサンプルを公開している。 これを読んで行くのをおすすめしたい。 `WebRTC Signaling Server Ayame `_ シグナリングの仕組みは WebRTC API で定義されていないため、 最初どうしたらいいかわからなくなることがある。 その勉強用にと用意した実装ということもあり活用してほしい。 WebRTC のフレームワークを使えるようになりたい --------------------------------------------- 基本的にフレームワークはオープンソースであると思うので、 そのドキュメントとソースコードを読むのが一番だ。ほとんどの人はこのフレームワークを使うというところになるだろう。 それこそ WebRTC は後回しにし、フレームワークを学ぶべきだ。 STUN/TURN に詳しくなりたい -------------------------- いるとは思わないが ... RFC 読むのが手っ取り早い。 難しいプロトコルではないので実際に実装してみるのも良い。 - `RFC 8489 - Session Traversal Utilities for NAT (STUN) `_ - `RFC 8656 - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) `_ 広告 ==== WebRTC SFU Sora --------------- `WebRTC SFU Sora `_ 商用の WebRTC SFU です。価格は同時 100 接続でライセンス費用は 1 年で 84 万円です。 3 ヶ月や 6 ヶ月のライセンスも用意してあります。製品のサポート料金込みです。 複数人数での会議や、 1000 人への配信、一対一の面談など様々な用途に利用可能です。 パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでも好きな環境で動かすことができます。 サーバさえあれば Nginx の設定と Let's Encrypt での証明書取得まで含めて 1 時間で可能です。 HTTPS が必須なのでその準備が必要ですがそれさえ対応できればすぐ確認可能です。 - 大変多くのお客様に採用いただいております - https://sora.shiguredo.jp/cases - とにかく **落ちないこと** を目的に作っています - とにかく **繋がること** を目的に作っています - とにかく **手間がかからないこと** を目的に作っています - 最新ブラウザのアップデートに追従しています - シグナリングサーバ内蔵ですので別途立てる必要はありません - TURN サーバ内蔵ですので別途立てる必要ありません - 日本語によるサポート対応しています - フルスクラッチによる自前実装なのですべて把握しています - 1:1 の双方向に対応しています - 1:1000 の片方向に対応しています - 3:1000 といった配信者が複数の片方向にも対応しています - 4K 30fps の配信も可能です - スポットライトという機能を利用することで 200 人以上の会議に対応しています - 録画機能があります - Chrome / Firefox / Edge / Safari といった主要ブラウザ全てに対応しています - Apache 2.0 ライセンスで JavaScript と iOS と Android 、Unity のクライアント SDK を公開しています - https://github.com/shiguredo/sora-js-sdk - https://github.com/shiguredo/sora-ios-sdk - https://github.com/shiguredo/sora-android-sdk - https://github.com/shiguredo/sora-unity-sdk - Apache 2.0 ライセンスで React Native 向け WebRTC ライブラリを公開しています - https://github.com/shiguredo/react-native-webrtc-kit - Sora と簡単に利用可能なサンプルも公開しています - https://github.com/shiguredo/react-native-webrtc-kit-samples - 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です - 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます - Apache 2.0 ライセンスで Sora 専用負荷試験ツールをオープンソースとして公開しています - `shiguredo/zakuro: WebRTC Load Testing Tool Zakuro `_ - Apache 2.0 ライセンスで Sora 専用録画合成ツールをオープンソースとして公開しています - `shiguredo/hisui: Recording Composition Tool Hisui `_ 興味のある方はお気軽に sora at shiguredo.jp までお問い合わせください。 紹介や検討資料も公開しております。 - `WebRTC SFU Sora の紹介 `_ - `WebRTC SFU Sora 検討資料 `_ WebRTC Native Client Momo ------------------------- `WebRTC Native Client Momo `_ GitHub にオープンソースで公開している WebRTC のネイティブクライアントです。 Linux と macOS と Windows で動作します。 - `OpenMomo プロジェクト `_ - ライセンスは Apache License 2.0 です - 多くの端末のハードウェアエンコーダに対応しています - Raspberry Pi Zero という非力デバイスでも H.264 ハードウェアエンコーダを利用し 720p@30 で配信可能です - `Jetson Nano `_ ではハードウェアエンコーダを利用することで 4K@30 で配信可能です - macOS でもハードウェアエンコーダを利用して動作します - SDL (Simple DyanmicMedia Layer) を利用することで受信した音声と映像を表示する機能を持っています WebRTC Signaling Server Ayame ----------------------------- `WebRTC Signaling Server Ayame `_ GitHub にオープンソースで公開している WebRTC のシグナリングサーバです。 Linux と macOS と Windows で動作します。 - `OpenAyame プロジェクト `_ - ライセンスは Apache License 2.0 です - 1:1 に特化させることでシンプルを保っています - 認証 / 認可の仕組みをウェブフックで実現しています - TURN の URL と Username / Credential 払い出しに対応しています - Apache 2.0 ライセンスで Web と Android の SDK を公開しています - iOS や Unity 対応も今後予定しています - `OpenAyame/ayame-web-sdk: Ayame Web SDK `_ - `OpenAyame/ayame-android-sdk: Ayame Android SDK `_ - React や React Native を利用したサンプルを公開しています - `OpenAyame/ayame-react-sample: Ayame React サンプル `_ - `OpenAyame/ayame-react-native-sample: Ayame React Native サンプル `_ - Chrome / Firefox / Safari / Edge 最新版に対応 Ayame Labo -------------------------------------- `Ayame Labo `_ Ayame を時雨堂がサービスとして提供しています。 - 無料で使えます - サインアップしないでも使えます - ただし TURN や認証機能などは利用できません - GitHub アカウントを持っていればすぐに利用できます - TURN の UDP / TCP / TLS を提供します - ルームに認証をかけられます - シグナリングキーを提供します - 認証ログを確認できます Sora Labo ------------------------------------- `Sora Labo `_ 商用製品の WebRTC SFU Sora を時雨堂が検証目的で無料で使えるサービスを提供しています。 - 無料で利用可能です - 商用目的では使えません - すぐに試せるサンプルも用意してあります - 法人、アカデミックでの利用は申請必須です - GitHub アカウントを持っていればすぐに利用できます - TURN の UDP / TCP / TLS を提供します - チャネルに認証をかけられます - シグナリングキーを提供します - 同時接続数制限があります - 認証ログを確認できます - 統計情報を確認できます