(57)【要約】【課題】プロキシサーバにおいてアプリケーションの識別を行い、各アプリケーションに対応したシグナリング処理を行う。【解決手段】識別情報取得部１０３は、通信部１０２で受信したアプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩがリクエストラインに記述されたメッセージから、アプリケーションの識別情報を取得する。アプリケーションの識別情報と、そのアプリケーションの識別情報を受信した場合の処理は、メモリ１０１に関連付けられて記憶されており、処理実行部１０４は、識別情報取得部１０３で取得したアプリケーションの識別情報に対応する処理を、メモリ１０１から読み出して実行する。【選択図】図１
2007201563.tif 000002
【特許請求の範囲】
【請求項１】
ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて通信の確立を行う第１の通信端末および第２の通信端末と、前記第１および第２の通信端末のＳＩＰアドレスを、それらの通信端末のＩＰアドレスと関連づけて記憶するロケーションサーバと接続可能なプロキシサーバであって、
アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）がリクエストラインに記述されたメッセージを受信した場合に行う処理とを関連づけて記憶する記憶手段と、
前記第１の通信端末から、第１のアプリケーションの識別情報と前記第２の通信端末のＳＩＰアドレスとを含むＳＩＰ  ＵＲＩがリクエストラインに記述された第１のメッセージを受信する手段と、
前記受信した第１のメッセージから前記第１のアプリケーションの識別情報を取得する識別情報取得手段と、
前記取得した第１のアプリケーションの識別情報に対応する処理を前記記憶手段から読み出して実行する処理実行手段と、
前記受信した第１のメッセージから前記第２の通信端末のＳＩＰアドレスを取得するＳＩＰアドレス取得手段と、
前記取得した第２の通信端末のＳＩＰアドレスに対応する前記第２の通信端末のＩＰアドレスを前記ロケーションサーバから取得するＩＰアドレス取得手段と、
前記取得した第２の通信端末のＩＰアドレスを用いて前記第２の通信端末に前記第１のメッセージを送信する送信手段と
を備えることを特徴とするプロキシサーバ。
【請求項２】
ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて通信の確立を行う第１の通信端末および第２の通信端末と、前記第１および第２の通信端末のＳＩＰアドレスを、それらの通信端末のＩＰアドレスと関連づけて記憶するロケーションサーバと、アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）がリクエストラインに記述されたメッセージを受信した場合に行う処理とを関連づけて記憶する記憶サーバと接続可能なプロキシサーバであって、
前記第１の通信端末から、第１のアプリケーションの識別情報と前記第２の通信端末のＳＩＰアドレスとを含むＳＩＰ  ＵＲＩがリクエストラインに記述された第１のメッセージを受信する手段と、
前記受信した第１のメッセージから前記第１のアプリケーションの識別情報を取得する識別情報取得手段と、
前記取得した第１のアプリケーションの識別情報に対応する処理を前記記憶サーバから読み出して実行する処理実行手段と、
前記受信した第１のメッセージから前記第２の通信端末のＳＩＰアドレスを取得するＳＩＰアドレス取得手段と、
前記取得した第２の通信端末のＳＩＰアドレスに対応する前記第２の通信端末のＩＰアドレスを前記ロケーションサーバから取得するＩＰアドレス取得手段と、
前記取得した第２の通信端末のＩＰアドレスを用いて前記第２の通信端末に前記第１のメッセージを送信する送信手段と
を備えることを特徴とするプロキシサーバ。
【請求項３】
前記第１の通信端末との間で送受信されるメッセージのリクエストラインにおけるＳＩＰ  ＵＲＩの第１の記述方法を前記ロケーションサーバから取得する手段をさらに備え、
前記識別情報取得手段および前記ＳＩＰアドレス取得手段は、前記ロケーションサーバから取得した第１の記述方法に基づいて前記第１のメッセージから前記第１のアプリケーションの識別情報または前記第２の通信端末のＳＩＰアドレスを取得する
ことを特徴とする請求項１または請求項２に記載のプロキシサーバ。
【請求項４】
前記第２の通信端末との間で送受信されるメッセージのリクエストラインにおけるＳＩＰ  ＵＲＩの第２の記述方法を前記ロケーションサーバから取得する手段と、
前記第１のメッセージのリクエストラインにおけるＳＩＰ  ＵＲＩの記述方法を前記ロケーションサーバから取得した第２の記述方法に変換する変換手段とをさらに備え、
前記送信手段は、前記変換手段によってＳＩＰ  ＵＲＩが前記第２の記述方法に変換された第２のメッセージを前記第２の通信端末へ送信する
ことを特徴とする請求項１または請求項２に記載のプロキシサーバ。
【請求項５】
前記送信手段は、メッセージを保存する保存サーバに前記第１のメッセージを送信する機能をさらに有し、
前記記憶手段は、前記第１の通信端末から前記第２の通信端末に対して音声通話を要求する第２のアプリケーションの識別情報と、前記ＩＰアドレス取得手段により前記第２の通信端末のＩＰアドレスを取得できない場合に、前記第１のメッセージを前記保存サーバへ送信するように前記送信手段を制御する第１の処理とを関連づけて記憶し、
前記処理実行手段は、前記識別情報取得手段で取得したアプリケーションの識別情報が前記第１の通信端末から前記第２の通信端末に対して音声通話を要求する前記第２のアプリケーションの識別情報である場合に、前記記憶手段から前記第１の処理を読み出して実行する
ことを特徴とする請求項１に記載のプロキシサーバ。
【請求項６】
前記送信手段は、プレゼンスサーバに前記第１のメッセージを送信する機能をさらに有し、
前記記憶手段は、前記第１の通信端末から前記第２の通信端末に対してプレゼンス情報の更新を要求する第３のアプリケーションの識別情報と、前記第１のメッセージを前記プレゼンスサーバに送信するように前記送信手段を制御する第２の処理とを関連づけて記憶し、
前記処理実行手段は、前記識別情報取得手段で取得したアプリケーションの識別情報が前記第１の通信端末から前記第２の通信端末に対してプレゼンス情報の更新を要求する前記第３のアプリケーションの識別情報である場合に、前記記憶手段から前記第２の処理を読み出して実行する
ことを特徴とする請求項１に記載のプロキシサーバ。
【請求項７】
前記記憶手段は、第４のアプリケーションの識別情報と、前記第１のメッセージを前記第２の通信端末へ送信することを拒否するメッセージを前記第１の通信端末に送信するように前記送信手段を制御する第３の処理とを関連づけて記憶し、
前記処理実行手段は、前記識別情報取得手段で取得したアプリケーションの識別情報が前記第４のアプリケーションの識別情報である場合に、前記記憶手段から前記第３の処理を読み出して実行する
ことを特徴とする請求項１に記載のプロキシサーバ。
【請求項８】
ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて通信の確立を行う第１の通信端末および第２の通信端末と、前記第１および第２の通信端末のＳＩＰアドレスを、それらの通信端末のＩＰアドレスと関連づけて記憶するロケーションサーバと接続可能なプロキシサーバの制御方法であって、
前記第１の通信端末から、第１のアプリケーションの識別情報と前記第２の通信端末のＳＩＰアドレスとを含むＳＩＰ  ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）がリクエストラインに記述された第１のメッセージを受信し、
前記受信した第１のメッセージから前記第１のアプリケーションの識別情報を取得し、
アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩがリクエストラインに記述されたメッセージを受信した場合に行う処理とを関連づけて記憶する記憶手段から前記取得した第１のアプリケーションの識別情報に対応する処理を読み出して実行し、
前記受信した第１のメッセージから前記第２の通信端末のＳＩＰアドレスを取得し、
前記取得した第２の通信端末のＳＩＰアドレスに対応する前記第２の通信端末のＩＰアドレスを前記ロケーションサーバから取得し、
前記取得した第２の通信端末のＩＰアドレスを用いて前記第２の通信端末に前記第１のメッセージを送信する
ことを特徴とするプロキシサーバの制御方法。
【請求項９】
ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて通信の確立を行う第１の通信端末および第２の通信端末と、前記第１および第２の通信端末のＳＩＰアドレスを、それらの通信端末のＩＰアドレスと関連づけて記憶するロケーションサーバと接続可能なプロキシサーバの制御プログラムであって、
コンピュータに、
前記第１の通信端末から、第１のアプリケーションの識別情報と前記第２の通信端末のＳＩＰアドレスとを含むＳＩＰ  ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）がリクエストラインに記述された第１のメッセージを受信する機能と、
前記受信した第１のメッセージから前記第１のアプリケーションの識別情報を取得する機能と、
アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩがリクエストラインに記述されたメッセージを受信した場合に行う処理とを関連づけて記憶する記憶手段から前記取得した第１のアプリケーションの識別情報に対応する処理を読み出して実行する機能と、
前記受信した第１のメッセージから前記第２の通信端末のＳＩＰアドレスを取得する機能と、
前記取得した第２の通信端末のＳＩＰアドレスに対応する前記第２の通信端末のＩＰアドレスを前記ロケーションサーバから取得する機能と、
前記取得した第２の通信端末のＩＰアドレスを用いて前記第２の通信端末に前記第１のメッセージを送信する機能と
を実現させることを特徴とするプロキシサーバの制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロキシサーバ、プロキシサーバの制御方法およびプロキシサーバの制御プログラムに係わり、特にＳＩＰ  ＵＲＩにアプリケーションの識別情報が含まれるメッセージを受信して通信端末間の通信の制御を行うことを可能にしたプロキシサーバ、プロキシサーバの制御方法およびプロキシサーバの制御プログラムに関する。
【背景技術】
【０００２】
従来、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）は、双方向の音声通信を２つの通信端末（ＳＩＰ−ＵＡ：Ｕｓｅｒ  Ａｇｅｎｔ、以下、ＵＡと呼ぶ）間で確立・制御するために用いられてきた（例えば、非特許文献１を参照）。ＳＩＰプロキシサーバは、２つのＵＡ間の通信メッセージの送受信を中継する働きをするサーバである。ＳＩＰによって制御されるＵＡ間のデータ送受信の関係は「セッション」と呼ばれ、この際に行われる通信の制御は「シグナリング」と呼ばれる。ＳＩＰにしたがって確立した通信において送受信されるデータは、上述したように音声データが代表的であるが、本来ＳＩＰは２つのＵＡ間のセッションを制御するための汎用プロトコルであり、通信の対象となるデータは音声に限られない。すなわち、送受信されるデータは、映像データや通信機器の遠隔制御のためのデータ、あるいは、ＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）接続のためのデータなどであってもよい。
【０００３】
ＳＩＰではＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いてセッションで使われる音声・映像コーデック、トランスポート層プロトコルなどを記述し、ＵＡが相互に使用する通信内容を特定する方法がとられている（例えば、非特許文献２を参照）。しかし、ＳＤＰは、音声・映像以外のデータが送受信される通信を特定するための記述能力が不十分であるため、音声・映像以外のデータが通信の対象となる場合には、通信内容の詳細を特定することができないという問題がある。なお、通信内容の詳細によって決まる特定の種類のセッションは、ＵＡ上の「アプリケーション」と呼ばれる。
【０００４】
例えば、家電遠隔制御とビデオ録画予約というアプリケーションでは、いずれもＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いた通信が行われるが、ＨＴＴＰ上でやりとりされる情報の内容や書式などのパラメータは、家電遠隔制御とビデオ録画予約とでは、それぞれ異なっている。しかし、ＳＩＰとＳＤＰを組み合わせて、これらの２つの通信の制御を行う場合、ＳＤＰでは、通信がＨＴＴＰを用いて行われること以上の詳細な記述ができないため、ＳＤＰを用いて、これらのアプリケーションを区別することはできなかった。そのため、ＳＩＰプロキシサーバにおいて、家電遠隔制御とビデオ録画予約とで異なるシグナリング処理を行うことができなかった（例えば、非特許文献３を参照）。
【非特許文献１】ＲＦＣ３２６１，  Ｒｏｓｅｎｂｅｒｇ，Ｊ．，  Ｓｃｈｕｌｚｒｉｎｎｅ，Ｈ．，  Ｃａｍａｒｉｌｌｏ，Ｇ．，  Ｊｏｈｎｓｔｏｎ，Ａ．，  Ｐｅｔｅｒｓｏｎ，Ｊ．，  Ｓｐａｒｋｓ，Ｒ．，  Ｈａｎｄｌｅｙ，Ｍ．  ａｎｄ  Ｅ．Ｓｃｈｏｏｌｅｒ，  “ＳＩＰ：Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ”，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ），  Ｊｕｎｅ  ２００２．
【非特許文献２】ＲＦＣ２３２７，  Ｈａｎｄｌｅｙ，Ｍ．  ａｎｄ  Ｖ．Ｊａｃｏｂｓｏｎ，  “ＳＤＰ：Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ”，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ），  Ａｐｒｉｌ  １９９８．
【非特許文献３】ＲＦＣ３２６４，  Ｒｏｓｅｎｂｅｒｇ，Ｊ．  ａｎｄ  Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，  “Ａｎ  Ｏｆｆｅｒ／Ａｎｓｗｅｒ  Ｍｏｄｅｌ  ｗｉｔｈ  ｔｈｅ  Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＳＤＰ）”，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ），  Ｊｕｎｅ  ２００２．
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述したように、ＳＩＰとＳＤＰを組み合わせてアプリケーションを識別する方法では、ＳＤＰのアプリケーション記述能力が不十分であるためにアプリケーションを識別することができない場合があった。そのため、ＳＩＰプロキシサーバにおいて、各アプリケーションに対応したシグナリング処理を行うことができない、という問題があった。
【０００６】
本発明は、上記従来技術の問題点を解決するためになされたものであって、プロキシサーバにおいてアプリケーションの識別を行い、各アプリケーションに対応したシグナリング処理を行うことを可能とするプロキシサーバ、プロキシサーバの制御方法およびプロキシサーバの制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明のプロキシサーバは、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて通信の確立を行う第１の通信端末および第２の通信端末と、前記第１および第２の通信端末のＳＩＰアドレスを、それらの通信端末のＩＰアドレスと関連づけて記憶するロケーションサーバと接続可能なプロキシサーバであって、アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）がリクエストラインに記述されたメッセージを受信した場合に行う処理とを関連づけて記憶する記憶手段と、前記第１の通信端末から、第１のアプリケーションの識別情報と前記第２の通信端末のＳＩＰアドレスとを含むＳＩＰ  ＵＲＩがリクエストラインに記述された第１のメッセージを受信する手段と、前記受信した第１のメッセージから前記第１のアプリケーションの識別情報を取得する識別情報取得手段と、前記取得した第１のアプリケーションの識別情報に対応する処理を前記記憶手段から読み出して実行する処理実行手段と、前記受信した第１のメッセージから前記第２の通信端末のＳＩＰアドレスを取得するＳＩＰアドレス取得手段と、前記取得した第２の通信端末のＳＩＰアドレスに対応する前記第２の通信端末のＩＰアドレスを前記ロケーションサーバから取得するＩＰアドレス取得手段と、前記取得した第２の通信端末のＩＰアドレスを用いて前記第２の通信端末に前記第１のメッセージを送信する送信手段とを備えることを特徴とする。
【０００８】
また、本発明のプロキシサーバの制御方法は、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて通信の確立を行う第１の通信端末および第２の通信端末と、前記第１および第２の通信端末のＳＩＰアドレスを、それらの通信端末のＩＰアドレスと関連づけて記憶するロケーションサーバと接続可能なプロキシサーバの制御方法であって、前記第１の通信端末から、第１のアプリケーションの識別情報と前記第２の通信端末のＳＩＰアドレスとを含むＳＩＰ  ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）がリクエストラインに記述された第１のメッセージを受信し、前記受信した第１のメッセージから前記第１のアプリケーションの識別情報を取得し、アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩがリクエストラインに記述されたメッセージを受信した場合に行う処理とを関連づけて記憶する記憶手段から前記取得した第１のアプリケーションの識別情報に対応する処理を読み出して実行し、前記受信した第１のメッセージから前記第２の通信端末のＳＩＰアドレスを取得し、前記取得した第２の通信端末のＳＩＰアドレスに対応する前記第２の通信端末のＩＰアドレスを前記ロケーションサーバから取得し、前記取得した第２の通信端末のＩＰアドレスを用いて前記第２の通信端末に前記第１のメッセージを送信することを特徴とする。
【０００９】
また、本発明のプロキシサーバの制御プログラムは、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて通信の確立を行う第１の通信端末および第２の通信端末と、前記第１および第２の通信端末のＳＩＰアドレスを、それらの通信端末のＩＰアドレスと関連づけて記憶するロケーションサーバと接続可能なプロキシサーバの制御プログラムであって、コンピュータに、前記第１の通信端末から、第１のアプリケーションの識別情報と前記第２の通信端末のＳＩＰアドレスとを含むＳＩＰ  ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）がリクエストラインに記述された第１のメッセージを受信する機能と、前記受信した第１のメッセージから前記第１のアプリケーションの識別情報を取得する機能と、アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩがリクエストラインに記述されたメッセージを受信した場合に行う処理とを関連づけて記憶する記憶手段から前記取得した第１のアプリケーションの識別情報に対応する処理を読み出して実行する機能と、前記受信した第１のメッセージから前記第２の通信端末のＳＩＰアドレスを取得する機能と、前記取得した第２の通信端末のＳＩＰアドレスに対応する前記第２の通信端末のＩＰアドレスを前記ロケーションサーバから取得する機能と、前記取得した第２の通信端末のＩＰアドレスを用いて前記第２の通信端末に前記第１のメッセージを送信する機能とを実現させることを特徴とする。
【発明の効果】
【００１０】
本発明の実施形態に係わるプロキシサーバによれば、アプリケーションの識別情報が宛先ＳＩＰ  ＵＲＩに含まれるメッセージを受信し、そのＳＩＰ  ＵＲＩからアプリケーションの識別情報を取得することで、アプリケーションごとのシグナリング処理を行うことが可能となる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施形態について説明する。
【００１２】
（第１の実施形態）
図１は、本発明の第１の実施形態に係わるＳＩＰプロキシサーバ１００を示すブロック図である。
【００１３】
この第１の実施形態に係わるＳＩＰプロキシサーバ１００は、アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩがリクエストラインに記述されたメッセージを受信した場合に行う処理とを関連づけて記憶するメモリ１０１と、ネットワークを介して他の通信端末やサーバなどとデータの送受信を行う通信部１０２と、通信部１０２で受信したメッセージからアプリケーションの識別情報を取得する識別情報取得部１０３と、識別情報取得部１０３で取得されたアプリケーションの識別情報に対応する処理をメモリ１０１から読み出して実行する処理実行部１０４と、通信部１０２で受信したメッセージから通信対象となる通信端末のＳＩＰアドレスを取得するＳＩＰアドレス取得部１０５と、ＳＩＰアドレス取得部１０５で取得したＳＩＰアドレスに対応するＩＰアドレスを、通信部１０２を介してロケーションサーバから取得するＩＰアドレス取得部１０６とを備えている。
【００１４】
また、図２は、第１の実施形態に係わるＳＩＰプロキシサーバ１００を含むネットワークシステムの構成を示す図である。
【００１５】
ＳＩＰプロキシサーバ１００は、通信端末（ユーザーエージェント、以下ＵＡと呼ぶ）であるＵＡ１（２００）、ＵＡ２（３００）、および、ロケーションサーバ４００とネットワークを介して接続されている。
【００１６】
以下では、まず、ＵＡ１およびＵＡ２のＳＩＰアドレスとＩＰアドレスとの関連付けをロケーションサーバ４００に登録する方法について説明する。
【００１７】
ＵＡ１およびＵＡ２が起動すると、これらの通信端末は、まずＲＥＧＩＳＴＥＲ処理を行う。具体的には、これらの通信端末のＳＩＰアドレスとＩＰアドレスとを含むＲＥＧＩＳＴＥＲリクエストを登録サーバ（レジストラ、図２には図示していない）へ送信する。登録サーバは、受信したＳＩＰアドレスとＩＰアドレスをロケーションサーバ４００へ送信し、ロケーションサーバ４００は、これらのＳＩＰアドレスとＩＰアドレスとを関連づけて記憶する。このように、ロケーションサーバ４００に、ＵＡ１およびＵＡ２のＳＩＰアドレスとＩＰアドレスとが、それぞれ関連付けられて記憶されることにより、ロケーションサーバ４００は、ＳＩＰプロキシサーバ１００からの問い合わせに応じて、特定のＳＩＰアドレスに対応するＩＰアドレスを回答することが可能になる。
【００１８】
次に、図１、図２および図３を用いて、ＳＩＰプロキシサーバ１００を介して、ＵＡ１からＵＡ２へ通信の確立を要求するメッセージが送信される場合の、ＳＩＰプロキシサーバ１００の動作について説明する。なお、図３は、第１の実施形態におけるＳＩＰプロキシサーバ１００の動作を示すフローチャートである。
【００１９】
まず、ＵＡ１上で動作するアプリケーションが、ＵＡ２に対して通信の確立を要求するＩＮＶＩＴＥメッセージを生成し、ＳＩＰプロキシサーバ１００に対して送信する。このとき、ＵＡ１上で動作するアプリケーションは、そのアプリケーションを識別する識別情報とＵＡ２のＳＩＰアドレスとを含むＳＩＰ  ＵＲＩをリクエストラインに記述する。
【００２０】
図４は、ＵＡ１で生成されるＩＮＶＩＴＥメッセージのヘッダの例である。図４に示すＩＮＶＩＴＥメッセージのヘッダでは、リクエストラインに記述されたＳＩＰ  ＵＲＩが、ＵＡ２のＳＩＰアドレス「ｓｉｐ：ｂｏｂ＠１０４８．ｃｏ．ｊｐ」と、アプリケーションの識別情報「ｖｏｉｐ」とを含んでいる。ここで、図４に示すアプリケーションの識別情報「ｖｏｉｐ」は、ＵＡ１からＵＡ２に対して音声通話を要求するアプリケーションの識別情報を表すものとする。
【００２１】
なお、ＳＩＰ  ＵＲＩにおけるアプリケーションの識別情報とＳＩＰアドレスの記述方法は、あらかじめメッセージの送受信を行うＵＡ１、ＳＩＰプロキシサーバ１００、および、ＵＡ２との間であらかじめ合意されているものとし、ここでは、アプリケーションの識別情報は、ＳＩＰアドレスのホスト部の最前部（「＠」の直後）に記述することとする。ただし、アプリケーションの識別情報とＳＩＰアドレスの記述方法は、このような方法には限定されず、例えば、図５に示すように、アプリケーションの識別情報をユーザ名の末尾（「＠」の直前）に、「−」を挿入して記述するようにしてもよい。また、ＳＩＰアドレスのユーザ名とホスト名に、アプリケーションの識別情報を分割して挿入してもよい。さらに、例えば、アプリケーションのバージョンのような、アプリケーションの識別情報に対する補足情報を、図６に示すように、ＳＩＰ  ＵＲＩのパラメータ部分に挿入することも可能である。
【００２２】
このようにしてＵＡ１で生成され、送信されたＩＮＶＩＴＥメッセージは、ＳＩＰプロキシサーバ１００の通信部１０２で受信される（ステップＳ１０１）。
【００２３】
ＳＩＰプロキシサーバ１００の通信部１０２で受信されたＩＮＶＩＴＥメッセージは、次に、識別情報取得部１０３に送られ、識別情報取得部１０３がＩＮＶＩＴＥメッセージのＳＩＰ  ＵＲＩからアプリケーションの識別情報を取得する（ステップＳ１０２）。上述した図４の例では、識別情報取得部１０３は、ＳＩＰ  ＵＲＩから、アプリケーションの識別情報「ｖｏｉｐ」を取得する。
【００２４】
識別情報取得部１０３でアプリケーションの識別情報が取得されると、次に、処理実行部１０４が、そのアプリケーションの識別情報に対応する処理をメモリ１０１から読み出して実行する（ステップＳ１０３）。
【００２５】
ここで、メモリ１０１には、アプリケーションの識別情報と、そのアプリケーションの識別情報を含むメッセージを受信した場合の処理とが関連づけられて記憶されているものとする。
【００２６】
例えば、後述するＵＡ２のＩＰアドレスを取得する処理においてＵＡ２のＩＰアドレスを取得できなかった場合などに、ネットワーク上に存在する、メッセージを保存する機能を有するサーバ（例えば、ボイスメールサービスを提供するサーバなど、図２には図示していない）に、受信したＩＮＶＩＴＥメッセージを転送する処理を、アプリケーションの識別情報「ｖｏｉｐ」と関連づけてメモリ１０１に記憶しておく。そして、実際にＩＰアドレス取得部１０６がＵＡ２のＩＰアドレスを取得できなかった場合には、受信したＩＮＶＩＴＥメッセージを、通信部１０２を通じて上記サーバへ転送するように制御を行う。
【００２７】
これとは別に、例えば、ＵＡ１からＵＡ２に対してビデオ予約の制御を行うアプリケーションの識別情報「ｐｖｒ」と、ＵＡ２のＩＰアドレスを取得する処理においてＵＡ２のＩＰアドレスを取得できなかった場合などに、「Ｎｏｔ  Ｆｏｕｎｄ」レスポンスをＵＡ１に返答する処理とを関連づけてメモリ１０１に記憶しておく。そして、実際にＩＰアドレス取得部１０６がＵＡ２のＩＰアドレスを取得できなかった場合には、受信したＩＮＶＩＴＥメッセージを転送することなく廃棄するとともに、ＵＡ１に対しては、通信部１０２を通じて「Ｎｏｔ  Ｆｏｕｎｄ」レスポンスを送信するように制御を行う。
【００２８】
このように、アプリケーションの識別情報と、そのアプリケーションの識別情報を含むメッセージを受信した場合の処理をメモリ１０１に関連づけて記憶しておくことで、ＳＩＰプロキシサーバ１００において各アプリケーションに対応したシグナリング処理を行うことが可能となる。
【００２９】
ＳＩＰプロキシサーバ１００の通信部で受信されたＩＮＶＩＴＥメッセージは、さらに、ＳＩＰアドレス取得部１０５にも送られる。そして、ＳＩＰアドレス取得部１０５は、ＩＮＶＩＴＥメッセージのＳＩＰ  ＵＲＩから、ＵＡ２のＳＩＰアドレスを取得する（ステップＳ１０４）。上述した図４の例では、ＳＩＰアドレス取得部１０５は、ＳＩＰ  ＵＲＩから、ＵＡ２のＳＩＰアドレス「ｓｉｐ：ｂｏｂ＠１０４８．ｃｏ．ｊｐ」を取得する。
【００３０】
ＳＩＰアドレス取得部１０５で取得されたＵＡ２のＳＩＰアドレスは、次に、ＩＰアドレス取得部１０６に送られる。そして、ＩＰアドレス取得部１０６は、ネットワークを介して接続されたロケーションサーバ４００に対して、ＵＡ２のＳＩＰアドレスに対応するＩＰアドレスを問い合わせるメッセージを通信部１０２から送信する（ステップＳ１０５）。
【００３１】
ロケーションサーバ４００にＵＡ２のＳＩＰアドレスがすでに登録されており、そのＳＩＰアドレスに関連づけてＵＡ２のＩＰアドレスが記憶されている場合には、ロケーションサーバ４００は、記憶されているＵＡ２のＩＰアドレスをＳＩＰプロキシサーバ１００へ送信する。一方、例えば、未だＵＡ２が起動していないなどの理由により、ロケーションサーバ４００にＵＡ２のＳＩＰアドレスおよびＩＰアドレスが記憶されていない場合には、ロケーションサーバ４００は、問い合わせのあったＵＡ２のＳＩＰアドレスに対応するＩＰアドレスを取得できない旨のメッセージをＳＩＰプロキシサーバ１００へ送信する。
【００３２】
ロケーションサーバ４００から送信されたメッセージは、通信部１０２で受信され、処理実行部１０４、および、ＩＰアドレス取得部１０６に送られる。
【００３３】
ロケーションサーバ４００から送信されたメッセージに、ＵＡ２のＩＰアドレスが含まれている場合には、ＩＰアドレス取得部１０６は、そのＩＰアドレスを用いて、ＵＡ１から送信されたＩＮＶＩＴＥメッセージをＵＡ２へと送信する（ステップＳ１０６）。
【００３４】
このような処理により、ＵＡ１から送信されるＩＮＶＩＴＥメッセージのＳＩＰ  ＵＲＩにアプリケーションの識別情報が含まれている場合にも、そのＩＮＶＩＴＥメッセージをＵＡ２へと送信することが可能になる。
【００３５】
一方、ロケーションサーバ４００から送信されたメッセージが、ＵＡ２のＩＰアドレスを取得できない旨のメッセージである場合には、上述したように、処理実行部１０４が、ＵＡ１から送信されたＩＮＶＩＴＥメッセージを、通信部１０２を介して、ボイスメールサービスを提供するサーバへと送信する。
【００３６】
このように本発明の第１の実施形態に係わるＳＩＰプロキシサーバ１００によれば、アプリケーションの識別情報と、通信を行おうとするＵＡのＳＩＰアドレスとを含むＳＩＰ  ＵＲＩがリクエストラインに記述されたメッセージを受信し、受信したメッセージからアプリケーションの識別情報を取得して、そのアプリケーションの識別情報に対応する処理を行なうので、アプリケーションごとに異なるシグナリング処理を行うことが可能となる。さらに、通信を行おうとするＵＡのＳＩＰアドレスも、受信したメッセージから取得できるので、対応するＩＰアドレスをロケーションサーバから取得し、メッセージを転送することが可能になる。
【００３７】
なお、受信したメッセージに含まれるＳＩＰ  ＵＲＩからアプリケーションの識別情報を取得し、取得した各アプリケーションに対応する処理を行う動作を、ＳＩＰにおける拡張機能として定義しておき、ＵＡ１からのメッセージに、その拡張機能を利用する旨の通知があった場合にのみ、ＳＩＰプロキシサーバ１００が上述した動作を行うようにすることも可能である。
【００３８】
アプリケーションの識別情報を含むＳＩＰ  ＵＲＩを用いてメッセージの送受信を行うことを、例えば、ここでは「ａｐｐ−ｉｎ−ｕｒｉ」と定義し、さらに、ＳＩＰアドレスのホスト部にアプリケーションの識別情報が挿入されることを「ａｐｐ−ｉｎ−ｈｏｓｔ」と定義する。これらの「ａｐｐ−ｉｎ−ｕｒｉ」「ａｐｐ−ｉｎ−ｈｏｓｔ」は、オプションタグと呼ばれる。
【００３９】
ＵＡ１およびＵＡ２は、起動後、ＲＥＧＩＳＴＥＲ処理を行う際に、ＲＥＧＩＳＴＥＲリクエストに、これらのオプションタグが記述されたＳｕｐｐｏｒｔｅｄヘッダとＰｒｏｘｙ−Ｒｅｑｕｉｒｅヘッダを付加する。ここでＳｕｐｐｏｒｔｅｄヘッダは、ＵＡ１およびＵＡ２が、Ｓｕｐｐｏｒｔｅｄヘッダに記述されたオプションタグに対応する拡張機能を利用可能であることを示すために用いられるヘッダである。一方、Ｐｒｏｘｙ−Ｒｅｑｕｉｒｅヘッダは、このヘッダに記述されたオプションタグに対応する拡張機能を利用する場合に必要となる動作を、ＳＩＰプロキシサーバ１００に対して要求していることを求めるために使用されるヘッダである。
【００４０】
これらのヘッダが記述されたＲＥＧＩＳＴＥＲリクエストが登録サーバで受信されると、登録サーバは、ＲＥＧＩＳＴＥＲリクエストに含まれるＵＡ１やＵＡ２のＳＩＰアドレスやＩＰアドレスとともに、上述したＳｕｐｐｏｒｔｅｄヘッダやＰｒｏｘｙ−Ｒｅｑｕｉｒｅヘッダに含まれるオプションタグの情報も、ロケーションサーバ４００へと送信する。そしてロケーションサーバ４００は、送信されたＳＩＰアドレス、ＩＰアドレスとともに、これらのオプションタグの情報も関連づけて記憶する。
【００４１】
そして、ＵＡ１が、この拡張機能を利用してメッセージの送受信を行う場合には、送信するメッセージのＰｒｏｘｙ−Ｒｅｑｕｉｒｅヘッダに、利用する拡張機能に対応するオプションタグを記述する。そして、ＳＩＰプロキシサーバ１００は、受信したメッセージのＰｒｏｘｙ−Ｒｅｑｕｉｒｅヘッダに拡張機能に対応するオプションタグが含まれている場合には、これに対応する動作を行う。上述した例では、Ｐｒｏｘｙ−Ｒｅｑｕｉｒｅヘッダに「ａｐｐ−ｉｎ−ｕｒｉ」「ａｐｐ−ｉｎ−ｈｏｓｔ」というオプションタグが記述されている場合には、識別情報取得部１０３が、受信したメッセージに記述されたＳＩＰ  ＵＲＩにおけるＳＩＰアドレスのホスト部分から、アプリケーションの識別情報を取得する動作を行う。一方、メッセージにＰｒｏｘｙ−Ｒｅｑｕｉｒｅヘッダの記述がない場合には、ＳＩＰ  ＵＲＩは、ＳＩＰアドレスのみを含むものと判断できるので、識別情報取得部１０３によるアプリケーションの識別情報を取得する動作は行うことなく、通常のメッセージ転送処理を行う。
【００４２】
このようにすることで、ＳＩＰプロキシサーバは、ＳＩＰ  ＵＲＩにアプリケーションの識別情報が含まれているメッセージと、含まれていない通常のメッセージのいずれにも対応することが可能になる。
【００４３】
また、上述した実施形態では、ＵＡ１からＵＡ２へ通信の確立を要求するＩＮＶＩＴＥメッセージを送信する場合の実施の形態について説明したが、このほかに、例えば、ＵＡ１からＵＡ２に対して、ＵＡ２のプレゼンス情報（例えば、ＲＦＣ３９０３，  Ａ．Ｎｉｅｍｉ，  “Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＳＩＰ）  Ｅｘｔｅｎｓｉｏｎ  ｆｏｒ  Ｅｖｅｎｔ  Ｓｔａｔｅ  Ｐｕｂｌｉｃａｔｉｏｎ”，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ），  Ｏｃｔｏｂｅｒ  ２００４  を参照）を取得するためのＳＵＢＳＣＲＩＢＥメッセージ（例えば、ＲＦＣ３２６５，  Ａ．Ｒｏａｃｈ，  “Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＳＩＰ）−Ｓｐｅｃｉｆｉｃ  Ｅｖｅｎｔ  Ｎｏｔｉｆｉｃａｔｉｏｎ”，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ），  Ｊｕｎｅ  ２００２  を参照）を送信する場合についても、ＳＩＰプロキシサーバ１００において、アプリケーションにより異なるシグナリング処理を行なうようにすることが可能である。
【００４４】
すなわち、例えば、ＵＡ１上で動作するアプリケーションが、ＵＡ２のプレゼンス情報をＵＡ２に対して直接回答させることを要求する場合には、ＵＡ１は、図７（ａ）に示すように、アプリケーションの識別情報として、「ｄｉｒｅｃｔ」がＳＩＰ  ＵＲＩに含められたＳＵＢＳＣＲＩＢＥメッセージを生成して、ＳＩＰプロキシサーバ１００に送信する。一方、ＵＡ２のプレゼンス情報を、ＵＡ２からではなく、通信端末のプレゼンス情報を保存するプレゼンスサーバ（図２には図示していない）に回答させること要求する場合には、ＵＡ１は、図７（ｂ）に示すように、アプリケーションの識別情報として、「ｉｎｄｉｒｅｃｔ」がＳＩＰ  ＵＲＩに含められたＳＵＢＳＣＲＩＢＥメッセージを生成して、ＳＩＰプロキシサーバ１００に送信する。
【００４５】
これに対して、ＳＩＰプロキシサーバ１００は、これらのアプリケーションの識別情報「ｄｉｒｅｃｔ」または「ｉｎｄｉｒｅｃｔ」をＳＩＰ  ＵＲＩに含むメッセージを受信した場合の処理をメモリ１０１に記憶しておく。具体的には、アプリケーションの識別情報「ｄｉｒｅｃｔ」と、受信したメッセージをＵＡ２に送信する処理とを関連づけて記憶しておく。また、アプリケーションの識別情報「ｉｎｄｉｒｅｃｔ」と、受信したメッセージをプレゼンスサーバに送信する処理とを関連づけてメモリ１０１に記憶しておく。
【００４６】
そして、ＳＩＰプロキシサーバ１００の識別情報取得部１０３は、受信したＳＵＢＳＣＲＩＢＥメッセージのＳＩＰ  ＵＲＩからアプリケーションの識別情報「ｄｉｒｅｃｔ」または「ｉｎｄｉｒｅｃｔ」を取得し、処理実行部１０４は、そのアプリケーションの識別情報に対応する処理をメモリ１０１から読み出して実行する。具体的には、アプリケーションの識別情報が「ｄｉｒｅｃｔ」である場合には、受信したＳＵＢＳＣＲＩＢＥメッセージを通信部１０２からＵＡ２に送信し、「ｉｎｄｉｒｅｃｔ」である場合には、受信したＳＵＢＳＣＲＩＢＥメッセージを通信部１０２からプレゼンスサーバへと送信する。ＳＵＢＳＣＲＩＢＥメッセージを受信したＵＡ２またはプレゼンスサーバは、ＳＵＢＳＣＲＩＢＥメッセージに対するＮＯＴＩＦＹメッセージをＳＩＰプロキシサーバ１００に送信し、ＳＩＰプロキシサーバ１００は、そのＮＯＴＩＦＹメッセージをＵＡ１に転送する。
【００４７】
このようにすることで、ＳＩＰプロキシサーバ１００は、ＳＩＰ  ＵＲＩに含められたアプリケーションの識別情報から、ＳＵＢＳＣＲＩＢＥメッセージの送信先を変えることが可能になり、ＵＡ１は、指定したＵＡ２またはプレゼンスサーバから、プレゼンス情報を取得することができる。
【００４８】
また、このほかにも、例えば、災害時や年末年始など、大量の通信要求によってネットワークトラフィックが増大する場合などに、ＳＩＰプロキシサーバ１００において、トラフィックを多く消費するテレビ電話などによる通信を要求するメッセージの送受信を、そのメッセージのＳＩＰ  ＵＲＩに含まれるアプリケーションの識別情報を利用して制限し、比較的トラフィックの少ない音声通話のみを許可することで、トラフィックの増加を防ぐようにすることも可能である。この場合、例えば、メモリ１０１に、通信を許可しないアプリケーションの識別情報を記憶しておき、識別情報取得部１０３で取得したアプリケーションの識別情報が、通信が許可されないものである場合には、処理実行部１０４から通信が許可されない旨のメッセージを返答するようにすればよい。
【００４９】
また、上述した実施形態では、アプリケーションの識別情報と、そのアプリケーションの識別情報を含むＳＩＰ  ＵＲＩがリクエストラインに記述されたメッセージを受信した場合に行う処理が、ＳＩＰプロキシサーバ１００内のメモリ１０１に関連づけて記憶されているものとしたが、このような関連付けはネットワーク上の記憶サーバに記憶されていてもよい。この場合、処理実行部１０４は、通信部１０２を介してネットワーク上の記憶サーバに対して、識別情報取得部１０３で取得したアプリケーションの識別情報に対応する処理を問い合わせるメッセージを送り、記憶サーバから回答のあった処理を行うようにすればよい。
【００５０】
なお、このＳＩＰプロキシサーバ１００は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、識別情報取得部１０３、処理実行部１０４、ＳＩＰアドレス取得部１０５およびＩＰアドレス取得部１０６は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、ＳＩＰプロキシサーバ１００は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、メモリ１０１は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【００５１】
（第２の実施形態）
第１の実施形態では、ＵＡ１から送信されるメッセージのリクエストラインにおけるＳＩＰ  ＵＲＩの記述方法は、ＵＡ１、ＵＡ２、および、ＳＩＰプロキシサーバ１００の間で、あらかじめ合意がとれているものとして説明を行った。
【００５２】
これに対して第２の実施形態では、例えば、ＵＡごとに、ロケーションサーバ４００にＳＩＰ  ＵＲＩの記述方法を登録しておき、ＳＩＰプロキシサーバは、このロケーションサーバ４００に登録された記述方法を取得して、ＳＩＰ  ＵＲＩからアプリケーションの識別情報やＳＩＰアドレスを取得する場合の実施の形態について説明する。
【００５３】
図８は、本発明の第２の実施形態に係わるＳＩＰプロキシサーバ１１００を示すブロック図である。
【００５４】
この第２の実施形態に係わるＳＩＰプロキシサーバ１１００は、図１に示す第１の実施形態に係わるＳＩＰプロキシサーバ１００に加えて、ロケーションサーバ４００からＳＩＰ  ＵＲＩの記述方法を取得する記述方法取得部１０７と、受信したメッセージに含まれるＳＩＰ  ＵＲＩの記述方法を変換する記述方法変換部１０８とをさらに備えている。
【００５５】
したがって、以下では、第１の実施形態と同じ動作を行う部分（メモリ１０１、処理実行部１０４、ＩＰアドレス取得部１０６）については、詳細な説明を省略する。
【００５６】
まず、ＵＡ１およびＵＡ２は、ＲＥＧＩＳＴＥＲ処理において、それぞれが用いるＳＩＰ  ＵＲＩの記述方法を登録サーバに送信する。登録サーバは、受信したＳＩＰ  ＵＲＩの記述方法を、ＵＡ１およびＵＡ２のＳＩＰアドレスやＩＰアドレスとともに、ロケーションサーバ４００に送信する。そして、ロケーションサーバ４００は、これらの受信した情報を、それぞれ関連づけて記憶する。なお、ＳＩＰ  ＵＲＩの記述方法は、例えば、上述したように、ＳＩＰの拡張機能におけるオプションタグとして定義しておいてもよい。
【００５７】
次に、ＵＡ１上で動作するアプリケーションが、ＵＡ２に対して通信の確立を要求するＩＮＶＩＴＥメッセージを生成し、ＳＩＰプロキシサーバ１１００に対して送信する。
【００５８】
ＵＡ１から送信されたＩＮＶＩＴＥメッセージは、ＳＩＰプロキシサーバ１１００の通信部１０２で受信され、次に、記述方法取得部１０７へと送られる。
【００５９】
記述方法取得部１０７は、通信部１０２からロケーションサーバ４００に対して、ＵＡ１およびＵＡ２のＳＩＰ  ＵＲＩの記述方法を問い合わせるメッセージを送信して、これらの記述方法を取得する。識別情報取得部１０３やＳＩＰアドレス取得部１０５は、取得した記述方法に基づいて、受信したＩＮＶＩＴＥメッセージのＳＩＰ  ＵＲＩから、アプリケーションの識別情報やＵＡ２のＳＩＰアドレスを取得する。
【００６０】
そして、記述方法取得部１０７が取得したＵＡ１とＵＡ２のＳＩＰ  ＵＲＩの記述方法が異なる場合には、記述方法変換部１０８が、受信したＩＮＶＩＴＥメッセージのＳＩＰ  ＵＲＩの記述方法を、ＵＡ１のＳＩＰ  ＵＲＩの記述方法からＵＡ２のＳＩＰ  ＵＲＩの記述方法へと変換する。例えば、ＵＡ１のＳＩＰ  ＵＲＩの記述方法では、アプリケーションの識別情報がＳＩＰアドレスのホスト部の先頭に記述されるのに対して、ＵＡ２では、ＳＩＰアドレスのユーザ名の末尾に記述される場合には、記述方法変換部１０８は、アプリケーションの識別情報をＳＩＰアドレスのユーザ名の末尾に含むＳＩＰ  ＵＲＩがリクエストライン記述されたＩＮＶＩＴＥメッセージを生成する。
【００６１】
このようにして記述方法変換部１０８でＳＩＰ  ＵＲＩの記述方法が変換されたＩＮＶＩＴＥメッセージが生成されると、そのメッセージは、通信部１０２を介して、ＵＡ２へと送信される。
【００６２】
このように本発明の第２の実施形態に係わるＳＩＰプロキシサーバ１１００によれば、ＵＡごとに異なるＳＩＰ  ＵＲＩの記述方法を用いている場合にも、ＳＩＰプロキシサーバ１１００において、記述方法の変換が行われるので、各ＵＡは、通信を確立しようとする相手のＳＩＰ  ＵＲＩの記述方法を意識することなく、メッセージの生成を行うことが可能になる。
【００６３】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００６４】
【図１】本発明の第１の実施形態に係わるＳＩＰプロキシサーバの構成を示すブロック図。
【図２】本発明の第１の実施形態のＳＩＰプロキシサーバを含むネットワークシステムの構成を示す図。
【図３】本発明の第１の実施形態の動作を示すフローチャート。
【図４】本発明の第１の実施形態のＳＩＰプロキシサーバが受信するメッセージの一例を示す図。
【図５】本発明の第１の実施形態のＳＩＰプロキシサーバが受信するメッセージの一例を示す図。
【図６】本発明の第１の実施形態のＳＩＰプロキシサーバが受信するメッセージの一例を示す図。
【図７】本発明の第１の実施形態のＳＩＰプロキシサーバが受信するメッセージの一例を示す図。
【図８】本発明の第２の実施形態に係わるＳＩＰプロキシサーバの構成を示すブロック図。
【符号の説明】
【００６５】
１００、１１００・・・ＳＩＰプロキシサーバ
１０１・・・メモリ
１０２・・・通信部
１０３・・・識別情報取得部
１０４・・・処理実行部
１０５・・・ＳＩＰアドレス取得部
１０６・・・ＩＰアドレス取得部
１０７・・・記述方法取得部
１０８・・・記述方法変換部
【図１】
2007201563.tif 000003
【図２】
2007201563.tif 000004
【図３】
2007201563.tif 000005
【図４】
2007201563.tif 000006
【図５】
2007201563.tif 000007
【図６】
2007201563.tif 000008
【図７】
2007201563.tif 000009
【図８】
2007201563.tif 000010