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

■[P2P][VoIP]P2P SIPに対するJ. Rosenberg氏のコメント

前回の日記を書くにあたって、個人的に参考になった文章を紹介しておきます。

IETFには、SIPの拡張について議論するSIPPING（Session Initiation Proposal Investigation）というワーキンググループがあります。そこのメーリングリストで、今年の1月末から2月にかけて

[Sipping] SIP P2P draft
http://www1.ietf.org/mail-archive/web/sipping/current/msg07401.html

To: sipping <sipping at ietf.org>
Subject: [Sipping] SIP P2P draft
From: Cullen Jennings <fluffy at cisco.com>
Date: Thu, 20 Jan 2005 21:51:22 -1000


David Bryan and I have submitted an draft of some early ideas on P2P with
SIP. Until it shows up in the repository, you can find it at

http://p2psip.org/

Cullen

というメール*1を発端にしたP2P SIPの要求に関する議論があったのですが、その議論に思いっきり冷や水を浴びせかけたJ. Rosenberg氏のコメントがそれです。この人は元dynamicsoftで今はCiscoに居る*2のですが、SIPやそれに関連したNAT越え関係のRFC、Internet Draftを数多く執筆しているパワフルなおじさんです。

そのメールの内容を訳してみた（かなり意訳含む）ので、以下に紹介しておきます。

Re: [Sipping] SIP P2P draft
http://www1.ietf.org/mail-archive/web/sipping/current/msg07440.html

To: Robert Sparks <rjsparks at nostrum.com>
Subject: Re: [Sipping] SIP P2P draft
From: Jonathan Rosenberg <jdrosen at cisco.com>
Date: Thu, 27 Jan 2005 19:00:13 -0500


I also appreciate this work, and think it is worth continuing discussion
on documentation on the subject.

私もこの仕事を高く評価するし、このテーマに関する文書について議論を続けるの
は価値あることだと考える。

Robert lists potential requirements below. However, I don't see them as
requirements per se; mostly they seemed like questions around how a
particular problem is addressed when building a p2p network.

Robertは潜在的な要求を下のメールで列挙している。しかし、私にはこれらが本質
的な要求には見えない――そのほとんどは、P2Pネットワークを構築する際に特有
の問題をどのように解決するか、についての質問のように見える。

The real requirements question is whether our aim is to build p2p just for
sip, or to build a generic p2p protocol (i.e., an implementation of chord
and bootstrapping techniques) that provide a generic p2p service. In
particular, one might imagine a protocol that effectively exposes an API
on participating hosts which, given a resource name, a hashing mechanism,
and a p2p system ID (i.e., which p2p network), it returns the IP address
of the place where that resource can be found. Such a generic protocol
would support joins, leaves, and so on. From my brief reading on p2p
literature it seems like this decomposition is common.

要求に関する本当の論点は、我々の目的がSIPだけのためのP2Pを構築することなの
か、それとも一般的なP2Pプロトコル（すなわち、Chordの実装と、ブートストラッ
プのテクニック）を構築することなのか、である。特に、後者なら参加ホストへ効
果的にAPIを公開するプロトコルを想像できる。ここで言うAPIとは特に、リソース
名、ハッシュのメカニズムそしてP2PシステムID（すなわちP2Pネットワーク）を与
えられると、そのリソースの存在する場所のIPアドレスを返すようなものである。
そのような汎用プロトコルは参加や離脱などをサポートするだろう。私がP2Pに関
する文献を簡単に読んだ限り、この分析は一般的であるように思える。

In essence, is the goal to build a generic, standardized p2p toolkit ontop
of which we can build lots of p2p applications, or is it just to make sip
p2p and do it in a sip specific way?

本質において、多くのP2Pアプリケーションの土台として利用できる汎用的で標準
化されたP2Pツールキットを作ることが目的なのか、それともSIP P2Pを作ってそれ
をSIP特有の方法で利用することが目的なのか？

I will note that, even once you have developed such a toolkit, serious
questions remain about how it could be used by SIP for the purposes of
building a p2p network. The primary issue is security, of course. SIP
specifies its behaviors logically speaking; a proxy is just a role, and it
runs on a host at a specific IP address. Same with registrars, presence
servers, etc. If you envision that the p2p protocol effectively provides
an alternative to DNS - a way to find my proxy, or find my presence server
- then we could make SIP p2p by just replacing rfc3263 with that
mechanism.

そのようなツールキットを一旦開発しさえすれば、「P2Pネットワークを構築する
ためにそれをSIPでどう利用するか」という深刻な問題だけが残る、ということに
注意すること。当然、第一の問題はセキュリティだ。SIPはその振る舞いを明確に
している。プロクシは単なる機能で、特定のIPアドレスを持つホスト上で動作する。
レジストラや、プレゼンスサーバなども同様である。P2Pプロトコルが（プロクシ
やプレゼンスサーバを見つけるための方法である）DNSの代替を効果的に提供する
とすれば、我々はRFC3263をそのメカニズムで置き換えるだけでSIP P2Pを作ること
ができるだろう。

But it wouldn't work, of course. The reason is entirely security. SIP
assumes a trust relationship that has proxies and presence servers as
privileged systems - ones that users implicitly trust. p2p breaks
that. Thus, the challenge is entirely how to adapt sip to trust models
whereby the provider is an untrusted element by the user. Such an
"extension" to address doing that might even be useful in systems where
the server is still centrally located via DNS - for example a sip proxy
run by a coffee shop I happen to step into. Why should I trust them?

しかし、それはもちろん動作しないだろう。原因は全てセキュリティだ。SIPは特
権システムとしてのプロクシやプレゼンスサーバが持つ信頼関係を前提にしている。
そして、ユーザはそれらのサーバを無条件に信頼しているが、P2Pはその前提を破
壊してしまう。従って、課題はもっぱら、ユーザによる信頼できない要素が提供者
となる信頼モデルに対してどのようにSIPを適用するかということになる。そのよ
うな「拡張」は、サーバがまだ集中的に（DNSによって）配置されているシステム
――例えば、私がたまたま立ち寄ったコーヒーショップで動作するSIPプロクシ―
―でさえ使えるかもしれない。何故、私はそれらを信頼すべきなのだ？

A fair question to ask is whether certain features we want (like dialing
911 or protecting presence data from prying eyes) can ever reasonably be
accomplished in the differing trust models provided by p2p systems.

尋ねるべきもっともな質問とは、我々が求める特定の機能（緊急通報、またはプレ
ゼンスデータをのぞき見から守ること）はP2Pシステムによって提供されるものと
は異なる信頼モデルの上でしか成し遂げられないのか？ということである。

One of the big technical issues is NAT traversal. I think that is actually
not so hard. We have all of the tools already - ICE in particular is a p2p
traversal technique. ICE relies on STUN and TURN. Currently, it assumes
that the STUN and TURN servers are centralized. But, they need not
be. Instead, we could have them as peer components, and we use the p2p
network to locate those too. There, finding them is interesting. The
requirement is that you can be a TURN or STUN server if you are on the
public Internet. Thus, its not really a search for a single resource by
name, but rather a search for any resource with a particular property. Not
sure how that could be done in chord, worth considering some more.

大きな技術課題の1つはNAT越えである。私は、これは実際のところそれほど難しく
ないと考える。我々は既に全てのツールを持っている――特にICEはP2PのNAT越え
技術である。ICEはSTUNとTURNに依存する。現在のところ、STUNとTURNは集中化さ
れたサーバを前提としているが、必ずしもその必要はない。代わりにそれらをピア
のコンポーネントとして備え、我々はそれらを見つけるためにP2Pネットワークを
利用することもできる。つまり要求は、名前によって単一のリソースを探すこと
ではなく、むしろ特定の特性（STUNやTURNサーバとしての機能）を持つリソースを
探すことになる。それがChordによってどのように実現できるかは定かでないが、
もう少し考える価値がある。

（後略）

[文中で触れているRobert氏のメールはRe: [Sipping] SIP P2P draftを参照]

そして、（長いので省略しましたけど）Rosenberg氏は最後に、グローバルIPアドレスを持たないピアがChordに参加するためには、TURNサーバからグローバルIPアドレスとポートの組を取得して、Chordの識別子として用いることができるだろう……と述べています。

要するに「P2P SIPなんて言ってないで、リアルタイムコミュニケーション向けのP2Pプロトコル/ツールキットを作ればいいじゃねえかよ。まぁ、どっちにしろセキュリティが問題だけど」という話で、僕もこれに同意するんですけど、一方で「SIPを旗頭にすればとりあえず注目が集まるよ（今更P2Pフレームワークも無いだろ）」という現実も確かにあるわけで……。

■[P2P][VoIP]P2P SIP用組み込みソフトウェアNimX

Nimcat Networks Inc.
http://www.nimcatnetworks.com/

世の中には既にこんなものがあって、このソフトウェアを組み込んだ電話機がつい最近発売になったそうです。

Nimcat Networks Inc. - PRESS RELEASES
http://www.nimcatnetworks.com/Reading.aspx?fid=46&ftype=1

TORONTO (March 14, 2005) - Aastra Technologies Limited (TSX: AAH), a leader in enterprise communication access products, extended its industry leadership today with the launch of VentureIP(TM) the first enterprise-class, P2P (peer-to-peer) IP-based phone system. Powered by Nimcat Networks’ nimX software, the system enables small to-medium business (SMBs) to install, operate and manage a full-featured phone system by simply plugging the VentureIP 480i telephone into their local area network (LAN). The system scales on a phone by phone basis and can be connected to the local PSTN via the VentureIP Gateway.

中小企業向けにP2P SIPによるIP電話を実現し、従来のPSTNにはIPセントレックス方式で通話を実現するサービスを提供しています（参考：PEER TELEPHONY EXCHANGE (PTX)）。どこまでSIPを標準的に使っているのかまだよくわからないですが、ここの社員が書いているInternet Draftがあったのでそのうち読んでみます。

Industrial-Strength P2P SIP
http://www.ietf.org/internet-drafts/draft-matthews-sipping-p2p-industrial-strength-00.txt

（2005/08/21追記）
後日詳しく調べてみたところ、これはP2P技術を用いたVoIPミドルウェアがSIPにも対応しているだけのようです。P2P SIPと呼んでしまったのは早とちりでした。申し訳ありません。

NimXについては、詳細が分かり次第またここで取り上げます。