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機器の進化系にすぎない。