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

■[VoIP][NAT]SIPropの意義 / SIPの相互接続性問題を、NAT越え問題と対比して考える

SIProp
http://www.siprop.org/

今回紹介するSIPropとは、クライアント端末上でB2BUA（Back To Back User Agent）として動作し、各社SIP実装の違い（俗に言う「SIPの方言」）を吸収するオープンソースソフトウェアです。今年度の「未踏ソフトウェア創造事業」として採択され、現在開発が進められています。

クライアントサイドモジュール型 SIP-UAミドルウェア「SIProp」の開発(IPA 2006年度上期「未踏ソフト」採択概要)
http://www.ipa.go.jp/jinzai/esp/2006mito1/gaiyou/5-1.html

本提案では、現在世界的に問題となっているVoIP相互接続問題に対する解決案を提示し、さらに、それだけにとどまらず、その先のNGNやIMS、 FMCなどの将来のネットワークを見据えた拡張を行うことにより、長期にわたって使用可能なSIPミドルウェアを提案する。

本提案では、下記の特徴を持ったSIPアプリケーション開発用のミドルウェアを開発する。

• クライアントサイドで動作するB2BUAモジュール
• B2BUAの動作をモジュールにて定義可能なモデル
• SIPをHTTPのように、汎用的に扱うことを可能なモデル
• モバイル端末向けの実装

（「申請テーマ概要」より抜粋）

ちょうど最近、SIProp開発者の今村さんから直接お話を伺う機会があったのですが、そのお話を聞く限りでは、SIPropとは以下の図のように動作するソフトのようです（間違ってたらごめんなさい）。

こういう相互接続性の問題を目にすると、僕は、どうしても最初にNAT越え問題を連想してしまいます。まあ、過去にNAT越え問題を追っていたから、という単純な理由なんですけど……。

ただ、実際よく考えてみると、SIPの相互接続性問題とNAT越え問題を対比させることで、この問題の中でのSIPropの意義をうまく説明できる気がしてきました。そこで、今日はNAT越え問題の経緯を元に、僕が考えるSIPropの意義について説明してみたいと思います。

■ NAT越え問題の経緯

近年、NATを越えたP2P通信がうまくいかない理由……つまり、NATの奇妙な動作に関する理解が進むにつれて、NAT越え問題にもようやく進展が見られ始めました。以下は、その経緯に関する個人的な見解です。

まず、2002年頃に、それまでのNAT実装が4種類（Full Cone、Restricted Cone、Port Restricted Cone、Symmetric）に整理されました。これが2003年3月にSTUNのRFC（RFC3489）として公開されることで、専門家以外にも、NATの問題が共有されるようになります。

その後、STUNでは越えられないとされたSymmetric NATへの各種対策が各地で検討され、その中でNAT実装の整理も見直されていきます。この最新の整理は、ユニキャストUDPに対するNATの動作を標準化する文書NAT Behavioral Requirements for Unicast UDP（draft-ietf-behave-nat-udp）（リンク先はIETF Tools）の中に見ることができます。

ちなみに、最新の整理では、Cone NATやSymmetric NATという用語は既に廃止されていて、これらの動作は「Address and Port Mapping（インバウンドパケットに対する許可/拒否ルール）」や「Port Assignment Behavior（アウトバウンドパケットに対するポート番号の割り当てルール）」という用語に置き換えられています。また、宛先IPアドレスがプライベートIPアドレスの場合の動作（Hairpinning Behavior、パケットを折り返すかどうか）など、RFC3489の時点では考慮されていなかった問題も新たに登場しています。

このように、NAT実装の特徴が細かく整理されたことで、現在では複数ある実装パターンのどれが望ましいのかを具体的に議論できるようになりました。Behavior Engineering for Hindrance Avoidance (behave)ワーキンググループで議論されている上記のdraft-ietf-behave-nat-udpでは、それぞれの細かい仕様に"Justification"という項目が設けられて、「なぜその動作を標準とするのか」という理由がしっかりと記されています。

■ SIP実装の種類についても「仮の整理」が必要

上記のように、NAT越え問題の分野では、まずNAT実装の種類について仮の整理（Cone NATとか）が付いてから、それをベースとして議論が進み、複数の実装の違いを細かく比較できるようになってから、NAT自体の動作を標準化する方向に進んでいます。

これと同じように、SIPの相互接続性問題の分野でも、まずSIP実装の種類について仮の整理を付ける必要があるはずです。

実際、「SIPには方言がある」ということ自体は関係者の間で周知されていると思うのですが、僕みたいに「SIPがどんなものか何となく知っている」程度の人間には、具体的にどういう問題があるのかさっぱり分かってないのではないでしょうか。これでは、理想的な実装について議論できる人の数はかなり限られてしまいます。

そこで、このSIPropは、まさにこの「仮の整理」を付けるための枠組みとして理想的なアプローチになるのではないか……と僕は考えています。

SIPropでは各社のSIPメッセージを一度共通のSIPメッセージ（FlatSIP）に変換します。この変換部分がオープンソースのプログラム（モジュール）として記述されるため、そのソースコードを読めば、各実装の差異を誰でも詳しく知ることが出来るようになります。そのため、今後、各社仕様に合わせたSIPropのモジュールが充実していくにつれて、SIPのあるべき動作を標準化するための議論を行いやすくなっていくはずです。

■ 今後の展開について

以上のようなことから、今後SIPropが成功すれば、SIPの相互接続性問題に関する議論は一気に進むようになると思います。

ただ、個人的に不安……というかよく分からないのですが、各社のSIP実装の違いを本当にこのようなモジュールで吸収することができるのでしょうか？　基本的な機能は「IPアドレスとポート番号を変換する」くらいしか無いNATに比べて、SIPの仕様は非常に膨大です。

今村さんによると、SIPの仕様は、RFCにおいてStandardとされている方式だけでも以下の6つがあるそうです。参考までに、各RFCのページ数を括弧内に記載しておきます。

• RFC 3261, SIP: Session Initiation Protocol（269ページ）
• RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification（38ページ）
• RFC 3420, Internet Media Type message/sipfrag（8ページ）
• RFC 3515, The Session Initiation Protocol (SIP) Refer Method（23ページ）
• RFC 3891, The Session Initiation Protocol (SIP) "Replaces" Header（16ページ）
• RFC 3892, The Session Initiation Protocol (SIP) Referred-By Mechanism（25ページ）

NGN（Next Generation Network）のように既存の電話網をSIPで置き換えようという話になると、これに加えて更に仕様が増えていくわけで……。SIPropがうまく議論のための枠組みとして普及したとしても、その先は長い道のりになりそうです。

しかし、SIPの相互接続性問題を解決できなければ、いずれ「どこかのベンチャーが作ったスゴイIP電話アプリケーションの採用するプロトコルがいつの間にかデファクトになっていた」ということにもなりかねません。そうなっては困る人たちがSIPropに協力してくれれば、いろいろ面白いことが出来るようになると思うのですが……ともあれ今後のSIPropの活動は要注目です。

■ 参考

1週間ほど前のITProでも、ちょうどSIPropを取り上げていました。4ページに渡る詳細な記事ですので、SIPropについて更に詳しく知りたい方は、まずこちらをご覧になることをお勧めします。

SIP相互接続を実現する「SIProp」(ITpro)
http://itpro.nikkeibp.co.jp/article/COLUMN/20061108/253036/

■[VoIP]SIProp開発者の今村さんによる、SIP相互接続性問題の三分類

前回の日記で「SIPには方言があるっていうけど、具体的にどういう問題があるのかよく分からない」と書いていたところ、SIProp開発者の今村さんのブログでフォローがありました。

SIP相互接続問題のカテゴリー(なんとなく実験 with SIProp開発記)
http://www.noritsuna.com/archives/2006/11/sip_4.html

今村さんは、このエントリーでSIPの相互接続性問題を以下の3つの問題に分けて解説しています。

• トランザクション(SIPスタック)レベルの問題
• シーケンス(UA・機能)レベルの問題
• スペック(機能仕様)レベルの問題

詳しくは元エントリーの方を読んでもらうとして、この分類の面白いところは2番目の「シーケンスレベルの問題」と、3番目の「スペックレベルの問題」を切り分けているところだと思います。

最初にこの文章を読んだとき、僕はこの2番目と3番目の問題の区別がよく分からなかったのですが、文章をよく読んでみると

●シーケンス(UA・機能)レベルの問題
基本的に、RFCでは、トランザクションの定義はありますが、シーケンス(機能)に関する定義はありません。そのため、SIPをPBXのプロトコルとして使用する場合には、独自でシーケンス(機能)を定義する必要があるのです。

2番目のこれは、ある機能をどういうシーケンスで実現するか、という「実装の問題」で、

●スペック(機能仕様)レベルの問題
これは、プロトコル的には、シーケンス(UA・機能)レベルの問題と同じではあるのですが、UAとしては、影響が出るものなので、ここでは別としています。
こちらは、同じ名称でも、具体的には別物というものとなります。

たとえば、電話でよく使用される留守電機能(留守電シーケンス)があります。

• 家庭用電話機では、電話機自体に留守電を保存し、再生します。
• ケータイでは、キャリア側(サーバ側)に留守電を保持し、再生することもできます。
• PBXでは、留守電メッセージをMP3などに変換して、メールで送信する機能もあったりします。

というように、一口に「留守電機能」といっても、端末メーカーやPBXメーカーにより、スペック(機能仕様)自体が全く違っていたりするのです。

3番目のこれは、ある機能をどういう名称で呼ぶか、という「用語の問題」。基本的にSIPropが対処するのは「実装の問題」になるので、この切り分けを重視しているのかもしれません（上記の文章の「UAとしては、影響が出るもの」というあたりで）。

ただ、そう言っても、SIPropの活動がスペックレベルの問題を解決しないというわけではなくて……今後SIPropの活動の中でシーケンス（機能）がいろいろ定義されると、その用語を使ってスペックを明確に定義できるようになる（＝スペックレベルの問題が解決する）という効果も期待できます。スペックの定義が曖昧なためにシーケンスレベルでの違いがでてくる、ということは往々にしてあるわけですしね。