- 更新
2023-10-04
- 作者
@voluntas
- バージョン
2023.2
- URL
この記事が良いと思ったらこの記事に Star をお願いします。
株式会社時雨堂 で 多くの商用環境で利用されている WebRTC SFU Sora を 1 から設計/開発/販売している。 WebRTC スタックは暗号ライブラリの利用している部分以外はすべて自前実装。
- WebRTC を今から学ぶ人に向けて
- WebRTCの裏側
- WebRTC Conference Japan で話してきた
- WebRTC スタックコトハジメ
- WebRTC の未来
- WebRTC SFU コトハジメ
- WebRTC SFU をフルスクラッチで作ってみた
- リアルタイム動画配信コトハジメ
- 詳解 WebRTC
- 仕事で WebRTC
この Gist へのコメントではなく Twitter で @voluntas まで DM を飛ばして欲しい。
WebRTC は闇が深く、変化が早い技術だ。そのため公開されている情報はすぐ古くなってしまう。 それらの古い情報を参照して不幸になる開発者を減らすために書いている。
できるだけ最新情報に追従するようにしている。
ブラウザ同士でリアルタイムコミュニケーションを実現するための仕組み
WebRTC は P2P を利用したブラウザ同士を前提とした技術として作られている。 もちろん、WebRTC 自体はプロトコルの組み合わせでしかないため、 P2P を使わなかったり、ブラウザ以外を使ったりすることもできる。
WebRTC の通信プロトコルには TCP ではなく、 UDP が採用されている。 これは音声や映像のデータを扱う以外に、大量のデータを高速に送ることができるよう、再送を自前でコントロールできるようにするためである。
通信はデフォルトで暗号化されており、データグラム向けの TLS である DTLS が採用されている。
直接相手とやりとりをする P2P を実現する機能が含まれており、 NAT 越えを実現する仕組みが含まれる。 NAT 越えをするためのプロトコルには STUN/TURN そしてそれら２つの技術を組み合わせた ICE と呼ばれる仕組みを採用した。
実際に NAT 越えを実現するためには STUN サーバや TURN サーバが必要となる。 通常は TURN/STUN サーバとして 1 台で提供される。
WebRTC という単語が音声や映像を送受信するプロトコルとして使われることが多くなってきているように感じているので、 整理しておきたい。
まず WebRTC はその名の通り Web でリアルタイムなコミニュケーションをやり取りする技術である。 具体的に定義されたプロトコルの名前ではない。
Web でリアルタイムなコミニュケーションをやりとりするには多くの技術が必要になる。 そのため、 WebRTC を実現するためには数多くのプロトコルが利用されている。
WebRTC は実はデバイス管理やスクリーンキャプチャという概念も含んでいる。 これはリアルタイムなコミニュケーションにはマイクやカメラが必要なためである。 カメラやマイクを使うにはデバイス認識、デバイス選択という機能が必要になる。これも WebRTC の一部だ。
そしてそれらのデバイスから取得した音声や映像をそのまま送ると転送量が大変なことになってしまうため、 圧縮して送る技術が必要になる。これも WebRTC の一部だ。主にコーデックと呼ばれる技術だ。
さらに、コミニュケーションということは相手が存在するため、 その相手と直接やり取りをするための P2P の技術が必要になる。これも WebRTC の一部だ。
そして最後に、その相手との通信を実現する技術が必要になる。これも WebRTC の一部になる。
WebRTC は沢山の技術の集合体と考えてもらって問題ない。 それらをブラウザから簡単に使えるようにした仕組みが WebRTC API である。
上記の複雑な仕組みを意識することなく、 JavaScript を 100 行も書かずに実現できるようになっている。
ここで大事なのは WebRTC は用意された API を利用するだけなら難しい技術ではない。 むしろとてもシンプルになっており、使いやすい API だ。
ただその用意されている部分から少しでも逸脱するとハードルが突然あがる。 例えばブラウザ以外で行いたいとか、 用意されているコーデック以外を使いたいとか、内部で利用するプロトコルを変えたいとかだ。
WebRTC はリアルタイムなコミニュケーションを実現するために、 とてつもないめんどくさい技術を利用した技術で、それをブラウザから簡単に使えるようにした技術である。
WebRTC を説明する際、チャネルの種類が曖昧に説明されてることが多い。
WebRTC にはメディアチャネルとデータチャネルの二つがある。
- 映像と音声のデータ通信方式がメディアチャネル
- 好きなデータをやりとりできるのがデータチャネル
WebRTC とメディアチャネルが同一と表現されることが多いので要注意。
メディアだろうがデータだろうが、お互いの通信を統一するためのプロトコルとして SDP が採用されている。 簡単に言えばメディアでいえば自分は音声をこの形式で送るなどだ。
メディア、つまり映像と音声を送り合う仕組みである。 実態は RTP/RTCP と呼ばれるリアルタイムに映像や音声を配信するプロトコルが採用されている。
RTP はとても古いプロトコルであるが、かなり拡張されており、新しい仕組みが積極的に採用されている。
データチャネルは SCTP をベースとしたプロトコルで、テキストデータまたはバイナリデータを扱うことが出来る。 そのため映像や音声も取り扱える。むしろ何でもよい。
データチャネルは再送回数や再送時間を指定したり、順番保証を指定したりと TCP のようにも、UDP のようにも利用できる。 かつ通信はデータグラム向けの TLS である DTLS 1.2 で暗号化されている。
SCTP は TCP と UDP のいいところ取りをしたプロトコルだと思ってもらってよい。 SCTP (2000-) もなり古いプロトコルだが、残念ながら流行っているとはいえない。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 でデータをリアルタイムにやり取りできるという強みから、 ロボットへの組み込みなどでも利用される事例もでてきている。
ブラウザで暗号化されている状態で HoL Blocking を避けて通信する技術としては秀逸だが、残念ながら SCTP 自体が複雑すぎるため、 このあたりは今後 WebTransport over HTTP/3 に置き換わっていくと思われる。ただ WebTransport 自体が HTTP/3 上に構築されており、 複雑化していることもあり、単純に QUIC だけで使われるパターンもでてくるだろう。
WebRTC はよく P2P の技術と呼ばれるがこれは正しい。 ブラウザ同士でデータのやりとりを実現することができる。 ただし、シグナリングと呼ばれる仕組みが必須になる。
シグナリングというのはあまり聞き慣れない言葉だとおもうが、 P2P でやり取りする前に必要な情報をサーバを経由してやり取りする仕組みだ。
実はシグナリングにはいろいろな仕組みがあるのだが、 WebRTC では定義されていないため、ここでは大まかに定義する。
- 通信しようとする相手の IP アドレスの解決
- 相手の名前から IP アドレスを取得するなど。 つまりこれから通話する相手の IP アドレスを取得することができるようになる仕組み
- 相手がその通信を許可するかどうか
- そもそも誰にでも繋がってはいけないので、拒否されているかどうかを判断する仕組み
- 通信状態（セッションと呼ぶ）において使用するパラメータの合意
- メディアチャネルであれば、お互いの映像に使うコーデックや最大フレームレートなどの合意をとる仕組み
- 証明書のフィンガープリント情報の交換
このいくつかの仕組みをまとめてシグナリングと呼ぶことが多い。
これらのを P2P の接続をする前にやりとりするにはシグナリングサーバが必要になる。 つまりセッションを確立する前に判断しなければいけないため、ブラウザ同士が直接やりとりすることができないからだ。
シグナリングは本来はセッションの終了まで管理すべきであろう。 このあたりは WebRTC では 仕様が決められていない ため、実装側に任されている。
シグナリングの規格が存在しないのはサーバー設計側としては自由で大変良いのだが、 配信ツールなどで扱う場合はどのシグナリング規格を採用すればいいのかわからない、 そのため WHIP と WHEP という規格の策定が進んでいる。
- WHIP は WebRTC-HTTP ingestion protocol の略で、 WebRTC 配信側のシグナリング規格
- WHEP は WebRTC-HTTP Egress Protocol の略で、WebRTC 視聴側のシグナリング規格
仕様はとてもシンプルで SDP のやりとりを HTTP POST で Offer を投げて 201 Crated で Answer を返すというものだ。
仕様はまだまだ途中だが、 OBS Studio にはすでに WHIP 対応実装が始まっている。
OSB と組み合わせるとこんなことが実現出来る。
https://gyazo.com/dc6775976a74a236856ed2e045c02781
WebRTC の世界は P2P を前提として入るが、それとは別に MCU と SFU という世界がある。 これは P2P でやりとりをするのではなく、クライアント・サーバモデルでやりとりをする。
MCU や SFU は WebRTC の標準的な考え方からすると異端ではあるが、一定以上の品質や数を担保する場合は必須となる。
理解を深めたい場合は以下の記事が参考になる。
WebRTCにおいてP2P/SFU/MCUでビデオ通話品質の差があるか｜tnoho｜note
昔からある技術で、3 拠点以上でテレビ会議をする場合に使われている。MCU の特徴はサーバによる合成だ。
つまりそれぞれの音声や映像が別に送られてくるのではなく、サーバで合成されて 1 つの音声や映像として送られてくる。
100 人が参加する会議があったとしても、サーバで 1 つに合成される。
良いことだらけだが、合成するためサーバ側のリソースを恐ろしく使うため、最近は MCU から SFU が主軸になっていっている。 現実問題 MCU を採用しているサービスはほとんど存在しない。
また End to End Encryption (E2EE) が MCU では実現できないという問題もある。
SFU という単語が出てきたのはここ数年。ただ概念自体は前からある。 以前だとメディアルーターと呼ばれていた。最近でも SFU と呼ばずメディアルーターや SFM (Selective Forwarding Middlebox) と呼ぶ場合もある。
SFU は MCU だと CPU リソースを使われてしまうことから考え出された仕組みだ。
クライアントが配信する音声や映像をサーバが代理で他のクライアントやサーバに送るという仕組み。 そのため、クライアントは 10 人参加者がいた場合でもサーバに映像を送るだけで済む。
P2P の場合のフルメッシュと MCU の間の技術でバランスが良い事もあり WebRTC でクライアント・サーバモデルの場合は SFU が選択されることが多い。
SFU の場合は E2EE が採用できる。実際 Google Meet や FaceTime for Web は 3 人以上の場合は WebRTC SFU を利用しながら、E2EE を実現している。
現時点ではほぼ SFU 一択となる。MCU の場合、高圧縮な映像技術を利用した場合の合成コストが高くなりすぎている。 現時点の主要なサービスは SFU のような転送が主体なサーバを利用していると考えてよい。
よく言われる WebRTC SFU の課題をどう解決しているかをまとめておいたので参考にしてほしい。
- 全員に同一ビットレートを配信する必要がある
Simulcast や SVC を利用することで解決している
- 大規模配信ができない
多段 (Origin - Edge) にすることで解決している
- 同時に多くのユーザを視聴できない
話をしている人だけを高画質にするなどの負荷を下げる機能を独自に実装することで解決している
- 録画ファイルが一つにならない
録画合成の仕組みを別途用意することで解決している
すでに WebRTC の登場から 10 年以上が経過しており普通に安定して使える。 むしろ既存の技術よりも新しい仕組みが多く取り入らられている。
Chromium Blog: Celebrating 10 years of WebM and WebRTC
不安定とか繋がらないとかはネットワークの問題がほとんどで、 WebRTC という技術自体はとても良くできており、大変安定している。
2021 年 1 月に WebRTC が W3C と IETF 標準となった。
WebRTC is now a W3C and IETF standard
宣伝記事にはなるが、以下に仕事で 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 が圧倒的シェアを誇っている。
そしてさらに、それらのコアとなる技術はオープンソースとして公開されており、 ライセンスの下であれば自由に利用することができる。
macOS Safari でも iOS Safari でも動作する。
Chromium ベースになったこともあり、動作する。 ただしコーデックの AV1 など、一部機能は利用できない。
その辺の話はこの資料にまとめたので読んでみてほしい。
iOS 14.3 で WKWebView が getUserMedia に対応したため、 Chrome や Firefox でも動作するようになった。
一応ドキュメントは公開されている。ただ情報は少ない。
以下は 時雨堂 の CTO が書いている解説書。定期的に更新されるため以下を買うのが一番よい。
WebRTC ネイティブライブラリガイド for iOS and Android
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 を利用した場合、回線が不安定になったらヘッドオブラインブロッキング (Head-of-line blocking) が発生する。
WebRTC の場合は発生しない。そのため音声や映像、データの遅延が発生しにくくなる。 WebRTC では音声や映像に特化した再送や輻輳制御を行っているため。
また WebRTC はデータを送りつける技術のため待ちが発生しない。 ただこれは WebRTC だからとかではなく TCP でもデータを送りつける方式であれば遅延は少なくなる。 ここは方式の違いであり TCP や UDP の差ではない。
なぜ UDP なのか ------------------�
- P2P で NAT 超えをしたいから
- UDP ホールパンチング
- 再送を独自で行いたいから
- NACK (Negative ACKnowledgement)
- 再送を行いたくないから
基本的にはこの 2 点。
ビットレートを下げることで実現は可能。 WebRTC では帯域推定と呼ばれる機能を利用して、低回線の場合は解像度を自動で下げて、ビットレートを抑える仕組みが入っている。
ちなみに 50 kbps でも映像は配信可能。音声であれば Google の Lyra を使うなどすれば帯域が弱い回線でも利用できる。
趣味で触る程度なら特に難しくはない。TURN/STUN サーバを立てるのが少し難易度が高めなくらいだろうか。 ただ、WebRTC 自体をビジネスにする場合かなり難しいといって問題ないと思う。
そもそもリアルタイムが NAT 越えやらで難しい。さらに映像や音声は複雑な仕組みが使われている。 WebRTC の仕組み自体は今後もっともっと複雑になっていく。
ただ、WebRTC を利用するだけであれば難しくはない。お勧めは自力ではなくサービスやパッケージを利用することだ。
P2P を前提とするならば、必要と認識もらってかまわない。NAT 越えをするために最低限必要なサーバだ。
特になくてもよい。ただし特定のネットワーク環境では P2P で通信ができないため、接続確率を上げるためには TURN サーバは必要だ。 実際繫がらないを減らすためには TURN サーバは必須。
80 % は TURN が無くても繋がり、10 % は TURN-UDP があれば繋がり、のこり 10 % は TURN-TCP と TURN-TLS があれば繋がるという話がある。
通常の UDP で繋がらず、TURN の UDP が繋がらないときに TURN の TCP 、 そして TURN の TCP が繋がらないときに TURN の TLS にフォールバックしていく仕組み。
TURN-TLS までフォールバックしてつながらない時はそもそも諦めるしか無い。
仕様として決められていないので何でもよい。
よくあるのは WebSocket と JSON の組み合わせだが、 XMPP も使われたりする。オリジナルの場合もあり、 様々なライブラリやサービスでのシグナリングの互換性はないと割り切って良い。
メディアチャネルであれば DTLS-SRTP で、データチャネルであれば DTLS によって暗号化される。
- RFC 6347: Datagram Transport Layer Security Version 1.2
- データグラム向けの TLS とおぼえてもらえればいい。
- RFC 3711: The Secure Real-time Transport Protocol (SRTP)
- RTP というプロトコルのセキュア版と覚えてもらえばいい
- RTP はリアルタイムプロトコルの略で音声や映像をリアルタイムにやり取りするプロトコルの１つ
- RFC 3550: RTP: A Transport Protocol for Real-Time Applications
シグナリングを利用して交換する SDP の中身の a=fingerprint に書いてあるフィンガープリントの値を利用した仕組みを使っている。 DTLS の証明書検証時にこの fingerprint の値と送られてきた証明書を検証している。
TURN サーバは 暗号化された状態のまま データをリレーするため、通信状態をみることはできない。
実はすごく複雑なため簡単な回答が出来ない。基本的なものは互換性があるが、それ以外は非互換なものは少なくない。
興味がある人は WebRTC 1.0 Interoperability Tests Results を見てみるとよい。
多くの帯域があるネットワークと高性能なマシンが必要になる。 ちなみに VP8 や H.264 でフル HD での配信は 2500 kbps 程度あればいける。
- VP9 を利用すれば 1500 kbps 程度でフル HD で、30 fps な映像が配信可能
- AV1 を利用すれば 1000 kbps 程度でフル HD で、30 fps な映像が配信可能
H.264 で 4K@30 を配信したいのであれば、15 Mbps 程度は必要。
音声はマイクの機能依存になる。もちろん回線はイイ回線があること前提。
YVC-1000 - スピーカーフォン/マイク&スピーカー - ヤマハ株式会社
これを買えば解決する。12 万円と高額だが、一つ買えば幸せになれるので本当におすすめ。
1-4 名、程度向けでもこれを買えば問題ない。
getDisplayMedia を利用することで利用可能。
この機能は Chrome と Firefox と Edge と Safari 主要ブラウザの全てに搭載されており、利用することができる。
ただしスクリーシェア機能はモバイル版のブラウザには搭載されていない。 モバイルでスクリーンシェアを実現したい場合はネイティブアプリを開発する必要がある。
まずは以下を読んでもらいたい。
API の勉強であれば W3C を見てもらうのが早い、ただブラウザごとに実装が異なるので注意。
WebRTC 1.0: Real-time Communication Between Browsers
MDN もお勧めしておきたい。
プロトコルスタックの勉強は一筋縄ではいかない。以下にまとめてあるので見てほしい。
今後の WebRTC について不定期に更新しているので見てもらえれば。
YouTube が専用のツール不要で Chrome からすぐに配信可能になったが、あれは WebRTC と HLS/MPEG-DASH 技術の組み合わせだ。
日本では pixiv Sketch Live が実現している技術で、 簡単に言うとブラウザからサーバに WebRTC で音声や映像を送り、サーバ側でリアルタイムに HLS/MPEG-DASH 形式に変換して配信する方式だ。
この技術を使うことで気軽な配信と大規模な配信の２つを実現できるようになる。今後とても注目される技術の１つだ。
詳細について知りたい場合は以下を見てほしい。
YouTube が WebRTC 配信に対応した – V – Medium
利用可能。すでに Chrome Canary M90 から利用できるようになっている。遅延も特に H.264 や VP9 と変わらない。
AV1 Encoder - Chrome Platform Status
- P2P であればデフォルトで E2EE を利用している。
- MCU は仕組み上利用できない
- 別途まとめているので参考にしてもらえれば
クライアント・サーバ経由の DataChannel の代わりとして WebTransport を利用するのは可能。 ただし、MediaChannel の代わりは現時点では RTP/RTCP 部分を完全に自前で実現する必要があるため、体力のある企業限定。
WebTransport over HTTP/3 のフォールバックは WebTransport over HTTP/2 になった。
WebRTC の仕組み自体はなくならず、そのまま継続すると考えてよい。あせって WebTransport を試す必要はない。
WebRTC はどうも難しいというイメージを持たれていることが多いが、それは正しい。 実際リアルタイムなデータを P2P でやり取りをするのはとても難しい。
ただ WebRTC の Web API 自体はとてもそれらを簡単にしてくれているし、 多くのフレームワークも提供されており、それを使うことでかなり難易度は下がる。
ここでは目的別の WebRTC の歩き方を書いていこうと思う。
まずは以下の二つの資料を読むことをオススメしたい。
基本的な知識はこの二つで得られる。あとは手を動かしてみるだけだ。
WebRTC という技術は様々な集合体ということもあり、全てに詳しくなるのはおそらく無理だと思って良い。 そのため、どの部分について詳しくなるのかを決めて、進めるといいだろう。
参考書などは一切ないし、どこから始めるとかはない。 やるかやらないかだけの世界なのでコツコツやってみてほしい。
プロトコル部分だけであれば、自分でまとめた資料があるんで参考にしてもらえれば。
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 に向けて変わっているが、プロトコルの基本的な部分は大きく変わらないので安心してほしい。
そのため最低限のプロトコルの知識を得ておくところから入ると良い。
ソースコードをひたすら追いかけるしかない。
external/webrtc - Git at Google
4 週間に一回ブランチが切られる、さらにブランチ自体も前に進む。 最新版に追従しなければいいのでは？と思うかもしれないが、そもそもブラウザが前に進んでいるのに追従しないという選択肢はない。
使うだけであれば無理にプロトコルを学んだりする必要はない。 一番良いのは動くサンプルを試してみることだろう。
サンプルを触ってみてさえすれば WebRTC API が何しているかどうかが学べる。 基本的には以下の２つの API を理解すれば良くなる。
このあたりはお作法で使えば良いので、とにかくサンプルを読むと良い。
手前味噌だが AppRTC という webrtc.org が公開しているサンプルに合わせたシグナリングサーバとサンプルを公開している。 これを読んで行くのをおすすめしたい。
シグナリングの仕組みは WebRTC API で定義されていないため、 最初どうしたらいいかわからなくなることがある。 その勉強用にと用意した実装ということもあり活用してほしい。
基本的にフレームワークはオープンソースであると思うので、 そのドキュメントとソースコードを読むのが一番だ。ほとんどの人はこのフレームワークを使うというところになるだろう。
それこそ WebRTC は後回しにし、フレームワークを学ぶべきだ。
いるとは思わないが ... 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 です。価格は同時 100 接続でライセンス費用は 1 年で 84 万円です。 3 ヶ月や 6 ヶ月のライセンスも用意してあります。製品のサポート料金込みです。
複数人数での会議や、 1000 人への配信、一対一の面談など様々な用途に利用可能です。
パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでも好きな環境で動かすことができます。
サーバさえあれば Nginx の設定と Let's Encrypt での証明書取得まで含めて 1 時間で可能です。 HTTPS が必須なのでその準備が必要ですがそれさえ対応できればすぐ確認可能です。
- 大変多くのお客様に採用いただいております
- とにかく 落ちないこと を目的に作っています
- とにかく 繋がること を目的に作っています
- とにかく 手間がかからないこと を目的に作っています
- 最新ブラウザのアップデートに追従しています
- シグナリングサーバ内蔵ですので別途立てる必要はありません
- TURN サーバ内蔵ですので別途立てる必要ありません
- 日本語によるサポート対応しています
- フルスクラッチによる自前実装なのですべて把握しています
- 1:1 の双方向に対応しています
- 1:1000 の片方向に対応しています
- 3:1000 といった配信者が複数の片方向にも対応しています
- 4K 30fps や 1080p 60fps の配信も可能です
- スポットライトという機能を利用することで 200 人以上の会議に対応しています
- 録画機能があります
- Chrome / Firefox / Edge / Safari といった主要ブラウザ全てに対応しています
- Apache 2.0 ライセンスで JavaScript と iOS と Android 、Unity 、C++ 、 Flutter のクライアント SDK を公開しています
- 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
- 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます
- Apache 2.0 ライセンスで Sora 専用負荷試験ツールをオープンソースとして公開しています
- Apache 2.0 ライセンスで Sora 専用録画合成ツールをオープンソースとして公開しています
- Apache 2.0 ライセンスで Sora 専用統計収集ツールをオープンソースとして公開しています
興味のある方はお気軽に sora at shiguredo.jp までお問い合わせください。
紹介や検討資料も公開しております。
商用の WebRTC SFU である Sora のクラウド版です。
最大同時接続数 5000 と最大利用帯域 20 Gbps 程度まで利用可能です。
転送量や利用時間といった課金体系や Sora の運用から解放されるサービスです。
興味のある方はお気軽に sora-cloud at shiguredo.jp までお問い合わせください。
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) を利用することで受信した音声と映像を表示する機能を持っています
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 を利用したサンプルを公開しています
- Chrome / Firefox / Safari / Edge 最新版に対応
Ayame を時雨堂がサービスとして提供しています。
- 無料で使えます
- サインアップしないでも使えます
- ただし TURN や認証機能などは利用できません
- GitHub アカウントを持っていればすぐに利用できます
- TURN の UDP / TCP / TLS を提供します
- ルームに認証をかけられます
- シグナリングキーを提供します
- 認証ログを確認できます
商用製品の WebRTC SFU Sora を時雨堂が検証目的で無料で使えるサービスを提供しています。
- 無料で利用可能です
- 商用目的では使えません
- すぐに試せるサンプルも用意してあります
- GitHub アカウントを持っていればすぐに利用できます
- TURN の UDP / TCP / TLS を提供します
- チャネルに認証をかけられます
- シグナリングキーを提供します
- 同時接続数制限があります
- 認証ログを確認できます
- 統計情報を確認できます