歴史 #

WebRTC を学ぶ際、開発者はその複雑さに苛立ちを覚えることがあります。WebRTC の機能が現在のプロジェクトとは無関係であることを知り、WebRTC がもっとシンプルであればと思うのです。問題は、使用例が人によって異なることです。リアルタイム通信には豊かな歴史があり、さまざまな人がさまざまなものを作ってきました。

本章では、WebRTC を構成するプロトコルの開発者へのインタビューを掲載しています。それぞれのプロトコルを構築する際の設計について洞察し、最後に WebRTC そのものについてのインタビューを行います。ソフトウェアの意図や設計を理解すれば、そのソフトウェアを使ってより効果的なシステムを構築することができます。

RTP #

RTP および RTCP は、WebRTC のすべてのメディア伝送を担当するプロトコルです。1996年1月にRFC 1889で定義されました。著者の一人であるRon Frederickが自ら語ってくれるというのはとてもラッキーなことです。Ron は最近、RTPに影響を与えたプロジェクトであるNetwork Video toolを GitHub にアップロードしました。

彼自身の言葉です。

1992年10月、私はIPマルチキャストをベースにしたネットワークビデオ会議ツールを書こうと思い、Sun VideoPixフレームグラバーカードの実験を始めました。このプログラムは、LBLで開発されたオーディオ会議ツール「vat」をモデルにしたもので、会議に参加するユーザーに同様の軽量なセッションプロトコルを使用し、特定のマルチキャストグループにデータを送り、他のグループメンバーからのトラフィックを監視するだけのものでした。

このプログラムを成功させるためには、ネットワークに出す前にビデオデータを圧縮する必要がありました。私の目標は、家庭用ISDN回線の帯域幅である128kbps程度に収まる、見た目にも美しいデータストリームを作ることでした。さらに、その半分の帯域で見られるようなものを作りたかった。そのためには、画像サイズとフレームレートに応じて、約20倍の圧縮が必要でした。私はこの圧縮を実現し、使用した技術の特許を申請しました。これは後に特許US5485212Aとして認められました: 電話会議のためのソフトウェアビデオ圧縮。

1992年11月初旬、私はビデオ会議ツール「nv」を（バイナリ形式で）インターネットコミュニティに公開しました。初期テストの後、このツールを使って、 11月のインターネット技術タスクフォースの一部を世界中にビデオキャストしました。15カ国の約200のサブネットでこの放送を受信することができ、1週間のうちに約50～100人が「nv」を使ってビデオを受信しました。

その後、オーストラリアの「NetWorkshop」、MCNCの「Packet Audio and Video」、スウェーデンの「MultiG Workshop on Distributed Virtual Realities」など、他の3つのワークショップやいくつかの小規模な会議でも「nv」を使ってインターネット全体に向けた放送が行われました。

1993年2月には「nv」のソースコードを公開し、3月にはウェーブレットベースの圧縮方式を導入したバージョンを公開しました。1993年5月には、カラービデオにも対応しました。

「nv」をはじめとするインターネット会議ツールのネットワークプロトコルは、インターネット技術タスクフォース（IETF）で標準化されたリアルタイム・トランスポート・プロトコル（RTP）をベースにしています。RFC 1889-1890で最初に発表され、その後RFC 3550-3551で改訂され、音声やビデオの特定フォーマットを伝送するためのプロファイルをカバーするさまざまな他のRFCも追加されました。

その後、数年にわたって「nv」の開発が続けられ、多くのハードウェアプラットフォームやビデオキャプチャーデバイスにツールが移植されました。当時、インターネット上で会議を中継するための主要なツールの一つとして使われ続け、NASAからシャトルミッションのライブ中継に選ばれたこともある。

1994年には、他社が開発したビデオ圧縮アルゴリズムを「nv」でサポートするようにした。これには、SunVideoビデオキャプチャカードがサポートするCellBフォーマットなどのハードウェア圧縮方式も含まれる。これにより、「nv」はCUSeeMeフォーマットでビデオを送信できるようになり、MacやPCでCUSeeMeを実行しているユーザーにビデオを送信できるようになりました。

「nv」が最後に公開されたのは、1994年7月にリリースされた「3.3beta」だった。私は「nv」をRTPプロトコルのバージョン2に移行させることを目的とした「4.0alpha」のリリースに取り組んでいましたが、私が他のプロジェクトに移ったため、この作業は完了しませんでした。4.0αのコードは、Network Video toolのアーカイブに含まれていますが、未完成であり、特にRTPv2のサポートが不完全であるなど、既知の問題があります。

「nv」で提供されたフレームワークは、後にXerox PARCの「Jupiter multi-media MOO」プロジェクトにおけるビデオ会議の基礎となり、後にMicrosoftに買収されたスピンオフ企業「PlaceWare」の基礎となりました。また、このコードは、高帯域幅のイーサネットやATMネットワーク上でNTSC放送品質のビデオを送ることができる多くのハードウェアビデオ会議プロジェクトの基礎としても使われました。また、このコードの一部は、ネットワークベースのビデオ録画・再生サービスである「Mediastore」のベースとしても使用しました。

ドラフトに参加していた他のメンバーの動機やアイデアは覚えていますか？

私たちは皆、IPマルチキャストの研究者で、インターネット・マルチキャスト・バックボーン（通称MBONE）の構築に携わっていました。MBONEは、IPマルチキャストを最初に開発したスティーブ・デアリング、ヴァン・ジェイコブソン、スティーブ・キャスナーの3人によって作られました。スティーブ・デアリングと私はスタンフォード大学で同じ指導教官でしたが、スティーブはスタンフォード大学を辞めてXerox PARCで働くことになりました。私はインターンとしてXerox PARCでIPマルチキャスト関連のプロジェクトにひと夏を過ごし、スタンフォード大学在学中はパートタイムで、その後はフルタイムで働き続けました。ヴァン・ジェイコブソンとスティーブ・キャスナーは、ヘニング・シュルツリンと私と一緒に、初期のRTP RFCの4人の著者のうちの2人でした。私たちは皆、様々な形のオンラインコラボレーションを可能にするMBONEツールを開発していましたが、これらのツールが使用できる共通のベースプロトコルを作ろうとしたことがRTPにつながったのです。

マルチキャストはとても魅力的です。WebRTCは完全にユニキャストですが、その点について説明していただけますか？

スタンフォード大学に入学してIPマルチキャストについて学ぶ前、私はコンピュータを使って人々が互いにコミュニケーションを取る方法について長い間研究してきました。私は80年代初頭にダイアルアップの掲示板システムを運営していましたが、そこでは人々がログオンしてお互いにメッセージを残すことができ、プライベートなもの（電子メールに相当するもの）とパブリックなもの（ディスカッショングループ）がありました。同じ頃、CompuServeというオンラインサービスの存在も知りました。CompuServeの優れた機能の一つに「CB Simulator」というものがあり、人々がリアルタイムで会話をすることができました。すべてテキストベースでしたが、本物のCBラジオのように「チャンネル」という概念があり、同じチャンネルにいる限り、複数の人が他の人の入力した内容を見ることができました。私は、タイムシェアリングシステム上で動作する自作のCBを作り、そのシステム上のユーザーがリアルタイムにメッセージを送れるようにしました。実は、そのうちの1つのシステムは今でも稼働していて、30数年前に大学で一緒だった人たちと毎日のように会話をしているんですよ。

しかし、スタンフォード大学でIPマルチキャストについて学んだとき、マルチキャストを使って真の「ラジオ」のようなものを手に入れることができるという考えに興味を持ちました。偶然にも、私がIPマルチキャストのコードを移植していたコンピュータは、サンの第一世代のSPARCステーションで、実は電話品質のオーディオハードウェアを内蔵していたのです。マイクからの音をデジタル化して、内蔵スピーカー（またはヘッドフォン出力）で再生できるのです。そこで私が最初に考えたのは、IPマルチキャストを使ってその音声をリアルタイムでネットワーク上に送る方法を見つけ出し、テキストの代わりに実際の音声を使って「CBラジオ」に相当するものを作れないかということでした。

コンピュータは一度に1つのオーディオストリームしか再生できないので、複数の人が話している場合には、再生する前に複数のオーディオストリームを数学的に1つに「ミックス」する必要があるなど、いくつか厄介な点がありましたが、オーディオサンプリングの仕組みを理解すれば、ソフトウェアですべて解決することができました。このオーディオアプリケーションがきっかけで、私はMBONEに取り組み、最終的には「nv」でオーディオからビデオへと移行しました。

プロトコルに含まれていないもので、追加しておけばよかったと思うものはありますか？プロトコルの中で後悔していることはありますか？

後悔しているとまでは言いませんが、RTPに対する大きな不満のひとつは、RTPのデータトラフィックと並行して走る制御プロトコルであるRTCPの実装が複雑だったことです。RTPが広く採用されなかったのは、この複雑さが大きく影響していると思います。特にユニキャストの場合は、RTCPの機能の一部がそれほど必要ではありませんでした。ネットワークの帯域幅が希少ではなくなり、輻輳がそれほど大きな問題ではなくなったため、多くの人がオーディオやビデオを普通のTCP（後にはHTTP）でストリーミングするようになり、一般的には「十分に」機能するのでRTPを扱う価値はありませんでした。

残念なことに、TCPやHTTPを使用すると、マルチパーティのオーディオやビデオのアプリケーションは、同じデータをネットワーク上で何度も送信しなければならず、それを受信する必要のある各ピアに送信しなければならず、帯域幅の観点からは効率が非常に悪くなります。私は、IPマルチキャストの採用を研究機関だけでなく、もっと推進していればよかったと思うことがあります。そうすれば、ケーブルテレビや放送テレビからインターネットベースのオーディオやビデオへの移行を、もっと早く実現できたと思います。

RTPでどんなものが作られると想像していましたか？RTPを使ってどんなものが作られると想像していましたか？また、失われてしまったクールなRTPプロジェクトやアイデアはありますか？

私が作って面白かったのは、IPマルチキャストを使った古典的な「Space War」ゲームのバージョンでした。セントラルサーバを持たずに、複数のクライアントがそれぞれspacewarバイナリを実行し、自機の位置、速度、向いている方向、発射した「弾」の同様の情報をブロードキャストし始めると、他のすべてのインスタンスがその情報を拾ってローカルにレンダリングし、ユーザーはお互いの自機や弾を見ることができ、自機がお互いに衝突したり、弾が当たったりすると「爆発」します。爆発の際に発生する「破片」は、他の船を破壊できる生きたオブジェクトにして、時には連鎖反応を起こすようにしました。

オリジナルのゲームの精神に則り、シミュレートされたベクターグラフィックスを使ってレンダリングしました。船自体は、PARCの同僚にデザインを手伝ってもらったベクター形式の線分の束で、みんなの船がユニークな外観になっています。

基本的にRTPは、完全なインオーダー・デリバリーを必要としないリアルタイム・データ・ストリームの恩恵を受けられるものであれば、何でも利用できる。つまり、オーディオやビデオに加えて、共有のホワイトボードのようなものを構築できます。ファイル転送でも、特にIPマルチキャストとの組み合わせでは、RTPの恩恵を受けることができます。

BitTorrentのようなものを想像してみてください。ただし、ピア間でポイント・ツー・ポイントでデータをやり取りする必要はありません。オリジナルのシーダーは、マルチキャストストリームをすべてのリーチャーに一度に送信することができ、途中でパケットロスがあっても、データの受信に成功したピアからの再送ですぐに解決できます。ネットワークの真ん中でパケットロスが発生すると、その地点から下流にいるたくさんのクライアントが同じデータを逃してしまうことになるからです。

なぜ独自の動画圧縮を行う必要があったのですか？当時は他になかったのでしょうか？

私が「nv」を作り始めた当時、ビデオ会議を行うシステムは非常に高価な専用ハードウェアしかありませんでした。例えば、スティーブ・カスナーはBBN社の「DVC」（後に「PictureWindow」として商品化）というシステムを利用していました。圧縮には専用のハードウェアが必要だが、解凍はソフトウェアで行うことができた。「nv」がユニークなのは、圧縮と解凍の両方をソフトウェアで行い、必要なハードウェアは入力されたアナログビデオ信号をデジタル化するものだけだということです。

映像を圧縮するための基本的なコンセプトは、「nv」と同時期に登場したMPEG-1規格などによってすでに確立されていましたが、MPEG-1を使ったリアルタイムのエンコーディングは、当時は絶対にできませんでした。私が行った変更は、これらの基本的な概念を、より安価なアルゴリズムで近似することでした。コサイン変換や浮動小数点などは避け、SPARCステーションでは非常に遅いため、整数の乗算も避けました。加減算とビットマスク、シフトだけでできる限りのことをしようとしました。そうすることで、ビデオのような感覚を維持するのに十分なスピードを取り戻すことができました。

「nv」がリリースされてから1〜2年も経たないうちに、MBONEだけでなく、Macに搭載されたCU-SeeMeツールなど、さまざまなオーディオ・ビデオツールが登場しました。そのため、明らかに時代に合ったアイデアだと思いました。実際、私は「nv」をこれらのツールの多くと相互運用できるようにしましたし、いくつかのケースでは、他のツールが私の「nv」コーデックをピックアップして、私の圧縮スキームを使用する際に相互運用できるようにしました。

WebRTC #

WebRTCの標準化には、この章で紹介した他のすべての取り組みに比べて、非常に大きな努力が必要でした。2つの異なる標準化団体（IETFとW3C）と、多くの企業や国の何百人もの人々の協力が必要でした。WebRTCを実現するために必要な動機と途方もない努力の内側を見るために、Serge Lachapelleに来てもらいました。

SergeはGoogleのプロダクトマネージャーで、現在はGoogle Workspaceのプロダクトマネージャーを務めています。インタビューの内容をまとめてみました。

WebRTCに取り組むことになったきっかけは？ #

私は、大学時代からコミュニケーションソフトウェアの構築に情熱を注いできました。90年代にはnvのような技術が登場し始めましたが、使いこなすのは困難でした。私は、ブラウザからすぐにビデオ通話に参加できるプロジェクトを作りました。それをWindowsに移植したのです。

この経験を生かして、共同設立したMarratechという会社で、グループビデオ会議のソフトウェアを作りました。私たちはグループビデオ会議用のソフトウェアを開発しました。技術的には、当時の状況は大きく異なっていました。ビデオの最先端は、マルチキャスト・ネットワークに基づいていました。ユーザーはネットワークに依存して、通話中の全員にビデオパケットを配信することができました。そのため、サーバーも非常にシンプルなものでした。しかし、これには大きな欠点があり、ネットワークをそれに合わせて設計しなければなりませんでした。業界では、マルチキャストからパケットシャッフル（一般的にはSFUと呼ばれる）へと移行していきました。

Marratechは2007年にGoogleに買収されました。私はその後、WebRTCを伝えるプロジェクトに参加することになりました。

Googleの最初のプロジェクト #

未来のWebRTCチームが最初に取り組んだプロジェクトは、Gmailの音声・ビデオチャットでした。音声や動画をブラウザに取り込むのは簡単なことではありませんでした。そのためには、さまざまな企業からライセンスを取得する必要がありました。音声はGIPsから、ビデオはVidyoから、ネットワークはlibjingleからライセンスを受けました。そして、それらすべてを一緒に動作させるのがマジックでした。

それぞれのサブシステムはまったく異なるAPIを持っており、異なる問題を解決することを前提としていました。すべてを一緒に動作させるには、ネットワーク、暗号、メディアなどの知識が必要です。Justin Ubertiは、この作業を引き受けてくれた人です。彼は、これらのコンポーネントをまとめて、使いやすい製品を作りました。

ブラウザでリアルタイムにレンダリングすることも、とても大変でした。NPAPI（Netscape Plugin API）を使ったり、巧妙なことをたくさんしないとうまくいきませんでした。このプロジェクトで得た教訓は、WebRTCに大きな影響を与えました。

Chrome #

同時期に Google 社内で Chrome プロジェクトが始まりました。このプロジェクトには大きな目標があり、非常に興奮していました。WebGL、オフライン、データベース機能、ゲーム用の低遅延入力などの話がありました。

NPAPIからの脱却が大きな焦点となりました。NPAPIは強力なAPIですが、大きなセキュリティ上の問題があります。Chromeでは、ユーザーの安全を守るためにサンドボックス方式を採用しています。安全でない可能性のある操作は、別のプロセスで実行されます。何か問題が発生しても、攻撃者はユーザーのデータにアクセスできません。

WebRTCの誕生 #

私にとってWebRTCは、いくつかの動機から生まれました。それらが相まって、努力が生まれました。

RTC 体験を構築するのは、こんなに難しいことではないはずです。同じものを異なる開発者が再実装することで、多くの努力が無駄になっています。このようなイライラするような統合問題を一度解決して、他のことに集中すべきです。

人間のコミュニケーションは妨げられることなく、オープンであるべきです。テキストやHTMLはオープンでいいのに、リアルタイムでの自分の声や映像がオープンでないのはなぜでしょうか？

セキュリティは最優先事項です。NPAPIを使うことは、ユーザーにとってベストではありませんでした。これは、デフォルトで安全なプロトコルを作るチャンスでもありました。

WebRTCを実現するために、Googleはそれまで使っていたコンポーネントを買収し、オープンソース化しました。ビデオ技術ではOn2を、RTC技術ではGlobal IP Solutionsを買収しました。私はGIPSの買収を担当していました。これらを組み合わせて、ブラウザ内外で使いやすくする作業に取り掛かりました。

標準化 #

WebRTCの標準化は、私たちが本当にやりたいと思っていたことでしたが、私もチームのメンバーもやったことがありませんでした。この点については、GoogleのHarald Alvestrand氏に大変お世話になりました。彼はすでにIETFで幅広い活動を行っており、WebRTCの標準化プロセスを開始しました。

2010年の夏、マーストリヒトで非公式の昼食会が開かれました。多くの企業から開発者が集まり、WebRTCがどうあるべきかを議論しました。昼食会には、Google、Cisco、Ericsson、Skype、Mozilla、Linden Labsなどのエンジニアが参加しました。全出席者と発表者のスライドはrtc-web.alvestrand.comでご覧いただけます。

また、SkypeはIETFでOpusと一緒に仕事をしていたこともあり、いくつかの素晴らしいガイダンスを提供してくれました。

巨人の肩の上に立つ #

IETF で作業をするということは、それまでの作業の延長線上にあるということです。 WebRTCでは、多くのものが存在していたことが幸いしました。すでに解決されていたので、すべての問題に取り組む必要はありませんでした。もし既存の技術が気に入らなければ、イライラするかもしれませんが。既存のものを無視するにはよほどの理由が必要で、自分で作るという選択肢はありません。

また、シグナリングなどの再標準化も意識的に行いませんでした。これはすでにSIPやその他のIETF以外の取り組みで解決されており、非常に政治的な問題になりかねないと考えたからです。最終的には、この空間に加えるべき価値があまりないと感じたのです。

私は、Justin や Harald ほどは標準化に関与しませんでしたが、標準化を楽しんでいました。それよりも、ユーザーのためのモノづくりに戻りたいという気持ちの方が強かったですね。

今後の展望 #

WebRTC は現在、素晴らしい状態にあります。多くの反復的な変更が行われていますが、特に私が取り組んでいるものはありません。

私が最も期待しているのは、クラウド・コンピューティングがコミュニケーションに何をもたらすかということです。高度なアルゴリズムを用いることで、通話中のバックグラウンドノイズを除去し、これまで不可能だったコミュニケーションを可能にすることができます。また、WebRTCは通信にとどまらず、9年後にはクラウドベースのゲームにも使われるようになるとは、誰が予想したでしょうか。これらはすべて、WebRTCという基盤がなければ実現しません。