2015年10月26日から30日にかけて、札幌で「TPAC2015」が開催されました。本記事はその中でも、29日と30日に開催されたWebRTCワーキンググループの議論をレポートします。
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つ以上のエンコードがあることを明示しなければなりません。具体的なコードサンプルは以下となります：
|
1 2 3 4 5 6 7 8 |
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向けのパラメータを記載します。たとえば、以下のようになります。
|
1 2 3 4 5 6 7 8 9 10 |
// クライアント側の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種類のどれかの振舞いをすることで問題を解決します。
- 全ての候補を収集する(ただし、getUserMediaの同意があるときのみ)
- 制限付き収集その１(ローカルはデフォルトの候補のみと、RFC1918で規定されるアドレスの候補を集める。これがデフォルトの動作になる)
- 制限付き収集その２(ローカルの候補は無し。ただしpreferenceやextensionで設定が必要)
- プロキシのみ(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日間の議論であったため、全てを本記事で紹介できたわけではありません。さらに興味のある方は、以下のアジェンダ・議事録をご覧ください。
