UTALI

書き溜めておいた技術記事や旅行記のバックアップです。

WebRTCの現状 - STUN/TURN・シグナリングサーバーについて - (8/8)

STUN

NATはプライベートネットワークで利用されるIPアドレスを管理する機能の総称である。しかしここで使用されるアドレスは外部からは利用できない。

グローバルIPアドレスなしでは、WebRTCのピアと通信を行うことができない。この問題を回避するためにWebRTCではSTUNを利用する。

STUNサーバーはWAN上で1つのシンプルな仕事を行う。それはリクエスト元(NATの背後にあるアプリケーション)のIPアドレスとポートをチェックしてその情報をレスポンスとして返すことだ。

言い換えれば、STUNサーバーを利用するアプリケーションはWAN上から見た時の自分のIPアドレスとポートを知ることができる。

このプロセスはWebRTCのピアの公開ネットワーク上でアクセスできる自身のアドレスを取得することを可能にして、それを別のピアにシグナリングを使って通知して、直接的な通信の準備(実際はNATの規格別に異なる挙動を示すが、原理は同じだ)をする。

STUNサーバーはあまり多くの仕事をするわけでも多くの情報を保存するわけでもない。だから比較的低スペックのサーバーでも多くの数のリクエストをさばくことができる。

ほとんどのWebRTCの通信はSTUNのみで接続することができる。その割合は webrtcstats.comによれば概ね86%だ。

とはいえ複雑なNATとファイアーウォールの背後のPeer同士ではその割合は低くなるだろう。

f:id:mochizuki_p:20160908114227p:plain

TURN

RTCPeerConnectionはUDPを使用した直接的な通信を確立することを試みる。もしこれが失敗したらRTCPeerConnectionはTCPでの通信を試みるだろう。そしてこれも失敗したら、TURNサーバーの出番になる。これはエンドポイント間の通信を中継する。

注:TURNはピア間での音声・映像・データのストリーミングを仲介するために使われる。シグナリングではない!

TURNサーバーはグローバルIPを割り当てられている必要がある。これはプロキシやファイアウォールの背後にあるピア間で通信できるためだ。TURNサーバーは概念的には単純な仕事しかしない。

つまり、データーを中継することだ。しかし、STUNサーバーと異なり、多くの帯域を占有する。このためTURNサーバーは高性能である必要がある。

f:id:mochizuki_p:20160908114231p:plain

この図はSTUNが失敗した場合のTURNサーバーの役割をあらわしている。両方のピアがTURNサーバーを介して情報をやり取りする。

STUN・TURNサーバーをデプロイする。

apprtc.appspot.comで利用しているように、試しにGoogleが公開しているパブリックSTUNサーバー(stun.l.google.com:19302 )を使用してみよう。

もし商用でSTUN/TURNサーバーを利用する場合は、 rfc5766-turn-serverを利用することをおすすめする。

これはサーバー設定の親切なガイドもついているので、AWSなどでの利用も簡単だ。

別のTURNサーバーとしてresoundがある。これもAWSで利用可能だ、Google Compute Engineでの利用手順を大まかに説明しよう。

  1. ファイアーウォールを設定を変更するポート443番と3478番を解放する

  2. 4つのインスタンスを設定するそれぞれにグローバルIPを割り当てる

  3. ローカルのファイアウォールを設定を行う(あらゆるANYからのANYを許可する)

  4. ツールをインストールするbash sudo apt-get install make sudo apt-get install gcc

  5. creytiv.com/re.htmlからlibreをインストールする

  6. creytiv.com/restund.htmlからrestundを取得して展開する。

  7. wget hancke.name/restund-auth.patch を実行して-p1 < restund-auth.patchでパッチを適用する。

  8. libreとrestundでmakeを起動する。

  9. restund.confを設定する(IPアドレスを置き換えて共通の暗証番号を設定する)そして/etcにコピーする

  10. restund/etc/resturnを/etc/init.dにコピーする

  11. restundの設定をして、LD_LIBRARY_PATHをセットする。そしてrestund.conf を /etc/restund.confへコピーする

right 10のipアドレスを使用するようにresound.confを設定する

  1. restundを起動する

  2. リモートのクライアントでstundが動作するか確認する。

1対1を超えて、複数間でのWebRTC

Justin Ubertが提案したREST API for access to TURN Services IETF基準を見てみるといいかもしれない。

単なる1対1のメディア配信を超えて、たとえば3人以上の同僚でのビデオ会議、あるいは何百人の視聴者にライブ映像を届けるようなケースを想像してみよう。

WebRTCはこのような複数人に対してのRTCPeerConnectionを利用して網の目のようにエンドポイント間のネットワークを構築することもできる。

この手法はtalky.ioのようなアプリで採用されている。

そしてあまり大きくないネットワークであれば完璧に動作する。しかしそれ以上になると、特にモバイル環境では、処理性能と帯域を圧迫して難しくなる。

f:id:mochizuki_p:20160908114220p:plain

その代わり、WebRTCは一つのエンドポイントに対して別の複数のエンドポイントにデータを配信するようにすることができる。

これはWebRTCのエンドポイントをサーバとして動かすことができ、再送信させるメカニズムを構築することになる。

このサンプルはwebrtc.orgによってsample client applicationとして提供されている。

Chrome31とOpera18から、1つのRTCPeerConnectionからのMediaStream を別のクライアントに送信できるようになった。

これによってより柔軟性のある構造が実現できる。なぜならWebアプリがどのピアと接続するか選択できるようになったからだ。

複数のコントロールユニット

多くのエンドポイントに対してはMCU Multipoint Control Unit を使うことが得策だ。これは複数のクライアントに対してメディアを配信するブリッジとして機能するサーバーである。

MCUはビデオ会議における複数のコーデック、フレームレートを扱うことができ、ストリーミングの再配信や音声や動画のリミックスをすることもできる。マルチパーティの通信では、考慮すべき問題がある。

特にどのように複数のビデオ入力を表示して、音声を合成するかということだ。vLineのようなクラウドサービスではこの最適化を扱うことができる。 これはMCUのハードを購入することで可能であるし、自分で自作することもできる

f:id:mochizuki_p:20160908105623j:plain

オープンソースのMCUも利用可能だ。たとえばLicode(以前はLynckiaという名前)はWebRTC用のMCUで、OpenTokにはMantisがある。

ブラウザを超えて:VoIP、電話、メッセージング

WebRTCの規格によってWebRTCのアプリはいろいろなデバイスの間、つまり、ブラウザやほかの通信機器、たとえば電話やビデオ会議システムで利用することができる。

SIPはVoIPやビデオ会議システムで使用されるシグナリングの規格だ。WebRTCのクライアントとSIPクライアントで通信するためには、WebRTCはシグナリングを仲介するプロキシサーバーが必要となる。

シグナリングはゲートウェイを経由する必要があるけど、一度通信が確立すればSRTPのトラフィック(音声でも動画でも)はピアツーピアで直接やりとりできる。

PSTN(Public Switched Telephone Network)はアナログ回路で動作する古い電話システムだ。

WebRTCと昔ながらの電話と通話をするためにはPSTNゲートウェイを通過する必要がある。同様に、WebRTCのWebアプリがIMクライアントのようなJingleエンドポイントと通信する場合はは仲介役となるXMPPサーバーが必要だ。JingleはGoogleによってXMPPの拡張として開発され、音声や動画をやり取りすることができる。

現在のWebRTC実装は、GoogleがGoogle Talkとして開発したC++のlibjingleライブラリを元にしている。

いくつかのアプリやライブラリ、プラットフォームはWebRTCと通信できるようなAPIを用意している。

  • sipML5 オープンソースのJavaScriptで実装されたSIPクライアント

  • jsSIP JavaScriptのSIPライブラリ

  • Phono オープンソースのJavaScriptの電話APIで、プラグインとして構築された。

  • Zingaya 埋め込み可能なphone widget

  • Twilio 音声とメッセージング

  • Uberconference 会議用

sipML5 の開発者はwebrtc2sipゲートウェイも開発している。TethrとTropoはa framework for disaster communicationsで簡潔にデモンストレーションを行った。OpenBTS cellでフィーチャーフォンとWebRTCでの通話をキャリアなしで行った。

さらに知りたい人には

WebRTC codelab: step-by-step instructions how to build a video and text chat application, using a Socket.io signaling service running on Node.

2013 Google I/O WebRTC presentation with WebRTC tech lead, Justin Uberti.

Chris Wilson’s SFHTML5 presentation: Introduction to WebRTC Apps.

The WebRTC Book gives a lot of detail about data and signaling pathways, and includes a number of detailed network topology diagrams.

WebRTC and Signaling: What Two Years Has Taught Us: TokBox blog post about why leaving signaling out of the spec was a good idea.

Ben Strong’s presentation A Practical Guide to Building WebRTC Appsprovides a lot of information about WebRTC topologies and infrastructure.

The WebRTC chapter in Ilya Grigorik’s High Performance Browser Networkinggoes deep into WebRTC architecture, use cases and performance.

この文章はHTML5 ROCKS から 翻訳・転載したものです。