ビデオ SaaS のエンジニアリング最前線を主催しました

こんにちは、@24guchiaです。

掲題の通り、イベントに登壇しました。
イベント URL はこちら。 ビデオSaaSのエンジニアリング最前線

今回は、 Twilio をやっていたときからの盟友、本間さんに誘われて、軽率に OK しました。また、本間さんの旧友の高松さんとともに登壇し、ベルフェイスの広報?で社内勉強会を一緒に盛り上げてくれているエミさんと、 1 ヶ月以上毎日ウェビナーをしている堀さんにも協力いただき、無事に開催までこぎつけました。

登壇資料はこちら。

登壇自体は何度か経験がありましたが、主催側に回るのははじめてなので、経緯などをまとめておきます。

“ビデオ SaaS のエンジニアリング最前線を主催しました” の続きを読む

ハイパフォーマンスブラウザネットワーキングと関連する RFC を読んだ

こんにちは、@24guchiaです。

オライリーのハイパフォーマンスブラウザネットワーキングを読み終わりました。去年の 11 月に買って、なかなか難しく、積んだりしてたら時間かかりました。だいたい 350 ページくらいなので、それなりの文量です。

やっと読み終わって嬉しくてツイートしてしまったw

読み始めるきっかけは WebRTC を使って開発する上での基礎力作りです。

“ハイパフォーマンスブラウザネットワーキングと関連する RFC を読んだ” の続きを読む

Twilio Video が簡単に使える OSS が出ました

こんにちは、@24guchiaです。

Deploy your own video collaboration app in five minutes or less

Twilio Video が使えて、かんたんにビデオチャットができる OSS が Twilio 社よりでました。

特長としては、

  • マルチプラットフォームで使える
    • Web(ReactJS)
    • iOS
    • Android
  • ノーコードでとりあえず動かせる
  • ビデオチャットで求められる要件がだいたい満たされている
    • 画面共有
    • カメラの有効化・無効化
    • マイクのミュート・アンミュート
    • 電波状況のモニター
    • Dominant Speaker(一番声が大きい人)を検出してくれる

というわけでやってみました。

“Twilio Video が簡単に使える OSS が出ました” の続きを読む

OpenTokのチュートリアルやってみた

こんにちは、@24guchiaです。
入社エントリーにある通り、bellFaceに入社しました。

ベルフェイス株式会社に入社しました

bellFaceはOpenTokを使っているので、
チュートリアルをニート期間中にやってみましたのでまとめておきます。
なお、内容は執筆時点(2019年10月25日)のもののため、
最新の情報はドキュメントを参照してください。 “OpenTokのチュートリアルやってみた” の続きを読む

レバレジーズ株式会社を退職しました

こんにちは、@24guchiaです。
タイトルの通り、7年勤めたレバレジーズ株式会社を退職しました。

レバレジーズ退職後は、ベルフェイス株式会社に入社しました。

ベルフェイス株式会社に入社しました

“レバレジーズ株式会社を退職しました” の続きを読む

WebRTC Meetup Tokyo #21 参加レポート

こんにちは、@24guchiaです。

先日参加したWebRTCミートアップの参加レポートです。
https://atnd.org/events/105581

聞く側兼、話す側でした。
このイベント、話す側もしたのは年始に書いた記事で
Twilio以外のコミュニティに顔出ししたいと書いた目標のためです。

18/19の振り返りとこれから

引き続きやっていきたい。 “WebRTC Meetup Tokyo #21 参加レポート” の続きを読む

WebRTCについて調べた

こんにちは、@24guchiaです。

Webの記事何本かと本2冊買って読んでみたので、一度、現状の理解を書いてみます。

ちなみに買った本は下の本と、

 

わか(った気にな)るWebRTCの電子版です。

https://booth.pm/ja/items/504677

読む順番としては、わか(った気にな)るWebRTCを読んで、

ざっくり概要を頭に入れてわかった気になってから、リックテレコムのWebRTCの本を読むと良いと思います。

いきなりリックテレコムから入ると心が折れること間違い無し。

最近、リックテレコムから販売されている本を買うことが増えてきた。

この記事は古いので、こちらの記事も参考にしてください。(2020年7月10日 追記)

ハイパフォーマンスブラウザネットワーキングと関連する RFC を読んだ

 

この記事で分かること

WebRTCってそもそも何か、どういうところで使われてて、

どんなプロトコルが用意されているかが分か(った気にな)るようになります。

なんで調べたの?

Twilioを使うにあたって、Twilioがそのあたり難しい部分を吸収したライブラリやSDKを用意してくれてるけど、

デバッグするにあたってあまりにも分からないことが多すぎたため。

Twilio使わないから知らなくても良いや〜って思わず、ネットワークについての勉強になるし、

最近ではiOS11からWebRTC対応されスマホ全般で使える技術となったので、

Web系の開発をしている人は押さえておくべき技術になっていくでしょう。

WebRTCってそもそも何?

Web Real Time Communicationの略。名前の通り、

ブラウザでのリアルタイム性を持つコミュニケーション全般を取り扱います。

コミュニケーションは具体的に、音声通話や動画(ビデオチャット)などを指します。

特長はインターネット回線につながっているブラウザさえあれば、

上記コミュニケーションを行える点です。

もう電話機や専用のソフトウェアは必要なくなります。

WebRTCを使っているサービスは何がある?

Twilio

appear.in

Slack音声通話

などがあります。使ったことがあるサービスがあると思います。

リアルタイムコミュニケーションってどうやってるの?

  1. 音声などの情報入出力の許可をユーザによって行わせる
    • 不正にユーザの情報を収集しづらくするために、ユーザに許可・拒否を選択させる
  2. ピア同士の接続の確立
    • 次に詳細な説明を書きます
  3. ピア同士のデータ交換
    • データ交換によって、音声通話やビデオチャットが可能になります
  4. 接続の終了

ピア同士の接続の確立って難しそうだね?

はい、難しいですね

接続の確立について、オファーアンサーネゴシエーションという

ローカルとリモートの設定を交換する手法があります。

  1. 接続を試みる側がどのメディアどのデコードで送るかをオファーとして送る
  2. 受け手側は、送られたオファーに対して、対応可能かと他に使いたいものリストをアンサーとしてオファー側に送る
  3. アンサーを受取、各ピア同士で受け取った情報を設定することでデータ交換が行えるようになる

ネットワークの制限

セキュリティを高めるためのファイアウォールや

NATの存在が接続の確立にあたっては障害となる。

その回避を行うため、特別なプロトコルが用意されています。

NAT is 何?

Network Address Translatorの略。

IPアドレスは有限の資源であり、資源の有効活用のために使われる。

グローバルIPをNAT機能持ちルータで、ルータ内のプライベートIPとの変換を行う技術。

NAPTであることがほとんどで、ポートの変換も行うことが多い。

正確にはNAPTだけど、一旦NATで統一します。

ピア同士が接続されるWebRTCだが、

NATの存在のため、接続先ピアがどのプライベートIPを持っているかが

外側からは分からないため、下記NAT越えが行われる。

NAT越え is 何?

上記問題への対応のため、ピアに直接パケットを送るために行われる手法・技術。

具体的には、ホールパンチという手法でNATを透過したテストパケットを送れるかどうかを試す。

ホールパンチ is 何?

NATの外から、プライベートIPアドレスとポート番号のペアを知るために行われる手法。

具体的には下記手法を試していく。

ICE is 何?

Interactive Connectivity Establishmentの略。プロトコルのひとつ。

NAT越えを行うための手法の一つ。ICEでは下記を行う。

  • IPアドレスとポート番号のペアを集める
  • ピア同士がペアを交換する
  • ホールパンチを試す
  • 繋がるペアでデータ交換を行う

上記が純粋な手法で、よくあるICEではSTUNプロトコルとTURNプロトコルを使い、

ピア同士の接続の確立を試みます。

また、VanillaとTrickleという拡張がある。

Vanilla ICE is 何?

標準のICEを指す。拡張であるTrickleが出来たため、標準がVanillaと呼ばれる。

VanillaはすべてのIPアドレスとポート番号のペアを収集してから

すべて接続を試し、接続確立されたものから使用するペアを選択する。

バニラという単語自体には標準という意味がある。

ICEという名前のためのシャレみたいなもんでしょうね。

Trickle ICE is 何?

標準のICEに対し、拡張されたICEを指す。

Vanillaに対し、Trickleではペアを順次交換し、接続成功した時点で処理が終了されるので、

接続確立までがVanillaよりも速くできる可能性がある。

現時点ではChrome/Firefoxと一部ブラウザでしか対応していないため、

使用する際には最新の情報を調べてください。

Trickleは滴り落ちるという意味なので、ペアを少しずつ試すという点が

アイスが滴り落ちるのと様子に似ているからこの名前なんだと思います。

STUN is 何?

Session Traversal Utilities for NAT の略。プロトコルのひとつ。

これもNAT越えのための手法のひとつ。

STUNで対象のピアのネットワーク上にNATが存在するかどうかを確認するプロトコル。

テストパケットをSTUNサーバに送り、自分のIPが外部のネットワーク上からどういうIPで見えるかを確認します。

自分のIPと一致していれば、NATは存在しません。

NATが存在しなければ、NAT越えの必要なくパケットを送ることが出来ます。

存在する場合は、NATが一つ以上存在し、一番外側のNATの情報が取得できます。

STUNでアドレスとポートのマッピングを取得します。

このマッピング情報をもとにピア同士で接続するのがSTUNです。

TURN is 何?

Traversal Using Relays around NAT の略。プロトコルのひとつ。

TURNはSTUNの拡張プロトコル。ICEがホールパンチに失敗した場合、メディアリレーを行う。

ブラウザに実装されているTURNクライアントと、NATの外にあるTURNサーバと

接続先のピアがTURNサーバを経由し、メディア情報を交換している。

STUNとの違いはSTUNはピア同士で接続するのに対し、

TURNはピアとピアの間にTURNサーバが存在し、

TURNサーバ経由で接続する点が異なります。

ICEとSTUNとTURNの関係

同じNAT超えをしているし最初どういう関係かわかりませんでしたが、

iwashiさんからTwitterでリプライいただけたので書いておきます。

各プロトコルは独立している。TURNはSTUNの拡張プロトコル。

ICEはICE自身でのアドレスとポートのマッピングを行い、

さらにTURNとSTUNも利用するプロトコルです。

まとまれ

これらのプロトコルを用いて、ピア同士で接続できれば晴れてリアルタイムコミュニケーションが楽しめます。

Twilioではこの辺り難しいところを何も考えずに使える点が良いですね。

音声通話はもちろん、最近ではビデオチャット機能も充実してきているとのことなので、

手っ取り早くWebRTCに触れてみたい方はTwilioをさわってみてはどうでしょう。

https://twilio.kddi-web.com/

どういう構成だとSTUNでつなぐことが出来て、

TURNが必要になるのはどういう構成なのかなど今度調べてみます。