歴史で振り返るWebRTC

概要

すでにいろんなブラウザに実装されて、商用（？）サービスなども登場しているWebRTCですが、この記事では「なぜWebRTCが登場したのか？」「どうしてこんな仕組みになっているのか？」を振り返ることで、VoIPからWebRTC、そしてORTCへの変遷を振り返りたいと思います。

Before WebRTC: VoIP

WebRTCが登場するまでは、インターネット上/IP上でリアルタイム通信を実現する技術としてVoIPがありました。中でも、今までで最も成功したVoIPのフレームワークとしてはSIPが挙げられるでしょう。WebRTCで初めてリアルタイム通信に関わった方でも名前くらいは聞くことがあるのではないでしょうか。WebRTCで利用されているSDPやRTPも、SIPとセットで仕様が作られました。

SIPはWebRTCでも必要なシグナリング機能を提供するための使われるのですが、なぜSIPが「標準仕様として」必要だったのでしょうか。これは、リアルタイム通信を含めた通信の常識どおりの発想から来ています。すなわち、「通信が行われる参照点（＝インタフェース）で通信方法（＝プロトコル）を決めたルール（＝仕様）を決めて、そのルールに従っていればちゃんとお互いに通信（＝相互接続）ができるようにする」というものです。これによって、Aさんが通話などのサービスを利用する際に、標準ルールに則った端末を買ってさえくれば、どんなメーカのどんな製品でもちゃんと通信を行うことができますし、別のサービスを利用するBさんと接続したい場合も、同じルールに従ってさえいればそのまま接続することができます。こうした世界を実現するために、SIPというルールが作られました。RTPについても同様です。

SIPでは典型的にこのような台形構造をとることになるため、SIP Trapezoid（台形）と呼ばれることが一般的です。

WebRTC

SIPが一段落して、世の中でもサービスが普及した折、SIPを作った標準化団体であるIETFで非常に刺激的（衝撃的？）なプレゼンが行われました。発表を行ったのはJonathan Rosenbergという方で、SIP仕様の筆頭著者となっている方です。SIPに関わった方なら120%知っているような超有名人で、SIPのコア仕様以外にも関連するRFCをたくさん書かれている、SIPといえばこの人！みたいな人です。（ちなみに、元Googleの幹部に同姓同名の方がいらっしゃいますが、別人です）

スライドは下記から入手できます。
www.ietf.org/proceedings/80/slides/plenaryt-5.pptx

要約すると、「SIPは失敗だった」という内容になっています（若干曲解ですが）。10年以上の歳月・人生をSIP関連の技術に投じて、Mr. SIPと呼ばれることもあったらしいJonathanが、自身のが世界へと多大な貢献を実現した証として公言し自慢してもよいはずのSIPを「失敗」と呼ぶに至らせた理由はなんだったのでしょうか。発表の中では、要求が生じてから実装・標準化が行われるまでのプロセスが長すぎたこと、また、SIPのコア仕様以外の仕様が作られすぎてわけがわからなくなったことがあげられています。タイトルにSIPが入るRFCの数は発表が行われた2011年の時点でも優に100を超えており、一口にSIPといっても「お前はどこからどこまでサポートしているんだ？」ということになる状況ができてしまっていました。

さらに同発表の中では、じゃあどうすればいいのか、というところまで言及されています。ここで登場するのが近年のWebサービスです。同じ発表から資料を貼り付けます。

この図の意味するところは、「HTTPさえあればいろいろダウンロードしてこれるんだから、それ以外のルールを使いたい場合はそのダウンロードするアプリにルールを書いとけばなんとかなるじゃん」ということです。

・・・JS等に慣れ親しんだWeb開発者やの方からすると「あったりまえやん！」という声が聞こえてきそうです。が、電話からVoIPの流れを汲んだ経歴を持った人々からすると、これは衝撃的な内容だったと思います。端末とサーバの間や、サーバとサーバの間でルールを決めるからこそちゃんと通信ができると思っていたのに、それがなくても繋がるなんてどういうことだ！と思った人も多かったことでしょう。ようやくリアルタイム通信が近年のWebのトレンドに合致した、それがWeb Real Time CommunicationことWebRTCなのです。

WebRTCはこのResenbergの発表通りに設計がなされています。最新版のOverviewドラフトを眺めてみてもこの設計通りとなっていることがわかるでしょうし、このOverviewドラフトのもとになったFrameworkドラフトはRosenberg自身によって作成されています（http://tools.ietf.org/html/draft-rosenberg-rtcweb-framework-00 ）。「WebRTCはシグナリングプロトコルを決めない」ということを聞いたことがある方もいるかもしれませんが、これはHTTPというどんな環境でも通信ができるプロトコルがあるから、それでアプリをダウンロードさえすれば、あとはアプリの実装事態でなんとでもなるでしょう、という意味を持っているのです。端末がどんなルールに則るかなど気にする必要はありません。ルールは、上のサーバがJSによって指定できるようになったのです。その代わりに、WebRTCではJSとブラウザの間にあるAPIを別途ルールとして決めています。これが従来SIPで担わなければいけなかったルールに相当しています。

これによって、SIPが囚われてしまった標準化の罠をWebRTCが抜け出し、人類は先に進むことができるようになりました。

After WebRTC: ORTC

WebRTCによってSIPが夢見た世界が実現され、ようやく人類はゴールにたどり着いた・・・というわけではありません。残念ながら、歴史は繰り返してしまいます。次は何が問題になったのでしょうか。

最大の問題点はSDPです。WebRTCでは、メディアの設定の記述にSDPを利用します。SDPを採用するかどうかはWebRTCでもかなり大きな議論があったのですが、むやみに似たような仕様を作りたくない、すでにあるものは最大限流用して作業量を減らすべき、といった声が大きかったため採用されることになりました。結果論でしかないのですが、これがあだになりました。

第一の問題はSDPが読めない・読みにくいことです。WebRTCを触っていて意味不明な文字列だと思われたことがある方も多いと思いますが、あのフォーマットを所見で読み解ける人はいないことでしょう。

第二の問題はSDPのOffer/AnswerモデルがWebRTCで必要とされる使い方にそぐわないということです。Offer/Answerモデルというのは、「発信者（Offerer）が通信に必要なパラメータすべてを着信者（Answerer）に送り、着信者は通信に必要なパラメータすべてを発信者に返す」ことが前提になっています。いっせーのーでっというタイミングで必要な情報を全部いっぺんに交換するイメージです。何が問題になるかというと、パラメータの一部に変更が生じた場合に、その差分だけを送ることができず、必要ないパラメータまで送らなければいけないという点です。WiFi→モバイルなどのようにネットワークが変更になってIPアドレスが変わった場合でもその差分だけを送ることはできませんし、コーデックの設定だけを変えたいときなどもその情報だけを送ることはできません。ここまで読んでTrickle-ICEが思い浮かんだ方は相当WebRTCのフレームワークに詳しいのではと思いますが、Trickle-ICEはまさにこのOffer/Answerを一部ハックして、a=candidate行だけを別にやり取りすることで柔軟性を向上している仕様なのです。（同じくメディア関連の柔軟性向上を狙いm=行と付随する情報だけをやり取りするPartial Offer/Partial Answerと呼ばれる仕様も提案されていましたが、こちらは今のWebRTCでは採用されないことになっています。）

第三の問題はSDPもSIPと同じく様々な拡張仕様が存在することです。そのため、どの拡張までをサポートするのか？が明確にならないと、ブラウザによって理解できるSDPが変わってしまうことになり、通信が失敗する可能性があります。これを解決するためにはSDPのサポート範囲を明記してやることが必要となり、現在依存リストが作られています（http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-06）

これに対して、そもそもSDPを使うのをやめればよい、諸悪の根源はSDPだ！という声が大きくなりました。SDPだけが原因ではありませんが、これら課題が契機となってできたのがORTCです。ORTCではSDPの代わりにJSON形式でメディアの情報を記述することなっており、少なくともSDPよりは直観的にわかりやすいです。また、いわゆるOffer/Answerモデルを採用していません。さらに、脈々と引き継がれてきた過去のSDP仕様に縛られることもなくなります。

これによって、人類はさらに先に進むことができる・・・と思いたいです。

最後に

この記事ではWebRTCの歴史を振り返り、VoIPからWebRTC、そしてORTCまでの流れを簡単に述べました。なんでそもそもこんなことになっているんだろう？とか、なんでWebRTCとかORTCが出てきたんだろう？という方のお役に立てば幸いです。