Skip to content

Instantly share code, notes, and snippets.

@voluntas

voluntas/webrtc_for_work.rst

Last active February 7, 2024 13:33
Show Gist options
  • Star 148 You must be signed in to star a gist
  • Fork 4 You must be signed in to fork a gist
  • Save voluntas/379e48807635ed18ebdbcedd5f3beefa to your computer and use it in GitHub Desktop.
Save voluntas/379e48807635ed18ebdbcedd5f3beefa to your computer and use it in GitHub Desktop.
Download ZIP
仕事で WebRTC
Raw
webrtc_for_work.rst

仕事で WebRTC

日時

2023-01-15

作

@voluntas

バージョン

2023.1

url

https://voluntas.github.io/

この資料は以下の製品の宣伝を含みます。

もし気になる点があった場合は Twitter にて @voluntas 宛にメンションをいただけると助かります。

depth

1

概要

WebRTC を調べると、便利なライブラリを使った P2P のサンプルで終わることが多く、 実際にビジネスレベルでの運用を考える時の情報が少なすぎるのが問題だと考えています。

また WebRTC はブラウザのアップデートに伴い仕様が変わる場合があり、過去の資料では動かないこともあります。 2020 年現在では Chrome 、Firefox、 Safari、 Edge と主要なブラウザすべてで WebRTC は動作します。

この資料では WebRTC を仕事で利用する場合、何をしたいのか、 やりたいことをするには何をすればいいのかを、選ぶお手伝いができればと考えています。

注意

  • この資料は宣伝です
  • この資料では他社の商用製品については扱いません
  • この資料では具体的に JavaScript をどう書くべきかという話などは扱いません
  • この資料では具体的な WebRTC の仕様については扱いません

判断

ここでは様々な側面から見た WebRTC 需要に対して、どうしたらいいのかをざっくり書いてきます。

趣味で勉強してみたい

これを読む必要はありません。色々試してみましょう。調べてみればいろいろ情報が出てきます。

一番先に読むべきは はじめに | 好奇心旺盛な人のためのWebRTC です。

その後は手を動かしていくために Real time communication with WebRTC を読みながら試していくのがおすすめです。

より深く学びたい場合は ハイパフォーマンス ブラウザネットワーキング の 18章 WebRTC を読みましょう。

仕事で使いたい

WebRTC を使う場合、一番最初にはお金を払うか自分たちでがんばるかを決める必要があります。

WebRTC は音声や映像を扱う以上、繋がらないが誰もがわかる技術です。 そのため、できる限り繋がる必要があります。ただ、それが繋がらなくてもいい場合だってあります。 おまけ的な機能だったらチャットでカバーできたりもしますし、最終的にはメールや Skype でも良い場合だってあります。

まずはお金を払う用意があるのかどうかを確認しましょう。

仕事として P2P を前提として使っていきたい

1 対 1 までであれば P2P で問題ないでしょう、3 人以上になった時点で SFU を検討するべきです

まずは是非 WebRTC Signaling Server Ayame の利用を検討してみてください。かんたんに利用できます。

仕事として MCU を前提として使っていきたい

2021 年時点では WebRTC を利用する場合に MCU を採用することはメリットはありません。 本当に MCU が必要か検討し直してみてください。

仕事として SFU を前提として使っていきたい

OSS でがんばるか、商用のサービスかパッケージを利用するかを選ぶ必要があります。

ブラウザ対応状況

仕事で利用する場合に一番気になるのがブラウザ対応状況です。

Chrome

現時点 WebRTC を安定的に利用するならば、Chrome が一番無難です。

Firefox

Chrome よりかなり遅れてきています、 かなり おすすめできません。 実際に WebRTC API がいくつか実装されていないため、Firefox のみに向けた対応が必要になります。

Edge

Chrome と同等です。

Safari

WebRTC を安定して利用できるブラウザです。ただし細かい点で Chrome や Edge に劣ります。

JavaScript クライアント

商用サービスや商用パッケージを利用する場合はクライアントが用意されていることが多いと思いますので、それを利用するのが一番です。 また OSS でもクライアントが用意されている場合があるため、それを使うのが無難です。

WebRTC API はブラウザごとに仕様が異なります。さらにアップデートされるたびにその状況は変化していっています。まずはそこを意識しましょう。

JavaScript ライブラリ選定

実はこれといったおすすめは特にありません。色々ありますがメンテナンスが終了するタイミングでさてどうしたらいいかとなってしまいます。 簡単に使えるライブラリは隠蔽が多く、あなたのやりたいことが阻害されることが多いです。

おすすめは商用サービスのクライアントが OSS で公開されている場合があるので、それを参考にしてみるのが良いと思います。

WebRTC adapter

ブラウザの互換性を一番に考慮することになります。

そのため既存の便利ライブラリを覚えるのではなく、 adapter というブラウザの互換性を吸収してくれるライブラリを使うことを検討しても良いかもしれません。

webrtcHacks/adapter: Shim to insulate apps from spec changes and prefix differences. Latest adapter.js release:

ただ最近では adapter を使う必要性は殆どなくなってきていますので、1 から書いてみてもいいかもしれません。

トラブルシューティング

あまりにいろいろな要因があるため、対応が難しく、ノウハウが重要になります。

まず、一番最初にすることは webrtc.org が提供してくれている test.webrtc.org に接続してもらう事です。

https://test.webrtc.org/

ここにアクセスして貰い Start を押して貰いましょう。

すべての調査が終わったら、バグマークをクリックしてアップロードレポートをクリックし、URL を生成して貰いましょう。

その後その URL を貰って、ログを確認してみてください。

ログを貰ってからが勝負です。がんばりましょう。

ブラウザやスマートフォン以外で使いたい

https://webrtc.org/native-code/native-apis/

ネイティブで利用できる仕組みがありますので、ブラウザ以外でも利用可能です。ただ情報はかなり少ないです。 また利用するソースコードのバージョンは 6 週間ごとに上がっていきますので追従は iOS/Android と同様ですのである程度の覚悟が必要です。

ネイティブ API を利用した shiguredo/momo: WebRTC Native Client Momo を OSS として公開しています。是非使ってみてください。

データチャネルを使いたい

データチャネルは WebRTC 上で音声や映像以外のデータをやり取りするための仕組みで、 P2P でデータのやり取りをする仕組みとして使われてきました。 P2P でのデータやり取りで使われてきたのはほとんどファイル転送や P2P の仕組みを上手く使った CDN やファイル共有あたりが有名でした。 つまり WebRTC のデータチャネルは今まではあまり使いみちがないというのが現実でした。

ただ、最近ではエッジデバイスでの映像解析が可能になったことにより、映像とともに解析データをリアルタイムに送りたいという要望や、 VR で音声とモーションデータを送りたいといったデータだけではなく音声や映像との組み合わせの需要がでてきました。

お金を払う用意はない (P2P 編)

無償で提供されているサービス、またはオープンソースを使うということなります。 その場合はいくつかの課題に立ち向かう必要があります。

  • 繋がらないときにどうするか
  • ブラウザのアップデートへの追従をどうするか
  • シグナリングサーバの運用をどうするか
  • STUN/TURN サーバの運用をどうするか
  • iOS/Android アプリどうするか

主にこの 5 つが課題になります。まずはお金を払わず P2P で運用する場合をまとめてみます。

繋がらないときにどうするか

がんばりましょう、理由は様々です。ノウハウを溜め込みましょう。ネットワーク環境、ブラウザ環境、プラグイン、様々な原因があります。

Stack Overflow で助言を求めましょう。

ブラウザのアップデートへの追従をどうするか

がんばりましょう。適当にライブラリを決めてしまうと追従を止める可能性はあります。もちろん Pull-Request を送ったりするのもとても良いことです。

Chrome と Firefox と Safari のブラウザの変更履歴に目を凝らしましょう。

シグナリングサーバの運用をどうするか

がんばりましょう。シグナリングサーバは WebRTC の仕様としては決められていません。 どんな実装でも問題ありません。基本的には WebSocket と JSON の組み合わせが多いです。

この部分は利用者数を想定する必要があります。基本的に WebRTC を利用する場合はシグナリング用の通信は張りっぱなしにすることが多いです。 そのため 1 サーバで同時に張れる量を調べてみるのが良いです。

Golang や Node.js なんでも良いです、好きな言語で作ってもよし。既存のシグナリングサーバ実装を使うもよしです。

ただ、無償で提供されているシグナリングサーバはいつ閉じるのかわかりません。ここは注意しましょう。

STUN/TURN サーバの運用をどうするか

がんばりましょう。TURN サーバを建てないと 70% 程度しか繫がらないという調査結果があります。 つまり 30% はつながりません。仕事で使う場合はこれは受け入れられないでしょうから、 TURN サーバのノウハウを溜め込んでいきましょう。

ありがたいことに TURN サーバの選択肢は多くありません。最初は信頼と実績の coturn という STUN/TURN サーバを利用してみてください。

https://github.com/coturn/coturn

TURN サーバを運用するということはトンネルサーバを提供するということになります。転送量を気にしましょう。 映像や音声はすぐに最大値を利用してきます。WebRTC であれば 2000 kbps とかもザラにつかってきますので、 あっというまに転送量が 1G 行きます。また、TURN サーバが落ちている場合は繫がらないのと同等ですので気をつけてください。

TURN サーバは認証が必須です。Username/Credential はワンタイムで利用できるようにしましょう。 coturn は RDB や Redis といったデータベースと連携できますので、うまく組み合わせていきましょう。

TURN-TCP と TURN-TLS まで対応させてしまえば、 そのポートが潰されて限りは大丈夫なはずです。 たまに MITM やってる FW がありますがそこはまぁあきらめてください。

iOS/Android アプリどうするか

がんばりましょう。まずは https://webrtc.org/ を眺めてみることをお勧めします。

ビルドして、使えるようになるのがまず一番です。忘れていけませんがこのコードもガンガンバージョンは上がっていきます。 ブラウザだけではなくこれらのコアライブラリにも追従していく必要があります。

React-Native や Flutter を利用するというのも手です。

以下は時雨堂がメンテナンスしている様々な環境向けの libwebrtc ビルドで、 iOS/Android 向けのビルドも含んでいます。

https://github.com/shiguredo-webrtc-build/webrtc-build

WebRTC Signaling Server Ayame

これは宣伝です

OpenAyame プロジェクト

Ayame は WebRTC SFU を１から開発している時雨堂が、 オープンソースとして公開している WebRTC を P2P で利用する際に必要となるシグナリングサーバです。

成果は Apache License 2.0 としてオープンソースで公開しています。

OpenAyame/ayame: WebRTC Signaling Server Ayame

Go で書かれており、 1:1 の利用に限定することでかなりシンプルに作られています。

Web SDK や SDK のサンプルもあります。 React を利用したサンプルも用意しています。

WebRTC シグナリングサービス Ayame Labo

これは宣伝です

Ayame Labo は Ayame と完全互換なサービスとして提供し、 さらにルーム認証や STUN/TURN サーバを提供している 無料 で利用可能なサービスです。

Ayame Labo

Ayame 完全互換のサービスです。そのため、最初はサービスを利用していたが、自社で運用するといった切り替えが可能です。

Ayame Labo ドキュメント

お金を払う用意はない (OSS SFU/MCU 編)

お勧めは Janus です。様々な機能を持っていますし、たくさんの場所で利用されています。 今 OSS を選択するのであれば Janus が現実的だと思います。

お金を払う用意はある (商用 MCU 利用編)

大規模なうえに MCU が必須で自社運用を考えるのであれば、自分が知っている範囲であれば今のところ一つです。 ちなみに SFU 機能も持っています。まずは代理店を探してみると良いでしょう。

ただ、現時点では商用 MCU を選択するメリットは少なくなってきています。

Zoom や Google Meet 、MS Teams など多くのサービスが SFU を採用しています。

お金を払う用意はある (商用コールセンター編)

WebRTC とコールセンターで検索するといくつか出てきます。大規模すぎて自前で何かという世界ではありません。 WebRTC 1% それ以外 99% の世界ですので、まずはこの資料を読む前にもっと調べることがあるはずです。

コールセンターの仕組みは複雑です、それを踏まえてください。

お金を払う用意はある (商用 SFU 利用編)

WebRTC SFU Sora

これは宣伝です

WebRTC SFU Sora

商用の WebRTC SFU です。価格は同時 100 接続でライセンス費用は年間 84 万円です。 3 ヶ月ライセンスも用意してあります。製品のサポート料金込みです。

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

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

サーバさえあれば起動までは 30 分です。 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 ライブラリを公開しています
  • 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
    • 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます

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

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

お金を払う用意はある (商用 SFU サービス利用編)

Sora Cloud

これは宣伝です

Sora Cloud

商用の WebRTC SFU である Sora のクラウド版です。

最大同時接続数 5000 と最大利用帯域 20 Gbps まで利用可能です。

転送量や利用時間といった課金と Sora の運用から解放されるサービスです。

興味のある方はお気軽に Sora Cloud サイト内にあるメールにてお問い合わせください。

広告

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 で動作します。

Sora Labo

Sora Labo

Sora を時雨堂がサービスとして提供しています。

  • 無料で使えます
  • 商用目的では使えません
  • 法人、アカデミックでの利用は申請必須です
  • GitHub アカウントを持っていればすぐに利用できます
  • TURN の UDP / TCP / TLS を提供します
  • チャネルに認証をかけられます
    • シグナリングキーを提供します
  • 同時接続数制限があります
  • 認証ログを確認できます
  • 統計情報を確認できます

Ayame Labo

Ayame Labo

Ayame 完全互換のサービスを時雨堂が提供しています。

  • 無料で使えます
  • サインアップしないでも使えます
    • ただし STUN/TURN や認証機能などは利用できません
  • GitHub アカウントを持っていればすぐに利用できます
  • TURN の UDP / TCP / TLS を提供します
  • ルームに認証をかけられます
    • シグナリングキーを提供します
  • 認証ログを確認できます

おまけ

世界の WebRTC プラットフォーム一覧。おそらく世界で一番詳しい資料です。

WebRTC Platforms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment