| 更新: | 2020-07-04 |
|---|---|
| 作者: | @voluntas |
| バージョン: | 2020.2 |
| URL: | https://voluntas.github.io/ |
この記事が良いと思ったらこの記事に Star をお願いします。
株式会社時雨堂 で 1 から WebRTC SFU を開発している。 WebRTC スタックは暗号ライブラリの利用している部分以外はすべて自前実装。
- WebRTCの裏側
- WebRTC Conference Japan で話してきた
- WebRTC スタックコトハジメ
- WebRTC の未来
- WebRTC SFU コトハジメ
- WebRTC SFU をフルスクラッチで作ってみた
- リアルタイム動画配信コトハジメ
- Edge と WebRTC について
- Safari と WebRTC について
- WebRTC スタックを一から実装する場合読んでおくべき資料まとめ
- 詳解 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 という単語が音声や映像を送受信するプロトコルとして使われることが多くなってきているように感じているので、 整理しておきたい。
まず 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 をベースとしているため、映像や音声だって取り扱える。むしろ何でもよい。
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 の接続をする前にやりとりするにはシグナリングサーバが必要になる。 つまりセッションを確立する前に判断しなければいけないため、ブラウザ同士が直接やりとりすることができないからだ。
シグナリングは本来はセッションの終了まで管理すべきであろう。 このあたりは 仕様が決められていない ため、実装側に任されている。
WebRTC の世界は P2P を前提として入るが、それとは別に MCU と SFU という世界がある。 これは P2P でやりとりをするのではなく、クライアント・サーバモデルでやりとりをする。
MCU や SFU は WebRTC の標準的な考え方からすると異端ではあるが、一定以上の品質や数を担保する場合は必須となる。
理解を深めたい場合は以下の記事が参考になる。
WebRTCにおいてP2P/SFU/MCUでビデオ通話品質の差があるか｜tnoho｜note
昔からある技術で、3 拠点以上でテレビ会議をする場合に使われている。MCU の特徴はサーバによる合成だ。
つまりそれぞれの音声や映像が別に送られてくるのではなく、サーバで合成されて 1 つの音声や映像として送られてくる。
100 人が参加する会議があったとしても、サーバで 1 つに合成される。
良いことだらけだが、合成するためサーバ側のリソースを恐ろしく使うため、最近は MCU から SFU が主軸になっていっている。
また End to End Encryption (E2EE) が MCU では実現できないという問題もある。
SFU という単語が出てきたのはここ数年。ただ概念自体は前からある。 以前だとメディアルーターと呼ばれていた。最近でも SFU と呼ばずメディアルーターと呼ぶ場合もある。
SFU は MCU だと CPU リソースを使われてしまうことから考え出された仕組みだ。
クライアントが配信する音声や映像をサーバが代理で他のクライアントやサーバに送るという仕組み。 そのため、クライアントは 10 人参加者がいた場合でもサーバに映像を送るだけで済む。
P2P の場合のフルメッシュと MCU の間の技術でバランスが良い事もあり WebRTC でクライアント・サーバモデルの場合は SFU が選択されることが多い。
SFU の場合は E2EE が採用できる。実際 Google Duo は 3 人以上の場合は WebRTC SFU を利用しながら、E2EE を実現している。
すでに Chrome に搭載されてから 7 年以上が過ぎており、普通に安定して使える。 むしろ既存の技術よりも新しい仕組みが多く取り入らられている。
不安定とか繋がらないとかはネットワークの問題がほとんどで、 WebRTC という技術自体はとても良くできており、大変安定している。
そして今でも進化し続けている。
Chromium Blog: Celebrating 10 years of WebM and WebRTC
宣伝記事にはなるが、以下に仕事で WebRTC を利用する話をまとめておいたので見てもらいたい。
- 最新ブラウザへの追従
- 繋がらない人へのサポート対応
主にこの３点。両方ともこちらで事前に予測は難しい。ブラウザへの追従はメーリングリストやコミットログを見ておいて実際に検証していく必要がある。 つながらない人へのサポート対応は、ネットワーク環境などなど、いろいろなものに依存してしまうのでなんともいえない。実際に運用してノウハウをためるしかない。
基本的にクライアント側で頑張る必要があるので 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 が圧倒的シェアを誇っている。
そしてさらに、それらのコアとなる技術はオープンソースとして公開されており、 ライセンスの下であれば自由に利用することができる。
2020 年 7 月時点の最新版である Safari 13 ではとても安定して動作する。
2020 年 7 月時点の最新版である Edge 83 ではとても安定して動作する。
その辺の話はこの資料にまとめたので読んでみてほしい。
iOS の Chrome や Firefox は WKWebView ベースなので、 getUserMedia 非対応。
ちなみに SFSafariViewController は iOS 13 で getUserMedia に対応した。
webrtc.org が提供してくれていた。今はアーカイブがあるのみ。
Bintray や Cocoapod で最新版の libwebrtc ビルドを Google が提供している
これらを上手く活用する事がおすすめだ。
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 の差ではない。
ビットレートを下げることで実現は可能。 WebRTC では帯域推定と呼ばれる機能を利用して、低回線の場合は解像度を自動で下げて、ビットレートを抑える仕組みが入っている。
ちなみに 50kbps でも映像は配信可能。
趣味で触る程度なら特に難しくはない。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 によって暗号化される。
- Datagram Transport Layer Security - Wikipedia
- データグラム向けの TLS とおぼえてもらえればいい。
- Secure Real-time Transport Protocol - Wikipedia
- RTP というプロトコルのセキュア版と覚えてもらえばいい
- RTP はリアルタイムプロトコルの略で音声や映像をリアルタイムにやり取りするプロトコルの１つ
- Real-time Transport Protocol - Wikipedia
シグナリングを利用して交換する SDP の中身の a=fingerprint に書いてあるフィンガープリントの値を利用した仕組みを使っている。 DTLS の証明書検証時にこの fingerprint の値と送られてきた証明書を検証している。
TURN サーバは 暗号化された状態のまま データをリレーするため、通信状態をみることはできない。
実はすごく複雑なため簡単な回答が出来ない。基本的なものは互換性があるが、それ以外は非互換なものは少なくない。
最後の大物である Safari が 11 にて対応した。 iOS のモバイル Safari も対応している。ただし現在も WKWebView は getUserMedia に非対応なので注意してほしい。
IE の対応予定はない。
2020 年 07 月時点で Chrome ほぼ同等と認識してもらって良いい。特に問題なく利用できる。
多くの帯域があるネットワークと高性能なマシンが必要になる。 ちなみに VP8 や H.264 でフル HD での配信は 2500kbps 程度あればいける。
VP9 を利用すれば 1500kbps 程度でフル HD で、30fps な映像が配信可能。
4K@30 を配信したいのであれば、 15Mbps 程度は必要。
音声はマイクの機能依存になる。もちろん回線はイイ回線があること前提。
YVC-1000 - スピーカーフォン/マイク&スピーカー - ヤマハ株式会社
これを買えば解決する。12 万円と高額だが、一つ買えば幸せになれるので本当におすすめ。
1-4 名、程度向けでもこれを買えば問題ない。
getDisplayMedia を利用することで利用可能。
この機能は Chrome と Firefox と Edge と Safari 主要ブラウザの全てに搭載されており、利用することができる。
API の勉強であれば W3C を見てもらうのが早い、ただブラウザごとに実装が異なるので注意。
WebRTC 1.0: Real-time Communication Between Browsers
MDN もお勧めしておきたい。
プロトコルスタックの勉強は一筋縄ではいかない。以下にまとめてあるので見てほしい。
WebRTC スタックを一から実装する場合読んでおくべき資料まとめ
今後の WebRTC について定期的に更新しているので見てもらえれば。
YouTube が専用のツール不要で Chrome からすぐに配信可能になったが、あれは WebRTC と HLS/MPEG-DASH 技術の組み合わせだ。
日本では pixiv Sketch Live が実現している技術で、簡単に言うとブラウザからサーバに WebRTC で音声や映像を送り、サーバ側でリアルタイムに HLS/MPEG-DASH 形式に変換して配信する方式だ。
この技術を使うことで気軽な配信と大規模な配信の２つを実現できるようになる。今後とても注目される技術の１つだ。
詳細について知りたい場合は以下を見てほしい。
YouTube が WebRTC 配信に対応した – V – Medium
利用可能。すでに libwebrtc には実装されはじめている。
WebRTC Native Client Momo では Momo 同士の AV1 送受信に対応しているので、興味あれば試してみてほしい。
- P2P であればデフォルトで E2EE を利用している。
- MCU は仕組み上利用できない
- SFU については WebRTC SFU + E2EE コトハジメ を読んでほしい
WebRTC はどうも難しいというイメージを持たれていることが多いが、それは正しい。 実際リアルタイムなデータを P2P でやり取りをするのはとても難しい。
ただ WebRTC の Web API 自体はとてもそれらを簡単にしてくれているし、 多くのフレームワークも提供されており、それを使うことでかなり難易度は下がる。
ここでは目的別の WebRTC の歩き方を書いていこうと思う。
WebRTC という技術は様々な集合体ということもあり、全てに詳しくなるのはおそらく無理だと思って良い。 そのため、どの部分について詳しくなるのかを決めて、進めるといいだろう。
参考書などは一切ないし、どこから始めるとかはない。 やるかやらないかだけの世界なのでコツコツやってみてほしい。
プロトコル部分だけであれば、自分でまとめた資料があるんで参考にしてもらえれば。
WebRTC API を理解したい場合は W3C を読むのが一番早い、 ただブラウザごとに実装が異なるため、 MDN を参考にするのも良い。
書籍であればまずは O'Reilly Japan - ハイパフォーマンス ブラウザネットワーキング の WebRTC を読むことをオススメしたい。
WebRTC API はあくまで WebRTC のプロトコル部分を API にしたものなので、 プロトコルを理解できれば API の理解も早い。
プロトコルを理解する、というのは別にプロトコルを実装する必要はなく、 利用してるプロトコルの概要を理解すれば良い。
そのため、プロトコルから説明しているハイパフォーマンスブラウザネットワーキングはとても良い。
WebRTC の API はバージョン 1.0 に向けて変わっているが、プロトコルの基本的な部分は大きく変わらないので安心してほしい。
そのため最低限のプロトコルの知識を得ておくところから入ると良い。
ソースコードをひたすら追いかけるしかない。
external/webrtc - Git at Google
6 週間に一回ブランチが切られる、さらにブランチ自体も前に進む。 最新版に追従しなければいいのでは？と思うかもしれないが、そもそもブラウザが前に進んでいるのに追従しないという選択肢はない。
使うだけであれば無理にプロトコルを学んだりする必要はない。 一番良いのは動くサンプルを試してみることだろう。
サンプルを触ってみてさえすれば WebRTC API が何しているかどうかが学べる。 基本的には以下の２つの API を理解すれば良くなる。
- getUserMedia
- RTCPeerConnection
このあたりはお作法で使えば良いので、とにかくサンプルを読むと良い。
手前味噌だが AppRTC という webrtc.org が公開しているサンプルに合わせたシグナリングサーバとサンプルを公開している。 これを読んで行くのをおすすめしたい。
シグナリングの仕組みは WebRTC API で定義されていないため、 最初どうしたらいいかわからなくなることがある。 その勉強用にと用意した実装ということもあり活用してほしい。
基本的にフレームワークはオープンソースであると思うので、 そのドキュメントとソースコードを読むのが一番だ。ほとんどの人はこのフレームワークを使うというところになるだろう。
それこそ WebRTC は後回しにし、フレームワークを学ぶべきだ。
いるとは思わないが ... RFC 読むのが手っ取り早い。 難しいプロトコルではないので実際に実装してみるのも良い。
Discord に webrtc-jp というサーバを立てた。 WebRTC や WebTransport の情報共有がメイン。
商用の WebRTC SFU です。価格は同時 100 接続で年間利用料ライセンス 60 万円です。 毎年かかります。製品のサポート料金込みです。200 接続だと年間 120 万円です。
複数人数での会議や、 数百人への配信、一対一の面談など様々な用途に利用可能です。
パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでも好きな環境で動かすことができます。
サーバさえあれば起動までは 10 分です。 HTTPS が必須なのでその準備が必要ですがそれさえ対応できればすぐ確認可能です。
- 大変多くのお客様に採用いただいております
- とにかく 落ちないこと を目的に作っています
- とにかく 繋がること を目的に作っています
- とにかく 手間がかからないこと を目的に作っています
- 最新ブラウザのアップデートに追従しています
- シグナリングサーバ内蔵ですので別途立てる必要はありません
- TURN サーバ内蔵ですので別途立てる必要ありません
- 日本語によるサポート対応しています
- フルスクラッチ自前実装なのですべて把握しています
- 1:1 の双方向に対応しています
- 1:1000 の片方向に対応しています
- 3:1000 といった配信者が複数の片方向にも対応しています
- スポットライトという機能を利用することで 200 人以上の会議に対応しています
- 録画機能があります
- Chrome / Firefox / Edge / Safari といった主要ブラウザ全てに対応しています
- Apache 2.0 ライセンスで JavaScript と iOS と Android 、Unity のクライアント SDK を公開しています
- Apache 2.0 ライセンスで React Native 向け WebRTC ライブラリを公開しています
- https://github.com/shiguredo/react-native-webrtc-kit
- Sora と簡単に利用可能なサンプルも公開しています
- 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
- 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます
興味のある方はお気軽に sora 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) を利用することで受信した音声と映像を表示する機能を持っています
- ROS に対応しているため、ROS から気軽に利用可能です
- 有償ビルドツールを利用すれば Windows でも利用可能です
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 を提供します
- チャネルに認証をかけられます
- シグナリングキーを提供します
- 同時接続数制限があります
- 認証ログを確認できます
- 統計情報を確認できます