言語ゲーム

とあるエンジニアが嘘ばかり書く日記

Twitter: @propella
トップ > WikiPhone プレゼン資料収集中

WikiPhone プレゼン資料収集中

だいぶご無沙汰になってしまったが C5 でプレゼンをしなくてはならない都合上、WikiPhone についての情報を再度纏めている。今まで書いた事と重複するが自分用メモなので気にしないで書く。

開発動機。毎週の電話会議で使ってる Gizmo がへぼくて繋がらない事が多く、本当に VoIP 技術がそんなに難しいものか確かめたかったのが一番最初の動機。そして調べていくうちに VoIP にものすごい違和感を感じ、インターネットで尊重されるべきシンプルさ優先の法則に基づいた物を作るとしたらどういう物になるかやってみようと思った事。

まず VoIP にまつわる技術の多くは、すでに 1995 年あたりに確立している物で、驚くなかれその時点ですでにビデオ通話に関する考慮もなされている。2007 年の視点で見ると細かいビット単位の固定長フォーマットにいらいらする。10年以上絶ってこれだけ帯域があがったのに品質がイマイチだと言う事は、そんな細かい工夫でどうにかなる問題じゃないという事か? あとそれらは既存の電話技術からの転用で、VoIP 自体が一つの世界を形作っていて他のインターネット技術との親和性に欠ける。他の技術を使わず音声と発信と認証にそれぞれ独自のメカニズムを使うというのは今風では無い。通話はともかく、認証と発信にはそれぞれ PKI や XMPP を使えば良い。と言う事は残る音声にどういった技術を使うかという問題が残る。

逆に音声さえ上手く流す事が出来れば、他の技術を開発する必要が無いという事だ。そこに TCP のみ使うというのは一つの逆転の発想だ。TCP には遅延が大きいという問題があるが、

  • 1) TCP の遅延は今後少なくなる(遅延を少なくしないと帯域を増やせないという TCP の特徴がそうさせるだろう)。
  • 2) UDP を使うにせよ、信号順序の管理を自前で行う必要があって、パケットの速度で通話が出来るわけではない。むしろカーネルがやる TCP の方が速いかも。

という事で TCP を使う事にした。特に UDP の順序管理はうっとおしくてやりたく無い。また、広く使われるプロトコルを目指した時に、CGI 感覚で気軽に音声を送れるというのが必要で、ストリーミングに UDP は不適切だ。

あとのひねりは TCP の中でも、特に HTTP を使うという判断だ。実は今の WikiPhone はまだ Web Proxy を通過する事が出来ないので、わざわざ HTTP を使う利点は無い。それでも HTTP は世界でもっとも使われるプロトコルであり、それに合わせる事で HTTPS 等 HTTP の技術の多くが転用できるのではと考えた。API が REST で構築されている事 (GET が音声受信、PUT が音声送信になっている) で多くのプログラマはプロトコルにすぐ馴染む事が出来る。なにより接続の方向がクライアントからの一方通行なので、NAT を気にしなくて良い(どうでも良い話ですが、今日久しぶりに納豆が買えました)。

HTTP を使う上での最大の問題は即時性だ。HTTP は一つずつ書類を取得する為のものなので、ずーっと音声を流しっぱなしに出来ない。WikiPhone の回答は二つある。

  • HTTP 接続を二本用意し、それぞれ受信と送信に使う。HTTP は半二重なので同時に送受信に使えないから。
  • 送信方式として、HTTP/1.1 Chunked http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616#Sec3.6 を使う。これはデータのサイズを指定しないで送信する時に使う方法で、一秒あたりのデータ量が決まってる VoIP では関係ないと思いきや、chunked 拡張ヘッダは HTTP ヘッダより短いので格段に効率が上がる。

特に chunked 送信を使うのが WikiPhone 低レベル技術のハイライトである。現在プロキシを通過できないのはこのせい。将来 WikiPhone が普及したら各プロキシベンダに対応してもらおうと都合よく考えている。

低レベル技術のハイライトが chunked 通信なら高レベルは何かというと、URL をチャンネルの識別子として使う事だ。誰かと話をしたいときには、その人と同じ URL にアクセスすればよいだけ。これはスケーラビリティー上のものすごい利点がある。まずデータベースが不要なので(ユーザ認識は WikiPhone の範囲外)サーバを分散出来る。そしてもしもサーバが分散できなかった場合でも DNS ラウンドロビンはもっとも簡単な負荷分散方式だし、スイッチでロードバランスさせるにも URL ベースが一番簡単。負荷に泣かされた事のある技術者なら手軽さはぐっと来ると思う。

こういった様々な技術を選択する上で、自宅サーバで使うという用途を念頭においているという事も書いておく。セキュリティ上、帯域上、その他色々の理由で、WikiPhone を中央の巨大サーバで多くの通話を処理するというには向いていない。むしろ各人の自宅に置いた自宅サーバに直接アクセスするのに最適だ。URL は IP アドレスを使っても良いし、no-ip でも良い。自分で勝手に自分の電話番号や放送局を作れるという事だ。あまり本当の野望を書くと将来逮捕されたときに困るので書かないが、自由に通信チャンネルを作れる事と、通信がサーバに静的に置かれたデータではなく、ストリーミングである事を組み合わせればかなりやばい事が色々出来る。

全体的に言える事はこの技術が超技術者フレンドリだと言う事(ユーザ俺だけ)。あと、実は音声技術に特化していない事。音声技術に特化しようと思えばもっと色々出来る。例えば今はミキシングはクライアントでのみ行っていて、サーバは音声に関してノータッチだ。これは将来どんな事にも使えるようにという事でこうしている。実際使えないチャットプログラムが付属している。

とはいえ、現行のあまりの音質の悪さに失望して、自分でもほとんど WikiPhone を使っていない。しかし今やってるコーデックスの仕事が完了したら、それも WikiPhone に取り入れるのでしばらくバージョンアップはお待ちください。

今までの日記内のリンク