JP2007157085A - Ｓｉｐサーバ共有モジュール、ｓｉｐメッセージ中継方式、プログラム - Google Patents

Abstract

【課題】特定のクライアントグループに所属する端末から送信されたＳＩＰメッセージがグループに所属しない端末に転送されないようにすると共に、そのしたレスポンスが当該グループに所属しない端末に送信されないようにする。
【解決手段】メッセージ送信元グループ識別部は端末が送信したＳＩＰメッセージをインターセプトし、送信元端末が所属するクライアントグループを識別する。グループタグ挿入部はメッセージ送信元グループ識別部が識別したグループに対応するグループタグをＳＩＰメッセージに挿入する。グループタグ削除部はＳＩＰプロキシサーバが送信したサーバ送信ＳＩＰメッセージからグループタグを削除する。メッセージ送信先グループ識別部はグループタグ削除部が削除したグループタグに対応するクライアントグループを識別し、サーバ送信ＳＩＰメッセージが当該グループに所属しないクライアント端末へ送信されることを防止する。
【選択図】図１

Description

本発明は、ＳＩＰサーバ共有モジュールに関し、特に複数のクライアントグループによるＳＩＰプロキシサーバの安全な共同利用を可能とするＳＩＰサーバ共有モジュールに関する。

従来、データセンタ内に設置されたＷｅｂキャッシュサーバやメールサーバ、データベースサーバ、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）プロキシサーバ等のアプリケーションサーバを複数のクライアントグループで利用する方法としては、クライアントグループ毎にデータセンタ内にＶＬＡＮを構築し、当該ＶＬＡＮ上に（クライアントグループ毎に）一つずつアプリケーションサーバを設置する方法が一般的に採られていた。しかしながら、この方法では、クライアントグループ毎にＶＬＡＮの構築及びアプリケーションサーバの設置が必要となり、多数のクライアントグループをデータセンタに収容することがコスト上困難であった。

この問題を解決する方法としては、アプリケーションサーバの前段にクライアント端末とサーバ間でやり取りされる要求・応答の中継処理を行うモジュール（以下、共有モジュール）を配置し、共有モジュールによって複数のクライアントグループに単一のアプリケーションサーバを共同利用させる方法が考えられる。

共有モジュールは次の機能を具備する必要がある。
（１）共有モジュールは、単一のアプリケーションサーバを複数のクライアントグループに共同利用させつつも、各クライアントグループがあたかも自分専用のアプリケーションサーバを利用しているかのような安全性を提供できるように、クライアント端末とアプリケーションサーバ間でやり取りされる要求・応答の中継処理を行う必要がある。
（２）上記（１）を実現するため、共有モジュールにおいてクライアント端末とアプリケーションサーバの間でやり取りされる全ての要求・応答をインターセプトする必要がある。更に、インターセプトした要求・応答メッセージを本来の宛先であるクライアント端末やアプリケーションサーバに転送する必要がある。具体的には、以下の（ａ）（ｂ）（ｃ）の要求・応答メッセージがインターセプト及び転送の対象となる。
（ａ）クライアント端末からアプリケーションサーバに対して送信する要求メッセージ。
（ｂ）アプリケーションサーバからクライアント端末に対して送信される応答メッセージ。
（ｃ）アプリケーションサーバにおいて転送処理されたクライアント端末から他のクライアント端末に宛てて送信された要求メッセージ。

（１）を実現する方法としては、例えばＷｅｂキャッシュサーバを対象とした方法が従来提案されている。
この方法では、Ｗｅｂキャッシュサーバと同一のノード内に複数クライアントグループによるＷｅｂキャッシュサーバの共同利用を可能とする共有モジュールを設置する。このため、この方法では、（２）の要求・応答のインターセプトについては特に問題にならない。共有モジュールは、クライアント端末が閲覧したＷｅｂコンテンツをＷｅｂキャッシュサーバがキャッシュする際に、当該クライアント端末が所属するクライアントグループを識別し、キャッシュするコンテンツのＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）にクライアントグループを示すグループタグを挿入して、Ｗｅｂキャッシュサーバに渡す。例えば、クライアントグループ１に所属するクライアント端末が閲覧したＵＲＬがｗｗｗ．ａ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌのコンテンツをキャッシュする際にはＵＲＬにグループタグｇｒｏｕｐ−１を挿入する。この結果、Ｗｅｂキャッシュサーバ上には、ｗｗｗ．ａ．ｃｏｍ−ｇｒｏｕｐ１／ｉｎｄｅｘ．ｈｔｍｌというＵＲＬでキャッシュされる。

また、クライアント端末がＷｅｂキャッシュサーバにキャッシュされたコンテンツを閲覧する際には、共有モジュールは当該クライアント端末が要求するコンテンツのＵＲＬに、当該クライアント端末が所属するクライアントグループを示すグループタグを挿入する。例えば、クライアントグループ２に所属するクライアント端末がＵＲＬがｗｗｗ．ａ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌのコンテンツの閲覧を要求した場合、Ｗｅｂキャッシュサーバにはｗｗｗ．ａ．ｃｏｍ−ｇｒｏｕｐ２／ｉｎｄｅｘ．ｈｔｍｌというＵＲＬが渡され、このＵＲＬでＷｅｂキャッシュサーバはキャッシュされたコンテンツを検索する。検索後、共有モジュールはクライアント端末からの閲覧要求に対する応答を、閲覧要求送信元のクライアント端末に送信する。

これにより、特定のクライアントグループに所属するクライアント端末の閲覧要求によりキャッシュされたコンテンツは、当該クライアントグループのクライアント端末からしか利用することができなくなる。この結果、複数のクライアントグループで単一のＷｅｂキャッシュサーバを共同利用しているにも関わらず、各クライアントグループではあたかも自分専用のキャッシュサーバを利用しているかのような安全性を得ることが可能となる。

（２）を実現する方法としては、例えば、一般的なＷｅｂプロキシサーバソフトであるＳｑｕｉｄ等を用い、共有モジュールをいわゆるプロキシサーバとして動作させる方法がある。
この方法は、共有モジュールが、クライアント端末に対してはアプリケーションサーバとして振る舞い、アプリケーションサーバに対してはクライアント端末として振る舞うというものである。具体的には、共有モジュールが、クライアント端末から受信した要求を予め設定されたアプリケーションサーバに転送する。また、クライアント端末からの要求を転送する際に、当該要求の送信元となったクライアント端末を記憶しておき、当該要求に対する応答をアプリケーションサーバから受信した場合には、記憶しておいたクライアント端末へ転送する。

従来技術の第一の課題点は、上述した（１）を実現する従来技術では、アプリケーションサーバに登録される情報（Ｗｅｂキャッシュサーバにキャッシュされるコンテンツ）にグループタグを挿入しているため、以下の（Ａ）（Ｂ）の問題が発生することである。
（Ａ）クライアント端末がグループを移動した後は、当該クライアント端末の閲覧によってキャッシュされたコンテンツであっても、キャッシュされたコンテンツは利用することができない。グループ移動後は新たにコンテンツをキャッシュし直さなければならない。また、グループを移動した後であっても、当該クライアント端末の閲覧によってキャッシュされたコンテンツは、以前所属していたクライアントグループから閲覧することが可能である。
（Ｂ）クライアントグループを削除した場合は、Ｗｅｂキャッシュサーバからキャッシュされたコンテンツを明示的に消さない限り、不要なキャッシュコンテンツがずっとキャッシュサーバ上に残ってしまう。また、新たにクライアントグループを作成した場合は、新規作成したクライアントグループに参加するクライアント端末が参加前までに閲覧し、キャッシュされたコンテンツは新規クライアントグループから利用不可能であり、新たにコンテンツのキャッシュを行わなければならない。

上述した（１）を実現する従来技術をＳＩＰに直接適用した場合、クライアント端末がＲＥＧＩＳＴＥＲメッセージによってＳＩＰプロキシサーバへ登録するＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）にグループタグを挿入する形態になるが、このようにした場合は、上述の課題と同様に、クライアントグループ移動後はＲＥＧＩＳＴＥＲメッセージを送信し直さなくてはならなかったり、移動しても明示的に以前登録したＵＲＩをＳＩＰプロキシサーバから削除しない限り、自分が所属するクライアントグループの外からの発呼を受信してしまったりするといった問題がある。仮に、グループ移動後のＲＥＧＩＳＴＥＲメッセージの再送信や登録済みエントリの削除等を行った場合、クライアント端末がグループを移動する度ＳＩＰプロキシサーバには当該処理に伴う負荷がかかってしまう。このように、従来技術ではクライアント端末の動的なクライアントグループ間の移動や、クライアントグループの動的な作成や削除に対応することができない。

従来技術の第二の課題点は、上述した（２）を実現する従来技術では、アプリケーションサーバからクライアント端末に向けた応答を、当該応答のトリガとなった要求を送信したクライアント端末に対して送信することにしているため、クライアント端末から要求を受信してから、その要求に対応する応答をサーバから受信し、クライアント端末に中継するまで、どのクライアント端末から要求を受信したかという情報を保持していなければならない点である。このため、大量の要求・応答の中継処理を同時に行う場合、共有モジュールで保持する情報量が膨大なものになり、共有モジュールにかかる負荷が大きい。

ＳＩＰの場合は、ＳＩＰプロキシサーバからクライアント端末へ送信される応答（レスポンスメッセージ）の中に応答送信先のクライアント端末の情報が記載されることになっているため、この情報を利用すれば共有モジュール上での情報保持は不要となるが、この情報は要求（リクエストメッセージ）送信元のクライアント端末からの自己申告を元に記載されるため、詐称されることもあり得る。詐称された場合、要求送信元とは無関係のクライアント端末に応答が送信されることになってしまう。

また、上述した（２）を実現する従来技術では、（ｃ）で示したアプリケーションサーバにおいて転送処理されたクライアント端末から他のクライアント端末に宛てて送信された要求メッセージをインターセプトし、本来の宛先であるクライアント端末へ転送する機能が具備されていない。

関連する技術として、特開２００４−３０３０９号公報（特許文献１）に共有キャッシュサーバが開示されている。
この従来技術では、仮想的に分離された複数の仮想ネットワークが複数のグループに対応して構築された共通ネットワーク上に配設される共有キャッシュサーバが、記憶装置と、複数の仮想インタフェースと、アドレス変換機能と、キャッシュ機能とを備える。
この共有キャッシュサーバにおいて、記憶装置は、複数のグループに対応する複数の記憶領域のそれぞれでコンテンツを記憶する。仮想インタフェース（ＶＩＦ）１、ＶＩＦ２は、複数の仮想ネットワークに対応して配設される。アドレス変換機能は、クライアントからＶＩＦ１を介して、コンテンツを要求するパケットを受信すると、パケット中のＩＰアドレスの一部を、ＶＩＦに対応する内部アドレスに変換する。キャッシュ機能は、アドレス変換機能で変換された内部アドレスに基づいて、記憶装置の記憶領域から対応するグループのコンテンツを読み出す。

特開２００５−３３７０２号公報（特許文献２）に通信装置が開示されている。
この通信装置は、複数の仮想私設網とグローバルネットワークとが接続されるＶＰＮ収容装置に接続される通信装置であり、通信アプリケーションプラットフォームと、ＳＩＰ Ｐｒｏｘｙ手段と、通信アプリケーションプログラムとを有する。
前記通信アプリケーションプラットフォームは、前記ＶＰＮ収容装置から受信したＳＩＰメッセージを前記ＳＩＰ Ｐｒｏｘｙ手段に送信すると共に、前記ＳＩＰ Ｐｒｏｘｙ手段から受信したＩＰアドレスが変換されたＳＩＰメッセージを前記ＶＰＮ収容装置に送信する。
前記ＳＩＰ Ｐｒｏｘｙ手段は、前記通信アプリケーションプラットフォームから受信したＳＩＰメッセージにＳＩＰ Ｐｒｏｘｙ処理を施した後に、当該ＳＩＰメッセージを前記通信アプリケーションプログラムに送信すると共に、前記通信アプリケーションプログラムから受信したＩＰアドレスが変換されたＳＩＰメッセージを、前記通信アプリケーションプラットフォームに送信する。
前記通信アプリケーションプログラムは、前記ＳＩＰ Ｐｒｏｘｙ手段から受信したＳＩＰメッセージ内のＩＰアドレスを適切なアドレス体系のＩＰアドレスに変換し、当該ＩＰアドレスを変換したＳＩＰメッセージを前記ＳＩＰ Ｐｒｏｘｙ手段に送信する。

特開２００５−２００８０号公報（特許文献３）に加入者端末間通信システムが開示されている。
この従来技術では、ＶＬＡＮ環境下における加入者端末間通信システムにおいて、ＩＰ電話の呼設定をするためのインターネットプロトコルを実行するＳＩＰサーバが、メディアスイッチ手段と、変換テーブルとを具備する。
メディアスイッチ手段は、ＶＬＡＮに接続されている加入者端末からの呼制御メッセージ内にメディア信号の受信先として指定している自加入者端末のＩＰアドレスとポート番号を、プールされている使用可能なＳＩＰサーバのＩＰアドレスとポート番号に書き換える。変換テーブルは、前記書き換えた対応付け情報を保存する。なお、前記メディアスイッチ手段は、メディア信号通信時には、前記加入者端末から受信したＳＩＰサーバのＩＰアドレスとポート番号宛のメディア信号を、前記変換テーブルを元に変換した相手加入者端末のＩＰアドレスとポート番号宛に送信する。

特開２００４−１７９８５３号公報（特許文献４）にサーバ装置が開示されている。
この従来技術では、同じＩＰアドレスを持つ可能性のある複数の仮想閉域網のそれぞれの網と通信可能なサーバ装置が、受信パケットのレイヤ２フレーム内にある送信元である通信装置の物理アドレスを記憶する手段と、該受信パケットに対する応答パケットを送信するときに、応答先のＩＰアドレスに関係なく、前記手段で記憶した該物理アドレスを該応答パケットの宛先レイヤ２アドレスとして設定する設定手段を備える。

特開２００４−１６５８２３号公報（特許文献５）にＩＰアドレス変換装置が開示されている。
このＩＰアドレス変換装置は、受信手段と、抽出手段と、判別手段と、置換手段と、対応管理表と、変換手段と、送信手段とを備える。
受信手段は、ＳＩＰメッセージを受信する。抽出手段は、前記受信手段で受信したＳＩＰメッセージ内のＩＰアドレス情報を抽出する。判別手段は、前記抽出手段で抽出されたＩＰアドレス情報にＩＰアドレスが含まれるか否かを判断し、前記抽出されたＩＰアドレス情報にＩＰアドレスが含まれる場合に、前記抽出されたＩＰアドレスの仮想ＩＰアドレスへの変換の要否を判別する。置換手段は、前記判別手段で、仮想ＩＰアドレスへ変換する必要がないと判別されたＩＰアドレスを、ＩＰアドレス識別情報に置き換える。対応管理表は、前記置換手段で置き換えられたＩＰアドレス識別情報は、。ＩＰアドレスとの対応関係を登録する。変換手段は、前記判別手段で、仮想ＩＰアドレスへ変換する必要があると判別されたＩＰアドレスを、仮想ＩＰアドレスに変換する。送信手段は、ＩＰアドレス情報が変更されたＳＩＰメッセージを送信する。

特開２００４−１４７１９５号公報（特許文献６）に音声通信方法が開示されている。
この音声通信方法において、送信元端末装置は該送信元端末装置を管理する第１のゲート装置へ呼接続要求を送信する。前記呼接続要求を受けた第１のゲート装置は、第１の呼制御情報を公衆電話網を介して送信先端末装置を管理する第２のゲート装置へ送信する。前記第２のゲート装置は送信先端末装置へ呼接続要求を送信する。前記送信先端末装置は通話可能か否かの返答を前記第２のゲート装置へ送信する。前記送信先端末装置から通話可能の返答を受けた場合に、前記第２のゲート装置は第２の呼制御情報を前記公衆電話網を介して前記第１のゲート装置へ送信すると共に、ＩＰネットワークに接続されているポートをオープンする。前記第１のゲート装置は前記第２のゲート装置からの第２の呼制御情報を受けて前記ＩＰネットワークに接続されているポートをオープンする。前記送信元端末装置及び送信先端末装置は、前記第１、第２のゲート装置のオープンされたポート及び前記ＩＰネットワークを介してパケット通信による通話を行う。

特開２００４−３０３０９号公報 特開２００５−３３７０２号公報 特開２００５−２００８０号公報 特開２００４−１７９８５３号公報 特開２００４−１６５８２３号公報 特開２００４−１４７１９５号公報

本発明の目的は、ＳＩＰプロキシサーバ（単一でも複数でも良い）を複数のクライアントグループで共同利用させながら、あたかも各クライアントグループが自分専用のＳＩＰプロキシサーバを利用しているかのような安全性を提供するＳＩＰサーバ共有モジュールを提供することにある。
本発明の他の目的は、クライアント端末が所属するクライアントグループを移動した際に、ＲＥＧＩＳＴＥＲメッセージの再度送や登録済みのＵＲＩを削除することなく、移動先クライアントグループからの着呼等の受信や移動前に所属していたクライアントグループからの着呼等の拒否を可能とすることで、クライアント端末のクライアントグループ間の動的な移動や、クライアントグループの動的な作成、削除に対応するＳＩＰサーバ共有モジュールを提供することにある。
本発明の更に他の目的は、共有モジュールが要求送信元端末の情報を保持することなく、ＳＩＰプロキシサーバから送信される応答や転送される要求を、当該応答や要求のトリガとなった要求の送信元クライアント端末が所属するクライアントグループの外に送信されることを防ぐＳＩＰサーバ共有モジュールを提供することにある。

以下に、［発明を実施するための最良の形態］で使用される番号を括弧付きで用いて、課題を解決するための手段を説明する。これらの番号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために付加されたものである。但し、それらの番号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。

本発明のＳＩＰサーバ共有モジュール（１００）は、複数のクライアントグループ（３００）と前記複数のクライアントグループ（３００）が利用するＳＩＰプロキシサーバ（２００）との間で送受信されるＳＩＰメッセージの中継を行うＳＩＰサーバ共有モジュール（１００）であって、
前記ＳＩＰメッセージのうち、前記複数のクライアントグループの各々（３００）に所属するクライアント端末（３１１）から前記ＳＩＰプロキシサーバ（２００）へ送信されるクライアント送信ＳＩＰメッセージから、前記クライアント送信ＳＩＰメッセージを送信したクライアント端末（３１１）が所属するクライアントグループ（３００）を識別するメッセージ送信元グループ識別部（１１０）と、前記メッセージ送信元グループ識別部（１１０）が識別したクライアントグループ（３００）に対応するグループタグを前記クライアント送信ＳＩＰメッセージに挿入するグループタグ挿入部（１２１）と、前記ＳＩＰメッセージのうち、前記ＳＩＰプロキシサーバ（２００）から前記クライアントグループ（３００）に所属するクライアント端末（３１１）へ送信されるサーバ送信ＳＩＰメッセージに対して、前記サーバ送信ＳＩＰメッセージに含まれるグループタグの削除を行うグループタグ削除部（１２２）と、前記サーバ送信ＳＩＰメッセージに含まれるグループタグに対応するクライアントグループ（３００）と異なるクライアントグループ（３００）に所属するクライアント端末（３１１）に前記サーバ送信ＳＩＰメッセージが送信されることを防止するメッセージ送信先グループ識別部（１５０）とを有する。

前記メッセージ送信先グループ識別部（１５０）は、前記サーバ送信ＳＩＰメッセージに含まれるグループタグに対応するクライアントグループ（３００）と、前記サーバ送信ＳＩＰメッセージの実際の送信先クライアント端末（３１１）が所属するクライアントグループ（３００）とが一致する場合、前記サーバ送信ＳＩＰメッセージを前記送信先クライアント端末（３１１）へ転送する。

前記メッセージ送信先グループ識別部（１５０）は、当該ＳＩＰサーバ共有モジュール（１００）が配置されたノードに複数の仮想的又は物理的ネットワークインタフェースが存在する場合、前記ＳＩＰサーバ送信メッセージに含まれるグループタグに対応するクライアントグループ（３００）毎に異なるネットワークインタフェースを指定して、前記ＳＩＰサーバ送信メッセージを送信する。

前記メッセージ送信先グループ識別部（１５０）は、前記サーバ送信ＳＩＰメッセージのＩＰヘッダ又はＵＤＰヘッダに含まれるパラメタを、前記ＳＩＰサーバ送信メッセージに含まれるグループタグに対応するクライアントグループ（３００）毎に異なるパラメタ領域に変換した後、前記サーバ送信ＳＩＰメッセージを送信先クライアント端末（３１１）に転送する。

前記グループタグ挿入部（１２１）は、前記メッセージ送信元グループ識別部（１１０）が識別したクライアントグループ（３００）に対応するグループタグを、前記クライアント送信ＳＩＰメッセージに含まれるパラメタのうち、ＳＩＰプロキシサーバ（２００）へ登録するＵＲＩが含まれず、且つ、ＳＩＰプロキシサーバ（２００）における転送処理により消去されず、且つ、リクエストメッセージと前記リクエストメッセージを受信した際にＳＩＰプロキシサーバ（２００）が送信するレスポンスメッセージとで同じ値が記載される、という条件を満たすいずれかのパラメタに対して挿入する。

前記グループタグ挿入部（１２１）は、前記メッセージ送信元グループ識別部（１１０）が識別したクライアントグループ（３００）に対応するグループタグを、前記クライアント送信ＳＩＰメッセージのヘッダ部分に含まれるＵＲＩのうちユーザ識別子の部分に挿入する。

前記グループタグ挿入部（１２１）は、前記クライアント送信ＳＩＰメッセージが前記ＳＩＰプロキシサーバ（２００）に対してプレゼンス情報を通知するメッセージである場合、前記クライアント送信ＳＩＰメッセージのボディ部分にも更にグループタグを挿入する。

前記グループタグ挿入部（１２１）は、前記メッセージ送信元グループ識別部（１１０）が識別したクライアントグループ（３００）が複数の場合、前記クライアント送信ＳＩＰメッセージのコピーを前記メッセージ送信元グループ識別部（１１０）が識別したクライアントグループ（３００）数分作成し、前記コピーのそれぞれに対して前記メッセージ送信元グループ識別部（１１０）が識別したクライアントグループ（３００）に対応するグループタグを挿入する。

前記グループタグ挿入部（１２１）は、更に、前記クライアント送信ＳＩＰメッセージがリクエストメッセージである場合、ＳＩＰサーバ共有モジュール（１００）が配置されたノードのＩＰアドレス及び前記ＳＩＰメッセージの待ち受けに利用するポート番号を前記クライアント送信ＳＩＰメッセージのＶｉａヘッダへ追記し、
前記グループタグ削除部（１２２）は、更に、前記サーバ送信ＳＩＰメッセージがレスポンスメッセージである場合、前記サーバ送信ＳＩＰメッセージのＶｉａヘッダに記載されたＳＩＰサーバ共有モジュール（１００）が配置されたノードのＩＰアドレス及びＳＩＰサーバ共有モジュール（１００）がＳＩＰメッセージの待ち受けに利用するポート番号を削除すると共に、前記サーバ送信ＳＩＰメッセージのＶｉａヘッダに記載されたクライアント端末（３１１）のＩＰアドレス及びポート番号を前記サーバ送信ＳＩＰメッセージのＩＰヘッダの宛先ＩＰアドレスとＵＤＰヘッダの宛先ポート番号に設定する。

本発明のＳＩＰサーバ共有モジュール（１００）は、アドレス変換ルールと、アドレス変換部（１３０）と
を更に有し、
前記アドレス変換ルールには、前記クライアント端末（３１１）がＲＥＧＩＳＴＥＲメッセージによって前記ＳＩＰプロキシサーバ（２００）への登録を要求するアドレスであるオリジナルアドレスと、前記ＳＩＰプロキシサーバ（２００）が送信するＳＩＰメッセージの宛先アドレスに設定された場合に前記ＳＩＰメッセージをインターセプトするためのアドレスであるインターセプトアドレスとを相互に変換するアドレス変換方法が記載されており、
前記アドレス変換部（１３０）は、前記クライアント送信ＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージである場合、前記クライアント送信ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるオリジナルアドレスを、前記アドレス変換ルールを参照してインターセプトアドレスに変換し、前記サーバ送信ＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージに対するレスポンスメッセージである場合、前記サーバ送信ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるインターセプトアドレスを、前記アドレス変換ルールを参照してオリジナルアドレスに変換し、前記サーバ送信ＳＩＰメッセージがリクエストメッセージである場合、前記サーバ送信ＳＩＰメッセージのＩＰヘッダ及びＵＤＰヘッダに指定されているインターセプトアドレスを、前記アドレス変換ルールを参照してオリジナルアドレスに変換する。

前記アドレス変換方法は、Ｍビットの広さを持つＩＰアドレス領域Ａに含まれる任意のＩＰアドレスとＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスａと、Ｎビットの広さを持つＩＰアドレス領域Ｂに含まれる任意のＩＰアドレスとＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスｂとを相互に変換するアドレス変換方法であって、前記アドレスａを前記アドレスｂに変換する際には、前記アドレスａのＩＰアドレスのうちＸ＜Ｎを満たすＸビット分を前記アドレスｂのＩＰアドレスにマッピングし、残りのＭ−Ｘビット分を前記アドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号にマッピングし、前記アドレスｂを前記アドレスａに変換する際には、前記アドレスｂのＩＰアドレスのうちＸビット分と前記アドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のうちＭ−Ｘビット分とを組み合わせて前記アドレスａのＩＰアドレスに変換することを特徴とする。

前記アドレス変換ルールは、インターセプトアドレスとして、前記ＳＩＰプロキシサーバ（２００）においてＳＩＰサーバ共有モジュール（１００）がゲートウェイとして設定されているＩＰアドレス領域を利用することを特徴とする。

前記アドレス変換ルールは、インターセプトアドレスとして、ローカルループバックアドレス領域に含まれるＩＰアドレス領域を利用することを特徴とする。

本発明のアドレス変換方法は、Ｍビットの広さを持つＩＰアドレス領域Ａに含まれる任意のＩＰアドレス、及びＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスａと、Ｎビットの広さを持つＩＰアドレス領域Ｂに含まれる任意のＩＰアドレス、及びＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスｂとを相互に変換するアドレス変換方法であって、（Ａ）前記アドレスａを前記アドレスｂに変換する際には、前記アドレスａのＩＰアドレスのうちＸ＜Ｎを満たすＸビット分を前記アドレスｂのＩＰアドレスにマッピングするステップと、（Ｂ）前記アドレスａのＩＰアドレスのうち残りのＭ−Ｘビット分を前記アドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号にマッピングするステップと、（Ｃ）前記アドレスｂを前記アドレスａに変換する際には、前記アドレスｂのＩＰアドレスのうちＸビット分と前記アドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のうちＭ−Ｘビット分とを組み合わせて前記アドレスａのＩＰアドレスに変換するステップとを具備する。

本発明のＳＩＰメッセージ中継方式は、（ａ）メッセージを受信した場合、前記メッセージがクライアント端末（３１１）から送信されたメッセージかＳＩＰプロキシサーバ（２００）から送信されたメッセージかを判別するステップと、（ｂ）前記受信したメッセージが前記クライアント端末（３１１）から送信されたメッセージの場合、アドレス変換が必要か否かを判断するステップと、（ｃ）アドレス変換が必要ない場合、特に処理を行わず前記クライアント端末（３１１）から送信されたメッセージを前記ＳＩＰプロキシサーバ（２００）へ転送するステップと、（ｄ）アドレス変換が必要な場合、前記クライアント端末（３１１）から送信されたメッセージがＲＥＧＩＳＴＥＲメッセージか否かを判断するステップと、（ｅ）前記クライアント端末（３１１）から送信されたメッセージがＲＥＧＩＳＴＥＲメッセージである場合、ヘッダ部分のＣｏｎｔａｃｔヘッダに含まれるＩＰアドレス又はポート番号といったオリジナルアドレスを順方向変換するステップと、（ｆ）順方向変換後、前記ＳＩＰプロキシサーバ（２００）へＲＥＧＩＳＴＥＲメッセージを送信するステップとを具備する。

本発明のＳＩＰメッセージ中継方式は、（ｇ）前記受信したメッセージが前記ＳＩＰプロキシサーバ（２００）から送信されたメッセージの場合、アドレス変換が必要か否かを判断するステップと、（ｈ）アドレス変換が不要な場合、前記ＳＩＰプロキシサーバ（２００）から送信されたメッセージに含まれるグループタグの削除を行うステップと、（ｉ）アドレス変換が必要な場合、前記ＳＩＰプロキシサーバ（２００）から送信されたメッセージがリクエストメッセージであるか否かを判断するステップと、（ｊ）前記ＳＩＰプロキシサーバ（２００）から送信されたメッセージがリクエストメッセージである場合、当該ＳＩＰメッセージが前記クライアント端末（３１１）へ転送されるように、ＳＩＰメッセージのＩＰヘッダの宛先アドレス又は宛先ポート番号をインターセプトアドレスから前記オリジナルアドレスへ逆方向変換するステップと、（ｋ）逆方向変換後、前記ＳＩＰプロキシサーバ（２００）から送信されたメッセージに含まれるグループタグの削除を行うステップとを更に具備する。

本発明のＳＩＰメッセージ中継方式は、（ｌ）前記ＳＩＰプロキシサーバ（２００）から送信されたメッセージがレスポンスメッセージの場合、ＲＥＧＩＳＴＥＲメッセージ対するレスポンスメッセージであるか否かを判断するステップと、（ｍ）前記ＳＩＰプロキシサーバ（２００）から送信されたメッセージがＲＥＧＩＳＴＥＲメッセージ対するレスポンスメッセージの場合、Ｃｏｎｔａｃｔヘッダに含まれるＩＰアドレス又はポート番号であるインターセプトアドレスを、前記オリジナルアドレスに逆方向変換するステップと、（ｎ）逆方向変換後、前記ＳＩＰプロキシサーバ（２００）から送信されたメッセージに含まれるグループタグの削除を行うステップとを更に具備する。

本発明のプログラムは、上記のいずれかのＳＩＰメッセージ中継方式をコンピュータに実行させる。

第一の効果は、クライアント端末とＳＩＰプロキシサーバの間で頻繁にメッセージの交換が行われる環境においても、複数のクライアントグループによる安全なＳＩＰプロキシサーバの共同利用を可能にすることである。その理由は、本発明のＳＩＰサーバ共有モジュールはＳＩＰメッセージのうち、クライアント端末からＳＩＰプロキシサーバへ送信されるクライアント送信ＳＩＰメッセージから、クライアント送信ＳＩＰメッセージを送信したクライアント端末が所属するクライアントグループを識別するメッセージ送信元グループ識別部と、メッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグをクライアント送信ＳＩＰメッセージに挿入するグループタグ挿入部と、ＳＩＰメッセージのうち、ＳＩＰプロキシサーバからクライアントグループに所属するクライアント端末へ送信されるサーバ送信ＳＩＰメッセージに対して、サーバ送信ＳＩＰメッセージに含まれるグループタグの削除を行うグループタグ削除部と、サーバ送信ＳＩＰメッセージに含まれるグループタグに対応するクライアントグループと異なるクライアントグループに所属するクライアント端末にサーバ送信ＳＩＰメッセージが送信されることを防止するメッセージ送信先グループ識別部を有し、クライアント端末からリクエストメッセージを受信した際に、どのクライアント端末からリクエストメッセージを受信したかという情報を保持していなくても、特定のクライアントグループに所属するクライアント端末から送信されたリクエストメッセージが当該クライアントグループ以外のクライアントグループに所属するクライアント端末に転送されることを防ぎ、更に、当該リクエストメッセージに対するレスポンスメッセージが当該クライアントグループ以外のクライアントグループに所属するクライアント端末に送信されることを防ぐことが可能なためである。

第二の効果は、クライアント端末のクライアントグループ間の動的な移動やクライアントグループの動的な作成、削除に対応できることである。具体的には、クライアント端末のクライアントグループの移動や、クライアントグループ作成や削除があってもＳＩＰプロキシサーバに登録されているＳＩＰ ＵＲＩやコンタクトアドレスの情報を変更する必要がない。その理由は、本発明のＳＩＰサーバ共有モジュールのグループタグ挿入部は、クライアントグループに対応するグループタグをクライアント送信ＳＩＰメッセージに含まれるパラメタ（Ｐａｒａｍｅｔｅｒ）のうち、以下の全ての条件を満たすいずれかのパラメタに対してグループタグを挿入するためである。
「条件」
（１）ＳＩＰ ＵＲＩが含まれない。
（２）ＳＩＰプロキシサーバにおける転送処理により消去されない。
（３）リクエストメッセージと前記リクエストメッセージを受信した際に前記ＳＩＰプロキシサーバが送信するレスポンスメッセージとで同じ値が記載される。

第三の効果は、特定のクライアントグループに所属するクライアント端末から通知されたプレゼンス情報が、当該クライアントグループ以外のクライアントグループに所属するクライアント端末へ通知されることを防止することが可能であることである。その理由は、本発明のＳＩＰサーバ共有モジュールのグループタグ挿入部は、クライアント送信ＳＩＰメッセージがプレゼンス情報を通知するメッセージである場合には、前記クライアント送信ＳＩＰメッセージのボディ部分にもグループタグを挿入するためである。

第四の効果は、クライアント端末が複数のクライアントグループに所属する場合においても、当該クライアント端末が所属するクライアントグループ以外のクライアントグループに所属するクライアント端末には、当該クライアント端末が送信したリクエストメッセージが転送されたり、リクエストメッセージに対するレスポンスメッセージが送信されたりすることを防ぐことである。その理由は、本発明のＳＩＰサーバ共有モジュールのグループタグ挿入部は、メッセージ送信元グループ識別部が識別したクライアントグループが複数の場合は、クライアント送信ＳＩＰメッセージのコピーをメッセージ送信元グループ識別部が識別したクライアントグループ数分作成し、コピーのそれぞれに対してメッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグを挿入するためである。

第五の効果は、ＳＩＰプロキシサーバとＳＩＰサーバ共有モジュールの間にトンネリングリンクが構築されていない場合でもＳＩＰプロキシサーバから送信されたレスポンスメッセージをＳＩＰサーバ共有モジュールでインターセプトできることである。その理由は、本発明のＳＩＰサーバ共有モジュールのグループタグ挿入部は更に、クライアント送信ＳＩＰメッセージがリクエストメッセージである場合に、ＳＩＰサーバ共有モジュールが配置されたノードのＩＰアドレス及びＳＩＰサーバ共有モジュールがＳＩＰメッセージの待ち受けに利用するポート番号をクライアント送信ＳＩＰメッセージのＶｉａヘッダへ追記し、グループタグ削除部は、更に、サーバ送信ＳＩＰメッセージがレスポンスメッセージである場合に、サーバ送信ＳＩＰメッセージのＶｉａヘッダに記載されたＳＩＰサーバ共有モジュールが配置されたノードのＩＰアドレス及びＳＩＰサーバ共有モジュールがＳＩＰメッセージの待ち受けに利用するポート番号を削除すると共に、サーバ送信ＳＩＰメッセージのＶｉａヘッダに記載されたクライアント端末のＩＰアドレス及びポート番号をサーバ送信ＳＩＰメッセージのＩＰヘッダの宛先ＩＰアドレスとＵＤＰヘッダの宛先ポート番号に設定するためである。

第六の効果は、ＳＩＰプロキシサーバとＳＩＰサーバ共有モジュールの間にトンネリングリンクが構築されていない場合でもＳＩＰプロキシサーバからクライアント端末へ送信されたリクエストメッセージをＳＩＰサーバ共有モジュールでインターセプトできることである。
その理由は、本発明のＳＩＰサーバ共有モジュールは、クライアント端末がＲＥＧＩＳＴＥＲメッセージによってＳＩＰプロキシサーバへの登録を要求するアドレスであるオリジナルアドレスと、ＳＩＰプロキシサーバが送信するＳＩＰメッセージの宛先アドレスに設定された場合に、当該ＳＩＰメッセージをＳＩＰサーバ共有モジュールがインターセプト可能となるアドレスであるインターセプトアドレスとを相互に変換するアドレス変換方法が記載されたアドレス変換ルールと、クライアント送信ＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージである場合には、クライアント送信ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるオリジナルアドレスを、アドレス変換ルールを参照してインターセプトアドレスに変換し、サーバ送信ＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージに対するレスポンスメッセージである場合には、サーバ送信ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるインターセプトアドレスを、アドレス変換ルールを参照してオリジナルアドレスに変換し、サーバ送信ＳＩＰメッセージがリクエストメッセージである場合には、サーバ送信ＳＩＰメッセージのＩＰヘッダ及びＵＤＰヘッダに指定されているインターセプトアドレスを、前記アドレス変換ルールを参照してオリジナルアドレスに変換するアドレス変換部を更に有しているためである。

第七の効果は、インターセプト用アドレスとして確保できるＩＰアドレス領域がオリジナルアドレスの取り得るＩＰアドレス領域よりも狭い場合であっても、ＳＩＰプロキシサーバから送信されたＳＩＰメッセージに含まれるインターセプトアドレスを一意のオリジナルアドレスへ逆方向変換できることである。
その理由は、本発明のＳＩＰサーバ共有モジュールのアドレス変換ルールには、Ｍビットの広さを持つＩＰアドレス領域Ａに含まれる任意のＩＰアドレスとＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスａとＮビットの広さを持つＩＰアドレス領域Ｂに含まれる任意のＩＰアドレスとＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスｂとを相互に変換するアドレス変換方法であって、アドレスａをアドレスｂに変換する際には、アドレスａのＩＰアドレスのうちＸ＜Ｎを満たすＸビット分をアドレスｂのＩＰアドレスにマッピングし、のこりのＭ−Ｘビット分をアドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号にマッピングし、アドレスｂをアドレスａに変換する際には、アドレスｂのＩＰアドレスのうちＸビット分とアドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のうちＭ−Ｘビット分とを組み合わせてアドレスａのＩＰアドレスに変換することを特徴とするアドレス変換方法が記載されるためである。

以下に本発明の第１実施形態について添付図面を参照して説明する。
本発明の第一の実施の形態を図面を用いて説明する。
図１に示すように、本発明におけるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）通信網は、ＳＩＰサーバ共有モジュール１００と、ＳＩＰプロキシサーバ２００と、クライアントグループ３００とを有する。

ＳＩＰサーバ共有モジュール１００は、複数のクライアントグループ３００（３００−ｉ、ｉ＝１〜ｎ：ｎはグループ数）と、クライアントグループに所属する各クライアント端末が共同利用するＳＩＰプロキシサーバ２００との間に位置し、クライアント端末とＳＩＰプロキシサーバ２００の間でやり取りされるメッセージの中継処理を行う。

ＳＩＰプロキシサーバ２００は、以下の（処理１）から（処理４）までの処理を行うサーバである。実装によっては（処理２）から（処理４）までのいずれかの処理を行う機能が実装されていなかったり、（処理１）から（処理４）以外の処理を行う機能が実装されたりする場合もあるが、以下ではそうしたサーバも含めてＳＩＰプロキシサーバと呼ぶ。

（処理１）クライアント端末情報の登録処理
クライアント端末から登録メッセージ（ＲＥＧＩＳＴＥＲメッセージ）を受信し、クライアント端末のＳＩＰ ＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）とコンタクトアドレス（クライアント端末のＩＰアドレス及びＳＩＰ用待ち受けポート番号）をデータベースに登録する。登録メッセージにはコンタクトアドレスの付加情報として、クライアント端末の利用目的や特徴に関する情報が含まれる場合もある。

（処理２）クライアント端末間のメッセージ転送処理
クライアント端末から他のクライアント端末へ送信されたメッセージを転送する。転送を行うメッセージには主に呼の確立・終了・転送等の呼制御を行うためのメッセージ（ＩＮＶＩＴＥメッセージ、ＲＥＦＥＲメッセージ、ＢＹＥメッセージ、ＣＡＮＣＥＬメッセージ等）（２−１）、クライアント端末の状態（プレゼンス情報）を通知するためのメッセージ（ＰＵＢＬＩＳＨメッセージ、ＮＯＴＩＦＹメッセージ等）（２−２）、クライアント端末間で主にチャット等を行う際に任意の情報をやり取りするメッセージ（ＭＥＳＳＡＧＥメッセージ等）（２−３）や、前述の目的によらず、クライアント端末間でのメッセージの到達を確認するための汎用的なメッセージ（ＡＣＫメッセージ等）（２−４）等が含まれる。

（処理３）情報通知のための登録要求の処理
クライアント端末が特定の情報（例えば、他のクライアント端末のプレゼンス情報）を受信するために送信する登録要求メッセージ（ＳＵＢＳＣＲＩＢＥメッセージ等）を受けつける。

（処理４）クライアント端末情報の問い合わせに対する回答処理
クライアント端末からの要求メッセージ（ＯＰＴＩＯＮＳメッセージ等）により、他のクライアント端末の登録情報を回答する。

ＳＩＰプロキシサーバ２００は（処理１）で登録された情報に基づき、（処理２）から（処理４）までの処理を行うことを特徴とする。（処理２）では、クライアント端末から送信されたメッセージの宛先は送信先のクライアント端末のＳＩＰ ＵＲＩで表され、（処理１）で登録された情報を元に宛先クライアント端末のＳＩＰ ＵＲＩに対応するコンタクトアドレスを解決し、当該コンタクトアドレスに対してメッセージを転送する。（処理３）では、受信したい情報がＳＩＰ ＵＲＩで指定され、当該ＳＩＰ ＵＲＩと受信を要求したクライアント端末の関係が（処理１）の情報を元に登録される。（処理４）では、問い合わせ対象のクライアント端末がＳＩＰ ＵＲＩで表され、（処理１）で登録された情報を元に問い合わされたＳＩＰ ＵＲＩに該当する登録情報を回答する。
ＳＩＰプロキシサーバ２００は上記（処理１）から（処理４）の処理を要求するメッセージ（ＲＥＧＩＳＴＥＲ，ＩＮＶＩＴＥ、ＲＥＦＥＲ、ＢＹＥ、ＣＡＮＣＥＬ、ＰＵＢＬＩＳＨ、ＭＥＳＳＡＧＥ、ＡＣＫ、ＳＵＢＳＣＲＩＢＥ、ＯＰＴＩＯＮＳ等のメッセージ、一般にリクエストメッセージと呼ばれる）を受信すると、処理結果をレスポンスメッセージによって要求元に通知する。

クライアント端末３１１はパソコンに限らず、ＩＰ電話端末、情報家電等、ＳＩＰプロトコルに対応したアプリケーション（ＳＩＰ ＵＡ（Ｕｓｅｒ Ａｇｅｎｔ））を搭載した端末である。クライアント端末は他の複数のクライアント端末とクライアントグループを形成する。

クライアントグループ３００は同一グループに属さないクライアント端末との通話やメッセージ交換、プレゼンス情報の通知、登録情報の開示等を望まないクライアント端末の集合である。本発明ではクライアントグループとして、以下で説明するネットワークレベルのクライアントグループとアプリケーションレベルのクライアントグループを対象とする。

ネットワークレベルのクライアントグループとは、例えば同一の企業イントラネットや企業内の部門イントラネット等に接続したクライアント端末のように、同じネットワークに接続する他の端末とのみ接続性が確保され、外部のネットワークとの接続性がない（又はＷｅｂやＭａｉｌなどごく限られたアプリケーションによる接続性しか有さない）閉じたネットワークに接続しているクライアント端末のグループである。ネットワークレベルのグループは、ネットワークが特定されれば一意にクライアントグループが特定される。ネットワークレベルのクライアントグループとしては前述した企業イントラネットや部門イントラネットなどの他に、例えばＳｏｆｔｅｔｈｅｒやＥｍｏｔｉｏｎＬｉｎｋ等のように公衆網上をグループ内の他のクライアント端末とＩＰＳｅｃトンネルやＳＳＬトンネル等を利用して接続することで、仮想的に閉じたネットワークを形成しているグループも含まれる。

ネットワークレベルのクライアントグループがＳＩＰプロキシサーバ２００との通信を行う際のネットワーク構成例を図２に示す。図２では、クライアントグループ３００は個々のプライベート網（同一の企業イントラネットや企業内の部門イントラネット等や公衆網上を同一クライアントグループに参加するクライアント端末がＩＰＳｅｃトンネルやＳＳＬトンネル等を利用して接続することで形成される仮想的に閉じたネットワーク）と対応しており、インターネット等の公衆網５００上においてＩＰＳｅｃやＳＳＬ等により通信の安全性が確保されたＶＰＮトンネルによりＳＩＰプロキシサーバ２００が配置されたデータセンタネットワーク６００と接続している。ＶＰＮゲートウェイ４００は公衆網５００とデータセンタネットワーク６００の間に位置し、ＶＰＮトンネルの終端処理をする。ＶＰＮゲートウェイ４００は公衆網側に接続するＶＰＮ側インタフェース（ＩＦ）４２０とデータセンタネットワーク６００に接続するデータセンタ側ＩＦ４３０を有している。また、ＶＰＮ側ＩＦ４２０は更に仮想的に複数のＩＦ（仮想インタフェース（ＶＩＦ））４２１（４２１−ｉ、ｉ＝１〜ｎ）を有しており、それぞれのＶＩＦは各プライベート網３００とＶＰＮトンネルを介して接続している。ＶＰＮ終端部４１０はＶＰＮトンネルの終端処理を行う機能を有しており、更に、例えば、図３に示すようなパケット転送ルールを参照してＶＰＮトンネルを経由してプライベート網３００から受信したパケットにアドレス変換処理を行ってデータセンタネットワーク６００へ転送したり、データセンタネットワーク６００側から受信したパケットをヘッダ情報に基づいてプライベート網３００に転送したりする機能を有する。

一方、アプリケーションレベルのクライアントグループとは、グループウェアサーバや社員情報管理サーバ等のグループ情報管理サーバにおいて、各クライアント端末とグループの対応関係が定義されたグループである。グループ情報管理サーバの管理情報としては、例えばクライアント端末の識別子と所属グループ、更にはクライアント端末のＩＰアドレス等が挙げられる。

クライアント端末が接続するネットワークと所属するクライアントグループの間に対応関係はない。すなわち異なるクライアントグループに所属するクライアント端末が同一のネットワークに接続するケースがあり得る。

アプリケーションレベルのクライアントグループがＳＩＰプロキシサーバ２００との通信を行う際のネットワーク構成例を図４，図５に示す。図４ではＳＩＰプロキシサーバ２００、クライアント端末がインターネット又は同一のプライベート網に接続し、クライアント端末間は所属するクライアントグループによらず接続性が保障されている。図５でも同様にクライアント端末は同一のプライベート網に接続し、クライアント端末間は所属するクライアントグループによらず接続性が保障されている。

なお、クライアントグループの構成方法によらず、同一のクライアント端末が同時に複数のクライアントグループに参加するケースがあり得る。

ＳＩＰサーバ共有モジュール１００は、同一クライアントグループに属さないクライアント端末間で上述した（処理２）から（処理４）までのメッセージの転送、情報通知のための登録、クライアント端末情報の問い合わせに対する回答、が行われないようメッセージの中継処理を行う。例えば、（処理２）に関してはクライアントグループＡに所属するクライアント端末からの発呼要求やプレゼンス情報の通知、チャットメッセージが他のクライアントグループに所属するクライアント端末へ転送されないようにする。また、（処理３）に関してはクライアントグループＡに所属するクライアント端末からの他のクライアントグループに所属するクライアント端末のプレゼンス情報を受信するための要求がＳＩＰプロキシサーバ２００へ登録されないようにする。（処理４）に関してはクライアントグループＡに所属するクライアント端末からの他のクライアントグループに所属するクライアント端末の登録情報に対する問い合わせに対してＳＩＰプロキシサーバ２００からの回答がなされないようにする。

更に、特定のクライアントグループに所属するクライアント端末から送信されたリクエストメッセージをトリガとしてＳＩＰプロキシサーバ２００から送信されるレスポンスメッセージが当該クライアントグループ以外のクライアントグループに所属するクライアント端末へ送信されないようにする。

上記のようなメッセージ中継処理を行うことにより、ＳＩＰサーバ共有モジュール１００は複数のクライアントグループ３００で共通のＳＩＰプロキシサーバ２００を利用させながら、あたかも各クライアントグループがグループ専用のＳＩＰプロキシサーバ２００を利用しているかのようなセキュリティを提供する。

ＳＩＰサーバ共有モジュール１００の配置形態の例を図６から図８に示す。図６に示すようにサーバマシン（ＳＩＰサーバ共有ノード８００）の中に単独で配置される形態や、図７に示すように、ＶＰＮゲートウェイと同一のノード９００に配置され、アプリケーションレベルゲートウェイとして機能する形態、さらには、図８に示すようにＳＩＰプロキシサーバ２００と同一のノードに配置される形態などがある。図６から図８はネットワークレベルのクライアントグループを図示しているが、クライアントグループの構成方法によらず、上記いずれの配置形態もとることができる。

ＳＩＰサーバ共有モジュール１００は、メッセージ送信元グループ識別部１１０と、グループタグ挿抜部１２０と、アドレス変換部１３０と、メッセージ種別判断部１４０と、メッセージ送信先グループ識別部１５０を備える。以下、それぞれについて説明する。

メッセージ送信元グループ識別部１１０は、クライアント端末から送信されたメッセージについて、送信元クライアント端末が所属するクライアントグループを識別し、グループタグ挿抜部１２０に通知する。クライアントグループの識別方法は、クライアントグループの構成によって異なる。

クライアントグループがネットワークレベルのグループの場合、次のような方法が考えられる。ＶＰＮゲートウェイ４００やアプリケーションレベルゲートウェイ９００のＶＰＮ終端部４１０においてクライアント端末から受信したメッセージのＩＰヘッダの送信元ＩＰアドレスやＵＤＰヘッダ（又はＴＣＰヘッダ）の送信元ポート番号を、ＶＰＮ毎に（クライアント端末が所属するクライアントグループ毎に）異なるアドレス領域へ変換し、メッセージ送信元グループ識別部１１０が、変換後の送信元アドレス又は送信元ポート番号から、当該受信メッセージの送信元端末が所属するクライアントグループを判断するというものである。なお、変換対象は送信元ＩＰアドレス、送信元ポート番号に限らずＩＰヘッダの他のパラメタ（例えばプロトコル番号等）やより上位レイヤの例えばＴＣＰ、ＵＤＰヘッダのポート番号等でも良い。但し、現実的にＶＰＮ終端部４１０において、ＩＰより上位のＴＣＰやＵＤＰのヘッダ情報を変換する場合、変換処理の負荷が高くなるため、現実的ではない。

この方法をとる場合、ＶＰＮ終端部４１０とメッセージ送信元グループ識別部１１０において、予めメッセージのどの部分（例えばＩＰヘッダの送信元アドレス）を変換するのか、どのＶＰＮ（クライアントグループ）をどのパラメタの領域に変換するのか（例えばクライアントグループ１は１０．１０．１０／２４へクライアントグループ２は１０．１０．２０／２４）といったルールについて、共通のものを設定しておく必要がある。例えば、ＶＰＮ終端部４１０が図３に示すパケット転送ルールを利用している場合、メッセージ送信元グループ識別部１１０は図９に示すようなメッセージの送信元を識別するルールが登録されたテーブル（以下、メッセージ送信元グループ識別テーブル）を持つ必要がある。

なお、クライアント端末が複数のクライアントグループに所属する場合もあり得るが、クライアントグループがネットワークレベルのグループである場合には、当該クライアント端末が送信したＳＩＰメッセージがどのクライアントグループから送信されたかが一意に特定される。このため、ネットワークレベルのクライアントグループの場合には、メッセージ送信元グループ識別部１１０はＳＩＰメッセージを受信した際グループタグ挿抜部１２０に必ず単一のクライアントグループを通知する。

アプリケーションレベルのクライアントグループの場合、メッセージ送信元グループ識別部１１０は、グループ情報管理サーバ７００と連携してグループ識別を行う。具体的には、クライアント端末とＳＩＰサーバ共有モジュール１００がＳＩＰメッセージをやり取りする際にクライアント端末から提示されるユーザＩＤを元に、グループ情報管理サーバ７００に問い合わせる等の方法が考えられる。例えば、クライアント端末がＳＩＰダイジェスト認証を行う場合、メッセージ送信元グループ識別部１１０はダイジェスト認証において提示されたユーザＩＤを元に、当該クライアント端末が所属するクライアントグループをグループ情報管理サーバ７００に問い合わせる等の方法が考えられる。また、クライアント端末がＳＩＰメッセージをＳＳＬで行うＳＩＰＳに対応している場合、ＳＳＬコネクション構築時にクライアント端末が提示するクライアント証明書からユーザＩＤを抽出し、これを元に当該クライアント端末が所属するクライアントグループをグループ情報管理サーバ７００に問い合わせる等の方法が考えられる。

なお、グループ情報管理サーバ７００に問い合わせた結果、クライアント端末が複数のクライアントグループに所属していることが分かった場合、メッセージ送信元グループ識別部１１０はクライアント端末が所属する全てのクライアントグループを通知する。すなわち、ネットワークレベルのクライアントグループと異なり、アプリケーションレベルのクライアントグループの場合は、メッセージ送信元グループ識別部１１０がＳＩＰメッセージを受信した際、グループタグ挿抜部１２０に複数のクライアントグループを通知するケースがある。

グループタグ挿抜部１２０は、クライアント端末から送信されたＳＩＰメッセージに対してグループタグを挿入するグループタグ挿入部１２１とＳＩＰプロキシサーバ２００から送信されたＳＩＰメッセージに含まれるグループタグをメッセージ送信先グループ識別部に通知すると共に、グループタグをＳＩＰメッセージから削除するグループタグ削除部１２２の２つのモジュールからなる。以下、各モジュールについて説明する。

グループタグ挿入部１２１は、クライアント端末が送信したＳＩＰメッセージに対して、メッセージ送信元グループ識別部１１０から通知されたクライアントグループに基づき、ＳＩＰメッセージの送信元クライアント端末が所属するクライアントグループに対応したグループタグを挿入する。

また、メッセージ種別判断部１４０に問い合わせ、クライアント端末が送信したＳＩＰメッセージがリクエストメッセージである場合には、当該リクエストメッセージをトリガとしてＳＩＰプロキシサーバ２００から送信されるレスポンスメッセージをＳＩＰサーバ共有モジュール１００がインターセプトできるようにＶｉａヘッダにＳＩＰサーバ共有モジュール１００のＩＰアドレス及びＳＩＰの待ちうけに利用するポート番号を追記する。

なお、メッセージ送信元グループ識別部１１０から複数のクライアントグループを通知された場合は、以下のいずれかの処理を行う。

クライアント端末が送信したＳＩＰメッセージのコピーを通知されたクライアントグループの数だけ作成し、通知されたクライアントグループに対応するグループタグを各コピーに挿入する。

クライアント端末が送信したＳＩＰメッセージにメッセージ送信元グループ識別部１１０から通知されたクライアントグループに対応するグループタグを全て挿入する。

グループタグを挿入した後、アドレス変換部１３０にＳＩＰメッセージを渡す。
グループタグを挿入する方法はグループタグの挿入位置に応じて二つの方法がある。第一の方法はＳＩＰメッセージに含まれるＳＩＰ ＵＲＩに挿入する方法であり、第二の方法はＳＩＰ ＵＲＩ以外の部分に挿入する方法である。

「第一の方法」
ＳＩＰ ＵＲＩは、
ｓｉｐ（又はｓｉｐｓ）：＜ユーザ識別子＞：＜パスワード＞＠＜ホスト又はドメイン空間＞：＜ポート番号＞；＜その他情報＞
のフォーマットに従い、例えばｓｉｐ：ＵｓｅｒＤ：ｐａｓｓｗｄ＠ｗｅｓｔ．ｎｅｔ：５０６０のＵＲＩの場合、ＵｓｅｒＤがユーザ識別子、ｐａｓｓｗｄがパスワード、ｗｅｓｔ．ｎｅｔがドメイン空間、５０６０が当該クライアント端末がＳＩＰの待ち受けに利用するポート番号に該当する（この例ではその他情報に該当する部分は記載されていない。なお、パスワード及びポート番号、その他情報は省略される場合が多い）。第一の方法の場合、グループタグ挿入部はＳＩＰ ＵＲＩの構成要素のうち、ユーザ識別子の部分にグループタグを挿入する。ユーザ識別子以外の部分、例えばホスト又はドメイン空間や、その他情報の部分にグループタグを挿入する方法も考えられるが、これらの部分はＳＩＰサーバの実装によってはデータベースに登録されない場合もあるので望ましくない。なお、＠マークより前の部分は＜ホスト又はドメイン空間＞の部分がドメイン空間ではなく、ＩＰアドレスやＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）によってホストを指定している場合省略されるケースがあるが、このようなケースでは、第一の方法ではグループタグの挿入は行わない。

ＳＩＰ ＵＲＩはＳＩＰメッセージに複数記述されるのが一般的だが、グループタグ挿入部１２１はＳＩＰメッセージのヘッダ部分に含まれる全てのＳＩＰ ＵＲＩに対してグループタグを挿入する。ボディ部分にＳＩＰ ＵＲＩが記載される場合もあるが、ボディ部分は基本的にＳＩＰプロキシサーバ２００における転送処理で利用されることがない部分なため、ボディ部分に記載されるＳＩＰ ＵＲＩへのグループタグ挿入を行う必要はない。

クライアント端末から送信されたＳＩＰメッセージがＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、ＣＡＮＣＥＬ、ＯＰＴＩＯＮＳ、ＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＰＵＢＬＩＳＨ等のメソッドのリクエストメッセージである場合には、ＳＩＰメッセージのヘッダ部分のスタートライン（リクエストライン）に含まれるリクエストＵＲＩ及びＦｒｏｍヘッダ及びＴｏヘッダ、Ｃｏｎｔａｃｔヘッダ等で指定されたＵＲＩ全てにグループタグが挿入される。一方スタートラインにメソッドを含まない１００Ｔｒｙｉｎｇや１８０Ｒｉｎｇｉｎｇ、２００ＯＫ等のレスポンスメッセージの場合は、スタートラインにはリクエストＵＲＩを含まないため、Ｆｒｏｍヘッダ、Ｔｏヘッダ、Ｃｏｎｔａｃｔヘッダ等で指定されたＵＲＩのみにグループタグが挿入される。

グループタグ挿入の具体例を以下に示す。
例えば、クライアントグループ１のクライアント端末ＡがＦｒｏｍ、Ｔｏ、ＣｏｎｔａｃｔヘッダのＳＩＰ ＵＲＩが、
Ｆｒｏｍ： ｓｉｐ：ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍ
Ｔｏ： ｓｉｐ：ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍ
Ｃｏｎｔａｃｔ： ＵｓｅｒＡ＠４．３．２．１
のように指定されたＲＥＧＩＳＴＥＲメッセージを送信した場合、グループタグ挿入部はリクエストメッセージの各ヘッダに以下のようにグループタグを挿入する。
Ｆｒｏｍ： ｓｉｐ：ＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍ
Ｔｏ： ｓｉｐ：ＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍ
Ｃｏｎｔａｃｔ： ｓｉｐ：ＵｓｅｒＡ−ｇｒｏｕｐ１＠４．３．２．１

この結果、ＳＩＰプロキシサーバ２００にはオリジナルのＳＩＰ ＵＲＩ、ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍではなく、グループタグ挿入部１２１によりグループタグの挿入されたＳＩＰ ＵＲＩ、ＵｓｅｒＡ−ｇｒｏｕｐ１（又はＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍ）が登録される。なお、ＵｓｅｒＡ−ｇｒｏｕｐ１とＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍのどちらを登録するかは、ＳＩＰプロキシサーバ２００の実装により異なる。

仮に、クライアントグループ１以外のクライアント端末が宛先として、ＳＩＰメッセージのＴｏヘッダに、ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍを指定したＩＮＶＩＴＥメッセージやＢＹＥメッセージといったリクエストメッセージを送信したとしても、グループタグ挿入部１２１がｇｒｏｕｐ１とは異なるグループタグをＵＲＩに挿入するため、クライアント端末Ａのエントリ（ＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍ）がヒットすることはない。このため、グループ外からのＳＩＰメッセージをＳＩＰプロキシサーバ２００が受信した場合、上述した（処理２）〜（処理４）までの全ての処理について該当するＳＩＰ ＵＲＩがない旨のエラーメッセージ（４０４ Ｎｏｔ Ｆｏｕｎｄのステータスコードが記載されたレスポンスメッセージ）がクライアント端末に返信される。

例えば、クライアントグループ２のクライアント端末ＸがＦｒｏｍ、Ｔｏ、ＣｏｎｔａｃｔヘッダのＳＩＰ ＵＲＩが、
Ｆｒｏｍ： ｓｉｐ：ＵｓｅｒＸ＠ｈｅｒｅ．ｃｏｍ
Ｔｏ： ｓｉｐ：ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍ
Ｃｏｎｔａｃｔ： ＵｓｅｒＸ＠５．６．７．８
のように指定されたＩＮＶＩＴＥメッセージを送信した場合、グループタグ挿入部１２１はリクエストメッセージの各ヘッダに以下のようにグループタグを挿入する。
Ｆｒｏｍ： ｓｉｐ：ＵｓｅｒＸ−ｇｒｏｕｐ２＠ｈｅｒｅ．ｃｏｍ
Ｔｏ： ｓｉｐ：ＵｓｅｒＡ−ｇｒｏｕｐ２＠ｈｅｒｅ．ｃｏｍ
Ｃｏｎｔａｃｔ： ｓｉｐ：ＵｓｅｒＸ−ｇｒｏｕｐ２＠５．６．７．８

この結果、ＳＩＰプロキシサーバ２００はＵｓｅｒＡ−ｇｒｏｕｐ２によってメッセージ転送先のコンタクトアドレスを検索するため、クライアント端末Ａのエントリ（ＵｓｅｒＡ−ｇｒｏｕｐ１）はヒットせず、エラーメッセージがクライアント端末Ｘに返信される。

以上のように、第一の方法では上述した（処理２）から（処理４）までの全てのメッセージについて、グループ外の端末からのメッセージがＳＩＰプロキシサーバ２００によってエラー処理され、クライアント端末に転送されることがない。これにより、グループ内のセキュリティが保たれる。また、（処理１）の処理についても、例えばグループ２のクライアント端末Ｘがグループ１のクライアント端末Ａに成りすますことを意図し、ＲＥＧＩＳＴＥＲメッセージを送信したとしても、ＳＩＰプロキシサーバ２００にはＳＩＰ ＵＲＩ、ＵｓｅｒＡ−ｇｒｏｕｐ２＠ｈｅｒｅ．ｃｏｍが登録されるため成りすましを防ぐことができる。この時、クライアント端末ＡのＳＩＰ ＵＲＩには、ＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍが登録されるため、グループ１のクライアント端末はＳＩＰ ＵＲＩ、ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍを利用して、クライアント端末Ａを指定することが可能である。

しかし、第一の方法には次のような問題がある。クライアント端末が新たなクライアントグループに参加すると、グループ参加前に送信したＲＥＧＩＳＴＥＲメッセージやＳＵＢＳＣＲＩＢＥメッセージにより登録されたエントリは新たに参加したクライアントグループでは参照することができない。換言すれば、参加前のＲＥＧＩＳＴＥＲメッセージやＳＵＢＳＣＲＩＢＥメッセージによってＳＩＰプロキシサーバ２００に登録されたエントリでは、クライアントグループ内の他のクライアント端末からのＳＩＰメッセージを当該クライアント端末に転送することができない。このため、新たなクライアントグループに参加する度にＲＥＧＩＳＴＥＲメッセージやＳＵＢＳＣＲＩＢＥメッセージを送信し直す必要がある。また、クライアント端末がグループ参加前に送信したＲＥＧＩＳＴＥＲメッセージやＳＵＢＳＣＲＩＢＥメッセージによりＳＩＰプロキシサーバ２００に登録されたエントリは期限切れとなるまで有効であるため、明示的な削除を行わない限りグループ参加後であっても一定期間グループ外のクライアント端末から送信されたＳＩＰメッセージが当該クライアント端末に転送され得る。

また、第一の方法単独で前述のようにクライアントグループ外からの（処理２）〜（処理４）のリクエストメッセージがＳＩＰプロキシサーバ２００からクライアントグループへ転送されることを防ぐことはできるが、クライアントグループ外からのリクエストメッセージをトリガとしてＳＩＰプロキシサーバ２００から送信されるレスポンスメッセージについてはクライアントグループへの送信を防ぐ手段が別途必要となる。すなわち、第一の方法単独では、例えばクライアントグループ１からのリクエストメッセージをトリガとしてＳＩＰプロキシサーバ２００から送信されるレスポンスメッセージがクライアントグループ２へ送信されることを防ぐことができない。こうしたレスポンスメッセージはメッセージ送信先グループ識別部１５０によってクライアントグループ外への転送が防がれる。

「第二の方法」
第二の方法では、ＳＩＰメッセージに含まれるパラメタのうち以下の三つの条件を満たすパラメタのいずれかにグループタグを挿入する。
（Ａ）ＳＩＰ ＵＲＩが含まれないパラメタ。
（Ｂ）ＳＩＰプロキシサーバ２００における転送処理により消去されないパラメタ。
（Ｃ）リクエストメッセージと当該リクエストメッセージを受信した際にＳＩＰプロキシサーバ２００が送信するレスポンスメッセージとで同じ値が記載されるパラメタ。

（Ｂ）の条件を満たすパラメタにグループタグを挿入することでＳＩＰサーバ共有モジュール１００がＳＩＰプロキシサーバ２００からリクエストメッセージを受信した際に、当該リクエストメッセージがどのクライアントグループから送信されたリクエストメッセージ（がＳＩＰプロキシサーバ２００から転送されてきた）かを把握することが可能となる。この結果、ＳＩＰプロキシサーバ２００から送信されたリクエストメッセージをリクエストメッセージの送信元クライアント端末が所属するクライアントグループに転送することが可能となる。つまり、リクエストメッセージの送信元クライアント端末が所属するクライアントグループとは異なるクライアントグループに所属するクライアント端末へ転送されることを防ぐことができる。

（Ｃ）の条件を満たすパラメタにグループタグを挿入することでＳＩＰサーバ共有モジュール１００がＳＩＰプロキシサーバ２００からレスポンスメッセージを受信した際に、当該レスポンスメッセージのトリガとなったリクエストメッセージがどのクライアントグループから送信されたかを把握することが可能となる。この結果、リクエストメッセージに対するレスポンスメッセージを、リクエストメッセージの送信元クライアント端末が所属するクライアントグループに転送することが可能となる。つまり、リクエストメッセージの送信元クライアント端末が所属するクライアントグループとは異なるクライアントグループに所属するクライアント端末へ転送されることを防ぐことができる。

上記３つの条件を満たすパラメタとしては、Ｃａｌｌ−ＩＤヘッダやＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ、Ｖｉａヘッダ等が挙げられる。
なお、ＳＩＰメッセージのうち、クライアント端末からプレゼンス情報を発行するためにＳＩＰプロキシサーバ２００へ送信されるメッセージ（ＰＵＢＬＩＳＨメッセージ等）の場合は、上記３つの条件を満たすパラメタにグループタグを挿入するのに加え、プレゼンス情報が記載されているメッセージのボディ部にもグループタグを挿入する。こうすることで、プレゼンス情報が発行元のクライアント端末が所属するクライアントグループの外に通知されることを防ぐことができる（詳細は後述する）。なお、ボディ部分の拡張を行う場合はヘッダ部分のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールド及びＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドを書き換える必要がある。

以下、第二の方法を利用した場合のグループタグの挿入例を説明する。
例えば、クライアントグループ１に所属するクライアント端末Ａが、同じくクライアントグループ１に所属するクライアント端末Ｂへ発呼する場合、クライアント端末ＡがＳＩＰプロキシサーバ２００へ送信したＩＮＶＩＴＥメッセージのＣａｌｌ−ＩＤヘッダにｇｒｏｕｐ−１というタグを挿入する。上述した（処理２）の転送処理の結果、ＳＩＰプロキシサーバ２００からクライアント端末Ｂへ送信されるＩＮＶＩＴＥメッセージのＣａｌｌ−ＩＤヘッダにもｇｒｏｕｐ−１というタグが挿入されている状態となる。これにより、メッセージ送信先グループ識別部１５０は当該メッセージをグループ１に送信すべきと判断し、クライアント端末Ｂへ転送される。

一方、クライアントグループ２に属するクライアント端末Ｘが、クライアントグループ１に属するクライアント端末Ｂへの発呼を行う場合、クライアント端末ＸがＳＩＰプロキシサーバ２００へ送信したＩＮＶＩＴＥメッセージのＣａｌｌ−ＩＤヘッダにはｇｒｏｕｐ−２というタグが挿入される。この場合、ＳＩＰプロキシサーバ２００からクライアント端末Ｂへ送信されるＩＮＶＩＴＥメッセージのＣａｌｌ−ＩＤヘッダにもｇｒｏｕｐ−２というタグが挿入されている状態となるため、メッセージ送信先グループ識別部１５０が当該ＩＮＶＩＴＥメッセージをクライアントグループ２へ転送すべきと判断する。したがってクライアントグループ１に属するクライアントＢへは転送されない。

第二の方法では、クライアント端末から送信されたＲＥＧＩＳＴＥＲメッセージやＳＵＢＳＣＲＩＢＥメッセージに含まれるオリジナルのＳＩＰ ＵＲＩがそのままＳＩＰプロキシサーバ２００に登録される。ＳＩＰプロキシサーバ２００はオリジナルのＳＩＰ ＵＲＩを利用してメッセージの転送処理を行う。

このため、クライアントグループへ参加や脱退してもＳＩＰ Ｐｒｏｘｙサーバに登録されるＳＩＰ ＵＲＩは変わらないため、第一の方法と異なり、クライアントグループ参加の度にＲＥＧＩＳＴＥＲやＳＵＢＳＣＲＩＢＥを行う必要がない。また、クライアントグループ参加後に明示的に参加前までにＳＩＰプロキシサーバ２００に登録されていた情報を削除したりＲＥＧＩＳＴＥＲやＳＵＢＳＣＲＩＢＥを再送信したりしなくても即座にクライアントグループ外メンバからのＳＩＰメッセージが転送されなくなる。

一方で、第二の方法ではクライアントグループ外のクライアント端末からでもＳＩＰ Ｐｒｏｘｙサーバに登録されたエントリを参照できてしまうため、クライアントグループ外のクライアント端末からのリクエストメッセージに対しても上述した（処理３）、（処理４）の処理が行われてしまう。例えば、クライアントグループ２に所属するクライアント端末がクライアントグループ１に所属するクライアント端末の登録情報を取得するため、（処理４）のＯＰＴＩＯＮＳメッセージをＳＩＰプロキシサーバ２００へ送信した場合、当該ＯＰＴＩＯＮＳメッセージはＳＩＰプロキシサーバ２００によって処理され、クライアントグループ２に所属するクライアント端末へ登録情報が通知されてしまう。

グループタグ削除部１２２は、ＳＩＰプロキシサーバ２００から送信されたＳＩＰメッセージに含まれるグループタグを検索して削除すると共に、削除したグループタグをメッセージ送信先グループ識別部１５０に通知する。グループタグの削除はリクエストメッセージ、レスポンスメッセージの別に関係なく行う。なお、グループタグの挿入が第二の方法により、ＳＩＰメッセージのボディ部に対して行われた場合は、グループタグの削除のみならず、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ及びＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈも削除結果に基づいて書き直す。

また、ＳＩＰプロキシサーバ２００から送信されたＳＩＰメッセージがレスポンスメッセージであった場合には、レスポンスメッセージのＶｉａヘッダに挿入されているＳＩＰサーバ共有モジュール１００のＩＰアドレス、ポート番号を削除する。更に、レスポンスメッセージがクライアント端末へ転送されるようにするため、Ｖｉａヘッダに含まれるクライアント端末のコンタクトアドレスをレスポンスメッセージのＩＰヘッダ及びＵＤＰヘッダへセットする。

アドレス変換部１４０は、ＳＩＰプロキシサーバ２００からクライアント端末に対して送信されるＳＩＰメッセージのうち、特にリクエストメッセージをＳＩＰサーバ共有モジュールがインターセプトできるようにＳＩＰメッセージのアドレス変換を行う。

ＳＩＰメッセージのうちレスポンスメッセージについては、リクエストメッセージが転送された経路を逆に辿って転送される。リクエストメッセージが辿った経路はＳＩＰメッセージのヘッダ部分のＶｉａヘッダに記載されるが、Ｖｉａヘッダにはグループタグ挿入部１２１によって、ＳＩＰサーバ共有モジュール１００のＩＰアドレス及びポート番号が記録される。このため、レスポンスメッセージについてはアドレス変換部１４０が特に処理を行わなくてもＳＩＰサーバ共有モジュール１００がインターセプトすることが可能である。

通常、ＳＩＰプロキシサーバ２００がクライアント端末へリクエストメッセージを送信する場合、前述の（処理１）の処理において登録されたクライアント端末のコンタクトアドレスに対してリクエストメッセージを送信する。しかし、ＳＩＰプロキシサーバ２００がクライアント端末のコンタクトアドレスを宛先アドレスに指定してリクエストメッセージを送信した場合、ＳＩＰサーバ共有モジュール１００の配置形態によってはＳＩＰプロキシサーバ２００から送信されたリクエストメッセージがＳＩＰサーバ共有モジュール１００を中継せずに直接クライアント端末に送信されたり、クライアント端末にも到達せずに結果的に廃棄されたりするケースが起こり得る。

このようなケースの発生を防ぐためには以下の二つの方法が考えられる。
一つ目の方法は、ＳＩＰプロキシサーバ２００とＳＩＰ共有モジュール１００の間にトンネリングリンクを構築する方法である。

トンネリングリンクは、当該トンネリングリンクを構築した２つのノードのどちらか一方のノード内で稼動するプログラムがトンネリングリンクに送信したメッセージが必ず他方のノードに送信されるという特徴を持つ。トンネリングリンクの例としてはＩＰＳＥＣトンネルモードやＳＯＦＴＥＴＨＥＲ等で利用されているＥｔｈｅｒ Ｏｖｅｒ ＨＴＴＰＳトンネル等が挙げられる。このため、ＳＩＰプロキシサーバ２００が稼動するノードにおいて、自ノードから送信されるメッセージのうち、宛先ポート番号がＳＩＰで利用するポート番号（通常はＵＤＰ：５０６０番）のメッセージ（すなわち、ＳＩＰメッセージ）を、宛先アドレスによらずトンネリングリンクに送信するという設定をしておけば、ＳＩＰプロキシサーバ２００から送信されたＳＩＰメッセージは宛先アドレスによらずトンネリングリンクのもう一方の終端点、すなわちＳＩＰ共有モジュール１００に送信される。

トンネリングリンクの例を図１０に示す。図１０ではＳＩＰプロキシサーバ２００からＳＩＰ ＵＲＩ、ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍ、ＩＰアドレス、１００．１．１．１のクライアント端末へ送信されるＩＮＶＩＴＥメッセージを例示している。ＳＩＰプロキシサーバ２００から送信されたＩＮＶＩＴＥメッセージ１２１０はＳＩＰプロキシサーバ２００ノードのトンネル終端部１１１０でカプセル化ヘッダ１２２０を付与され、トンネリングリンク１１２０に送信される。なお、トンネル終端部１１１０は条件に合致したパケット（この場合は宛先ポート番号が５０６０番のＵＤＰパケット）にカプセル化ヘッダ１２２０を付与し（エンカプセレイト）、トンネリングリンク１１２０に送信すると共に、トンネリングリンク１１２０経由で受信したパケットのカプセル化ヘッダ１２２０を除去する（デカプセレイト）機能を持つ。図１０の例ではトンネリングリンク１１２０としてＩＰＳＥＣトンネルモードが利用され、カプセル化ヘッダ１２２０としてＩＰＳＥＣヘッダが付与されている。トンネリングリンク１１２０経由でパケットを受信したＳＩＰサーバ共有ノードのトンネル終端部１１３０は受信したパケットをデカプセリングしてＳＩＰサーバ共有モジュール１００へ渡す。図１０に示すようにトンネリングリンクを利用することで、ＳＩＰプロキシサーバ２００から送信されるＳＩＰメッセージは宛先アドレスによらず、ＳＩＰ共有ノードに送信されるため、リクエストメッセージのインターセプトが可能となる。

但し、この方法によりリクエストメッセージのインターセプトを行う場合は、ＳＩＰプロキシサーバ２００においてトンネリングリンク構築のための設定が必要になるのに加え、基本的に全てのＳＩＰメッセージがＳＩＰ共有モジュールに転送されることになるため、ＳＩＰプロキシサーバ２００が他のＳＩＰプロキシサーバ２００へＳＩＰメッセージを送信できなくなる。

この方法によりインターセプトを行う場合、トンネリングリンクの構築やインターセプトしたＳＩＰメッセージのデカプセレイトはＳＩＰサーバ共有ノード内のトンネル終端部１１３０が行うため、アドレス変換部１４０は特に処理を行う必要がない。

二つ目の方法は、アドレス変換部１４０が前述の（処理１）の処理においてクライアント端末がＳＩＰプロキシサーバ２００に対して登録を要求するコンタクトアドレス（以下、オリジナルアドレス）をＳＩＰサーバ共有モジュールがインターセプト可能となるようなアドレス（以下、インターセプトアドレス）に変換する方法（以下、順方向変換）である。以下、二つ目の方法について詳しく述べる。

図１１に、二つ目の方法をとった場合のアドレス変換部１４０の処理フローを示す。
以下、図１１を参照してアドレス変換部１４０の処理フローについて説明する。

（１）ステップＳ１０１
アドレス変換部１４０がメッセージを受信する。
（２）ステップＳ１０２
メッセージを受信した場合、クライアント端末から送信されたメッセージかＳＩＰプロキシサーバ２００から送信されたメッセージかを判別する。
（３）ステップＳ１０３
クライアント端末から送信されたメッセージの場合、まずアドレス変換が必要か否かを判断する。アドレス変換が必要ない場合は、特に処理を行わずメッセージをＳＩＰプロキシサーバ２００へ転送する（ステップＳ１０６）。

ＳＩＰプロキシサーバ２００との間にトンネリングリンクが構築されている場合、アドレス変換は不要と判断する。トンネリングリンクが構築されていない場合、予めクライアント端末に割り当てられるＩＰアドレス領域が分かっており、且つ、当該ＩＰアドレス領域がインターセプト用アドレスに含まれている場合は、アドレス変換不要と判断する。また、特にネットワークレベルのクライアントグループの場合、特定のクライアントグループについて予めクライアントグループに所属するクライアント端末に割り当てられるＩＰアドレス領域が分かっており、且つ、当該アドレス領域がインターセプトアドレスに含まれている場合、当該クライアントグループから送信されたメッセージ、及び当該クライアントグループへＳＩＰプロキシサーバ２００から送信されたメッセージについてはアドレス変換不要と判断する。上記以外の場合はアドレス変換が必要と判断する。なお、どのグループから又はどのグループへ送信されたメッセージかは、メッセージに挿入されたグループタグから判断する。

（４）ステップＳ１０４
ステップＳ１０３において、アドレス変換が必要な場合、メッセージ種別判断部１４０に問い合わせ、当該メッセージがＲＥＧＩＳＴＥＲメッセージか否かを判断する。
（５）ステップＳ１０５
ＲＥＧＩＳＴＥＲメッセージである場合にはヘッダ部分のＣｏｎｔａｃｔヘッダに含まれるＩＰアドレス又はポート番号（オリジナルアドレス）を順方向変換する。
（６）ステップＳ１０６
順方向変換後、ＳＩＰプロキシサーバ２００へＲＥＧＩＳＴＥＲメッセージを送信する。

（７）ステップＳ１０７
一方、ステップＳ１０２の判定において、メッセージがＳＩＰプロキシサーバ２００から送信されたメッセージの場合、まずアドレス変換が必要か否かを判断する。判断基準はクライアント端末から送信されたメッセージを処理する場合と同じである。アドレス変換が不要な場合にはメッセージをグループタグ削除部１２２に渡す（ステップＳ１１２）。
（８）ステップＳ１０８
アドレス変換が必要な場合にはメッセージ種別判断部１４０に問い合わせ、リクエストメッセージであるか否かを判断する。
（９）ステップＳ１０９
リクエストメッセージである場合には、当該ＳＩＰメッセージがクライアント端末へ転送されるように、ＳＩＰメッセージのＩＰヘッダの宛先アドレス又は宛先ポート番号をインターセプトアドレスからオリジナルアドレスへ変換する処理（以下、逆方向変換）を行う。逆方向変換処理後、グループタグ削除部１２２にメッセージを渡す（ステップＳ１１２）。

（１０）ステップＳ１１０
ステップＳ１０８において、ＳＩＰプロキシサーバ２００から送信されたメッセージがレスポンスメッセージの場合は、メッセージ種別判断部１４０に問い合わせ、ＲＥＧＩＳＴＥＲメッセージ対するレスポンスメッセージであるか否かを判断する。
（１１）ステップＳ１１１
ＲＥＧＩＳＴＥＲメッセージ対するレスポンスメッセージの場合は、Ｃｏｎｔａｃｔヘッダに含まれるＩＰアドレス又はポート番号がインターセプトアドレスとなっているので、これをオリジナルアドレスに逆方向変換する。
（１２）ステップＳ１１２
その後、メッセージをグループタグ削除部１２２に渡す。

順方向変換及び逆方向変換を行う際は、双方の変換処理において共通のルールに基づき変換を行う必要がある。本ルールはアドレス変換テーブル１３１に記載されており、順方向変換及び逆方向変換時に参照される。

インターセプトアドレスとしては以下の（Ａ）〜（Ｃ）のアドレス、又はアドレス領域が利用できる。
（Ａ）ＳＩＰサーバ共有モジュール１００自身のＩＰアドレス。
このアドレス領域はＳＩＰサーバ共有モジュール１００の配置形態によらずインターセプトアドレスとして利用できる。以下の変換方法が考えられる。

（Ａ−１）順方向変換時にＳＩＰ ＵＲＩとオリジナルアドレスの対応関係をアドレス変換テーブル１３１に記憶しておき、逆方向変換時にはアドレス変換テーブル１３１を参照し、インターセプトしたメッセージのＵＲＩを元にオリジナルアドレスに変換する。この方法では、ＵＲＩとオリジナルアドレスの関係を全クライアント端末について記憶しておかなければならずクライアント端末の数の増加に伴い、記憶すべきルールの規模が増加する。

（Ａ−２）ＳＩＰサーバ共有モジュール１００自体に複数のアドレスが割り当てられている場合、アドレス変換テーブル１３１にオリジナルアドレスとインターセプト用アドレスの変換ルールを登録しておく。

例えば、ＳＩＰサーバ共有モジュール１００に１３３．１／１６（１３３．１．０．０〜１３３．１．２５５．２５５）の領域に含まれるＩＰアドレス全てが割り当てられている場合、アドレス変換テーブル１３１には、オリジナルアドレスの下位１６ビットをインターセプトアドレス（すなわち１３３．１／１６）にマッピングするというルールを記憶しておく。

例えば、オリジナルアドレスが１０．２．３．４の場合下位１６ビット、すなわち３．４の部分をマッピングし、１３３．１．３．４というインターセプトアドレスに順方向変換する。

ＳＩＰサーバ共有モジュール１００が宛先アドレスが１３３．１．３．４のＳＩＰメッセージを受信した場合には、１３３．１．３．４の３．４をオリジナルアドレスの上位１６ビット、すなわち１０．２と組み合わせ１０．２．３．４に逆方向変換する。

この場合、１０．２／１６の範囲のＩＰアドレスを持つクライアント端末からのみＳＩＰメッセージを受信するという条件であれば、クライアント端末の数によらず、「オリジナルアドレスのＩＰアドレスは上位１６ビットが必ず１０．２であり、下位１６ビットはインターセプトアドレスと同じにする」という変換ルールのみを記憶していれば良い。

クライアント端末のＩＰアドレスの範囲がＳＩＰサーバ共有モジュール１００に割り当てられているＩＰアドレス（すなわちインターセプトアドレス）の範囲よりも広い場合、例えば１０／８の範囲のＩＰアドレスを持つクライアント端末からＳＩＰメッセージを受信する場合、８ビット分の情報がＳＩＰサーバ共有モジュール１００のＩＰアドレスにマッピングできなくなる。例えば、下位１６ビットをマッピングして１３３．１．３．４というインターセプト用アドレスに変換した場合、オリジナルアドレスは１０．ｘ．３．４のｘの部分が不明になる。このような場合には、オリジナルアドレスのうちＳＩＰサーバ共有モジュール１００のＩＰアドレスにマッピングしきれなかった部分を、ＳＩＰサーバ共有モジュールのポート番号にマッピングする方法が考えられる。前述のケースでは上位９ビット目から１６ビット目までの８ビット分の情報がＩＰアドレスにマッピングできないため、ＳＩＰサーバ共有モジュールは８ビット分のポート番号（例えば５０６０〜５３１６（＝５０６０＋２＾８））をインターセプトアドレスとして利用する。

例えば、１０．７．３．４：５０６０のオリジナルアドレスを順方向変換する場合、ＩＰアドレスには下位１６ビットの３．４をマッピングして１３３．１．３．４とし、７の部分（すなわちＩＰアドレスの上位９ビット目から１６ビット目）はポート番号にマッピングして５０６７とし、最終的に１３３．１．３．４：５０６７をインターセプトアドレスとして利用する。

この場合、変換ルールは、「オリジナルアドレスのＩＰアドレスは上位８ビットが必ず１０であり、ポート番号は５０６０である。オリジナルアドレスの下位１６ビットはインターセプトアドレスの下位１６ビットへマッピングし、上位９ビット目から１６ビット目まではポート番号５０６０〜５３１６の範囲にマッピングする」となる。

なお、ポート番号までマッピングの対象に含める場合は、ＳＩＰサーバ共有モジュール１００はインターセプト用アドレスとして利用する複数のポート番号（上の例では５０６０〜５３１６）で待ち受け状態になっている必要がある。

（Ｂ）ＳＩＰプロキシサーバ２００とＳＩＰサーバ共有モジュール１００が配置されたノード（以下、ＳＩＰメッセージ転送ノード）が同一サブネットに接続し、ＳＩＰプロキシサーバ２００においてＳＩＰメッセージ転送ノードのＩＰアドレスがゲートウェイアドレスとして設定されているアドレス領域。

例えば、ＳＩＰメッセージ転送ノードのアドレスが１０．０．０．２５４（サブネット領域は１０．０．０／２４）で、ＳＩＰプロキシサーバ２００において１０．１／１６のアドレスに関するゲートウェイアドレスが１０．０．０．２５４（ＳＩＰメッセージ転送ノードのアドレス）に設定されている場合、ＳＩＰプロキシサーバ２００が１０．１／１６の範囲内にあるアドレス宛に送信したメッセージは、全てＳＩＰメッセージ転送ノードを経由することになる。このため、この場合は１０．１／１６のアドレスをインターセプトアドレスとして利用する。

オリジナルアドレスがインターセプトアドレスの範囲内にない場合には、上記Ａ−２と同じ方法でアドレス変換を行う。

（Ｃ）ローカルループバックアドレス（１２７／８）。
このアドレス領域はＳＩＰサーバ共有モジュール１００とＳＩＰプロキシサーバ２００が物理的に同一のノードに存在する場合（例えば図８に示す構成の場合）に利用できる。上記Ａ−２と同じ方法でアドレス変換を行う。

メッセージ送信先グループ識別部１５０は、グループタグ削除部１２２から通知されたグループタグを元にＳＩＰプロキシサーバ２００から送信されたＳＩＰメッセージを転送すべきクライアント端末が所属するクライアントグループを識別し、ＳＩＰメッセージが当該クライアントグループ以外のクライアントグループに所属するクライアント端末へ転送されることを防止する。これにより、ＳＩＰプロキシサーバ２００から転送されたリクエストメッセージやＳＩＰプロキシサーバ２００から送信されたレスポンスメッセージが当該リクエストメッセージやレスポンスメッセージのトリガとなったリクエストメッセージの送信元クライアント端末が所属するクライアントグループの外部に転送されることを防ぐことができる。具体的処理内容はクライアントグループがネットワークレベルのグループの場合と、アプリケーションレベルのグループの場合とで異なる。

クライアントグループがアプリケーションレベルのグループの場合は以下の処理を行う。
メッセージ送信先グループ識別部１５０は、グループタグにより識別したＳＩＰメッセージを転送すべきクライアントグループと、実際にＳＩＰメッセージの転送先となるクライアント端末が所属するグループが一致することを確認し、一致する場合にのみＳＩＰメッセージをクライアント端末へ転送する。

ＳＩＰメッセージの転送先となるクライアント端末が所属するグループを把握する際にはまず、ＳＩＰメッセージの転送先となるクライアント端末を把握し、その後当該クライアント端末が所属するクライアントグループを把握する。

ＳＩＰメッセージの転送先となるクライアント端末の把握については、ＳＩＰプロキシサーバ２００から受信したＳＩＰメッセージがレスポンスメッセージの場合は、レスポンスメッセージのＶｉａヘッダに記載されているクライアント端末のＩＰアドレス、又はホスト名から把握することができる。また、ＳＩＰメッセージがリクエストメッセージの場合は、ＳＩＰメッセージのＩＰヘッダに記載された宛先ＩＰアドレスから把握することができる。

ＳＩＰメッセージの転送先となるクライアント端末が所属するクライアントグループを把握する方法については、例えばクライアント端末のＩＰアドレスと所属クライアントグループがグループ情報管理サーバに登録されている場合には、ＳＩＰメッセージの転送先となるクライアント端末のＩＰアドレスを元にグループ情報管理サーバに問い合わせを行って、クライアントグループを把握する方法が考えられる。

一方、クライアントグループがネットワークレベルのグループの場合、メッセージ送信先グループ識別部１５０はグループタグ削除部１２２から通知されたクライアントグループに対応するプライベート網へＳＩＰメッセージを送信する。これを実現するため、メッセージ送信先グループ識別部１５０は何らかの方法でＶＰＮ終端部に対して送信先のプライベート網（メッセージを送信する仮想ＩＦ）を指定する必要がある。具体的な送信方法は、ＳＩＰサーバ共有モジュール１００の配置形態によって異なる。

例えば、図７のようにＳＩＰサーバ共有モジュール１００とＶＰＮ終端部分４１０が同一のノードに存在する場合、メッセージ送信先グループ識別部１５０はＶＰＮ終端部４１０においてＶＰＮ毎に用意されている仮想インタフェース４２１のいずれかを指定してＳＩＰメッセージを送信する。

一方、図６や図８のように、ＶＰＮゲートウェイ４００とＳＩＰサーバ共有モジュール１００が異なるノードに存在する場合には、メッセージ送信先グループ識別部１５０がＶＰＮ終端部４１０における仮想インタフェース４２１を直接指定することは不可能である。送信先プライベート網の指定方法としては例えば、ＶＰＮゲートウェイ４００に対して送信するＳＩＰメッセージの送信元ポート番号を送信先プライベート網毎に異なる値にして通知する方法が考えられる。例えば、クライアントグループがｇｒｏｕｐ１からｇｒｏｕｐ３まで存在する場合、送信先グループ識別部１５０は、グループタグ削除部１２２から通知されたクライアントグループがｇｒｏｕｐ１のメッセージは送信元ポート番号１００００〜１０９９９を、ｇｒｏｕｐ２の場合は１１０００〜１１９９９を、ｇｒｏｕｐ３の場合は１２０００〜１２９９９を利用するという具合に、ＳＩＰメッセージ送信先のクライアントグループ（プライベート網）に応じて送信元ポート番号を使い分ける。
図１２に設定例を示す。以下、このような設定を保持するテーブルを、メッセージ送信先グループ識別テーブルと呼ぶ。

ＶＰＮ終端部４１０にも同様のルールをパケット転送ルールに設定しておき、送信元ポート番号が１００００〜１０９９９のメッセージはｇｒｏｕｐ１（に対応するプライベートネットワーク）へ、１１０００〜１１９９９の場合はｇｒｏｕｐ２へ、１２０００〜１２９９９の場合はｇｒｏｕｐ３へ転送するというように設定しておく。図３に例を示す。このような設定を行うことで、ＶＰＮゲートウェイ４００とＳＩＰサーバ共有モジュール１００が異なるノードに存在する場合にも、ＳＩＰサーバ共有モジュール１００からＶＰＮ終端部４１０に対してＳＩＰメッセージを送信すべきプライベート網を指定することが可能になる。

なお、図６や図８のようにＳＩＰサーバ共有モジュール１００とＶＰＮゲートウェイ４００が異なるノードに配置されている場合には、ＳＩＰサーバ共有モジュール１００からクライアント端末へ送信するＳＩＰメッセージは必ずＶＰＮゲートウェイを経由させる必要がある。これを実現する方法としては、図１０で示したのと同様にＶＰＮゲートウェイ４００とＳＩＰサーバ共有モジュール１００が存在するノード（図６のＳＩＰサーバ共有ノード、又は図８のＳＩＰプロキシサーバ２００ノード）との間にトンネリングリンクを構築する方法が考えられる。ＳＩＰサーバ共有モジュール１００が存在するノードにおいて、送信メッセージがＳＩＰメッセージの場合、前述の例では送信元ポート番号が１００００から１２９９９の場合には、送信メッセージをＶＰＮゲートウェイ４００との間に構築されたトンネリングリンクに送信するというように設定しておく。

メッセージ種別判断部１４０は、メッセージ送信先グループ識別部１５０、グループタグ挿抜部１２０、アドレス変換部１３０からの問い合わせに対して、メッセージの種別を応答する。メッセージの種別とは、メッセージがリクエストメッセージ、レスポンスメッセージのどちらであるか、やメッセージのメソッド、レスポンスメッセージのトリガとなったリクエストメッセージのメソッド等である。リクエストメッセージのメソッドは、レスポンスメッセージのヘッダ部分のうちＣＳｅｑヘッダに記載されたメソッドを見ることで判断できる。レスポンスメッセージのＣＳｅｑヘッダにはどのメソッドのリクエストメッセージに対するレスポンスメッセージかが記載されている。

次に、本実施の形態におけるＳＩＰサーバ共有モジュール１００の動作例について説明する。以下の説明は特に断りのない場合、ＳＩＰ通信網が図６の構成の場合の動作例についての説明である。

まず、クライアント端末からＳＩＰプロキシサーバ２００へ送信されるリクエストメッセージを転送する際の動作について図１３Ａ，図１３Ｂを用いて説明する。
図１３Ａ，図１３Ｂは、図６の構成に示すＳＩＰ通信網において、クライアント端末Ａ３１１がＳＩＰプロキシサーバ２００に対してＲＥＧＩＳＴＥＲメッセージを送信する際のシーケンスを示している。

クライアント端末Ａ３１１（ＩＰアドレス１０．１．１．１００）では、ＳＩＰプロキシサーバ２００としてＳＩＰサーバ共有モジュール１００のＩＰアドレス（１７２．１６．１．１００ホスト名の場合もある）が設定されている。クライアント端末Ａ３１１が送信するＲＥＧＩＳＴＥＲメッセージを図１４Ａに示す。クライアント端末Ａ３１１が送信したＲＥＧＩＳＴＥＲメッセージはＶＰＮゲートウェイ４００が中継処理を行う。

（１）ステップＳ２０１
ＶＰＮゲートウェイ４００は、クライアント端末Ａ３１１からＲＥＧＩＳＴＥＲメッセージを受信すると、パケット転送ルールを参照し、後にＳＩＰサーバ共有モジュール１００（のメッセージ送信元グループ識別部１１０）がＲＥＧＩＳＴＥＲメッセージを受信した際に、メッセージ送信元クライアント端末の所属するクライアントグループを識別できるように、受信メッセージに対して変換処理を施す。
（２）ステップＳ２０２
例えば、ＶＰＮゲートウェイ４００においてパケット転送ルールが図３に示すように設定されている場合、ＶＰＮゲートウェイ４００はパケットのＩＰヘッダの送信元ＩＰアドレスを変換した後ＳＩＰサーバ共有モジュール１００へ転送する。図１４Ａのメッセージの場合、ＶＰＮゲートウェイによって図１４Ｂに示すように送信元ＩＰアドレスが変換される。ここでは、図中の点線楕円で示した部分がＶＰＮゲートウェイにおいて変換された送信元ＩＰアドレスである（１０．１０．１０．１００）に変換される。
（３）ステップＳ２０３
ＳＩＰサーバ共有モジュール１００がＲＥＧＩＳＴＥＲメッセージを受信すると、まずメッセージ送信元グループ識別部１１０がメッセージ送信元グループ識別テーブルを参照し、受信したＲＥＧＩＳＴＥＲメッセージの送信元クライアント端末が所属するクライアントグループを識別する。
（４）ステップＳ２０４
メッセージ送信元グループ識別テーブルにはＶＰＮゲートウェイ４００においてメッセージに施された処理に基づきメッセージの送信元クライアント端末が所属するクライアントグループが識別できるように、パケット転送ルールに対応したルールが記載されている。図９に図３に示すパケット転送ルールに対応するメッセージ送信元グループ識別テーブルを示す。図１４Ｂのメッセージを受信した場合、送信元ＩＰアドレスが１０．１０．１０．１００となっているので、メッセージ送信元識別部１１０はクライアントグループをクライアントグループ１と識別し、グループタグ挿入部１２１へ通知する。
（５）ステップＳ２０５
グループタグ挿入部１２１はメッセージ送信元クライアント端末の所属グループの通知を受けると、当該クライアントグループに対応するグループタグをＲＥＧＩＳＴＥＲメッセージに挿入する。また、ＲＥＧＩＳＴＥＲメッセージに対するレスポンスメッセージをＳＩＰサーバ共有モジュール１００がインターセプトできるように、受信したメッセージのＶｉａヘッダにＳＩＰサーバ共有モジュール１００のＩＰアドレス（ホスト名でも良い）及びＳＩＰの待ちうけポート番号（デフォルトのポート番号（５０６０）を使用する際は省略できる）を追記する。グループタグ挿入部１１０が図１４Ｂに示すメッセージに対して上記の処理を施した後の例を図１４Ｃに示す。図中点線楕円で示した部分がグループタグ挿入部１１０において処理された部分である。なお、図１４Ｃで示した例では、グループタグの挿入方法として上述した第一の方法が採られている。

図１４Ｅに、グループタグが第二の方法により挿入された場合の例を示す。ここでは、図中の点線楕円で示した部分がグループタグ挿入部である。図１４Ｅで示した例ではｃａｌｌ−ＩＤヘッダにグループタグが挿入されている。

（６）ステップＳ２０６
メッセージにグループタグが挿入された後、メッセージはアドレス変換部１３０に渡される。
（７）ステップＳ２０７
アドレス変換部１３０はまずアドレス変換が必要か否かを判断する。例えば、図１０に示したようにＳＩＰプロキシサーバ２００とＳＩＰサーバ共有モジュール１００の間にトンネリングリンクが構築されている場合や、オリジナルアドレスがインターセプトアドレスの領域に含まれている場合はアドレス変換が不要となる。
（８）ステップＳ２０８
アドレス変換が必要だと判断した場合は、メッセージ種別判別部１４０に問い合わせメッセージがＲＥＧＩＳＴＥＲメッセージであるか否かを確認する。
（９）ステップＳ２０９
メッセージがＲＥＧＩＳＴＥＲメッセージである場合にはアドレス変換テーブル１３１を参照してＣｏｎｔａｃｔヘッダに含まれるオリジナルアドレスの順方向変換を行う。図１５に示すルールがアドレス変換テーブル１３１に登録されている場合、アドレス変換部１３０は図１４Ｃのメッセージに対して図１４Ｄのように順方向変換を行う。なお、図中の点線楕円で示した部分が変換部分である。
（１０）ステップＳ２１０
アドレス変換後、ＳＩＰプロキシサーバ２００へ、図１４ＤのＲＥＧＩＳＴＥＲメッセージを送信する。
（１１）ステップＳ２１１
ＳＩＰプロキシサーバ２００はＲＥＧＩＳＴＥＲメッセージを受信すると、ＳＩＰ ＵＲＩ、ＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍ（＠以降は省略される場合もある）及びＵＲＩに対応するＩＰアドレスとして、１７２．１７．１．１００を登録する。

上記のようにグループタグ挿入方法として第一の方法がとられた場合、登録後、例えばクライアントグループ２：３００−２に所属するクライアント端末Ｘ３２１がクライアント端末Ａ３１１を宛先とする（ＴｏヘッダにＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍを指定した）ＩＮＶＩＴＥやＯＰＴＩＯＮＳ、ＳＵＢＳＣＲＩＢＥ等のリクエストメッセージを送信したとしても、当該リクエストメッセージはグループタグ挿入部１２１においてグループタグが挿入され、ＴｏヘッダがＵｓｅｒＡ−ｇｒｏｕｐ２＠ｈｅｒｅ．ｃｏｍとなるため、ＳＩＰプロキシサーバ２００は対応するＳＩＰ ＵＲＩが登録されていない旨クライアント端末Ｘ３２１に通知し（４０４ Ｎｏｔ Ｆｏｕｎｄのレスポンスメッセージを返信する）、上述の（処理２）〜（処理４）までの処理は行われない。つまり、クライアントグループ外からのリクエストメッセージに対して上述の（処理２）〜（処理４）までの処理が行われることはない。

また、クライアント端末Ｘ３２１が自身のＵＲＩをＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍと詐称してＲＥＧＩＳＴＥＲメッセージを送信し、クライアント端末Ａ３１１への成りすましを図ったとしても、ＳＩＰプロキシサーバ２００にはＵｓｅｒＡ−ｇｒｏｕｐ２＠ｈｅｒｅ．ｃｏｍというクライアント端末Ａ３１１からのＲＥＧＩＳＴＥＲメッセージに基づき登録されるＳＩＰ ＵＲＩ（ＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍ）とは別のＳＩＰ ＵＲＩが登録される。このため、クライアントグループ外からのリクエストメッセージに基づく成りすましを防ぐことができる。

一方、グループタグ挿入方法として第二の方法がとられた場合、例えば、グループタグ挿入部１２１において図１４Ｅのようにグループタグの挿入が行われた場合、ＳＩＰプロキシサーバ２００には、ＳＩＰ ＵＲＩ、ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍ、ＩＰアドレス、１７２．１７．１．１００が登録される。すなわちグループタグの挿入が行われていないオリジナルのＵＲＩが登録される。

このため、第二の方法がとられた場合、登録後、例えばクライアントグループ２：３００−２に所属するクライアント端末Ｘ３２１がクライアント端末Ａ３１１を宛先とする（ＴｏヘッダにＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍを指定した）ＩＮＶＩＴＥやＯＰＴＩＯＮＳ、ＳＵＢＳＣＲＩＢＥ等のリクエストメッセージを送信すると、第一の方法とは異なり、クライアントグループ外からのリクエストメッセージにも関わらずＳＩＰプロキシサーバ２００では（処理２）〜（処理４）の処理が行われる。このため、（処理３）の処理についてはグループ外からでも情報通知のための登録が行えることになる。例えばクライアントグループ２：３００−２のクライアント端末Ｘ３２１からクライアントグループ１：３００−１のクライアント端末Ａ３１１のプレゼンス情報の通知を受けるための登録要求を行った場合、クライアントグループ外端末への登録要求にも関わらずＳＩＰプロキシサーバ２００に登録される。但し、後述するように実際にクライアント端末Ａ：３１１のプレゼンス情報がクライアント端末Ｘ３２１に通知されることはない。あくまで通知要求が登録されるだけである。また、（処理４）の処理についても、クライアントグループ外からでもクライアント端末の情報を取得できることになってしまう。

但し、第二の方法によりグループタグの挿入が行われて、クライアントグループ外からのリクエストメッセージに対してＳＩＰプロキシサーバ２００が（処理２）〜（処理４）までの処理を行ったとしても、処理の結果ＳＩＰプロキシサーバ２００から転送されるリクエストメッセージ及びＳＩＰプロキシサーバ２００から送信されるレスポンスメッセージが、当該リクエストメッセージの送信元クライアントグループ以外に転送されることはない。例えばクライアントグループ２：３００−２に所属するクライアント端末から送信されたリクエストメッセージがクライアントグループ２：３００−２以外のクライアントグループに所属するクライアント端末に転送されることはないし、当該リクエストメッセージに対するＳＩＰプロキシサーバ２００からのレスポンスメッセージがクライアントグループ２以外のクライアントグループに所属するクライアント端末に送信されることはない。これについては後述する。

次に、ＳＩＰプロキシサーバ２００からクライアント端末へ送信されるレスポンスメッセージを転送する際の動作例について説明する。
図１６に、図１３Ａ，図１３Ｂで示したＲＥＧＩＳＴＥＲメッセージに対するレスポンスメッセージの転送例を示す。

（１）ステップＳ３０１
ＳＩＰプロキシサーバ２００はリクエストメッセージを受信すると、リクエストメッセージに対するレスポンスメッセージをリクエストメッセージのＶｉａヘッダに記載された経路を逆に辿って転送する。ＳＩＰプロキシサーバ２００が図１４Ｄに示すＲＥＧＩＳＴＥＲメッセージを受信した場合に送信するレスポンスメッセージの例を図１７Ａに示す。図１７Ａに示すレスポンスメッセージはＳＩＰサーバ共有モジュール１００へ送信される。

（２）ステップＳ３０２
ＳＩＰサーバ共有モジュール１００がレスポンスメッセージを受信すると、まずアドレス変換部１３０がメッセージ処理を行う。アドレス変換部１３０は順方向変換を行う際と同じ基準でアドレス変換が必要か否かを判断し、必要と判断した場合は図１１に示すフローチャートにしたがってアドレス変換テーブルを参照して逆方向変換を行う。図１７Ａに示すレスポンスメッセージを受信した場合、当該メッセージのＣＳｅｑヘッダからＲＥＧＩＳＴＥＲメッセージに対するレスポンスメッセージであることが分かるので、Ｃｏｎｔａｃｔヘッダに含まれるＩＰアドレス及びポート番号をインターセプトアドレスからオリジナルアドレスへ変換する。図１７Ａのメッセージに対して上記処理を行った後のメッセージを図１７Ｂに示す。ここでは、図中の点線楕円部がアドレス変換部１３０が変換を行った部分である。
（３）ステップＳ３０３
変換処理後、メッセージをグループタグ削除部１２２に渡す。

（４）ステップＳ３０４
グループタグ削除部１２２は渡されたメッセージに挿入されたグループタグを削除する。また、レスポンスメッセージのＶｉａヘッダに含まれるＳＩＰサーバ共有モジュール１００のＩＰアドレス及びポート番号を削除する。更に、Ｖｉａヘッダに含まれるクライアント端末のＩＰアドレス、ポート番号をメッセージのＩＰヘッダの宛先ＩＰアドレス、ＵＤＰヘッダの宛先ポート番号に設定する。
（５）ステップＳ３０５
これらの処理を行った後、グループタグをメッセージ送信先グループ識別部１５０に渡す。図１７Ｃにグループタグ削除部１２２が図１７Ｂに示すメッセージに対して処理を行った結果を示す。ここでは、図中の点線楕円部がグループタグ削除部１２２の処理した部分である。

（６）ステップＳ３０６
メッセージ送信先グループ識別部１５０は、通知グループタグからメッセージ送信先のクライアントグループを識別して、メッセージ送信先グループ識別テーブルを参照してメッセージ処理を行い、グループタグに対応するクライアントグループの外部にメッセージが転送されることを防止する。例えば、メッセージ送信先グループ識別テーブルとして図１２に示すテーブルを保持している場合、図１７ＣのメッセージのＵＤＰヘッダの送信元ポート番号をクライアントグループ１に割り当てられたポート番号に変換する。変換後のメッセージを図１７Ｄに示す。ここでは、図中の点線楕円部が変換部分である。
（７）ステップＳ３０７
メッセージ処理後、メッセージをクライアント端末へ送信する。

（８）ステップＳ３０８
メッセージ送信先グループ識別部１５０がクライアント端末へ送信したメッセージはＶＰＮゲートウェイ４００において中継処理される。ＶＰＮゲートウェイ４００はパケット転送ルールを参照しメッセージをどの仮想インタフェースから送信するかを決定する。
（９）ステップＳ３０９
例えば、図３に示すパケット転送ルールが設定されている場合、ＶＰＮゲートウェイは図１７Ｄに示すメッセージを受け取ると、送信元ポート番号から仮想インタフェース１から送信すべきと判断し、仮想インタフェース１から図１７Ｄのメッセージを送信する。

なお、ＳＩＰプロキシサーバ２００から送信されるレスポンスメッセージには（グループタグの挿入方法が第一の方法、第二の方法であるかに関わらず）当該レスポンスメッセージのトリガとなったリクエストメッセージと同じグループタグが挿入される。したがって、メッセージ送信先グループ識別部１５０における処理によってレスポンスメッセージがリクエストメッセージ送信元のクライアント端末が所属するクライアントグループとは異なるクライアントグループに転送されることが防止される。

図１６では第一の方法でグループタグの挿入が行われた場合の例を示したが、第二の方法でグループタグの挿入が行われた場合は以下のような処理が行われる。

例えば、グループタグをＣａｌｌ−ＩＤに挿入した場合、レスポンスメッセージのＣａｌｌ−ＩＤは当該レスポンスメッセージのトリガとなったリクエストメッセージと同じものが利用されることになっている（ＲＦＣでそのように定められている）ため、リクエストメッセージのＣａｌｌ−ＩＤに挿入されたグループタグと同じものがレスポンスメッセージにも挿入されることになる。したがって、メッセージ送信先グループ識別部１５０がレスポンスメッセージをグループタグに対応するクライアントグループに転送することで、リクエストメッセージ送信元のクライアント端末が所属するクライアントグループとは異なるクライアントグループにレスポンスメッセージを転送することを防ぐことができる。

次に、ＳＩＰプロキシサーバ２００からクライアント端末へ送信されるリクエストメッセージを転送する際のＳＩＰサーバ共有モジュール１００の動作について説明する。

図１８に転送時の動作例を示す。
図１８はクライアントグループ１：３００−１に所属するクライアント端末Ｂ：３１２がクライアント端末Ａ：３１１へＩＮＶＩＴＥメッセージを送信した際の動作を示したものである。なお、ＩＮＶＩＴＥメッセージはクライアント端末Ｂ：３１２からＳＩＰプロキシサーバ２００を経由してクライアント端末Ａ：３１１へ送信される。なお、図１８では、クライアント端末Ｂ：３１２からＳＩＰプロキシサーバ２００サーバ２００へＩＮＶＩＴＥメッセージを送信する際のシーケンスは省略している。

（１）ステップＳ４０１
ＳＩＰサーバ共有モジュール１００がＳＩＰプロキシサーバ２００からリクエストメッセージを受信すると、まずアドレス変換部１３０がメッセージの処理を行う。アドレス変換部１３０は受信したリクエストメッセージに対するアドレスの逆方向変換が必要か否かを判断し、必要である場合にはアドレス変換テーブル１３１を参照し、受信したリクエストメッセージのＩＰヘッダの宛先ＩＰアドレス及びＵＤＰヘッダの宛先ポート番号をオリジナルアドレスに戻す逆方向変換を行う。例えば、図１９Ｂに示したＩＮＶＩＴＥメッセージをＳＩＰプロキシサーバ２００から受信した場合、ＩＮＶＩＴＥメッセージは図１９Ｃに示すメッセージのように逆方向変換される。ここでは、図中の点線楕円部が変換部であり、図１５に示すアドレス変換ルールを参照した場合を示している。
（２）ステップＳ４０２
アドレス変換後、メッセージグループタグ削除部１２２に渡される。
（３）ステップＳ４０３
グループタグが削除される。
（４）ステップＳ４０４
グループタグがメッセージ送信先グループ識別部１５０に渡される。
（５）ステップＳ４０５
その後、メッセージ送信先グループ識別部１５０においてレスポンスメッセージ転送時と同様の処理が行われる。
（６）ステップＳ４０６〜Ｓ４０８
レスポンスメッセージ転送時と同様の処理が行われた後、ＶＰＮゲートウェイ４００を中継してクライアント端末へ転送される。

なお、第二の方法でグループタグの挿入が行われた場合、前述のようにクライアントグループ外からのリクエストメッセージであってもＳＩＰプロキシサーバ２００において（処理２）から（処理４）までの処理が行われる。しかし、ＳＩＰプロキシサーバ２００から転送されるリクエストメッセージにはＳＩＰプロキシサーバ２００が受信したリクエストメッセージと同じグループタグが挿入されるため、メッセージ送信先グループ識別部１５０における処理によりリクエストメッセージ送信元のクライアント端末が所属するクライアントグループとは異なるクライアントグループに転送されることはない。

例えば、グループタグをＣａｌｌ−ＩＤに挿入した場合、ＳＩＰプロキシサーバ２００から転送されたリクエストメッセージのＣａｌｌ−ＩＤにはＳＩＰプロキシサーバ２００が受信したリクエストメッセージと同じものが利用されることになっている。したがって、例えばメッセージ送信先グループ識別部１５０がＳＩＰプロキシサーバ２００から転送されたリクエストメッセージに挿入されているグループタグに対応するクライアントグループにリクエストメッセージを転送することで、リクエストメッセージ送信元のクライアント端末が所属するクライアントグループとは異なるクライアントグループにリクエストメッセージを転送することを防ぐことができる。

次に、プレゼンス情報の通知が行われる際のＳＩＰサーバ共有モジュール１００の動作について説明する。
プレゼンス情報の通知は、プレゼンス情報を発行するクライアント端末（以下、発行端末）がプレゼンス情報をＳＩＰプロキシサーバ２００に対して通知する（ＲＦＣではＰＵＢＬＩＳＨメッセージを利用する旨規定されているが、ＲＦＣによる規定から日が浅いこともありＰＵＢＬＩＳＨメッセージとは異なるメッセージによって通知される場合もある）と、予め上述の（処理３）の処理によりＳＩＰプロキシサーバ２００に発行端末のプレゼンス情報の通知要求を登録しているクライアント端末（以下、受信端末）に対してＳＩＰプロキシサーバ２００からプレゼンス情報が通知される（ＮＯＴＩＦＹメッセージが利用される）という手順で行われる。

発行端末が所属するクライアントグループ以外のグループに所属するクライアント端末に対してプレゼンス情報が通知されることを防ぐ必要がある。

第一の方法によりグループタグの挿入が行われた場合、発行端末が所属するクライアントグループ以外のグループに所属するクライアント端末からの通知要求がＳＩＰプロキシサーバ２００に登録されることはない。受信端末はＳＵＢＳＣＲＩＢＥメッセージのＴｏヘッダに発行端末のＳＩＰ ＵＲＩを指定して通知要求を行うが、ＳＩＰサーバ共有ノードによってＴｏヘッダに記載されたＳＩＰ ＵＲＩへのグループタグ挿入が行われるため、グループ外端末からの通知要求の登録は防がれる。例えばグループ１に所属するクライアント端末Ａ（ＳＩＰ ＵＲＩ、ＵｓｅｒＡ＠ｈｅｒｅ．ｃｏｍ）のプレゼンス情報についてグループ２のクライアント端末Ｘが通知要求をした場合、クライアント端末ＡのＳＩＰ ＵＲＩはＳＩＰサーバにおいてＵｓｅｒＡ−ｇｒｏｕｐ１＠ｈｅｒｅ．ｃｏｍと登録されるのに対し、クライアント端末Ｘの通知要求のＴｏヘッダはＵｓｅｒＡ−ｇｒｏｕｐ２＠ｈｅｒｅ．ｃｏｍと変換されるため、ＳＩＰプロキシサーバ２００はクライアント端末Ｘからの通知要求に対して要求された発行端末は存在しない旨応答する。

一方、第二の方法によりグループタグの挿入が行われた場合、前述のようにグループ外のクライアント端末からの通知要求の登録を防ぐことはできない。グループ外からのリクエストメッセージに対して（処理３）の処理が行われる。

第二の方法でグループタグの挿入が行われた場合、次の処理により発行端末が所属するクライアントグループ以外のグループに所属するクライアント端末に対してプレゼンス情報が通知されることが防がれる。

一般に発行端末からのプレゼンス情報はＰＵＢＬＩＳＨメッセージのボディ部に記載される。ボディ部に記載された情報がそのままＮＯＴＩＦＹメッセージのボディ部に転載され、受信端末に通知される。したがって、ＳＩＰサーバ共有モジュールはＰＵＢＬＩＳＨメッセージのボディ部にグループタグを挿入し、且つ、ＮＯＴＩＦＹメッセージのボディ部に挿入されたグループタグに対応するグループにＮＯＴＩＦＹメッセージを転送すれば良い。なお、ＮＯＴＩＦＹメッセージには、ＰＵＢＬＩＳＨメッセージに挿入したグループタグと同じグループタグが挿入されている。

具体的に、グループタグ挿入部がクライアント端末から受信したＳＩＰメッセージがＰＵＢＬＩＳＨメッセージである場合にはボディ部に対してグループタグを挿入し、ＳＩＰプロキシサーバ２００から受信したＳＩＰメッセージがＮＯＴＩＦＹメッセージである場合には、ボディ部に挿入されているグループタグを削除し、メッセージ送信先グループ識別部に通知すれば良い。

以上のように、本発明は、複数のクライアントグループと複数のクライアントグループが利用するＳＩＰプロキシサーバとの間で送受信されるＳＩＰメッセージの中継を行うＳＩＰサーバ共有モジュールに関するものである。
このＳＩＰサーバ共有モジュールは、メッセージ送信元グループ識別部と、グループタグ挿入部と、グループタグ削除部と、メッセージ送信先グループ識別部とを有することを特徴とする。
メッセージ送信元グループ識別部は、ＳＩＰメッセージのうち、クライアントグループに所属するクライアント端末からＳＩＰプロキシサーバへ送信されるクライアント送信ＳＩＰメッセージに対して、クライアント送信ＳＩＰメッセージを送信したクライアント端末が所属するクライアントグループを識別する。グループタグ挿入部は、メッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグをクライアント送信ＳＩＰメッセージに挿入する。グループタグ削除部は、ＳＩＰメッセージのうち、ＳＩＰプロキシサーバからクライアントグループに所属するクライアント端末へ送信されるサーバ送信ＳＩＰメッセージに対して、サーバ送信ＳＩＰメッセージに含まれるグループタグの削除を行う。メッセージ送信先グループ識別部は、サーバ送信ＳＩＰメッセージに含まれるグループタグに対応するクライアントグループと異なるクライアントグループに所属するクライアント端末にサーバ送信ＳＩＰメッセージが送信されることを防止する。

メッセージ送信先グループ識別部は、サーバ送信ＳＩＰメッセージに含まれるグループタグに対応するクライアントグループとサーバ送信ＳＩＰメッセージの実際の送信先クライアント端末が所属するクライアントグループとが一致する場合にのみ、サーバ送信ＳＩＰメッセージを送信先クライアント端末へ転送する。

メッセージ送信先グループ識別部は、ＳＩＰサーバ共有モジュールが配置されたノードに複数の仮想的又は物理的ネットワークインタフェースが存在する場合には、ＳＩＰサーバ送信メッセージに含まれるグループタグに対応するクライアントグループ毎に異なるネットワークインタフェースを指定して、ＳＩＰサーバ送信メッセージを送信する。

メッセージ送信先グループ識別部は、サーバ送信ＳＩＰメッセージのＩＰヘッダ又はＵＤＰヘッダに含まれるパラメタをＳＩＰサーバ送信メッセージに含まれるグループタグに対応するクライアントグループ毎に異なるパラメタ領域に変換した後、送信先クライアント端末に転送する。

グループタグ挿入部は、メッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグをクライアント送信ＳＩＰメッセージに含まれるパラメタのうち、以下の全ての条件を満たすいずれかのパラメタに対してグループタグを挿入する。
（１）ＳＩＰ ＵＲＩが含まれないＳＩＰプロキシサーバにおける転送処理により消去されない。
（２）リクエストメッセージとリクエストメッセージを受信した際にＳＩＰプロキシサーバが送信する。
（３）レスポンスメッセージとで同じ値が記載される。

グループタグ挿入部は、メッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグをクライアント送信ＳＩＰメッセージのヘッダ部分に含まれるＳＩＰ ＵＲＩのうちユーザ識別子の部分に挿入する。

グループタグ挿入部は、クライアント送信ＳＩＰメッセージがＳＩＰプロキシサーバに対してプレゼンス情報を通知するメッセージである場合には、クライアント送信ＳＩＰメッセージのボディ部分にも更にグループタグを挿入する。

グループタグ挿入部は、メッセージ送信元グループ識別部が識別したクライアントグループが複数の場合は、クライアント送信ＳＩＰメッセージのコピーをメッセージ送信元グループ識別部が識別したクライアントグループ数分作成し、コピーのそれぞれに対してメッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグを挿入する。

グループタグ挿入部は更に、クライアント送信ＳＩＰメッセージがリクエストメッセージである場合に、ＳＩＰサーバ共有モジュールが配置されたノードのＩＰアドレス及びＳＩＰサーバ共有モジュールがＳＩＰメッセージの待ち受けに利用するポート番号をクライアント送信ＳＩＰメッセージのＶｉａヘッダへ追記し、グループタグ削除部は更に、サーバ送信ＳＩＰメッセージがレスポンスメッセージである場合に、サーバ送信ＳＩＰメッセージのＶｉａヘッダに記載されたＳＩＰサーバ共有モジュールが配置されたノードのＩＰアドレス及びＳＩＰサーバ共有モジュールがＳＩＰメッセージの待ち受けに利用するポート番号を削除すると共に、サーバ送信ＳＩＰメッセージのＶｉａヘッダに記載されたＳＩＰサーバ共有モジュールが配置されたノードのＩＰアドレス及びＳＩＰサーバ共有モジュールがＳＩＰメッセージの待ち受けに利用するポート番号をサーバ送信ＳＩＰメッセージのＩＰヘッダの宛先ＩＰアドレスとＵＤＰヘッダの宛先ポート番号に設定する。

また、本発明のＳＩＰサーバ共有モジュールは、オリジナルアドレスと、アドレス変換ルールと、アドレス変換部とを更に有する。
オリジナルアドレスは、クライアント端末がＲＥＧＩＳＴＥＲメッセージによってＳＩＰプロキシサーバへの登録を要求するアドレスである。
アドレス変換ルールには、ＳＩＰプロキシサーバが送信するＳＩＰメッセージの宛先アドレスに設定された場合に、ＳＩＰメッセージをＳＩＰサーバ共有モジュールがインターセプト可能となるアドレスであるインターセプトアドレスとを相互に変換するアドレス変換方法が記載されている。
アドレス変換部は、クライアント送信ＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージである場合には、クライアント送信ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるオリジナルアドレスを、アドレス変換ルールを参照してインターセプトアドレスに変換する。また、サーバ送信ＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージに対するレスポンスメッセージである場合には、サーバ送信ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるインターセプトアドレスを、アドレス変換ルールを参照してオリジナルアドレスに変換する。更に、サーバ送信ＳＩＰメッセージがリクエストメッセージである場合には、サーバ送信ＳＩＰメッセージのＩＰヘッダ及びＵＤＰヘッダに指定されているインターセプトアドレスを、アドレス変換ルールを参照してオリジナルアドレスに変換する。

なお、本発明のアドレス変換方法では、Ｍビットの広さを持つＩＰアドレス領域Ａに含まれる任意のＩＰアドレスとＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスａとＮビットの広さを持つＩＰアドレス領域Ｂに含まれる任意のＩＰアドレスとＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスｂとを相互に変換する。
また、アドレスａをアドレスｂに変換する際には、アドレスａのＩＰアドレスのうちＸ＜Ｎを満たすＸビット分をアドレスｂのＩＰアドレスにマッピングし、のこりのＭ−Ｘビット分をアドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号にマッピングし、アドレスｂをアドレスａに変換する際には、アドレスｂのＩＰアドレスのうちＸビット分とアドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のうちＭ−Ｘビット分とを組み合わせてアドレスａのＩＰアドレスに変換する。

アドレス変換ルールは、インターセプトアドレスとして、ＳＩＰプロキシサーバにおいてＳＩＰ共有モジュールがゲートウェイとして設定されているＩＰアドレス領域を利用する。

アドレス変換ルールは、インターセプトアドレスとして、ローカルループバックアドレス領域に含まれるＩＰアドレス領域を利用する。

図１は、本発明のＳＩＰサーバ共有モジュールの構成を示すブロック図である。 図２は、ネットワークレベルのクライアントグループの場合の一般的なＳＩＰ通信網の構成を示す図である。 図３は、ＶＰＮゲートウェイにおけるパケット転送ルールを示す図である。 図４は、アプリケーションレベルのクライアントグループの場合の一般的なＳＩＰ通信網の構成を示す図である。 図５は、アプリケーションレベルのクライアントグループの場合の一般的なＳＩＰ通信網の構成を示す図である。 図６は、本発明のＳＩＰサーバ共有モジュールが単独でノードに配置された場合のＳＩＰ通信網の構成例を示す図である。 図７は、本発明のＳＩＰサーバ共有モジュールがＶＰＮ終端部と同一のノードに配置された場合のＳＩＰ通信網の構成例を示す図である。 図８は、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバと同一のノードに配置された場合のＳＩＰ通信網の構成例を示す図である。 図９は、本発明のＳＩＰサーバ共有モジュール内のメッセージ送信元グループ識別部が保持するメッセージ送信元グループ識別テーブルを示す図である。 図１０は、ＳＩＰプロキシサーバとＳＩＰサーバ共有モジュールの間でトンネリングが構築された場合のメッセージ構成を示す図である。 図１１は、本発明のＳＩＰサーバ共有モジュール内のアドレス変換部の動作を示すフローチャート図である。 図１２は、本発明のＳＩＰサーバ共有モジュール内のメッセージ送信先グループ識別部が保持するメッセージ送信先グループ識別テーブルを示す図である。 図１３Ａは、本発明のＳＩＰサーバ共有モジュールがクライアント端末から送信されたリクエストメッセージをＳＩＰプロキシサーバへ転送する際の動作を示すシーケンス図である。 図１３Ｂは、本発明のＳＩＰサーバ共有モジュールがクライアント端末から送信されたリクエストメッセージをＳＩＰプロキシサーバへ転送する際の動作を示すシーケンス図である。 図１４Ａは、本発明のＳＩＰサーバ共有モジュールがクライアント端末から送信されたリクエストメッセージをＳＩＰプロキシサーバへ転送する際のメッセージ構成を示す図である。 図１４Ｂは、本発明のＳＩＰサーバ共有モジュールがクライアント端末から送信されたリクエストメッセージをＳＩＰプロキシサーバへ転送する際のメッセージ構成を示す図である。 図１４Ｃは、本発明のＳＩＰサーバ共有モジュールがクライアント端末から送信されたリクエストメッセージをＳＩＰプロキシサーバへ転送する際のメッセージ構成を示す図である。 図１４Ｄは、本発明のＳＩＰサーバ共有モジュールがクライアント端末から送信されたリクエストメッセージをＳＩＰプロキシサーバへ転送する際のメッセージ構成を示す図である。 図１４Ｅは、本発明のＳＩＰサーバ共有モジュールがクライアント端末から送信されたリクエストメッセージをＳＩＰプロキシサーバへ転送する際のメッセージ構成を示す図である。 図１５は、本発明のＳＩＰサーバ共有モジュール内のアドレス変換テーブルに設定されたアドレス変換ルールを示す図である。 図１６は、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから送信されたレスポンスメッセージをクライアント端末へ転送する際の動作を示すシーケンス図である。 図１７Ａは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから送信されたレスポンスメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。 図１７Ｂは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから送信されたレスポンスメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。 図１７Ｃは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから送信されたレスポンスメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。 図１７Ｄは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから送信されたレスポンスメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。 図１８は、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから転送されたリクエストメッセージをクライアント端末へ転送する際の動作を示すシーケンス図である。 図１９Ａは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから転送されたリクエストメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。 図１９Ｂは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから転送されたリクエストメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。 図１９Ｃは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから転送されたリクエストメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。 図１９Ｄは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから転送されたリクエストメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。 図１９Ｅは、本発明のＳＩＰサーバ共有モジュールがＳＩＰプロキシサーバから転送されたリクエストメッセージをクライアント端末へ転送する際のメッセージ構成を示す図である。

符号の説明

１００ ＳＩＰサーバ共有モジュール
１１０ メッセージ送信元グループ識別部
１２０ グループタグ挿抜部
１２１ グループタグ挿入部
１２２ グループタグ削除部
１３０ アドレス変換部
１３１ アドレス変換テーブル
１４０ メッセージ種別判断部
１５０ メッセージ送信先グループ識別部
２００ ＳＩＰプロキシサーバ
３００（−ｉ、ｉ＝１〜ｎ） クライアントグループ
３１１ クライアント端末
３１２ クライアント端末
３２１ クライアント端末
３２２ クライアント端末
４００ ＶＰＮゲートウェイ
４１０ ＶＰＮ終端部
４２０ ＶＰＮ側インタフェース
４２１（−ｉ、ｉ＝１〜ｎ） 仮想インタフェース
４３０ データセンタ側インタフェース
５００ 公衆網
６００ データセンタネットワーク
７００ グループ情報管理サーバ
８００ ＳＩＰサーバ共有ノード
９００ アプリケーションゲートウェイ
１１１０ トンネル終端部
１１２０ トンネリングリンク
１１３０ トンネル終端部
１２１０ ＳＩＰメッセージ
１２２０ カプセル化ヘッダ

Claims (18)

1. 複数のクライアントグループと前記複数のクライアントグループが利用するＳＩＰプロキシサーバとの間で送受信されるＳＩＰメッセージの中継を行うＳＩＰサーバ共有モジュールであって、
   前記ＳＩＰメッセージのうち、前記複数のクライアントグループの各々に所属するクライアント端末から前記ＳＩＰプロキシサーバへ送信されるクライアント送信ＳＩＰメッセージから、前記クライアント送信ＳＩＰメッセージを送信したクライアント端末が所属するクライアントグループを識別するメッセージ送信元グループ識別部と、
   前記メッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグを前記クライアント送信ＳＩＰメッセージに挿入するグループタグ挿入部と、
   前記ＳＩＰメッセージのうち、前記ＳＩＰプロキシサーバから前記クライアントグループに所属するクライアント端末へ送信されるサーバ送信ＳＩＰメッセージに対して、前記サーバ送信ＳＩＰメッセージに含まれるグループタグの削除を行うグループタグ削除部と、
   前記サーバ送信ＳＩＰメッセージに含まれるグループタグに対応するクライアントグループと異なるクライアントグループに所属するクライアント端末に前記サーバ送信ＳＩＰメッセージが送信されることを防止するメッセージ送信先グループ識別部と
   を有する
   ＳＩＰサーバ共有モジュール。
2. 請求項１に記載のＳＩＰサーバ共有モジュールにおいて、
   前記メッセージ送信先グループ識別部は、前記サーバ送信ＳＩＰメッセージに含まれるグループタグに対応するクライアントグループと、前記サーバ送信ＳＩＰメッセージの実際の送信先クライアント端末が所属するクライアントグループとが一致する場合、前記サーバ送信ＳＩＰメッセージを前記送信先クライアント端末へ転送する
   ＳＩＰサーバ共有モジュール。
3. 請求項１に記載のＳＩＰサーバ共有モジュールにおいて、
   前記メッセージ送信先グループ識別部は、当該ＳＩＰサーバ共有モジュールが配置されたノードに複数の仮想的又は物理的ネットワークインタフェースが存在する場合、前記ＳＩＰサーバ送信メッセージに含まれるグループタグに対応するクライアントグループ毎に異なるネットワークインタフェースを指定して、前記ＳＩＰサーバ送信メッセージを送信する
   ＳＩＰサーバ共有モジュール。
4. 請求項１に記載のＳＩＰサーバ共有モジュールにおいて、
   前記メッセージ送信先グループ識別部は、前記サーバ送信ＳＩＰメッセージのＩＰヘッダ又はＵＤＰヘッダに含まれるパラメタを、前記ＳＩＰサーバ送信メッセージに含まれるグループタグに対応するクライアントグループ毎に異なるパラメタ領域に変換した後、前記サーバ送信ＳＩＰメッセージを送信先クライアント端末に転送する
   ＳＩＰサーバ共有モジュール。
5. 請求項１乃至４のいずれか一項に記載のＳＩＰサーバ共有モジュールにおいて、
   前記グループタグ挿入部は、前記メッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグを、前記クライアント送信ＳＩＰメッセージに含まれるパラメタのうち、ＳＩＰプロキシサーバへ登録するＵＲＩが含まれず、且つ、ＳＩＰプロキシサーバにおける転送処理により消去されず、且つ、リクエストメッセージと前記リクエストメッセージを受信した際にＳＩＰプロキシサーバが送信するレスポンスメッセージとで同じ値が記載される、という条件を満たすいずれかのパラメタに対して挿入する
   ＳＩＰサーバ共有モジュール。
6. 請求項１乃至４のいずれか一項に記載のＳＩＰサーバ共有モジュールにおいて、
   前記グループタグ挿入部は、前記メッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグを、前記クライアント送信ＳＩＰメッセージのヘッダ部分に含まれるＵＲＩのうちユーザ識別子の部分に挿入する
   ＳＩＰサーバ共有モジュール。
7. 請求項１乃至６のいずれか一項に記載のＳＩＰサーバ共有モジュールにおいて、
   前記グループタグ挿入部は、前記クライアント送信ＳＩＰメッセージが前記ＳＩＰプロキシサーバに対してプレゼンス情報を通知するメッセージである場合、前記クライアント送信ＳＩＰメッセージのボディ部分にも更にグループタグを挿入する
   ＳＩＰサーバ共有モジュール。
8. 請求項１乃至７のいずれか一項に記載のＳＩＰサーバ共有モジュールにおいて、
   前記グループタグ挿入部は、前記メッセージ送信元グループ識別部が識別したクライアントグループが複数の場合、前記クライアント送信ＳＩＰメッセージのコピーを前記メッセージ送信元グループ識別部が識別したクライアントグループ数分作成し、前記コピーのそれぞれに対して前記メッセージ送信元グループ識別部が識別したクライアントグループに対応するグループタグを挿入する
   ＳＩＰサーバ共有モジュール。
9. 請求項１乃至８のいずれか一項に記載のＳＩＰサーバ共有モジュールにおいて、
   前記グループタグ挿入部は、更に、前記クライアント送信ＳＩＰメッセージがリクエストメッセージである場合、ＳＩＰサーバ共有モジュールが配置されたノードのＩＰアドレス及び前記ＳＩＰメッセージの待ち受けに利用するポート番号を前記クライアント送信ＳＩＰメッセージのＶｉａヘッダへ追記し、
   前記グループタグ削除部は、更に、前記サーバ送信ＳＩＰメッセージがレスポンスメッセージである場合、前記サーバ送信ＳＩＰメッセージのＶｉａヘッダに記載されたＳＩＰサーバ共有モジュールが配置されたノードのＩＰアドレス及びＳＩＰサーバ共有モジュールがＳＩＰメッセージの待ち受けに利用するポート番号を削除すると共に、前記サーバ送信ＳＩＰメッセージのＶｉａヘッダに記載されたクライアント端末のＩＰアドレス及びポート番号を前記サーバ送信ＳＩＰメッセージのＩＰヘッダの宛先ＩＰアドレスとＵＤＰヘッダの宛先ポート番号に設定する
   ＳＩＰサーバ共有モジュール。
10. 請求項１乃至９のいずれか一項に記載のＳＩＰサーバ共有モジュールにおいて、
    アドレス変換ルールと、
    アドレス変換部と
    を更に有し、
    前記アドレス変換ルールには、
    前記クライアント端末がＲＥＧＩＳＴＥＲメッセージによって前記ＳＩＰプロキシサーバへの登録を要求するアドレスであるオリジナルアドレスと、
    前記ＳＩＰプロキシサーバが送信するＳＩＰメッセージの宛先アドレスに設定された場合に前記ＳＩＰメッセージをインターセプトするためのアドレスであるインターセプトアドレスと
    を相互に変換するアドレス変換方法が記載されており、
    前記アドレス変換部は、
    前記クライアント送信ＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージである場合、前記クライアント送信ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるオリジナルアドレスを、前記アドレス変換ルールを参照してインターセプトアドレスに変換し、
    前記サーバ送信ＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージに対するレスポンスメッセージである場合、前記サーバ送信ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるインターセプトアドレスを、前記アドレス変換ルールを参照してオリジナルアドレスに変換し、
    前記サーバ送信ＳＩＰメッセージがリクエストメッセージである場合、前記サーバ送信ＳＩＰメッセージのＩＰヘッダ及びＵＤＰヘッダに指定されているインターセプトアドレスを、前記アドレス変換ルールを参照してオリジナルアドレスに変換する
    ＳＩＰサーバ共有モジュール。
11. 請求項１０に記載のＳＩＰサーバ共有モジュールにおいて、
    前記アドレス変換方法は、
    Ｍビットの広さを持つＩＰアドレス領域Ａに含まれる任意のＩＰアドレスとＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスａと、
    Ｎビットの広さを持つＩＰアドレス領域Ｂに含まれる任意のＩＰアドレスとＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスｂと
    を相互に変換するアドレス変換方法であって、
    前記アドレスａを前記アドレスｂに変換する際には、前記アドレスａのＩＰアドレスのうちＸ＜Ｎを満たすＸビット分を前記アドレスｂのＩＰアドレスにマッピングし、残りのＭ−Ｘビット分を前記アドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号にマッピングし、
    前記アドレスｂを前記アドレスａに変換する際には、前記アドレスｂのＩＰアドレスのうちＸビット分と前記アドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のうちＭ−Ｘビット分とを組み合わせて前記アドレスａのＩＰアドレスに変換する
    ことを特徴とする
    ＳＩＰサーバ共有モジュール。
12. 請求項１０又は１１に記載のＳＩＰサーバ共有モジュールにおいて、
    前記アドレス変換ルールは、インターセプトアドレスとして、前記ＳＩＰプロキシサーバにおいてＳＩＰサーバ共有モジュールがゲートウェイとして設定されているＩＰアドレス領域を利用することを特徴とする
    ＳＩＰサーバ共有モジュール。
13. 請求項１０又は１１に記載のＳＩＰサーバ共有モジュールにおいて、
    前記アドレス変換ルールは、インターセプトアドレスとして、ローカルループバックアドレス領域に含まれるＩＰアドレス領域を利用することを特徴とする
    ＳＩＰサーバ共有モジュール。
14. Ｍビットの広さを持つＩＰアドレス領域Ａに含まれる任意のＩＰアドレス、及びＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスａと、
    Ｎビットの広さを持つＩＰアドレス領域Ｂに含まれる任意のＩＰアドレス、及びＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のペアであるアドレスｂと
    を相互に変換するアドレス変換方法であって、
    （Ａ）前記アドレスａを前記アドレスｂに変換する際には、前記アドレスａのＩＰアドレスのうちＸ＜Ｎを満たすＸビット分を前記アドレスｂのＩＰアドレスにマッピングするステップと、
    （Ｂ）前記アドレスａのＩＰアドレスのうち残りのＭ−Ｘビット分を前記アドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号にマッピングするステップと、
    （Ｃ）前記アドレスｂを前記アドレスａに変換する際には、前記アドレスｂのＩＰアドレスのうちＸビット分と前記アドレスｂのＵＤＰ又はＴＣＰの宛先又は送信元ポート番号のうちＭ−Ｘビット分とを組み合わせて前記アドレスａのＩＰアドレスに変換するステップと
    を具備する
    アドレス変換方法。
15. （ａ）メッセージを受信した場合、前記メッセージがクライアント端末から送信されたメッセージかＳＩＰプロキシサーバから送信されたメッセージかを判別するステップと、
    （ｂ）前記受信したメッセージが前記クライアント端末から送信されたメッセージの場合、アドレス変換が必要か否かを判断するステップと、
    （ｃ）アドレス変換が必要ない場合、特に処理を行わず前記クライアント端末から送信されたメッセージを前記ＳＩＰプロキシサーバへ転送するステップと、
    （ｄ）アドレス変換が必要な場合、前記クライアント端末から送信されたメッセージがＲＥＧＩＳＴＥＲメッセージか否かを判断するステップと、
    （ｅ）前記クライアント端末から送信されたメッセージがＲＥＧＩＳＴＥＲメッセージである場合、ヘッダ部分のＣｏｎｔａｃｔヘッダに含まれるＩＰアドレス又はポート番号といったオリジナルアドレスを順方向変換するステップと、
    （ｆ）順方向変換後、前記ＳＩＰプロキシサーバへＲＥＧＩＳＴＥＲメッセージを送信するステップと
    を具備する
    ＳＩＰメッセージ中継方式。
16. 請求項１５に記載のＳＩＰメッセージ中継方式において、
    （ｇ）前記受信したメッセージが前記ＳＩＰプロキシサーバから送信されたメッセージの場合、アドレス変換が必要か否かを判断するステップと、
    （ｈ）アドレス変換が不要な場合、前記ＳＩＰプロキシサーバから送信されたメッセージに含まれるグループタグの削除を行うステップと、
    （ｉ）アドレス変換が必要な場合、前記ＳＩＰプロキシサーバから送信されたメッセージがリクエストメッセージであるか否かを判断するステップと、
    （ｊ）前記ＳＩＰプロキシサーバから送信されたメッセージがリクエストメッセージである場合、当該ＳＩＰメッセージが前記クライアント端末へ転送されるように、ＳＩＰメッセージのＩＰヘッダの宛先アドレス又は宛先ポート番号をインターセプトアドレスから前記オリジナルアドレスへ逆方向変換するステップと、
    （ｋ）逆方向変換後、前記ＳＩＰプロキシサーバから送信されたメッセージに含まれるグループタグの削除を行うステップと
    を更に具備する
    ＳＩＰメッセージ中継方式。
17. 請求項１６に記載のＳＩＰメッセージ中継方式において、
    （ｌ）前記ＳＩＰプロキシサーバから送信されたメッセージがレスポンスメッセージの場合、ＲＥＧＩＳＴＥＲメッセージ対するレスポンスメッセージであるか否かを判断するステップと、
    （ｍ）前記ＳＩＰプロキシサーバから送信されたメッセージがＲＥＧＩＳＴＥＲメッセージ対するレスポンスメッセージの場合、Ｃｏｎｔａｃｔヘッダに含まれるＩＰアドレス又はポート番号であるインターセプトアドレスを、前記オリジナルアドレスに逆方向変換するステップと、
    （ｎ）逆方向変換後、前記ＳＩＰプロキシサーバから送信されたメッセージに含まれるグループタグの削除を行うステップと
    を更に具備する
    ＳＩＰメッセージ中継方式。
18. 請求項１５乃至１７のいずれか一項に記載のＳＩＰメッセージ中継方式を、コンピュータに実行させるためのプログラム。

Images