10月26日から31日にかけて、Santa Claraで開催された「TPAC 2014」。本レポートでは、TPACで行われたWebRTCワーキンググループについてレポートします。

TPACとは?

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

本記事では、WebRTC WG(ワーキンググループ)で議論された注目の話題をレポートします。WebRTC WGには、WebRTC(※)をより安心・安全に、一方で開発者には強力な柔軟性を与えたいと考えるメンバーが集まっています。

※ WebRTCとは？： WebRTC(Web Real Time Communication)とは、サーバを経由せずにブラウザ同士が通信する技術のことで、ブラウザから音声や映像を取得するようなAPIを含んでいます。これらのAPIにより、プラグインなしで、お好きな複数のデバイス間で音声・映像通信を実現できます。WebRTC自体の技術的な内容については、本サイトのWebRTCを使ってみよう！をご覧ください。

Media Capture タスクフォース

Media Captureタスクフォースは、Device APIsとWebRTC WGsの両者が参加するタスクフォースです。音声・映像をデバイスから取得するgetUserMedia APIを担当しています。今年のTACでは、いかに開発者に簡単にAPIを利用させるか、また、ラストコール(勧告候補の前にコメントや提案を受け付けるタイミングです)の準備ができた、という点について議論が集中しました。

Promises

MozillaのJan-Ivar Bruaroeyが推進するPromiseが議論が白熱したトピックです。 具体的には、getUserMediaを取り巻くイベント(例えばMedia Stream Track onended イベント)について、Promiseを利用する案が出ています。Promiseによってコードを綺麗に書くだけでなく、より詳細なエラー情報を開発者が利用可能になると、彼は述べています。

対して、RFTMの創設者であるEric Rescorlaは「不必要に複雑で、開発者が悪いコードを書いてしまう可能性がある」と述べ、強く反対しました。また、Promiseは複数回発生ようなイベントを扱えない、という問題があるとも述べています。 結局、MediaStreamTrack onendedイベントのようなイベントについては、reason codeを付けるのが最適という妥協点に達しました。getUserMediaは、メディアキャプチャに関するAPIの中でPromiseを使う唯一のAPIとなります。

出力デバイスの選択

WebRTCのアプリ開発の上で、開発者が直面する問題の1つに、音をスピーカから出力するか・ヘッドセットから出力するか、指定できないという問題があります。残念なことに、自由に出力デバイスを選択できるようにしてしまうと、セキュリティ上の懸念（例えば、悪意のあるサイトが広告を音声として流すようにな懸念）が出てきます。

GoogleのJustin Ubertiは、デバイスグループを定義するという、シンプルな解決方法を提案しました。 もし、入力と出力のデバイスが同一であるなら、同じデバイスグループに属するという考え方です。例えば、ヘッドセットや会議室のマイクが典型になります。本機能の前提として、もしユーザが入力デバイスに制御権を与えるなら、出力デバイスにも同じ権利が与えられてもよい、という考えがあります。本提案は歓迎されましたが、参加者はさらなる詳細(permissionの継続や仮のデバイス利用)について要望しました。

WebRTCワーキンググループ

WebRTC WGで議論された主なトピックは、オブジェクトを利用してWebRTC APIをモダンなものにする、ということ。マイクロソフトが推進するORTC(Object RTC)は明に言及されていないものの、明らかに多くの提案はORTCが推進力になっているものでした。

RTPSender と RTPReceiver

GoogleのJustinが、WebRTCでSDPを使うための新たな方法である、RTPSenderとRTPReceiverを提案しました。 現時点でストリームのビットレートを変更するためには、SDPのプレインテキストを書き換える必要があり、かなり大変です。また、SDPを見なければ、セッションで使われている最大のビットレートのような情報を取得できません。 Justinの提案は、これらの問題を解決するための第一歩になります。

この提案の中で最も受け入れられた部分は、RTCPeerConnectionオブジェクトの扱いにおいて、ストリームベースからトラックベース(RTCSender/Receiverオブジェクトにトラックを結びつける方法)へ、メディアを扱う方法を変えていくといった部分でした。

つまり、全てのトラックがRTCSenderオブジェクトを送り、全てのトラックがRTCReceiverオブジェクトを受け取ります。このようにすることで、同じトラックを複数の箇所で複製・利用できるようになり、ビットレート等もトラックごとに操作できるようになります。

また、提案の中には、ローカル/リモート候補、リモートのDTLS証明書、ユーザに対するビットレートのようなエンコードパラメタに挙げられる、トランスポートに関するデータを公開する方法も含まれています。全体として、この提案は良いと考えられたものの、エラーに対する操作やWebRTC 1.0に含める最小の仕様については、さらなる議論が必要となっています。

最後に、Justinはトラックを直接編集可能にする、という提案をしています。この提案によりモバイル機器の全面と背面のカメラを切り替えるときに発生する問題が解消できます（現在は、古いトラックを削除して、新しいトラックを追加し、再度ネゴシエーションする方法で対応しないといけません）。提案されたAPIであれば、トラックの内容を変更するだけで済み、再度ネゴシエーションする必要がありません。

またまたPromises

Jan-Ivarが再度登壇し、WebRTCについてもPromiseを利用するという、提案をしています。Media Captureセッションから受け取るフィードバックを利用して、promisesの実験的な利用を削減し、ICE・ピアコネクション・コールの発信のフローの中でPromiseを利用する教科書的な利用方法を提案しています。

Eric Rescorlaはまだ納得していなかったようなものの、エラー処理の簡単さに対するJan-Ivarのアピールが残りのグループの同意を勝ち取り、promiseが含められる点が合意され、既存のコールバックは非推奨となりました。

DTLS証明書

DTLS証明書は、ピア自身が本人であることを証明するために利用できます。マイクロソフトのMartin Thompsonは、Web Crypto APIを利用した、DTLS証明書を生成する新たなAPIを提案しました。

これにより、ドメイン毎・ユーザ毎に同じDTLS証明書を再利用できるようになりますし、証明書を毎回作成し直すことも可能になります。ただし残念なことに、Elliptic curve cryptography (日本語リンク)がWeb Crypto APIで動作するか誰も知らなかったので、明らかになるまで延期するのがよいという結論になりました。

Stats API (統計API)

Callstats.ioのファウンダであるVarun Singhは、新しいWebRTC stats APIドラフトの詳細について、WGの意見を募集しました。詳細とは例えば、変数名、コード名のフォーマット、bytesSent/Receivedがヘッダに計算結果を加えるべきか・それとも単にペイロードにすべきか、等になります。

Bugs, bugs and more bugs!

翌朝2日目の8:30という早朝から、bugzillaに出されているWebRTC関連のバグについて議論をするために、グループが集まりました。グループはそれぞれのバグについてのアクションを決めるために、3時間以上を費やしました。グループの参加者は徐々に減っていき、最後にはアクションを決定できなくなってしまいました。（主要メンバーが既に帰ってしまった！）

結論

2日間に渡り続いたTPAC 2014のWebRTC WGも終わりです。WebRTC劇場へPromiseが追加されますし、策定中の大きな仕様変更もまだあります。今後数年間で追加されるである新機能が楽しみですね！

(本記事は、飯田 アレン真人が英語で執筆し、編集部の岩瀬 義昌により翻訳されました)