2月5日、6日にかけて「WebRTC」をテーマとした、日本初のカンファレンスであるWebRTC Conference Japanで開催された。本記事では、その中の基調講演の1つである、WebRTCに於けるサーバーソリューションの決め手とは？の内容について紹介する。プレゼンターはDialogic社およびwebrtcH4cKSの主宰であるChad氏だ。
The picture of Chad Hart
当日の発表資料はこちらから
WebRTCサーバで考えるべきこと
WebRTCのサーバサイドインフラストラクチャを考えるに辺り、4つのサーバについて本セッションでは述べる。
- シグナリングサーバ
- NAT越えサーバ
- メディアサーバ(音声・映像・データ)
- ゲートウェイサーバ
シグナリングサーバ
WebRTCの通信は、最終的にはP2Pになるが、その過程でシグナリングサーバが必要だ。具体的にはSIPで使われているようなSDPを使って、メディア接続に必要な情報をやりとりする。
もちろん、単にそれだけではなくて以下のような機能も必要となる。
signaling consideration
- ユーザ認証
- アクセスコントロール、セキュリティ
- プッシュ通知 (特にバッテリ消費に注意)
- フェデレーション（他のサービスプロバイダとの相互接続）
- その他、現実社会で必要とされる機能
これらの機能は、WebRTC標準のスコープからは外れているが、アプリケーション開発においては必要となる機能だ。
NAT越えサーバ
次にNAT越えの機能だ。もし、NATが越えられなかった場合、ユーザにNWを変えてみて、とはサービス開発者がお願いすることは難しい。そこで、NAT越えの機能を提供する必要がある。
（編集部補足：NATの解説については当メディアの記事である壁を越えろ！WebRTCでNAT/Firewallを越えて通信しようが参考になります）
NAT越えに対して、レガシーなVoIPシステムでは、SBC(Session Border Controller)を利用している。 WebRTCは、異なったアプローチをとっており、そのプロトコルがICE(Interactive Connectivity Establishment)プロトコルだ。
ICEでは、STUNとTURNを利用している。
STUN
STUNの役割は、自身の外部のIP(NATの外側)を調べるためのプロトコルだ。そのため、非常にシンプルで軽量で、拡張性もある。
TURN
前述したSTUNだけでは越えられない課題もある。その場合、TURN(Traversal Using Relay NAT)を利用して、 トラフィックの中継をする。TURNはSBCに似た動作をする。実社会では環境にもよるが、10-15%程度がTURNを必要としている。
comparing STUN vs TURN
STUNと違って、TURNは帯域消費が大きく、運用コストも大きい。もし、エンジニアリング（設計等）が不適切だった場合は、レイテンシの増加、音声映像品質を損なうことがある。
メディアサーバ(音声・映像・データ)
次はメディアの話だ。さきほど見たように、TURNを経由する場合等、メディアはP2Pで流れないケースもある。
実際には、TURNでメディアを中継する以外に、メディア中継サーバを理由はたくさんある。
Many reasons for media server
- MCUを使ったマルチパーティ会議
- トランスコーディング(コーデックを変換すること)
- 既存VoIPとの相互接続
- メディアの録音、録画
- ストリーム処理（例えば、画像をビデオに挿入したり、DTMF音を音声に挿入したりする処理）
- 人とシステムとで通信する場合（例えば、音声認識による自動応答等）
クライアントで処理すべき？サーバで処理すべき？
前述した機能はクライアントサイドでも提供できるし、サーバサイドでも提供できる。それらにはトレードオフの関係がある。
例えば、モバイルデバイスの帯域は常に使えるわけじゃないし、無料でもない。また、特にCPUを消費すると、バッテリ消費も著しい。もし、機能をクラウド側（サーバ側）で提供できるのであれば、これらの課題は、解決/軽減できる。
マルチパーティのビデオ会議例
具体的にマルチパーティのビデオ会議を提供する場合を例にとって考えてみよう。
フルメッシュトポロジのアプローチ
マルチパーティの会議を提供するにあたり、最も簡単なトポロジはフルメッシュの構成だ。
Full Mesh
この場合サーバは不要になるのがメリットだが、クライアント側の処理能力の制限もあり、3-4人が限界になることが多い。もし、エンドポイントが増えた場合は、非効率になる。
スター型:MCUをつかったアプローチ
この課題に対する伝統的なアプローチがMCU(Multipoint Control Unit)だ。MCUはメディアを集約し、ミキシングし、各デバイスに流す。かなり、クライアントの処理負荷が軽いのがメリットだ。
ただし、MCUにも欠点がある。MCUはサーバの処理負荷が非常に高いことだ。特にHD品質のビデオを扱う場合は顕著になる。処理負荷が高い理由は、すべてのストリームをそれぞれ、エンコード・デコード処理する点にある。
MCUを改良した効率良いアプローチを、エンコーダシェアリングを呼んでいる。
MCU Resource Share
もし、複数のデバイスが同じストリームを受信するなら、MCU側のエンコード処理は1回で済む。この方式だと、CPUの利用率を30-50%ほど効率化できる。
スター型：SFUを使ったアプローチ
さらに新しいアプローチがSFU(Selective Forwarding Unit)だ。このアーキテクチャでは、まずクライアントは1つのストリームをSFUに送信する。SFUはエンドポイントが希望するストリームのみをリダイレクトする。
SFUの主なタスクは、ストリームの暗号化・復号化であり、サーバサイドでのエンコード・デコードは必要とされてない。そのため、多くのクライアントを捌くこと可能だ。
SFUにSimulcastの手法を組み合わせた方法もある。 この手法では、クライアントが1つのストリームを送るのではなく、 2つ以上のストリームを送信する。（よくあるのは高品質・低品質の両方を送る)
SFU
効果的な使い方としては、話し手のストリームは高品質の映像を流して、聞き手のストリームは低品質のものを使う方法だ。
実際に、Google Hangoutsでは、この技術を利用している。非常に興味深いのは、Googleは独自の実装を使って、これを実現している点だ。詳しくは、webrtcH4cKSを参照されたい。
VP9,SVC：未来のアプローチ
最後にScalable Vicdeo Coding(SVC)というアプローチも紹介する。
SVC
Simulcastと同様に、品質の異なる複数のメディアをクライアントが送り、SFUがリダイレクトする点は似ているが、SVCでは複数のストリームを1つのストリームにまとめて、レイヤー化している点が異なる。
ゲートウェイサーバ
最後のトピックはゲートウェイサーバだ。WebRTCゲートウェイサーバを提供するには、多くのコンポーネントが必要になる。
Gateway Function
- STUN/TURN : 前述した機能
- HTTP-to-SIP(H2S)：SIPとHTTPを変換する
- Mediaゲートウェイ：DTLSによる暗号化をSDESへ変換、ポート多重化技術等の対応
- トランスコード：VP8とOPUSを、既存のVoIPシステムのものへ変換
- SBC：既存のSIPと連携する場合に、SIPヘッダ修正等が必要
- APIゲートウェイ：システム制御のためのAPI
- SDK：WebやNativeに、WebRTCを追加するための開発キット
ここで重要なのは、上記の要素を提供するにあたり、標準化されているものはない、ということだ。そのため、規模やベンダ、また既に存在している機器を考慮して、必要なソリューションを自身で決める必要がある。
まとめ
現実世界でのデプロイ例
ここまで、いくつかのサーバについて紹介してきた。それらを実現している現実のアーキテクチャ例(とあるアメリカのサービスプロバイダの例)を紹介する。
WebRTC Arhcitedture Example
いくつかのキーとなる機能をピックアップする：
- STUN/TURNの利用
- Secure WebSocket(WSS)によるシグナリング
- GateWayでのH2S実装
- Webメディアゲートウェイでのトランスコード
- REST API経由による通信
- OAuth、OpenIDによる認証
- APIマネージャによるNWの防衛
サーバ技術のまとめ
本セッションでは、シグナリングサーバ、STUNサーバ、TURNサーバ、メディアサーバ、WebRTCゲートウェイサーバについて紹介した。
Summary
実際には、その他にWebサーバや、認証サーバが登場するが、これらは既にデプロイされているものだろう。組み合わせるとかなり複雑に見えるかもしれないが、一部のサーバはVoIP機器の進化系にすぎない。
