UTALI

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

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

Peer を見つけ出す

これは思いつきの言い回し - どうやって通話する相手を見つければいいのだろうか?

電話だったら電話番号と電話帳がある。オンラインビデオチャットだったら、アカウントとその管理法、そしてセッションを開始する方法が必要だ。

WebRTCはクライアントに通知を送って通話に参加してもらう必要がある。 Peerを見つけ出すメカニズムはWebRTCそれ自体には実装されていない。そしてここではその選択肢には立ちいらないことにしよう。

そのプロセスはemailやカスタムリンクを共有することで通話ができるtalky.io, tawk.comまたはbrowsermeeting.comのようなビデオチャットアプリと同じくらい単純なものだ。

開発者のChris Ballは興味深い、サーバーを使用しないWebRTCの実験をした。その内容はピア間でe-mailや伝書鳩のような伝達手段を使ってメタデータを交換するものだ。

どのようにシグナリングサービスを構築するのか?

もう一度言おう、シグナリングのプロトコルとメカニズムはWebRTCの規格には含まれていない。

何を選ぼうとあなたは中継サーバーが必要で、それはシグナリングのメッセージとクライアント同士のアプリケーションデータを交換する。

残念なことにWebアプリは単純にインターネットに「僕の友達と繋いでくれ!」と叫ぶだけでは不十分だ。

ありがたいことに、シグナリングのメッセージは短いし、大半の手続きは通話の最初に行えばよい。

apprtc.appspot.comやsamdutton-nodertc.jit.su で試してみよう。

この場合、ビデオチャットのセッションを通して大体30から45のメッセージがシグナリングの過程で交換された。すべてのメッセージの容量は10KBほどだった。

帯域の観点からみると望ましいことだけど、WebRTCのシグナリングはあまり多くの処理を行わない、ただメッセージを中継して小さなセッション情報(どのクライアントが接続しているかなど)を保持するだけだ。

メッセージをサーバーからクライアントに送信する

シグナリングのメッセージサービスは双方向的である必要がある。つまりクライアントからサーバー、サーバーからクライアントへと。

この双方向の通信モデルはHTTPのクライアント・サーバー、リクエスト・レスポンスモデルと対照的だ。

しかし、ブラウザで動作するWebアプリにサーバーからデータをプッシュするために長年の間にlong pollingのような様々な工夫が考案されてきた。

もっと最近の話をすれば、 EventSource APIは幅広く実装されてきた。これはサーバーから送信されたイベントをHTTPを仲介してブラウザに通知する。

ここにその簡単なデモアプリを用意した。 simpl.info/es.

EventSourceは一方通行のメッセージングのために設計された。しかし、これはXHRと組み合わせてシグナリングメッセージを交換するサービスに利用することができるかもしれない。

つまり電話をかける側のメッセージをXHRで通知して、それをEventSourceで電話を受ける側にプッシュする。

完全な2重のクライアント・サーバー間通信(メッセージが同時に2方向に流れていく)のために設計されたWebSocketはより自然な解決法だ。シグナリングをWebSocketのみで、あるいはEventSourceを利用して設計する利点はこの種のAPIがたとえばPHPやRuby、Pythonのような大半のホスティングパッケージに普通に実装されていることだ。

概ね4分の3のブラウザがWebSocketをサポートしている。さらに重要なことは、WebRTCを実装しているブラウザは、デスクトップでもモバイルでも、すべてWebSocketを使うことができる。

TLSは、プロキシ透過問題(詳しい情報はHigh Performance Browser NetworkingのWebSocket and proxy traversal see the WebRTC chapter を見て欲しい)と暗号化されていないメッセージを遮断されないために利用すべきである。

4/8