今、はやりのSIPサーバですが、解説書などによりますと、このサーバでＰ２Ｐを 実現することがかかれています。通常はこのサーバが２点のコネクションを制御するようですが、アドレス（IPとポート番号）があれば直接クライアントから接続さきのクライアント向けのパケットを発信して、呼制御してもよさそうな気がしますが、そのようのなっていない理由は何なのでしょうか。その方がよりＰ２Ｐという気がします。よろしくご回答ください。
米田さん，はじめまして。
私は，SIPについてあまり詳しくないので，はっきりしたことはわかりません。
RFCをチラっと眺めてみた限りでは， SIPのサーバっていうのは， いわゆるWebサーバのようなサーバマシンを指すのではなく， 接続先のマシン（電話 or コンピュータ ？）の中にある一つの機能， つまり，SIPのリクエストを受け付ける機能 を指しているように思えます。 つまり，SIPに対応する機器は，クライアントとサーバの機能を両方持っていて， 自分から他のマシンを呼び出すときは，クライアント機能を使って， 相手のサーバ機能にリクエストを送り， 逆に，相手から呼び出しを受けたときは，サーバ機能でリクエストを受け取る， っていうことなんじゃないのかしら。
間違っていたらゴメンナサイ。
>米田さん，はじめまして。 > >私は，SIPについてあまり詳しくないので，はっきりしたことはわかりません。 > >RFCをチラっと眺めてみた限りでは， >SIPのサーバっていうのは， >いわゆるWebサーバのようなサーバマシンを指すのではなく， >接続先のマシン（電話 or コンピュータ ？）の中にある一つの機能， >つまり，SIPのリクエストを受け付ける機能 >を指しているように思えます。 >つまり，SIPに対応する機器は，クライアントとサーバの機能を両方持っていて， >自分から他のマシンを呼び出すときは，クライアント機能を使って， >相手のサーバ機能にリクエストを送り， >逆に，相手から呼び出しを受けたときは，サーバ機能でリクエストを受け取る， >っていうことなんじゃないのかしら。 > >間違っていたらゴメンナサイ。
そのようなのですが、日経コミュニケーション2002.4.1のIP電話の記事では、多数の端末がつながるSIP電話網では、SIPサーバが存在し、そこでクライアントのIPアドレス、ポート番号等を管理し、端末間の呼制御をそのサーバが行うようにかかれています。そこで、疑問になるのが、端末間でサーバ機能、クライアント機能があるのであれば、SIPサーバから接続のためのIPアドレスとポート番号だけをもらって、呼び出しを開始する端末から、直接接続した方がSIPサーバの負荷がへるように思うのですが、なぜそのようのなっていないのかなという疑問なんです。アドレスを統括的に管理するサーバがあるのはモバイルやNAT越えの要求から、必須であるような気がするのですが、それはあくまでもアドレス（IPとポート番号）の管理のためだけのようなのに、なぜ呼の制御までサーバが面倒をみるのか？なぜなのでしょうか？コメントいただければたすかります。よろしくお願いします。
SIPのサーバには，次の3種類があるようです。 （この他にもロケーションサーバとかいろいろなものが登場しますが．．．） ・リクエストを受け付けるサーバ ・リクエストを他のサーバに転送するプロキシーサーバ ・別のサーバにリクエストし直すよう促すリディレクトサーバ あまり詳しくRFCを読んでいないのですが， この三つは，状況に応じて使い分けできるのだと思います。 だから，米田さんのおっしゃるように 接続相手のアドレスがわかっている状況なら， そこに直接接続して，リクエストを送れるのだと思います。 ただ，相手のIPアドレスがわからない状況だと， プロキシーサーバやリディレクトサーバがあると便利ですから， 多分，そうした仕組みを使うのだと思います。
SIPの仕様は，そうした役割や機能を サーバとして定義しているだけなのに対して， 日経コミュニケーションの記事は， プロキシーサーバとリディレクトサーバ機能を持った サーバマシンを用いたシステムを想定して， SIPの動きを説明しているようです。 で，そこには，米田さんが疑問に思った， 相手に直接接続する，という一番シンプルな形態が抜けている， ということだと思います。
雑誌のように，限られたページ数で解説する場合には， このように，ある局面だけ取り出して説明する， という手法を使いますし，ページ数の制約を考えると， それはそれで有効な手法なのですが， 必ずしも全体像を表すものではありません。 だから，米田さんのような疑問が湧いてくるのは当然のことですし， 疑問が湧いてくることが正しく理解している証だと思います。
そうした疑問を解決するには，もっと多く情報を収集して 物事の真相に迫るしかないですね。 まあ，TCP/IPの世界なら，そんな大仰なことをいわなくても， RFCを眺めてみれば済むだけですけど。
的確なご指摘ありがとうございました。RFCも含めていろいろ調べてみます。 日経の記事をかかれた方にも聞いてみるのもいいかと考えています。ありがとうございました。 ちなみに、私は、戸根さんのTCP/IPの解説書を読んでいます。参考になります。 今後とも、よろしくご指導ください。
コメント
SIP機器はクライアント機能とサーバ機能の両方持っているっていうこと？
米田さん，はじめまして。
私は，SIPについてあまり詳しくないので，はっきりしたことはわかりません。
RFCをチラっと眺めてみた限りでは，
SIPのサーバっていうのは，
いわゆるWebサーバのようなサーバマシンを指すのではなく，
接続先のマシン（電話 or コンピュータ ？）の中にある一つの機能，
つまり，SIPのリクエストを受け付ける機能
を指しているように思えます。
つまり，SIPに対応する機器は，クライアントとサーバの機能を両方持っていて，
自分から他のマシンを呼び出すときは，クライアント機能を使って，
相手のサーバ機能にリクエストを送り，
逆に，相手から呼び出しを受けたときは，サーバ機能でリクエストを受け取る，
っていうことなんじゃないのかしら。
間違っていたらゴメンナサイ。
Re SIP機器はクライアント機能とサーバ機能の両方持っているっていうこと？
>米田さん，はじめまして。
>
>私は，SIPについてあまり詳しくないので，はっきりしたことはわかりません。
>
>RFCをチラっと眺めてみた限りでは，
>SIPのサーバっていうのは，
>いわゆるWebサーバのようなサーバマシンを指すのではなく，
>接続先のマシン（電話 or コンピュータ ？）の中にある一つの機能，
>つまり，SIPのリクエストを受け付ける機能
>を指しているように思えます。
>つまり，SIPに対応する機器は，クライアントとサーバの機能を両方持っていて，
>自分から他のマシンを呼び出すときは，クライアント機能を使って，
>相手のサーバ機能にリクエストを送り，
>逆に，相手から呼び出しを受けたときは，サーバ機能でリクエストを受け取る，
>っていうことなんじゃないのかしら。
>
>間違っていたらゴメンナサイ。
そのようなのですが、日経コミュニケーション2002.4.1のIP電話の記事では、多数の端末がつながるSIP電話網では、SIPサーバが存在し、そこでクライアントのIPアドレス、ポート番号等を管理し、端末間の呼制御をそのサーバが行うようにかかれています。そこで、疑問になるのが、端末間でサーバ機能、クライアント機能があるのであれば、SIPサーバから接続のためのIPアドレスとポート番号だけをもらって、呼び出しを開始する端末から、直接接続した方がSIPサーバの負荷がへるように思うのですが、なぜそのようのなっていないのかなという疑問なんです。アドレスを統括的に管理するサーバがあるのはモバイルやNAT越えの要求から、必須であるような気がするのですが、それはあくまでもアドレス（IPとポート番号）の管理のためだけのようなのに、なぜ呼の制御までサーバが面倒をみるのか？なぜなのでしょうか？コメントいただければたすかります。よろしくお願いします。
雑誌の解説に全部を期待するのは無理があるのでは．．．
SIPのサーバには，次の3種類があるようです。
（この他にもロケーションサーバとかいろいろなものが登場しますが．．．）
・リクエストを受け付けるサーバ
・リクエストを他のサーバに転送するプロキシーサーバ
・別のサーバにリクエストし直すよう促すリディレクトサーバ
あまり詳しくRFCを読んでいないのですが，
この三つは，状況に応じて使い分けできるのだと思います。
だから，米田さんのおっしゃるように
接続相手のアドレスがわかっている状況なら，
そこに直接接続して，リクエストを送れるのだと思います。
ただ，相手のIPアドレスがわからない状況だと，
プロキシーサーバやリディレクトサーバがあると便利ですから，
多分，そうした仕組みを使うのだと思います。
SIPの仕様は，そうした役割や機能を
サーバとして定義しているだけなのに対して，
日経コミュニケーションの記事は，
プロキシーサーバとリディレクトサーバ機能を持った
サーバマシンを用いたシステムを想定して，
SIPの動きを説明しているようです。
で，そこには，米田さんが疑問に思った，
相手に直接接続する，という一番シンプルな形態が抜けている，
ということだと思います。
雑誌のように，限られたページ数で解説する場合には，
このように，ある局面だけ取り出して説明する，
という手法を使いますし，ページ数の制約を考えると，
それはそれで有効な手法なのですが，
必ずしも全体像を表すものではありません。
だから，米田さんのような疑問が湧いてくるのは当然のことですし，
疑問が湧いてくることが正しく理解している証だと思います。
そうした疑問を解決するには，もっと多く情報を収集して
物事の真相に迫るしかないですね。
まあ，TCP/IPの世界なら，そんな大仰なことをいわなくても，
RFCを眺めてみれば済むだけですけど。
ご回答ありがとうございます。
的確なご指摘ありがとうございました。RFCも含めていろいろ調べてみます。
日経の記事をかかれた方にも聞いてみるのもいいかと考えています。ありがとうございました。
ちなみに、私は、戸根さんのTCP/IPの解説書を読んでいます。参考になります。
今後とも、よろしくご指導ください。