TPACとは?

TPACとは、Webの標準化団体であるW3C(World Wide Web Consortium)が開催する1週間のイベントのことです。様々な国、様々な企業からメンバーが集まり、現在のWeb標準・将来的なWebの機能(例えば、cryptoやaudio)について議論します。今回は、札幌開催であり主要なWebRTC仕様策定者が一同に日本に集結しました。

tpac 2015

最大の議論の焦点となったサイマルキャスト

WebRTCのW3C側の仕様は、まだCR(勧告候補)になっていませんが、ORTCの議論に後押しされるかたちで、既に次世代の仕様である、WebRTC-NVの議論がはじまっています。今回のTPACではWebRTC 1.0(WebRTC-NVに対して、年内に切り上げる予定のWebRTCのバージョンを1.0としている)に対して、最終的にどの仕様を盛り込むのか、が1つの争点となりました。その中でも特に議論が盛り上がったのがサイマルキャスト(Simulcast)です。TPACで展開されたサイマルキャストの議論を理解するためには、先にサイマルキャストそのものを理解する必要があります。そこで、以下でサイマルキャストとは何か、なぜ必要なのか、を簡単に説明したのち、TPACの議論を紹介します。

サイマルキャストとは？

放送業界の用語として、サイマルキャストという用語をお聞きになった方もいるかもしれませんが、WebRTCの文脈で用いられるサイマルキャストは意味合いが異なります。WebRTCで利用するサイマルキャストを一言で表現すると、「送受信側が1つの動画を、異なる品質でエンコードしたストリームを送受信すること」となります。少しわかりにくいので、以下でさらに具体的な例を利用して説明します。

サイマルキャストがなぜ必要なのか？

WebRTCの弱点として挙げられる点として、「多人数会議の実現」があります。P2P通信のみで多人数会議を実現すると、ネットワークトポロジはフルメッシュ形式となり、端末の能力・帯域に限界が来てしまい、接続数がスケールしません。それを解決するための案として、何らかのサーバを利用するスター型トポロジを利用する案があります。サーバには大きく分けて、サーバ側で音声映像を結合するMCU、音声映像を結合せずに分配するSFUがあります。（MCU/SFUの詳細は、過去記事のWebRTCにおけるサーバーソリューションの決め手とは？を参照ください）

SFUを利用した場合、受信側デバイスの処理能力・帯域が豊富にあれば良いのですが、モバイル端末の場合は常に得られるとは限りません。そこで、登場するのがサイマルキャストという概念です。

simulcast

サイマルキャストでは、上図のように送信側が複数の音声・映像ストリームを受信側に送ります。複数のストリームとは例えば、高解像度の映像と低解像度の映像といったストリームを示します。複数ストリームを受け取ったSFUは、受信側の能力に応じて、適切なストリームを分配します。処理能力・帯域に余裕のある受信側クライアントは、高品質のストリームを受信し、余裕のない受信側クライアントは、低品質のストリームを受けとります。その結果、受信側は自身の能力にあったストリームを受信できることになります。

以上が、サイマルキャストの前提知識となります。以降、TPACの議論内容・要点をまとめます。TPACで議論のベースとして用いられた資料はこちらです。

サイマルキャストを実現するために必要な機能

サイマルキャストを実現するためには、送信側のAPI(JavaScript)でまず、2つ以上のエンコードがあることを明示しなければなりません。具体的なコードサンプルは以下となります：

var sender = pc.addTransceiver({sendEncodings: [
 {rid: “F”},
 {rid: “H”, scaleResolutionDownBy: 2},
 {rid: “Q”, scaleResolutionDownBy: 4}
]).sender;

// 補足：Transceiverという名前も新規に登場しています。
// 本記事では、詳細に説明いたしませんが、簡単に言えばRTPSenderとRTPReceiverを管理する親のオブジェクトとなります。

sendEncodingsの値として、rid(暫定的な名前なため、ridという名前自体は変わる可能性があります。詳細はridが規定されるRFCを参照ください)を利用して、複数ストリームを設定しています。ridの値である”F”/”H”/”Q”は単なる識別子であり、この値はブラウザが選択するのか、それともJavaScriptで設定するのか、について議論がありましたが、最終的にJavaScript側で設定する方向で議論が進みました。

また、scaleResolutionDownbyの値によって、送信ストリームの品質を分けています。scaleResolutionDownByはconstraints(制約)と設定する一例に過ぎず、ここで設定する値についても議論がありました。具体的にはフレームレート、最大ビットレート等で十分なのでは、といった意見が出ていました。

SDPによるネゴシエーション？

従来のWebRTCでは、送受信側でコーデックなどのパラメータを、SDPを利用したシグナリングによってネゴシエーションします。ridを利用したサイマルキャストについても、自然に考えれば、同様にSDPを利用したシグナリングになります。しかし、1点問題があります。SDPで規定される内容は、W3Cで規定する仕様ではなく、IETFのMMUSIC WGで規定であるため、仕様策定に非常に時間がかかるのです。(MMUSICの仕様策定には、これまでの歴史から時間がかかるケースが多いため)

そこで、TPACでは

• MMUSIC WGで、サイマルキャスト向けの仕様策定が上手くいった場合
• MMUSIC WGで、サイマルキャスト向けの仕様策定が上手くいかなかった場合

の2点を同時に考慮する議論が進みました。具体的な方針は以下の通りです。

MMUSIC WGの仕様策定が上手くいった場合

SDPでsimulcast向けのパラメータを記載します。たとえば、以下のようになります。

// クライアント側のSDP
a=rid:F send
a=rid:H send
a=rid:Q send
a=simulcast rid:F,H,Q

// サーバ側のSDP
a=rid:F recv
a=rid:H recv
a=simulcast rid:F,H

上記でネゴシエーションされたRIDをRTP/RTCPの拡張ヘッダの値として規定して、クライアント(例：ブラウザ)とサーバ間(例：SFU)でメディアを送受信する動作になります。

メディアの送受信方法には、いくつか案があり、TPACより前に議論の候補として挙げられていたのは、RTPのヘッダに載っているPT(Payload Type)の値を利用して、ストリームを識別する案でした。しかし、その案にはペイロード番号を使いきってしまうなどの懸念(この懸念はIETFのAVTEXT WGで説明がされています)があったため、RIDをRTP/RTCPヘッダ拡張として設定する案で議論が進んでいます。

MMUSIC WGの仕様策定が上手くいかなかった場合

SDPに対する変更は加えられないため、別の方法が必要になります。具体的な方法は、アプリケーション開発者に委譲されており、開発者が任意の手段でSDP以外の方法でシグナリングすることになります。柔軟なシグナリングを必要としなければ、開発者がパラメータを事前に設定しておいて、不要なシグナリングを減らすような案も考えられます。

どちらの場合でも発生される懸念

サイマルキャスト向けのJavaScriptAPIが利用できるようになると、送信側のブラウザが複数品質のメディアストリームを送れるようになります。その際、受信側はSFUではなく、ブラウザであるケースももちろんあります。その場合、「ブラウザは受信すべきか？どう振る舞うべきか？」といった議論もありました。この振舞いの仕様自体は、WebRTC 1.0のスコープ外であり、ブラウザにおけるSimucastの受信は定義されていません。仮にブラウザが受け取ったとしても、ブラウザは単に別のストリームとして扱えばいいのではないか、といった意見が上がっていました。

その他サイマルキャストの仕様策定における重要な考え方

TPACで重要な点として述べられていたのは、「MMUSICの仕様策定が上手くいかなかっとしても、ネットワーク経路上を飛び交うメディア(RTP/RTCP)については変更を加えない」ようにするという点です。シグナリングは比較的に容易にpolyfillができるので、MMUSICが間に合わなくても、MMUSICの仕様策定が終わり、最終的に整合がとれれば良いという考え方です。

サイマルキャスト以外のトピック

以下で簡単にサイマルキャスト以外のトピックを2つほど紹介します。

IPリーク問題

WebRTCは、P2Pで通信する際にICE(RFC5245 Interactive Connectivity Establishment)という技術を活用します。ICEの内部動作としては、可能な限り接続可能性を高めるために、少しでも通信相手と接続できる可能性がある候補を全て収集します。たとえば、プライベートIP、プライベートIPからインターネットへ出ていく際に変換されるNAT後のグローバルIP、などがその候補に該当します。

接続可能性を向上させる、という意味では正常な動作なのですが、全てのIPアドレスを収集するといったその動作の特性上、ユーザのIPが外部に漏れる懸念があります。実際にNY TimesがIP収集に利用していたといった実例もあります。結果として、同じNAT配下にいるメンバが外部に漏れてしまう、ネットワークトポロジが外部に漏れてしまう、複数のアドレスが同じであることを利用して個人特定に利用される、VPN/Proxyで隠されるべきアドレスが露出してしまうといった懸念があります。これがWebRTC界隈で話題にあがっているIPリーク問題です。

TPACでは、IPリーク問題に対する対応策としてこの資料をベースに議論が実施されました。

結論のみ述べると、以下の4種類のどれかの振舞いをすることで問題を解決します。

1. 全ての候補を収集する(ただし、getUserMediaの同意があるときのみ)
2. 制限付き収集その１(ローカルはデフォルトの候補のみと、RFC1918で規定されるアドレスの候補を集める。これがデフォルトの動作になる)
3. 制限付き収集その２(ローカルの候補は無し。ただしpreferenceやextensionで設定が必要)
4. プロキシのみ(preferenceやextensionで設定が必要)

上記の[2]においては、どの程度のアドレスを集めるのか、選択肢が2つあります。選択肢の1つ目はデフォルトのホスト候補のみ、もう1つの選択肢はRFC1918の全ての候補を集めるといったものです。結論は、実際に計測実験を実施して、接続確率がどの程度低下してしまうのか、たしかめてから最終的な動作を決定する、といった結論になりました。

RtpTransceiver

新たにRtpSenderとRtpReceiverをまとめ、SDPのm=セクションをモデル化したオブジェクトとして、RtpTranceiverが追加されています。アプリケーション開発者はRtpTranceiverを利用することで、メディアストリームトラックの行き先を柔軟にコントロールできるようになります。

TPACではRtpTransceiverに関する議論がいくつかあり、例えばこれまでのWebRTCでa=recvonlyを設定するために利用していたOfferToReceiveオプションは、Tranceiver側でも制御できるようになるため削除する、などが議論に上がりました。

最後に

ここまで、TPAC WebRTC WGでの議論となった課題の背景、議論内容を紹介してきました。2日間の議論であったため、全てを本記事で紹介できたわけではありません。さらに興味のある方は、以下のアジェンダ・議事録をご覧ください。

• アジェンダ
• WebRTC WG 1日目議事録
• WebRTC WG 2日目議事録

TPACはWebの標準化団体であるW3Cが年一回開催する全体会合です。今年はその会合がなんと、札幌で開催されます。最先端のWeb標準に関する様々な議論が日本で交わされること記念して、TPACの魅力を伝えるとともに、Web標準の今をわかりやすく紹介するイベント「Leading the way to W3C TPAC 2015」が、8月終わりに開催されました。テーマは「Webの未来の肌触りを感じよう」。

来週TPACに参加される方もそうでない方も、全ての方に改めてWeb標準に興味関心を持っていただきたいと考え、そのイベントの模様をレポートします！

はじめに

イベントはW3C Keioサイトマネージャーの中村修氏の挨拶から始まりました。

W3CとIETFの関わり

今年は、Web標準を作るW3CのTPACと、インターネットプロトコルの標準を作るIETFが、それぞれ10月と11月に日本で開催される。この2つの会議が同じ時期に同じ国で行われることは歴史的にみても初めての試みだ。例えば、Webブラウザ上でP2Pによる通信を実現するWebRTCを例にとると、関連するプロトコルの議論はIETF、APIやアーキテクチャの議論はW3Cで議論が進められており、今や両者は密接に関わっている。そのため、今回のような取り組みは非常に重要な意味を持つ。また、IETFとW3Cが作る標準は「オープン標準」であることが最も重要なこと。みんなが自由にソフトウェアを書いて、その上で同じく自由に新しいサービスを作っていけるように、そのための基盤作っていく作業をIETFとW3Cは日々やっている。そこを理解してほしい。

TPAC2015の歩き方

最初のセッションはHTML5 Experts.jpのエキスパートでもある矢倉眞隆氏による「W3Cの歩き方」です。矢倉氏は以前、W3Cメンバーであるミツエーリンクスに所属しており、そこで標準活動を積極的に行っていた経歴を持ち、2007年からほぼ毎年TPACに参加しているそうです。

W3Cの情報ってどうやって収集するの

W3Cの標準化に関する活動の様子を知る手段としては、「メーリングリスト」、「GitHub」、「F2Fミーティング」の3種類がある。中でも今はGitHubでの議論が活発。Issuesを活用し様々なトピックについて議論がなされているため、議論に加わりたい方にはオススメ。気軽にコメントやPRができる。F2Fミーティングは、各ワーキング・グループ毎にTPAC以外で、年2回以上は開催されており（グループごとに差がある）、コミュニケーションが密に取れるという意味では大変重要な役割を担っている。例えば、CSSのワーキング・グループでは、図形に関する議論が多いため、F2Fでプロジェクターを見ながら議論することで、より捗る傾向にある。

TPAC2015ではどのようなことが行われるのか

TPACはW3Cの全体会合（TECHNICAL PLENARY）、運営会議（ACミーティング）、F2Fミーティング（グループミーティング）で構成されており、年に1回実開催される。スケジュールやどのようなグループが議論を行うかは、公式サイトに掲載されている。

中でも注目は、水曜日に開催される「TECHNICAL PLENARY DAY」だ。これは、アンカンファレンス形式で進められる。TPACの参加者自身が喋りたい内容をその日の朝に出し合い、早い者勝ちで予め用意されているミニセッション枠を確保する。他の参加者たちは好きなセッションに参加可能である。これは、各グループの垣根を超えたコミュニケーションを促進することで、イノベーションを促進する狙いがある。

なぜTPACに参加するのか

標準化に関する内容は、Webで簡単に手に入る時代になった。この時代に、あえてTPACに行く理由はなにか？開発者目線のTPACは、ブラウザベンダにこのようなAPIを実装してほしい、ここの部分が使いにくいので変えてほしい等、開発者の声を積極にアピールする場になっている。また、直接あって話がしたい、発表したい、他の開発者と差を付けたいなど、野心的な想いを持った開発者も多い。

これからの標準化と開発者の関わり方

最近では、ブラウザベンダも標準をかなり意識し始めている。標準じゃないと実装しないという風潮になりつつある。そして、標準化の現場も変わりつつある。これまで標準化の場で作り出されるAPIは、開発者からの要望に基づいたハイレベル（高機能）なものが多かった。そのため、新しく出てくる様々なユースケースに対応できなかった。（対応に時間がかかっていた）今後は、様々なユースケースに短期間で対応できるように、ブラウザで扱える範囲にはなるが、比較的ローレベル（低機能）なAPIの標準化が主流になる。それを組み合わせることで、開発者は様々なユースケースに迅速に対応できる。（いわゆるExtensible Webの流れ）また、JQueryのように、ローレベルなAPIを開発者自らがラッパーしてわかりやすいAPIを定義するということが、増えてくるだろうと期待もされている。

Developer Meetup in Sapporoが開催されます！

次のセッションは、TPAC2015の開催に合わせて札幌で開催される「Developer Meetup in Sapporo」の紹介です。登壇は、このイベントをホストするNTTコミュニケーションズの本間咲来（さっくる）氏。

TPAC2015は参加条件があるため、一般の開発者が参加するにはちょっとハードルが高いイベント。そこで、TPAC2015の為に来日する海外のエキスパートと日本のエンジニアの交流の場として、TPAC2015初日（10/26）に「Developer Meetup in Sapporo」が開催されます。会場はW3Cと同じ会場。展示やトークセッション、懇親会が企画されていて通訳も用意されるそうです。まだ参加登録を受け付けているようなので、興味がある方は是非参加してみては？（参加は無料です）

また、イベント開催に合わせて、クリプトン・フューチャー・メディア株式会社主催の北海道オープンデータハッカソンが10/17に開催されました。ハッカソンの優秀者の作品はDevelopers Meetupで展示されるそうです。

※写真はイベント開催時（8月末）のものです

Eddystoneで始まるPhysical Webの世界

ここからは、ゲストスピーカーによる最新のWeb技術に関する、テクニカルセッションが続きます。

最初のセッションはリクルートテクノロジーズの加藤亮氏。加藤氏は以前当メディアで取材したPhysical Webのエキスパートです。このセッションでは、Physical Webをテーマに、Googleが7月に発表したばかりの標準規格である、Eddystoneについて解説していただきました。

Eddystoneとはなにか？

EddystoneはGoogleが7月に発表したBeacon Platformを構成するもので、ビーコンの規格。ビーコンは、フレームと呼ばれるデータを定期的にブロードキャストするもので、この規格では、ビーコンデバイスの振る舞いや、発信するパケットのフォーマットを規定している。Googleはオープン・スタンダードを提唱している。

Eddystoneには3つのフレーム（Eddystone-TLM、Eddystone-UID、Eddystone-URL）がある。Eddystone-TLMは、ビーコンの管理情報を送信するもので、バッテリ電圧や温度、起動後の経過時間、パケット送信料などを送る。重要なのは、Eddystone-UIDとEddystone-URLの方。

Eddystone-UID

Eddystone-UIDは、NamespaceとInstanceIDと呼ばれる固有IDを送信します。ビーコン受信側では、Namespaceを見て自分のサービスのビーコンかどうかを判断し、InstanceIDを利用して複数のビーコンをまたがった移動などを検知することができる。iBeacon的な用途をカバーするする、洗練されたオープン・スタンダードな仕様だといえる。

Eddystone-URL

Eddystone-URLは、Physical WebのおけるURIBeaconのことであり、NamespaceとInstanceIDの代わりにURLを送信する。小さいパケットの中にURLを載せるための工夫がなされているほか、長いURLは短縮URLを使うといった配慮が必要。これは、いわゆるPhysical Webの世界を現実のモノにするためのモノで、実験フェーズから実践フェーズへの移行を象徴付ける存在である。

Eddystone-URLはビーコンの新たなエコシステムを作る

一番の醍醐味は近接通信をサービスに活用できること。Eddystone-URLを使えば、ビーコンからBluetooth Low Energy（以下、BLE）でURLをブロードキャストできる。近くにいるスマホは、複数のビーコンから受信したURLを元にOGPなどを収集、リスト表示してユーザに提示することができる。

URLが必ずしも必要かといえばそうではなく、UIDとURLの変換テーブルをもったスマホアプリを独自に作れば同じようなことができる。これは今までのBeacon（iBeaconやEddystone-UID）のエコシステムで、独自に設置したビーコンとそれ専用のスマホアプリを配布し使ってもらうというもので、開発費もかかり、ユーザにビーコン毎に別のスマホアプリを導入してもらう必要があり、ハードルが高かった。

Eddystone-URLを利用すれば、URLという共通のフォーマットでデータのやり取りができるため、スマホには標準準拠アプリ（例えばWebブラウザ）を1つ入れておけばよく、コンテンツ提供側はビーコンとWebコンテンツを用意すればよい。これは、標準規格の上で様々なコンテンツが充実したWebのエコシステムによく似ており、ビーコンにおける新たなエコシステムと言ってもいい。今後周辺ビジネス含めて新たな競争が生まれる可能性を秘めている。つまり、Eddystone-URLはただの機能的なイノベーションの話ではなく、プラットフォームとしての意味合いが強いと言える。

すぐに使えるのか

もともとPhysical Webと言われていたこの技術であるが、7月にGoogleがBeacon Platformを正式発表したことで、実験フェーズから実践フェーズに移行したといってもいい。Eddystone-URL対応ビーコンデバイスも出始めており、既存のiBeaconでもファームウェアのアップデートで対応できるものもある。（例：Estimote）

また、Beacon Platform発表のすぐ後にChrome（最新iOS）がPhysical Webに対応した。Physical Webの機能をONにすれば受信したURLをウィジェットにリストアップすることが可能で、もちろんEddystone-URLからの情報を受けることもできる。まだ実験的な対応であることは否めないが、普及に向けた第一歩であることは間違いない。尚、本命はGoogle Nowで活用したいのではないかと考える。キラーアプリの登場が普及の鍵を握っている。

Web開発者が考えなければならないこと

サービス提供側としては、ビーコンを活用する関係でリアル・ワールドを考慮したサービス設計（UI/UXデザイン）が必要になる。例えば、スマホは基本的にはインポケットデバイスである。ビーコンの情報を受信してもユーザがスマホを見てくれなければ意味がない。ユーザが自然にスマホを見るような環境に上手くビーコンを配置したり（バス停やレストラン等）、サイネージなどと組み合わせて、歩いているユーザを立ち止まらせるような仕掛けを合わせて考えなければならない。

今後の展望

近接通信を活用したPhysical Webの普及で、WebブラウザからIoTデバイスへのダイレクトアクセスという需要が出てくる可能性がある。今でもWebBluetoothやWebNFCの議論があるが、FirefoxOSなどのWebOSで使えるようにすることが主目的となっている。今後、近接通信を前提とするWebサービスを作りたいという要望が出てくれば、純粋なWebブラウザ上のWebアプリケーションからもこれらの機能が必要となってくる。そして、これらの機能が整備されると、ビーコンにかぎらず、他の様々なIoTデバイスや近接通信機器とのIFとなり得るため、デバイスが普及した暁には、Webの大きなアドバンテージになっているはずである。

発表資料

加藤氏の発表資料はこちらで公開されているので、ぜひご覧ください。

終わりに＆次回予告

次回は加藤氏に続く3人のゲストスピーカーによるセッションの模様をお伝えします。そして、来週からはじまるTPACでの熱い議論、参加される方は現地で、参加されない方もインターネット等を通して、ぜひウォッチしてみてください！新しい発見があるかもしれません。