無印吉澤（※新エントリはhatenablogに掲載中）

■[NAT][VoIP]MicrosoftとCiscoがICE対応を表明？　それがどうしたというのか（後編）

前回の日記では、ICEというNAT越え技術はどのようなものか、というお話をしました。今回はその内容を踏まえて、メインのツッコミ部分に入っていきます。

ちなみに、今回の日記を書くにあたってICEのInternet Draft（draft-ietf-mmusic-ice-06）を一部読み直してみたのですが、全部で82ページもある面倒くさい代物なので、1〜6章と8〜12章だけ読んで済ませちゃいました。抜けがあったらそのせいです。そっと教えて下さい。

----

MicrosoftとCiscoがICEをサポートしても、それをきっかけとしてICEが広く使われるようになるとは思えない……と僕が考える理由は、主に2つあります。1つは、ICE自体がSIP UAの実装に大がかりな変更を要求すること。そしてもう1つは、特にSIPとの連携において、ICE自体に曖昧な部分が多いことです。

※以下の記述は個人的なメモとしての意味合いが強いので、細かい点に興味が無い方は一番下の「ICE対応＝独自実装対応」まで飛んで下さい。

■ SIP UAへの変更点

一口にICE対応と言っても、そのために必要なSIP UAの機能はとても多いです。

第一に必要な機能は、それぞれのSIP UAが、自分の使える可能性のあるアドレス（以下、アドレス候補）を取得して、相手のSIP UAに渡すための機能です。アドレス候補を取得するためにはSTUNクライアントやTURNクライアントの機能が必要ですし、そのアドレス候補を相手のSIP UAに渡すためにはSDPの拡張が必要です*1。

次に必要な機能は、相手から渡されたアドレス候補のうち、どれが使えるかを検査するための機能です。ICEではこの検査を接続性チェック（Connectivity Check）と呼んでいます。この接続性チェックは、かなり細かい状態遷移を伴う複雑な処理のようです。また、このチェックにはSTUNプロトコルを使うため、ICE対応のSIP UAはSTUNサーバを任意のポートで起動できる必要があります。

最後に必要な機能は、上記の接続性チェックに成功したソケットを、メディアストリームの受信に流用する機能です。しかも、Internet Draftに載っているシーケンス例では、一度メディアストリームの受信を開始したソケットについても、引き続きSTUNサーバとして動作することを要求しているふしがあります（必須ではないのかもしれませんが）。

このように、ICEをサポートするために必要な機能は、SIPのセッション確立に関わる全ての処理に影響しています。UPnPやSTUN、TURNといった単独で成り立つNAT越え技術とは異なり、ICEはシグナリングプロトコルと非常に密着しているのです。

■ ICE仕様の曖昧な部分

僕がInternet Draftをざっと読んだ印象では、ICEの仕様は非常に分かりにくい上に、曖昧な部分が多いような気がしました（この点について、詳しい人のコメント求む）。

特にSIPとICEの連携については、「接続性チェックによって生じる遅延の解消方法」と「STUN/TURNサーバの認証とSIPサーバの認証の連携方法」が曖昧な気がします。

前者の「接続性チェックによって生じる遅延」とは、200 OK送信からメディアストリーム開始までにかかる遅延のことです。ICE対応のSIP UAは、200 OKが送信されると接続性チェックを開始し、少なくとも1つのアドレス候補について接続性チェックが成功したあとで、ようやっとメディアストリームを開始することになります。この状況を電話にたとえると、受話器を上げてからしばらくの間は無音状態が続くということです……あまりよろしくないですよね。

で、この問題に対して、現在のInternet DraftはRECOMMENDEDとして以下の解決案を挙げています。

• 200 OKの前の18x provisional response（RFC3262）でSDPを交換して事前に接続性チェックをしてしまい、その後UPDATEメソッド（RFC3311）で最適なアドレスに切り替える
• RFC3262とRFC3311をサポートしていない場合は、unreliable 18x responseとre-INVITEで代替する
• とはいえ、unreliable 18x responseは相手側に届くことが保証されていないので、RFC3262にあるような再送を行うようにする

本来なら、この部分をもっとちゃんと決めておく必要があると思うんですが、このInternet Draftでは上記のような正常系について簡単に（全82ページのうち1ページ程度）触れているだけです。

一方、後者の「STUN/TURNサーバの認証とSIPサーバの認証の連携」はSTUNサーバやTURNサーバを勝手に使わせないようにするために必要になります。これは、管理外のSIP UAに使わせないようにする、ということも必要ですが、想定外の用途（ファイル転送など）には使わせない、ということも必要になるでしょう。特に、企業ユースなら尚更です。

STUNやTURNのプロトコルは元々単純なパスワード認証の機能を備えているのですが、そのためのアカウントをいつ発行し、どの程度の期間で無効にするのか？　ログイン時にアカウントを発行するのか、それともセッション確立時に発行するのか？　SIP UAはSTUN/TURNサーバをどうやって見つけるのか？　このあたりは、他社SIP UAとの相互接続性を考えると、曖昧なままでは困る部分ではないでしょうか。

■ ICE対応＝独自実装対応

以上のように、ICE対応というのは、従来のSIP UAに対する追加機能としては非常に重い機能であり、また曖昧な部分も多いと言えます。それに加えて、ICEはまだRFC化されていない不完全なプロトコルです。そう考えると結局、ICEに対応するということは「MicrosoftとCiscoの独自な仕様解釈に合わせてソフトウェアを作り込む」ことに他ならなくなってしまうのではないでしょうか？

また、その他のSIPソフトウェアメーカにとって、今更SIP UAをICEに対応させるメリットがあるかどうかも疑問です。というのも、今までIETFでSIP UA側のNAT越え技術を標準化するのが遅れすぎたため、SIP IP電話の世界では、既にSIP ALGやSBCといった、SIP UAに対して透過的にNAT越えを実現するサーバ製品が普及してしまっているからです。

要するに、今回の話はMicrosoftとCiscoがようやくIP電話に本腰を入れ始めたという以外の意味はないと思います。NAT越えの標準技術が採用されたからといってSIPの相互接続性が上がることはなく、Microsoft・Cisco連合とその他大勢の間の相互接続性は逆に下がっていくような気がしてなりません……。僕が悲観しすぎてるだけならいいんですけどね。