2月5日、6日にかけて「WebRTC」をテーマとした、日本初のカンファレンスであるWebRTC Conference Japanが開催されました。
本記事ではその中でも「エンタープライズ環境におけるWebRTC活用のポイント」というセッションの内容について紹介します。プレゼンターは日本ヒューレット・パッカード株式会社 通信メディアソリューションズ統括本部 スペシャリストの寄高啓明氏。今回は寄高氏の講演再現レポートでお届けします。

　▲日本ヒューレット・パッカード株式会社 通信メディアソリューションズ統括本部 寄高 啓明氏

WebRTCの特徴

日本HPの寄高（よりたか）と申します。HPといえばPCやプリンター、サーバのイメージをお持ちの方も多いと思いますが、そればかりではありません。弊社はいわゆるソリューション製品やSIなどの業務も行っておりまして、私は通信やテレコム向けのシステムを構築する仕事に従事しております。

なので、どうしても私もテレコムや通信事業者の見方が強くなってしまいがちかもしれませんが、どうかご容赦ください。まず最初に、ここにいらっしゃる方々には釈迦に説法になってしまうかもしれませんが、WebRTCの技術的な特徴をおさらいしたいと思います。

WebRTCは、ブラウザ上でリアルタイムコミュニケーションを実現できるものです。これは、私のようにテレコムの世界で生きてきた人間にとってはものすごく画期的なことです。

何が一番画期的かというと、開発者のベースが大きく広がるというところです。
テレコムの業界というのは、いわゆるインターネット世代の方々は聞いたことのないようなプロトコルを使って、1ビットでもミスがあると通信できないといった世界で生きています。そういう世界で生きている技術者というのは、もうかなり少なくなってしまっている。
一方Web技術者はその10倍、100倍という開発者人口があります。そうした方々の力を借りて、リアルタイムコミュニケーションの可能性を広げていくことができます。

2点目はデバイスフリーです。
ブラウザはスマホ、PC、タブレットと言ったデバイスには既に搭載されていますが、最近ではゲーム機やカーエレクトロニクスなどの分野にも積まれています。将来的にはウェアラブルデバイスや家電など、何にでもWebブラウザは載ってくる。そうしてWebブラウザの利用範囲が広がっていくことで、リアルタイムコミュニケーションの間口も広がっていく。

また、アプリのインストールがが不要であるという点も非常に重要です。
我々開発者とは異なり、一般のユーザにとっては「インストール」という行動は、実は大きなハードルを伴います。私自身もそうですが、友人などの間で評判が良くて安全なアプリしか基本的にはインストールしません。ですが、Webアプリはブラウザさえあれば動作しますので、URLに移動するだけでユーザが使いはじめることができる。導線が非常にスムーズなわけです。

4点目は、Webサービスを作る際に、どういう設計を行うかです。
WebRTCはやはりブラウザ同士のP2Pという文脈で語られることが非常に多いですが、サービスを作る側からすると、何らかのサーバを置くという可能性はどうしても捨てられないところがあります。サービスのユーザが取っている行動を知るためには、サーバ上でログを残したいですし、サーバ上で何らかの付加価値を付けるということもできます。どちらの設計が今後主流になっていくのかはわかりませんが、個人的にも非常に興味のあるところです。

WebRTCのユースケース

今回は「エンタープライズ環境におけるWebRTC活用のポイント」というセッションですので、WebRTCが有効に使えるであろうユースケースについて考えてきました。

ここでは、今現在実現されているユースケースだけではなく、今後可能になるであろうユースケースも考えてまいりましたので、そちらご紹介したいと思います。

まず思いつくのはコールセンターですね。コールセンターというのは、電話とコンピュータが連動する非常に複雑なシステムですが、こちらはWebRTCと非常に親和性がいい。海外ではすでに商用の導入事例が存在します。

ユニファイド・コミュニケーションの分野では、例えばマイクロソフトさんもLinqやSkypeをWebRTCで再実装するなんて噂もありますし、様々な既存のリアルタイムコミュニケーションを統合できる可能性があります。

ビデオやWeb会議の分野で使えるかもしれない、というのはもはや言わずもがなですね。

遠隔教育やヘルスケアの分野など、リモートで人をつなぐ必要性がある部分についても、利用されるのは間違いありません。

このように、よくWebRTCのユースケースとして挙げられるのは、「コミュニケーションというところを軸にして、その入口をブラウザにしましょう」という話かと思います。これらはもちろん実現が望まれるサービスではあるのですが、もう少し違ったユースケースも、WebRTCなら実現できるのではないかと思い、いろいろ考えてきました。

1つ目は「BYOD的活用」と書かせていただいていますが、こちらは具体的にはVDI（Virtual Desktop Infrastructure）だとか、DaaS（Desktop as a Service）といったクラウド側のサービスですね。
こうしたサービスはすでにいろいろな事業者さんが提供されていたりしますが、現状は、リモートデスクトップを表示する端末側も（会社内の）Windowsデスクトップであることが多い。

これは管理のコストを下げたり、セキュリティを向上させるという点では有効ではあると思うのですが、例えば生産性を向上させるとか、ワークライフバランスを改善するとか、そういうところにつながるものではない。ここにWebRTCというスパイスを加えると、ガラッと仕事のやり方を変えられるんじゃないかな、と思っています。

スライドの右側にあるのがDesktop as a Service、つまりクラウドですね。そしてクライアント側のデバイスは、WebRTCでつなぐことで、タブレットでも自宅のPCでも何でもよくなるわけです。これが実現できれば、自宅でも出先でも仕事できる、というユーザーメリットがあります。

BYODは、実際にはあんまりはやっていないんですよね。端末の管理がどうしても問題になってしまう。例えばMDM (Mobile Device Management)だとかMAM (Mobile Application Management)だとか、MCM (Mobile Contents Management)だとか、「MナントカM」でAからZまで全部作れるんじゃないかという。

それはそれで商売になるからいい、という話もあるんですが、こうした管理は企業側にとっても負担になりますし、社員側も自分個人の端末に「MナントカM」のアプリをあまり入れたくはないですよね。

そういう抵抗があって流行らないんじゃないかな、と。この状況はWebRTCなら、アプリのインストールもいらないし、端末側に何も残らないので、打開できるんじゃないかと考えています。

次は、遠隔業務支援です。WebRTCを使っているわけではないですが、近いことをやっているサービスはすでにあります。例えば事故現場を、遠隔地にいる医者や新聞社とリアルタイムに共有する…なんてことは行われている。

私はさらに、（WebRTCによってリアルタイムコミュニケーションの敷居が下がるので）一工夫加えられるんじゃないかと考えています。例えば事務処理なんかも、リアルタイムに現場と映像を見ながらやりとりできるんじゃないでしょうか。

続いて、このユースケースはちょっとこわいんですが、デスクトップの監視とかにも使えるだろうな、と。具体的なユースケースとしては、私の友人がSkypeでオンライン英会話を行えるサービスを使っているらしいのですが、講師の中にはバスローブやネグリジェを着て現れる先生がいたり、裏で友達とチャットをしていたりゲームをしていたり、講師側のガバナンスが効いていないそうなんですね。これを、デスクトップの映像をサーバ側に保存することによって、監査の目が行き届くようにするといった具合です。

で、こうしたユースケースをいろいろ考えていくと、弊社では「まずは作ってみよう」という話になるわけです。実装してみた上でWebRTCに期待することや、現状の課題なんかも見えてきました。最後に、それらを情報共有させていただければと思います。

WebRTCの期待と課題

まずはWebRTCに期待することからですね。

1つ目は、このセッションの最初の方でも申し上げましたが、デバイスフリー時代の幕開けです。どんなデバイス上でも、同様にリアルタイムコミュニケーションが行える時代がやってくる。

2つ目は、リアルタイムコミュニケーション技術-いわゆるVoIPなどのテレコムの技術が開放されます。これも開発生産性の向上などでメリットが大きいですね。

3つ目は、企業システムとの親和性です。Webのシステムは、企業のシステムと非常に親和性が高い。例えばERPやCRMと言ったシステムとの連携は非常にやりやすい。

そして最後に、一番個人的に期待しているのは、アドホックな利用です。スマホのアプリを使い捨てるというのはなかなか考えにくいですが、Webアプリならそれが可能です。WebブラウザでURLでアクセスするだけという軽いユースケース、これが今後広まっていくんじゃないかなと考えています。

一方で、実際に作ってみるといろいろ課題もありました。

1つ目がバッテリー消費。スマホだと顕著ですね。ビデオ通話などをしていると、あっという間に電池が減っていきます。

2つ目がブラウザの対応です。Chromeなんかですと、定期的にバージョンアップされてしまいますので、「いつの間にか動かなくなった」ということもよく起こります。

次がネットワークの帯域制御です。私自身がテレコムから来ている人間ですので、QoSですとか、みんなが使うサービスとしては大丈夫なのかな、というところが気になっています。

あとは着信の問題です。現時点では、着信を可能にするためには、ずっとWebブラウザを立ち上げておく必要が生じてしまう。ここは知恵の絞りどころですね。

最後にセキュリティです。これは永遠の課題ですので、今後も専門家を交えて検討が進むんだろうなと考えています。

弊社でもWebRTC Platformというものを考えております。その図を示して、本セッションを終わりにしたいと思います。ありがとうございました。

本記事では、WebRTC Conference Japanのセッションの1つである、「WebRTC DataChannelの活用方法とその可能性」について紹介する。講演者は、Mist Technologies株式会社CEO・田中晋太朗氏だ。

Mist Technologies株式会社　 田中晋太朗氏

セッション内容は、大きく以下の2点である。

• WebRTC DataChannelのおさらい
• ひねりのある使い方事例紹介

以下でそれぞれの内容について紹介する。（発表資料全体はこちらから）

WebRTC DataChannelのおさらい

概要

DataChannelは、サーバを介さずにテキストやバイナリデータを送ることができる。特にバイナリデータが重要で、ArrayBuffer、ArrayBufferView、Blob、Stringを送信可能だ。

DataChannel概要

注意点として、CreateOfferでSDPを作成する前に、createDataChannelしておく必要がある。なぜなら、相手との通信に必要なSDPが作成できないためだ。

プロトコルスタック

DataChannelを支えるプロトコルとしてSCTPがある。SCTPは、簡単に言ってしまえば、TCPとUDPの良いとこどりのプロトコルで、createDataChannelの引数にオプションを設定することにより、動作を変更できる。

ひねりのある使い方

事例1:DHT webrtc-chord

P2P技術が好きな方はご存知かもしれないが、DHT(分散ハッシュテーブル)のアルゴリズムの1つであるchordのWebRTC実装が、webrtc-chordだ。chordは、分散型のKVSに似ており、様々なノードが、バランスよくデータを保持できる。

webrtc-chord

DataChannelはこの中で、データの挿入・検索を実現するために利用されている。特に面白いのは、コントロールプレーン（実際のデータではなく、それを制御する通信のこと）をWebRTCのデータチャネルに担わせている点だ。

WebRTC Chordを利用すると、サーバでデータを持つ必要がなくなり、Pure P2Pに近づく。

事例2:ファイル共有 WebDrop

Mist Technologies社で、ウォーミングアップとして作ったサービスだ。ファイル共有をする際に、クラウドストレージにアップロードしたくないが、メール添付の容量を越えてしまう場合に、役立つ。

WebDrop

実装としては、JavaScriptからFileAPIを利用し、データを送る際に必要なメタ情報を、BinaryPackでArrayBufferへシリアライズして送っている。

Sharefestや、ShareDropが類似サービスだ。

データ送受信の注意点

ブラウザによって実装の違いが大きい点に注意する必要がある。例えば、ChromeやOperaでデータを送る場合は、バイナリの長さに制限がある。制限の長さを越えてしまうと、DataChannelがクローズされてしまう。

データ送受信の注意点1

一方でFirefoxは良く出来ていて、どれだけの長さを送信しても、不都合は生じない。ただし、受信時のonmessageでのバイナリの扱いが特徴的で、Firefoxではblobで取り出せるようになっている。そのため、他のブラウザと処理を合わせるためには、Blobで出てきた場合は、ArrayBufferで処理するように実装する。

Chrome等でバイナリの長さ上限を回避するには、2つの方法がある。

• UDPデータグラムの長さの制限 : あるサイズでデータを輪切り(Chunk)にする
• SDPの改変(b=AS:1638400等)により、帯域を変更する

データ送受信の注意点2

データを輪切りにして送信する場合は、送信側はデータをキューにためておいて、よいタイミングでsendを呼び出して送信する。受信側は、分割して送信されてくるので、Chunkを組み立てる必要がある。

事例3: MistCDN

もう1つの応用としてMistCDNを紹介する。

MistCDN1

MistCDN2

MistCDNはP2P型のCDNで、同じサイトを閲覧している近いユーザから、DataChannelでデータを受信する仕組みだ。フロントエンドの実装はTypeScriptを利用している。

どういう利点があるかというと、CDNを使った場合に、ユーザレスポンスの向上が挙げられる。また、CDN自体の利用量（コスト削減）も実現できる。

類似のサービスも色々あるが、動画の配信という点では、MistCDNに優位性がある。

P2P型CDNの要所

既存のCDNは、HTTPの仕様に沿って実現されており、オーバヘッドが少ない。P2P型のCDNを実現しようとすると、シグナリングが必要になり、オーバヘッドが生じる。オーバヘッドが大きい場合は、結局遅くなることもある。

P2Pの要所

そこで、シグナリングのメッセージを減らす、また、小さいコンテンツはまとめて送る、等の工夫が必要になる。

また、データを受信するPeerを選択する場合には、遠いPeerを選ばないように、帯域を利用する等の工夫をしている。（詳細は企業秘密）
ただし、クライアントサイドのコードは、誰でも読めてしまうので、将来的にオープンソース化も視野にいれている。

対応ブラウザの問題もつきまとうので、iOS向けにネイティブライブラリも開発している。

活用方法とその可能性(Discussion)

DHTのWebRTC実装等の事例を紹介してきたが、いくつかを組み合わせると、サーバの仕事を極力減らして、1つのシステムを組めるようになるのでは、と考えている。

今後登場しそうなWebRTC応用

シグナリングはどうしても必要になるが、SkyWay等のPaaSを使えばサーバを持たなくてよい。また、データについてもChordの上に載せてしまえば、これもサーバが不要だ。

Ustreamはメディアをサーバにアップロードして、各ユーザがダウンロードする仕組みになっているが、これをブラウザで実現できないか。まだ現実的にできるかは、わからないが。

最後に、ブラウザをエージェントとして利用すれば、グリッドコンピューティングも実現できるのではないか、と考えている。

2月5日、6日にかけて「WebRTC」をテーマとした、日本初のカンファレンスであるWebRTC Conference Japanで開催されました。 本記事では、その中の基調講演の1つである、「The WebRTC Continuum」の内容について紹介します。プレゼンターはOracleのダグラス・タイト氏です。

▲Oracleの通信マーケティング担当ディレクターであり、通信業界のビジネスと技術のエキスパート　Douglas Tait（ダグラス・タイト）氏

WebRTCの第一の波は終わった。次の波に備えよう

WebRTCが本格的に議論され始めたのは、ここ3年ほどのことです。Oracleも、WebRTCが議論され始めた当初から、通信分野の大手企業と共にWebRTCの進化に尽力し、エンタープライズ分野における可能性を探ってきました。WebRTCの「第一の波」は終わっていると考えてもいいでしょう。2013年から2014年にかけて、WebRTCの導入はかなり進みました。

そして2015年、WebRTCには第二の波が来ます。まずは市場のトレンドから探っていきます。2015年、WebRTCのデプロイは3倍になると予測されています。VoLTE（Voice over LTE: 超高速通信サービス（LTE）による音声通話サービス）は50%以上増加するでしょう。コールセンターは、プロプライエタリなソリューションからWebテクノロジーへと移行します。ユニファイド・コミュニケーションは、中央集権型からWeb上でより分散されたものになっていくと考えられます。

このセッションでは、WebRTCが次に起こすであろう「波」について語ります。波という話題について語るにあたり、以降は私が大好きなサーフィンに例えてお話することをお許し下さい。サーフィンに必要な物は3つ。サーフボードと波、そしてもちろん海です。

このセッションで言えば、サーフボードはWebRTCやWebRTCを利用できるデバイスです。波は、それらのデバイスを相互に接続するコネクション。そして海はネットワークそのものです。これら全ての分野においてたくさんの新規参入があるでしょう。しかし、これははまだ始まりに過ぎないのです。

キャズムを超えろ

ここで、ジェフリー・ムーアのキャズム理論に照らし合わせてみましょう。WebRTCは現在、アーリーアダプターの段階にあります。

この段階には「キャズム」という落とし穴があることをムーアは発見したわけですが、WebRTCも、現在抱える多くの問題を解決しなくては、キャズムから抜け出すことは困難です。

問題は大きく分けて3つあります。

一つはモビリティです。
認証や認可の仕組みを、WebRTCはそれ自体では持っていません。このことは、より多くのユーザ名／パスワードのペアを必要とするようになるかもしれません。また、DoS攻撃に対する対処についても、現在のWebRTCは備えていません。

次に信頼できるネットワークソリューション。
私たちは、携帯電話が世の中に普及していく段階で、携帯ネットワークの信頼性について数多くのことを学びました。通信圏外やローミングなどの知見です。また、ラップトップPCのほうが、携帯電話よりもさらに繋がりにくい状況です。 ブラウザのリロードやネットワークの問題でセッションが失われてしまったり、多くのセッションやコネクションからなる大きなネットワークのサポートが欠如しています。

最後に相互運用性です。
相互運用性というのはとても広い言葉です。例えばネットワーク間の相互運用性、ブラウザやデバイス間の相互運用性、メディアコーデックの相互運用性などの全てを含みます。

特にコーデックは、現在のWebRTCでは2つの動画コーデック（VP8/H.264）、2つの音声コーデック（Opus/G.711)が標準でサポートされる方向に向かっていますが、実際のネットワーク上ではもっと数多くのコーデックが利用されています。

こうしたキャズムを越えようと、様々な企業がチャレンジをしています。アメリカン・エキスプレスは、プレミアム会員向けに、WebRTCを使用したサポートサービスを提供しています。Amazonのメイデイボタンは、助けが必要なときにボタンを押すだけでオペレーターに接続され、オペレーターと共に画面の操作を行うことができます。Vonageは、インターネットを利用した電話サービスですが、固定電話や携帯電話への通話も格安で行うことが可能です。

WebRTCの最も素晴らしい点は、場所やデバイスを選ばないということです。現在はそうした世界になっていないから、電話をして2時間待つようなハメになるのです。コミュニケーションの流れで複雑だったところをシンプルにできる、それがWebRTCの最も大きな利点です。

来年はおそらく、こんなキャズムの話なんてしてないでしょう。なぜなら、来年にはこうしたキャズムは超えているからです。

新たな要件

では、この先WebRTCに必要とされるものは何でしょうか？　先ほどのサーフボードの例えに則り、デバイス、コネクション、ネットワークという3つの視点から見てみましょう。

まずデバイスですが、iOSネイティブや、AndroidネイティブのWebRTCインターフェースが必要とされています。WebRTCが、ノンブラウザの世界でも利用されるようになります。

コネクションにおいては、様々なメディアとのインタラクションをシームレスに統合したい、というニーズが生じています。例えばこの画面は、（この次に基調講演に登壇する）チャド・ハートさんのスライドから拝借したものですが、ブラウザやモバイルデバイス、SIPクライアントなどの様々なデバイスとのインタラクションが一画面に統合されています。また、DataChannelはIoTやM2Mの世界でも使われていくことになるでしょう。

ネットワークにおいては、様々な要件が生じています。例えば認証、RESTやJavaScriptを考慮した標準化されたインターフェース、より高速なNATトラバーサル、あらゆるものの仮想化などです。

WebRTCの発展を阻害するもの、それは、実は…

私はサーフィンが大好きで、子どもたちもよく連れ出します。そこで子どもたちに「サーフィンをする上で、一番怖いものは何？」と聞くと、「サメ」なんて答えが返ってくるのですが、実際にはそうではありません。

サーフィンをしている際に一番危険なのは、別のサーファーなんですよね。これと同じく、WebRTCの普及にとって問題なのは、実は外部の要因ではなくて、実は他の様々なベンダーだったりするのです。

例えばORTC。良いコンセプトなのはわかります。でも待てません！
コーデック。議論したい気持ちはわかりますが、先に進まなければ！
Internet Explorer。マイクロソフトのことを待っているわけにはいきません！
標準化団体。標準はどちらにせよ出てきますし、その中には良いものもあれば悪いものもあるでしょう。

私たちはもう、待っているわけにはいかないのです！

まとめ

では、このセッションのまとめに入りましょう。このセッションでは、WebRTCに来ている波をサーフィンに例え、3つに分けてお話してきました。

現在、WebRTCはキャズムを迎えようとしています。
キャズムを超えるために必要とされるのはモビリティ、信頼性、相互運用性です。

そしてその先に来る波が必要とするのは、モバイルデバイス、接続性、ネットワークです。

こうしてキャズムを超え、WebRTCが普及したそのとき、デバイスにも、場所にも、何にも縛られずにリアルタイムに人々がコミュニケーションする世界が開けてきます。それが私たちに広がる「未来」なのです。

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