岩瀬 義昌

WebRTCにおけるサーバーソリューションの決め手とは?─WebRTC Conference Japan基調講演

2月5日、6日にかけて「WebRTC」をテーマとした、日本初のカンファレンスであるWebRTC Conference Japanで開催された。本記事では、その中の基調講演の1つである、WebRTCに於けるサーバーソリューションの決め手とは?の内容について紹介する。プレゼンターはDialogic社およびwebrtcH4cKSの主宰であるChad氏だ。

 The picture of Chad Hart

The picture of Chad Hart

当日の発表資料はこちらから


WebRTCサーバで考えるべきこと

WebRTCのサーバサイドインフラストラクチャを考えるに辺り、4つのサーバについて本セッションでは述べる。

  • シグナリングサーバ
  • NAT越えサーバ
  • メディアサーバ(音声・映像・データ)
  • ゲートウェイサーバ

シグナリングサーバ

WebRTCの通信は、最終的にはP2Pになるが、その過程でシグナリングサーバが必要だ。具体的にはSIPで使われているようなSDPを使って、メディア接続に必要な情報をやりとりする。

もちろん、単にそれだけではなくて以下のような機能も必要となる。

signaling consideration

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

comparing STUN vs TURN

STUNと違って、TURNは帯域消費が大きく、運用コストも大きい。もし、エンジニアリング(設計等)が不適切だった場合は、レイテンシの増加、音声映像品質を損なうことがある。

メディアサーバ(音声・映像・データ)

次はメディアの話だ。さきほど見たように、TURNを経由する場合等、メディアはP2Pで流れないケースもある。

実際には、TURNでメディアを中継する以外に、メディア中継サーバを理由はたくさんある。

Many reasons for media server

Many reasons for media server

  • MCUを使ったマルチパーティ会議
  • トランスコーディング(コーデックを変換すること)
  • 既存VoIPとの相互接続
  • メディアの録音、録画
  • ストリーム処理(例えば、画像をビデオに挿入したり、DTMF音を音声に挿入したりする処理)
  • 人とシステムとで通信する場合(例えば、音声認識による自動応答等)

クライアントで処理すべき?サーバで処理すべき?

前述した機能はクライアントサイドでも提供できるし、サーバサイドでも提供できる。それらにはトレードオフの関係がある。

例えば、モバイルデバイスの帯域は常に使えるわけじゃないし、無料でもない。また、特にCPUを消費すると、バッテリ消費も著しい。もし、機能をクラウド側(サーバ側)で提供できるのであれば、これらの課題は、解決/軽減できる。

マルチパーティのビデオ会議例

具体的にマルチパーティのビデオ会議を提供する場合を例にとって考えてみよう。

フルメッシュトポロジのアプローチ

マルチパーティの会議を提供するにあたり、最も簡単なトポロジはフルメッシュの構成だ。

Full Mesh

Full Mesh

この場合サーバは不要になるのがメリットだが、クライアント側の処理能力の制限もあり、3-4人が限界になることが多い。もし、エンドポイントが増えた場合は、非効率になる。

スター型:MCUをつかったアプローチ

この課題に対する伝統的なアプローチがMCU(Multipoint Control Unit)だ。MCUはメディアを集約し、ミキシングし、各デバイスに流す。かなり、クライアントの処理負荷が軽いのがメリットだ。

ただし、MCUにも欠点がある。MCUはサーバの処理負荷が非常に高いことだ。特にHD品質のビデオを扱う場合は顕著になる。処理負荷が高い理由は、すべてのストリームをそれぞれ、エンコード・デコード処理する点にある。

MCUを改良した効率良いアプローチを、エンコーダシェアリングを呼んでいる。

MCU Resource Share

MCU Resource Share

もし、複数のデバイスが同じストリームを受信するなら、MCU側のエンコード処理は1回で済む。この方式だと、CPUの利用率を30-50%ほど効率化できる。

スター型:SFUを使ったアプローチ

さらに新しいアプローチがSFU(Selective Forwarding Unit)だ。このアーキテクチャでは、まずクライアントは1つのストリームをSFUに送信する。SFUはエンドポイントが希望するストリームのみをリダイレクトする。

SFUの主なタスクは、ストリームの暗号化・復号化であり、サーバサイドでのエンコード・デコードは必要とされてない。そのため、多くのクライアントを捌くこと可能だ。

SFUにSimulcastの手法を組み合わせた方法もある。 この手法では、クライアントが1つのストリームを送るのではなく、 2つ以上のストリームを送信する。(よくあるのは高品質・低品質の両方を送る)

SFU

SFU

効果的な使い方としては、話し手のストリームは高品質の映像を流して、聞き手のストリームは低品質のものを使う方法だ。

実際に、Google Hangoutsでは、この技術を利用している。非常に興味深いのは、Googleは独自の実装を使って、これを実現している点だ。詳しくは、webrtcH4cKSを参照されたい。

VP9,SVC:未来のアプローチ

最後にScalable Vicdeo Coding(SVC)というアプローチも紹介する。

SVC

SVC

Simulcastと同様に、品質の異なる複数のメディアをクライアントが送り、SFUがリダイレクトする点は似ているが、SVCでは複数のストリームを1つのストリームにまとめて、レイヤー化している点が異なる。

ゲートウェイサーバ

最後のトピックはゲートウェイサーバだ。WebRTCゲートウェイサーバを提供するには、多くのコンポーネントが必要になる。

Gateway Function

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

WebRTC Arhcitedture Example

いくつかのキーとなる機能をピックアップする:

  • STUN/TURNの利用
  • Secure WebSocket(WSS)によるシグナリング
  • GateWayでのH2S実装
  • Webメディアゲートウェイでのトランスコード
  • REST API経由による通信
  • OAuth、OpenIDによる認証
  • APIマネージャによるNWの防衛

サーバ技術のまとめ

本セッションでは、シグナリングサーバ、STUNサーバ、TURNサーバ、メディアサーバ、WebRTCゲートウェイサーバについて紹介した。

Summary

Summary

実際には、その他にWebサーバや、認証サーバが登場するが、これらは既にデプロイされているものだろう。組み合わせるとかなり複雑に見えるかもしれないが、一部のサーバはVoIP機器の進化系にすぎない。

Powered byNTT Communications

tag list

アクセシビリティ イベント エンタープライズ デザイン ハイブリッド パフォーマンス ブラウザ プログラミング マークアップ モバイル 海外 高速化 Angular2 AngularJS Canvas Chrome Cordova CSS de:code ECMAScript Edge Firefox Google Google I/O Google I/O 2014 HTML5 Conference 2013 html5j IoT JavaScript Microsoft Node.js PhoneGap Polymer SkyWay spdy TypeScript UI UX W3C W3C仕様 Webアプリ Web Components WebGL WebRTC WebSocket