SIPの相互接続性問題を、NAT越え問題と対比して考える無印吉澤(※新エントリはhatenablogに掲載中)吉澤です。このサイトではIPv6やP2Pなどの通信技術から、SNSやナレッジマネジメントなどの理論まで、広い意味での「ネットワーク」に関する話題を扱っていたのですが、はてなブログに引っ越しました。使っている方は以下のボタンで変更ください。Agent)として動作し、各社SIP実装の違い(俗に言う「SIPの方言」)を吸収するオープンソースソフトウェアです。今年度の「未踏ソフトウェア創造事業」として採択され、現在開発が進められています。FMCなどの将来のネットワークを見据えた拡張を行うことにより、長期にわたって使用可能なSIPミドルウェアを提案する。本提案では、下記の特徴を持ったSIPアプリケーション開発用のミドルウェアを開発する。クライアントサイドで動作するB2BUAモジュールB2BUAの動作をモジュールにて定義可能なモデルSIPをHTTPのように、汎用的に扱うことを可能なモデルモバイル端末向けの実装(「申請テーマ概要」より抜粋)ちょうど最近、SIProp開発者の今村さんから直接お話を伺う機会があったのですが、そのお話を聞く限りでは、SIPropとは以下の図のように動作するソフトのようです(間違ってたらごめんなさい)。いう相互接続性の問題を目にすると、僕は、どうしても最初にNAT越え問題を連想してしまいます。過去にNAT越え問題を追っていたから、という単純な理由なんですけど......。実際よく考えてみると、SIPの相互接続性問題とNAT越え問題を対比させることで、この問題の中でのSIPropの意義をうまく説明できる気がしてきました。そこで、今日はNAT越え問題の経緯を元に、僕が考えるSIPropの意義について説明してみたいと思います。近年、NATを越えたP2P通信がうまくいかない理由......つまり、NATの奇妙な動作に関する理解が進むにつれて、NAT越え問題にもようやく進展が見られ始めました。以下は、その経緯に関する個人的な見解です。Cone、Symmetric)に整理されました。これが2003年3月にSTUNのRFC(RFC3489)として公開されることで、専門家以外にも、NATの問題が共有されるようになります。NATへの各種対策が各地で検討され、その中でNAT実装の整理も見直されていきます。Tools)の中に見ることができます。Behavior(アウトバウンドパケットに対するポート番号の割り当てルール)」という用語に置き換えられています。Behavior、パケットを折り返すかどうか)など、RFC3489の時点では考慮されていなかった問題も新たに登場しています。このように、NAT実装の特徴が細かく整理されたことで、現在では複数ある実装パターンのどれが望ましいのかを具体的に議論できるようになりました。(behave)ワーキンググループで議論されている上記のdraft-ietf-behave-nat-udpでは、それぞれの細かい仕様に"Justification"という項目が設けられて、「なぜその動作を標準とするのか」という理由がしっかりと記されています。NATとか)が付いてから、それをベースとして議論が進み、複数の実装の違いを細かく比較できるようになってから、NAT自体の動作を標準化する方向に進んでいます。これと同じように、SIPの相互接続性問題の分野でも、まずSIP実装の種類について仮の整理を付ける必要があるはずです。実際、「SIPには方言がある」ということ自体は関係者の間で周知されていると思うのですが、僕みたいに「SIPがどんなものか何となく知っている」程度の人間には、具体的にどういう問題があるのかさっぱり分かってないのではないでしょうか。これでは、理想的な実装について議論できる人の数はかなり限られてしまいます。そこで、このSIPropは、まさにこの「仮の整理」を付けるための枠組みとして理想的なアプローチになるのではないか......と僕は考えています。SIPropでは各社のSIPメッセージを一度共通のSIPメッセージ(FlatSIP)に変換します。この変換部分がオープンソースのプログラム(モジュール)として記述されるため、そのソースコードを読めば、各実装の差異を誰でも詳しく知ることが出来るようになります。そのため、今後、各社仕様に合わせたSIPropのモジュールが充実していくにつれて、SIPのあるべき動作を標準化するための議論を行いやすくなっていくはずです。今後の展開について以上のようなことから、今後SIPropが成功すれば、SIPの相互接続性問題に関する議論は一気に進むようになると思います。基本的な機能は「IPアドレスとポート番号を変換する」くらいしか無いNATに比べて、SIPの仕様は非常に膨大です。今村さんによると、SIPの仕様は、RFCにおいてStandardとされている方式だけでも以下の6つがあるそうです。参考までに、各RFCのページ数を括弧内に記載しておきます。Network)のように既存の電話網をSIPで置き換えようという話になると、これに加えて更に仕様が増えていくわけで......。SIPropがうまく議論のための枠組みとして普及したとしても、その先は長い道のりになりそうです。SIPの相互接続性問題を解決できなければ、いずれ「どこかのベンチャーが作ったスゴイIP電話アプリケーションの採用するプロトコルがいつの間にかデファクトになっていた」ということにもなりかねません。なっては困る人たちがSIPropに協力してくれれば、いろいろ面白いことが出来るようになると思うのですが......ともあれ今後のSIPropの活動は要注目です。参考1週間ほど前のITProでも、ちょうどSIPropを取り上げていました。4ページに渡る詳細な記事ですので、SIPropについて更に詳しく知りたい方は、まずこちらをご覧になることをお勧めします。次の日記(2006/11/28)»2004|06|07|09|11|12|2005|01|02|03|04|05|06|07|08|09|10|11|12|2006|01|02|03|04|05|06|07|08|09|10|11|12|2007|01|02|03|05|06|07|08|09|10|11|12|2008|01|02|03|04|05|06|07|09|10|11|2009|01|02|03|04|05|07|08|10|2010|01|03|2015|03|スパム対策のため、60日以上前の日記へのコメント及びトラックバックは管理者が確認後に表示します。この日記に無関係と判断したコメント及びトラックバックは削除する可能性があります。30このサイトについてこの日記を書いているのは、吉澤というソフトウェア技術者です。muziyoshiz.jpまでどうぞ。