| 日時: | 2019-09-01 |
|---|---|
| 作: | @voluntas |
| バージョン: | 19.09.0 |
| url: | https://voluntas.github.io/ |
この記事は WebRTC SFU Sora や WebRTC シグナリングサービス Ayame Lite 、OpenAyame プロジェクト 、OpenMomo プロジェクト の宣伝記事です。
もし気になる点があった場合は Twitter にて @voluntas 宛にメンションをいただけると助かります。
Contents
WebRTC を調べると、便利なライブラリを使った P2P のサンプルで終わることが多く、実際にビジネスレベルでの運用を考える時の情報が少なすぎるのが問題だと考えています。
また WebRTC はブラウザのアップデートに伴い仕様が変わる場合があり、過去の記事では動かないこともあります。 最近では Chrome と Firefox に加え、 Edge が対応し、そして 2017 年秋には Safari が対応しました。 ちなみに、これら 4 つのブラウザは最悪なことに WebRTC の仕様がそれぞれ動作が異なります。
また、 2020 年には Flash が終了し、 Chrome M76 からはデフォルト無効になっています。 既存の Flash で実現していた機能を WebRTC や HLS/MPEG-DASH に切り替えていく必要がります。
この資料では WebRTC を仕事で利用する場合、何をしたいのか、やりたいことをするには何をすればいいのかを、選ぶお手伝いができればと考えています。
- この記事では具体的に JavaScript をどう書くべきかという話などは扱っていません
- この記事では具体的な WebRTC の仕様については触れていません
ここでは様々な側面から見た WebRTC 需要に対して、どうしたらいいのかをざっくり書いてきます。
これを読む必要はありません。色々試してみましょう。調べてみればいろいろ情報が出てきます。
まず勉強したいのであれば Real time communication with WebRTC を読みながら試していくのがおすすめです。
WebRTC を使う場合、一番最初に気にする必要があるのはお金を払う用意があるのかどうか、です。
WebRTC は音声や映像を扱う以上、繋がらないが誰もがわかる技術です。そのため、できる限り繋がる必要があります。ただ、それが繋がらなくてもいい場合だってあります。おまけ的な機能だったらチャットでカバーできたりもしますし、最終的にはメールや Skype でも良い場合だってあります。
まずは会社としてお金を払う用意があるのかどうかを確認しましょう。
1:1 までの会議であれば P2P で問題ないでしょう、 3 人になった時点で SFU を検討するべきです
まずは是非 OpenAyame/ayame: WebRTC Signaling Server Ayame の利用を検討してみてください。
MCU が必要ということは会議システムがメインでしょうか。MCU はそもそも会議システムの世界で生まれた技術ですのでそちらの代理店を色々探して見るのが良いです。
MCU は 1 部屋 1 コアを利用するくらいの CPU リソースを持っていくシステムです。その部分を考慮すると良いです。もちろん OSS もあるので、それも検討するのが良いでしょう。
サービスを利用するか、OSS でがんばるか、商用を利用するかの二択をまず選びます。 もちろんどちらかを選択して、辛くなったので切り替えるというのでも構わないと思います。
最初から SFU を選択できるのであればある程度 WebRTC への理解があると思いますので、まずは P2P を検討するもありです。
仕事で利用する場合に一番気になるのがブラウザ対応状況です。
現時点 WebRTC を安定的に利用するならば、Chrome が一番無難です。
Chrome より少し遅れてきていますが、あまりおすすめできません。
仕様がクローズドで、さらにソースがクローズドで、アップデートが不明確なため対応していると言っても現時点では採用はお勧めしません。 さらにデータチャネルに対応していません。
ただし新しい Chromium ベースの Edge はほぼ Chrome と同じため、推奨ブラウザといって問題ないです。
Safari 11 で WebRTC への対応しました。
2019 年 8 月時点で Safari 12.1.2 がリリースされています。 12.1 で Safari は推奨ブラウザと扱って問題ないくらい WebRTC が安定的に利用可能です。
商用サービスや商用パッケージを利用する場合はクライアントが用意されていることが多いと思いますので、それを利用するのが一番です。 また OSS でもクライアントが用意されている場合があるため、それを使うのが無難です。
WebRTC API はブラウザごとに仕様が異なります。さらにアップデートされるたびにその状況は変化していっています。まずはそこを意識しましょう。
実はこれといったおすすめは特にありません。色々ありますがメンテナンスが終了するタイミングでさてどうしたらいいかとなってしまいます。簡単に使えるライブラリは隠蔽が多く、あなたのやりたいことが阻害されることが多いです。
おすすめは商用サービスのクライアントが OSS で公開されているパターンがあるので、それを参考にしてみるのが良いと思います。
ブラウザの互換性を一番に考慮することになります。 そのためおすすめなのが既存の便利ライブラリを覚えるのではなく、 adapter というブラウザの互換性を吸収してくれるライブラリを使うことを検討しましょう。
adapter は世界中に WebRTC を利用している人たちの苦労が集まっています。まずはここから始めて、なれてきたら外していくで良いと思います。
あまりにいろいろな要因があるため、対応が難しく、ノウハウが重要になります。
まず、一番最初にすることは webrtc.org が提供してくれている test.webrtc.org に接続してもらう事です。 ただこれは当たり前ですが iOS ではできませんので要注意です。
ここにアクセスして貰い 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 で 1:1 のやり取りで、さらに限定的な場面でのみ利用可能と考えて間違いありません。
無償で提供されているサービス、またはオープンソースを使うということなります。その場合はいくつかの課題に立ち向かう必要があります。
- 繋がらないときにどうするか
- ブラウザのアップデートへの追従をどうするか
- シグナリングサーバの運用をどうするか
- STUN/TURN サーバの運用をどうするか
- iOS/Android アプリどうするか
主にこの 5 つが課題になります。まずはお金を払わず P2P で運用する場合をまとめてみます。
がんばりましょう、理由は様々です。ノウハウを溜め込みましょう。ネットワーク環境、ブラウザ環境、プラグイン、様々な原因があります。
Stack Overflow で助言を求めましょう。
がんばりましょう。適当にライブラリを決めてしまうと追従を止める可能性はあります。もちろん Pull-Request を送ったりするのもとても良いことです。
Chrome と Firefox と Safari のブラウザの変更履歴に目を凝らしましょう。
がんばりましょう。シグナリングサーバは WebRTC の仕様は決められていません。どんな実装でも問題ありません。多い実装は Node.js で Socket.io が多いようです。
この部分は利用者数を想定する必要があります。基本的に WebRTC を利用する場合はシグナリング用の通信は張りっぱなしにすることが多いです。そのため 1 サーバで同時に張れる量を調べてみるのが良いです。
Golang や Elixir なんでも良いです、好きな言語で作ってもよし。既存のシグナリングサーバ実装を使うもよし。
ただ、無償で提供されているシグナリングサーバはいつ閉じるのかわかりません。ここは注意しましょう。
がんばりましょう。TURN サーバを建てないと 70% 程度しか繫がらないという調査結果があります。つまり 30% はつながりません。仕事で使う場合はこれは受け入れられないでしょうから、 TURN サーバのノウハウを溜め込んでいきましょう。
ありがたいことに TURN サーバの選択肢は多くありません。まずは coturn というサーバを利用してみてください。
https://github.com/coturn/coturn
TURN サーバを運用するということはトンネルサーバを提供するということになります。転送量を気にしましょう。映像や音声はすぐに最大値を利用してきます。WebRTC であれば 2000kbps とかもザラにつかってきますので、あっというまに転送量が 1G 行きます。また、TURN サーバが落ちている場合は繫がらないのと同等ですので気をつけてください。
TURN サーバは認証が必須です。Username/Credential はワンタイムで利用できるようにしましょう。coturn は RDB や Redis といったデータベースと連携できますので、うまく組み合わせていきましょう。
TURN-TCP と TURN-TLS まで対応させてしまえば、 そのポートが潰されて限りは大丈夫なはずです。たまに MITM やってる FW がありますがそこはまぁあきらめてください。
がんばりましょう。まずは https://webrtc.org/ を眺めてみることをお勧めします。
ビルドして、使えるようになるのがまず一番です。忘れていけませんがこのコードもガンガンバージョンは上がっていきます。ブラウザだけではなくこれらのコアライブラリにも追従していく必要があります。 最近は日本語でビルド情報を公開してくれている方も多いのでそちらを参考にしてみるのが良いと思います。
色々妥協できるのであれば React-Native を利用するというのも手です。
oney/react-native-webrtc: A WebRTC module for React Native.
ただ、 React-Native も結局は iOS/Android の知識が必要なので、まぁ悩ましいところではあります。
これは宣伝です
Ayame は WebRTC SFU を１から開発している時雨堂が、 そのノウハウをつぎ込みオープンソースとして公開している WebRTC を P2P で利用する際に必要となるシグナリングサーバです。
成果は Apache License 2.0 としてオープンソースで公開しています。
OpenAyame/ayame: WebRTC Signaling Server Ayame
Go で書かれており、 1:1 の利用に限定することでかなりシンプルに作られています。商用にも耐える性能を持っています。
Web SDK や SDK のサンプルもあります。 React を利用したサンプルも用意しています。
ただし 2019 年 9 月現在 iOS/Android SDK はありません。今後開発予定です。
これは宣伝です
Ayame Lite は Ayame をサービスとして提供し、さらに面倒なルーム認証や STUN/TURN サーバを提供している 無料 で利用可能なサービスです。
WebRTC シグナリングサービス Ayame Lite 開発ログ
Ayame 自体には一切手を入れていません。そのため、最初はサービスを利用していたが、自社で運用するといった切り替えが可能です。
現在オープンベータテスト中ですので、是非利用してみてください。
WebRTC シグナリングサービス Ayame Lite の使い方
- meetecho/janus-gateway: Janus WebRTC Gateway
- MS の配信サービス Beam などに利用されています
- Beam は Mixer | Interactive Livestreaming と名前が変わりました
- versatica/mediasoup: Cutting Edge WebRTC Video Conferencing
- 今一番活発な開発が行われている C++/Node.js で書かれた WebRTC SFU です
- DataChannel にも対応しました
- Jitsi
- Atlassian が買収しましたが、別の会社に売却されました
- Kurento
- twilio が買収しました
- lynckia/licode: Open Source Communication Provider based on WebRTC and Cloud technologies
- C++ で書かれた MCU/SFU です
- medooze/media-server: WebRTC Media Server
- C++ で書かれた MCU/SFU です
お勧めは Janus です。様々な機能を持っていますし、たくさんの場所で利用されています。 今 OSS を選択するのであれば Janus が現実的だと思います。
利用する OSS を定めて、がつがつ使って Pull-Request を送ったり、 SO で解答したりしてみましょう。
有償のシグナリングサービスが幾つかあります。
- Twilio - Communication APIs for SMS, Voice, Video and Authentication
- 従量課金制です
- WebRTC TURN Server Cloud Provider - Xirsys
- 定額制ですが、通信量や接続数ごとにプランが変わります
これらは同時に STUN/TURN サービスも提供してくれています。ただ問題の繫がらないを解決するヒントはあまりしてくれません。そんなときはサービスを使うことで情報を可視化してくれます。
Analytics for WebRTC — callstats.io
さて、ここで少し気づいて貰う必要があります。お金を払おうがお金を払わまいが WebRTC の知識は必要になるということです。結局勉強する必要があります。
ざっくり勉強する必要があります。現在在庫がありませんが ... この本がおすすめです。
商用サービスは接続時間での従量課金制がほとんどです。
OpenTok | WebRTC Platform for Video, Voice and Messaging from TokBox
一通りの機能は揃っていますが、とても高額なのとサーバが日本にはありません。この辺りは要注意です。サポートもすべて英語になります。
Announcing Programmable Video Group Rooms: More Participants, Video Recording, and Pricing for Scale
日本だと KDDI が提供しています。
Twilio for KDDI Web Communications | コミュニケーションAPI
Agora.io ビデオ通話・ライブ配信SDK | iStudy
日本のサイトはあまり詳細には書いていないので Agora: The Global Leader in Real Time Communications 海外のサイトを見たほうが良いです。
マルキャス - WebRTCを利用したライブ配信システム -
バックエンドは OSS の SFU である mediasoup です。
SkyWay - Enterprise Cloud WebRTC Platform
大規模なうえに MCU が必須で自社運用を考えるのであれば、自分が知っている範囲であれば今のところ一つです。ちなみに SFU 機能も持っています。
まずは代理店を探してみると良いでしょう。価格と機能を確認し、それで納得できそうであれば検討をすると良いです。
WebRTC とコールセンターで検索するといくつか出てきます。大規模すぎて自前で何かという世界ではありません。 WebRTC 1% それ以外 99% の世界ですので、まずはこの記事を読む前にもっと調べることがあるはずです。
コールセンターの仕組みは複雑です、それを踏まえてください。
これは宣伝記事です
商用の WebRTC SFU です。価格は同時 100 接続で年間利用料ライセンス 60 万円です。毎年かかります。製品のサポート料金込みです。200 接続だと年間 120 万円です。
複数人数での会議や、 数百人への配信、一対一の面談など様々な用途に利用可能です。
パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでも好きな環境で動かすことができます。
サーバさえあれば起動までは 10 分です。デモ機能が内蔵しているので動かすまで 15 分です。
- 大変多くのお客様に採用いただいております
- とにかく 落ちないこと を目的に作っています
- とにかく 繋がること を目的に作っています
- とにかく 手間がかからないこと を目的に作っています
- 最新ブラウザのアップデートに追従しています
- シグナリングサーバ内蔵ですので別途立てる必要はありません
- TURN サーバ内蔵ですので別途立てる必要ありません
- 日本語によるサポート対応しています
- フルスクラッチ自前実装なのですべて把握しています
- 1:1 の双方向に対応しています
- 1:1000 の片方向に対応しています
- 3:1000 といった配信者が複数の片方向にも対応しています
- スポットライトという機能を利用することで 50 人以上の会議に対応しています
- 録画機能があります
- Chrome / Firefox / Edge / Safari といった主要ブラウザ全てに対応しています
- Apache 2.0 ライセンスで JavaScript と iOS と Android のクライアント SDK を公開しています
- Apache 2.0 ライセンスで React Native 向け WebRTC ライブラリを公開しています
- https://github.com/shiguredo/react-native-webrtc-kit
- Sora と簡単に利用可能なサンプルも公開しています
- 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
- 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます
興味のある方はお気軽に sora at shiguredo.jp までお問い合わせください。
紹介や検討資料も公開しております。
shiguredo/momo: WebRTC Native Client Momo
WebRTC クライアントをラズベリーパイゼロなどで動かせるようにした製品をオープンソースとして公開しています。
世界の WebRTC プラットフォーム一覧。おそらく世界で一番詳しい資料です。