Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
WebRTC コトハジメ

WebRTC コトハジメ

更新:2019-08-03
作者:@voluntas
バージョン:19.8.0
URL:https://voluntas.github.io/

この記事が良いと思ったらこの記事に Star をお願いします。

著者

株式会社時雨堂 でフルスクラッチで WebRTC SFU を開発している。 DTLS や SRTP も暗号ライブラリの利用している部分以外はすべて自前実装。

著者が書いた資料

間違いや質問について

この Gist へのコメントではなく @voluntas まで Twitter にてリプライを飛ばして欲しい。

目的

WebRTC は闇が深く、変化が早い技術だ。そのため公開されている情報はすぐ古くなってしまう。 それらの古い情報を参照して不幸になる開発者を減らすために書いている。

できるだけ最新情報に追従するようにしている。

概要

ブラウザ同士でリアルタイムコミュニケーションを実現するための仕組み

WebRTC は P2P を利用したブラウザ同士を前提とした技術として作られている。もちろん、WebRTC 自体はプロトコルの組み合わせでしかないため、 P2P を使わなかったり、ブラウザ以外を使ったりすることもできる。

WebRTC の通信プロトコルには TCP ではなく、 UDP が採用されている。これは音声や映像のデータを扱う以外にも、大量のデータを高速に送ることができるようにするためである。

通信はデフォルトで暗号化されており、データグラム向けの TLS である DTLS が採用されている。

直接相手とやりとりをする P2P を実現する機能が含まれており、 NAT 越えを実現する仕組みが含まれる。 NAT 越えをするためのプロトコルには STUN/TURN そしてそれら2つの技術を組み合わせた ICE と呼ばれる仕組みを採用した。

実際に NAT 越えを実現するためには STUN サーバや TURN サーバが必要となる。 通常は TURN/STUN サーバとして 1 台で提供される。

WebRTC という単語について

WebRTC という単語が音声や映像を送受信するプロトコルとして使われることが多くなってきているように感じているので、 整理しておきたい。

まず WebRTC はその名の通り Web でリアルタイムなコミニュケーションをやり取りする技術である。 具体的に定義されたプロトコルの名前ではない。

Web でリアルタイムなコミニュケーションをやりとりするには多くの技術が必要になる。 そのため、 WebRTC を実現するためには数多くのプロトコルが利用されている。

WebRTC は実はデバイス管理やスクリーンキャプチャという概念も含んでいる。 これはリアルタイムなコミニュケーションにはマイクやカメラが必要なためである。 カメラやマイクを使うにはデバイス認識、デバイス選択という機能が必要になる。これも WebRTC の一部だ。

そしてそれらのデバイスから取得した音声や映像をそのまま送ると転送量が大変なことになってしまうため圧縮して送る技術が必要になる。これも WebRTC の一部だ。主にコーデックと呼ばれる技術だ。

さらに、コミニュケーションということは相手が存在するため、 その相手と直接やり取りをするための P2P の技術が必要になる。これも WebRTC の一部だ。

そして最後に、その相手との通信を実現する技術が必要になる。これも WebRTC の一部になる。

WebRTC は沢山の技術の集合体と考えてもらって問題ない。それらをブラウザから簡単に使えるようにした仕組みが WebRTC API となる。

上記の複雑な仕組みを意識することなく、 JavaScript を 100 行も書かずに実現できるようになっている。

ここで大事なのは WebRTC は用意された API を利用するだけなら難しい技術ではない。 むしろとてもシンプルになっており、使いやすい方だ。

ただその用意されている部分から少しでも逸脱するとハードルが突然あがる。 例えばブラウザ以外で行いたいとか、用意されているコーデック以外を使いたいとか、内部で利用するプロトコルを変えたいとかだ。

WebRTC はリアルタイムなコミニュケーションを実現するために、 とてつもないめんどくさい技術を利用した技術で、それをブラウザから簡単に使えるようにした技術である。

二つのチャネル

WebRTC を説明する際、チャネルの種類が曖昧に説明されてることが多い。

WebRTC にはメディアチャネルとデータチャネルの二つがある。

  • 映像と音声のデータ通信方式がメディアチャネル
  • 好きなデータを放り込めるのがデータチャネル

WebRTC とメディアチャネルが同一と表現されることが多いので要注意。

SDP

メディアだろうがデータだろうが、お互いの通信を統一するためのプロトコルとして SDP が採用されている。 簡単に言えばメディアでいえば自分は音声をこの形式で送るなどだ。

メディアチャネル

メディア、つまり映像と音声を送り合う仕組みである。 実態は RTP/RTCP と呼ばれるリアルタイムに映像や音声を配信するプロトコルが採用されている。

RTP はとても古いプロトコルであるが、かなり拡張されており、新しい仕組みが積極的に採用されている。

データチャネル

データチャネルは SCTP をベースとしているため、映像や音声だって取り扱える。むしろ何でもよい。

SCTP は TCP と UDP のいいところ取りをしたプロトコルだと思ってもらってよい。SCTP もなり古いプロトコルだが、残念ながら流行っているとはいえない。SCTP over DTLS over UDP という多重構造になっている。

最近ではデータチャネルの通信を QUIC を利用するという実装も WebRTC が公開しているライブラリには入ってきている。

実際 Google が提供している Duo は WebRTC over QUIC という噂がある。

分散ファイル共有系だと WebTorrent - Streaming browser torrent client が WebRTC データチャネルを利用している。

CDN 系だと Peer5 - The Serverless P2P CDN For Video Live StreamingStreamroot | 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 の標準的な考え方からすると異端ではあるが、一定以上の品質や数を担保する場合は必須となる。

MCU (Multipoint Control Unit)

https://webrtcglossary.com/mcu/

昔からある技術で、3 拠点以上でテレビ会議をする場合に使われている。MCU の特徴はサーバによる合成だ。

つまりそれぞれの音声や映像が別に送られてくるのではなく、サーバで合成されて 1 つの音声や映像として送られてくる。

100 人が参加する会議があったとしても、サーバで 1 つに合成される。

良いことだらけだが、合成するためサーバ側のリソースを恐ろしく使うため、最近は MCU から SFU が主軸になっていっている。

SFU (Selective Forwarding Unit)

https://webrtcglossary.com/sfu/

SFU という単語が出てきたのはここ数年。ただ概念自体は前からある。SFU は MCU だと CPU リソースを使われてしまうことから考え出された仕組み。

クライアントが配信する音声や映像をサーバが代理で他のクライアントやサーバに送るという仕組み。 そのため、クライアントは 10 人参加者がいた場合でもサーバに映像を送るだけで済む。

P2P の場合のフルメッシュと MCU の間の技術でバランスが良い事もあり WebRTC でクライアント・サーバモデルの場合は SFU が選択されることが多い。

よくありそうな質問

使えるのか

すでに Chrome に搭載されてから 5 年以上が過ぎており、普通に安定して使える。

不安定とか繋がらないとかはネットワークの問題がほとんどで、 WebRTC という技術自体はとても良くできており、大変安定している。

そして今でも進化し続けている。

仕事で使いたい

宣伝記事にはなるが、以下に仕事で WebRTC を利用する話をまとめておいたので見てもらいたい。

仕事で WebRTC

何が大変か

  • 最新ブラウザへの追従
  • 繋がらない人へのサポート対応

主にこの二点。両方ともこちらで事前に予測は難しい。前者はメーリングリスト見ておいて実際に検証しておけば問題ない。 後者だけはもうネットワーク環境などなど、いろいろなものに依存してしまうのでなんともいえない。実際に運用してノウハウをためるしかない。

基本的にクライアント側で頑張る必要があるので JavaScript が複雑になっていく。

また、ブラウザ同士の仕様差吸収という問題もある。これは全てのブラウザが WebRTC 1.0 の仕様を満たしているわけではない。 そのため Chrome 、Firefox 、Edge 、Safari といったブラウザの差を吸収しなければならない。

どんな技術なのか

WebRTC は映像や音声、そしてデータを 不安定な回線 でも超低遅延で送受信する仕組み。 超低遅延というのはどのくらいかというと 200 ミリから 300 ミリ程度。

人と人が映像や音声でやり取りする際に、違和感を感じなく話をすることができるようになると考えてもらって問題ない。

いままでの技術とどう違うのか

注意してほしいのは今使われている WebRTC は新しくできた技術ではなく、既存技術をいろいろ組み合わせてできた技術。

音声や映像のやりとりには RTP (Real-time Transport Protocol) という歴史のあるプロトコルが利用されている。 またデータのやり取りには SCTP (Stream Control Transmission Protocol) というこちらも歴史のあるプロトコルが利用されている。

つまり、今まで使われてきた技術をうまくまとめ、ブラウザ上で使えるようにした技術と考えてもらって問題ない。

何がすごいのか

ブラウザというよく使われるものに、標準で実装されているということがとても大きい。 ブラウザさえあればリアルタイムで音声や映像のやり取りを行えることになる。

今まで音声や映像をリアルタイムにやり取りするためには専用のクライアントが必要になることがほとんどだった。 それがブラウザさえあれば、よくなった。

さらに WebRTC はベースとしている既存の技術を今の時代の要求に合うように改良が行われている。

  • 暗号化前提とされている
  • 最新の音声や映像の圧縮技術が採用されている
  • 最新の再送、輻輳制御技術が採用されている
  • 日々改善されていっている

また、いまや WebRTC はブラウザだけの技術ではない。 iOS や Android だけでなく、組み込み製品にも利用が可能になりリアルタイムな意思伝達の技術としては WebRTC が圧倒的シェアを誇っている。

そしてさらに、それらの技術を全て無料で、さらにオープンソースとして公開されており、利用することができる。

Safari では動作するのか?

2019 年 8 月時点の最新版である Safari 12.1.2 ではとても安定して動作する。

HLS や MPEG-DASH とどう違うのか

その辺の話はこの資料にまとめたので読んでみてほしい。

リアルタイム動画配信コトハジメ

iOS には Chrome があるがそれでもダメなのか

WebView は RTCPeerConnection は対応しているが getUserMedia はまだ非対応。

iOS の Chrome や Firefox は WebView なので動作しない。

今のところ WebView に getUserMedia が実装されるのはセキュリティ的な懸念で対応予定は未定。

iOS や Android のアプリはどうやって開発すればいいのか

webrtc.org がちゃんと提供してくれている。

さらに最近は Bintray や Cocoapod で最新版のビルドを Google が提供し始めている

これらを上手く活用する事。

WebRTC の P2P はどんな技術なのか

WebRTC はブラウザとブラウザで直接やり取りをするため、 P2P (Peer to Peer) という技術を利用している。

少し勘違いされやすいのが P2P なのであれば、サーバは不要だという思われてしまう。 WebRTC 残念ながら完全な P2P ではない。

お互いに直接やり取りするにしてもお互いの情報がまったくわからなければやりとりしようがないため、 最初だけお互いを仲介してくれるシグナリングサーバと呼ばれるものが必要になる。

シグナリングサーバ、聞き慣れないと思いますが難しい話ではなく自分の IP アドレスを始め自分がどんな状況にいるのかを「どこにいるのかもわからないやり取りしたい相手」に情報を伝達してくれるサーバである。 つまりシグナリングサーバさえ知っていればなんとかなる。

シグナリングサーバでやりとりする情報は、 WebRTC では SDP (Session Description Protocol) というプロトコルを利用する。 これも実は古くからあるプロトコル。

このプロトコルをシグナリングサーバ経由でやりとりをすることで P2P でのやり取りをする準備を行う。 やり取りが終わったらシグナリングサーバは不要でお互い直接やり取りするだけでよくなる。

遅延はどのくらいなのか

環境や回線やマシンパワーに依存する。好条件であれば 200 ミリ秒程度の遅延で配信が可能。

この辺りの遅延については超低遅延 (Ultra-Low 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 でも映像は配信可能。

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 によって暗号化される。

DTLS の証明書検証はどう行われているのか

シグナリングを利用して交換する SDP の中身の a=fingerprint に書いてあるフィンガープリントの値を利用した仕組みを使っている。DTLS の証明書検証時にこの fingerprint の値と送られてきた証明書を検証している。

TURN サーバで通信を見られてしまうのではないか

TURN サーバは 暗号化された状態のまま データをリレーするため、通信状態をみることはできない。

ブラウザ同士の互換性はあるのか

実はすごく複雑なため簡単な回答が出来ない。基本的なものは互換性があるが、それ以外は非互換なものは少なくない。

Chrome や Firefox や Edge や Safari 以外に対応するのか

最後の大物である Safari が 11 にて対応した。 iOS のモバイル Safari も対応している。ただし WebView は getUserMedia に非対応なので注意してほしい。

Safari と WebRTC について

IE の対応予定はない。

Edge の WebRTC 対応はどうなのか

2019 年 8 月時点でかなり残念な対応。その辺は以下の資料にまとめてあるので見てほしい。

Edge と WebRTC について

高画質で配信したい

多くの帯域があるネットワークと高性能なマシンが必要になる。ちなみに VP8 や H.264 でフル HD での配信は 3000kbps 程度あればいける。

VP9 を利用すれば 1500kbps 程度でフル HD で、30fps な映像が配信可能。

音声が聞こえにくい

音声はマイクの機能依存になる。もちろん回線はイイ回線があること前提。

YVC-1000 - スピーカーフォン/マイク&スピーカー - ヤマハ株式会社

これを買えば解決する。12 万円と高額だが、一つ買えば幸せになれるので本当におすすめ。

スクリーンシェア機能を使いたい

getDisplayMedia を利用することで利用可能。

この機能は Chrome と Firefox と Edge (Chromium ベース) に搭載されており、利用することができる。 Safari は Technology Preview で利用可能。

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 形式に変換して配信する方式だ。

この技術を使うことで気軽な配信と大規模な配信の2つを実現できるようになる。今後とても注目される技術の1つだ。

詳細について知りたい場合は以下を見てほしい。

YouTube が WebRTC 配信に対応した – V – Medium

WebRTC の歩き方

WebRTC はどうも難しいというイメージを持たれていることが多い。 実際リアルタイムなデータを P2P でやり取りをするのはとても難しい。

ただ WebRTC の Web API 自体はとてもそれらを簡単にしてくれているし、多くのフレームワークも提供されており、それを使うことでかなり難易度は下がる。

ここでは目的別の WebRTC の歩き方を書いていこうと思う。

WebRTC に詳しくなりたい

WebRTC という技術は様々な集合体ということもあり、全てに詳しくなるのはおそらく無理だと思って良い。 そのため、どの部分について詳しくなるのかを決めて、進めるといいだろう。

参考書などは一切ないし、どこから始めるとかはない。 やるかやらないかだけの世界なのでコツコツやってみてほしい。

プロトコル部分だけであれば、自分でまとめた資料があるんで参考にしてもらえれば。

WebRTC 資料まとめ

WebRTC API に詳しくなりたい

WebRTC API を理解したい場合は W3C を読むのが一番早い、 ただブラウザごとに実装が異なるため、 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 が何しているかどうかが学べる。 基本的には以下の2つの API を理解すれば良くなる。

  • getUserMedia
  • RTCPeerConection

このあたりはお作法で使えば良いので、とにかくサンプルを読むと良い。

手前味噌だが AppRTC という webrtc.org が公開しているサンプルに合わせたシグナリングサーバとサンプルを公開している。これを読んで行くのをおすすめしたい。

shiguredo/ayame: WebRTC Signaling Server Ayame

シグナリングの仕組みは WebRTC API で定義されていないため、 最初どうしたらいいかわからなくなることがある。 その勉強用にと用意した実装ということもあり活用してほしい。

WebRTC のフレームワークを使えるようになりたい

基本的にフレームワークはオープンソースであると思うので、そのドキュメントとソースコードを読むのが一番だ。ほとんどの人はこのフレームワークを使うというところになるだろう。

それこそ WebRTC は後回しにし、フレームワークを学ぶべきだ。

STUN/TURN に詳しくなりたい

いるとは思わないが ... RFC 読むのが手っ取り早い。 難しいプロトコルではないので実際に実装してみるのも良い。

WebRTC オンライン専用コミュニティ

Discord に webrtc-jp というサーバを立てた。 WebRTC の情報共有がメイン。

WebRTC オンライン専用コミュニティ

広告

WebRTC SFU Sora

WebRTC SFU Sora

商用の WebRTC SFU です。価格は同時 100 接続で年間利用料ライセンス 60 万円です。 毎年かかります。製品のサポート料金込みです。200 接続だと年間 120 万円です。

複数人数での会議や、 数百人への配信、一対一の面談など様々な用途に利用可能です。

パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでも好きな環境で動かすことができます。

サーバさえあれば起動までは 10 分です。デモ機能が内蔵しているので動かすまで 15 分です。

  • 大変多くのお客様に採用いただいております
  • とにかく 落ちないこと を目的に作っています
  • とにかく 繋がること を目的に作っています
  • とにかく 手間がかからないこと を目的に作っています
  • 最新ブラウザのアップデートに追従しています
  • シグナリングサーバ内蔵ですので別途立てる必要はありません
  • TURN サーバ内蔵ですので別途立てる必要ありません
  • 日本語によるサポート対応しています
  • フルスクラッチ自前実装なのですべて把握しています
  • 1:1 の双方向に対応しています
  • 1:1000 の片方向に対応しています
  • 3:1000 といった配信者が複数の片方向にも対応しています
  • スポットライトという機能を利用することで 200 人以上の会議に対応しています
  • 録画機能があります
  • Chrome / Firefox / Edge / Safari といった主要ブラウザ全てに対応しています
  • Apache 2.0 ライセンスで JavaScript と iOS と Android のクライアント SDK を公開しています
  • Apache 2.0 ライセンスで React Native 向け WebRTC ライブラリを公開しています
  • 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
    • 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます

興味のある方はお気軽に sora at shiguredo.jp までお問い合わせください。

紹介や検討資料も公開しております。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.