(57)【特許請求の範囲】
【請求項１】
複数のSIPサーバおよびゲートウエイを含む複数のノードがリング状に接続され、前記各ノードに固有のIPアドレスが割り当てられたSIPネットワークシステムのメッセージ交換方法において、
前記各ノードが、
ユーザ端末のセッション情報を管理する管理テーブルと、
メッセージをSIPネットワークと送受信するリング側インターフェース(I/F)と、
メッセージをユーザ側ネットワークと送受信するユーザ側I/Fとを具備し、
ユーザ端末が、送信元IPアドレスに自身のIPアドレス、宛先IPアドレスに自身のセッション情報を管理するSIPサーバのIPアドレスが登録され、発信者アドレスにユーザ端末のURI、着信者アドレスに外部ドメインのURIが登録された第１の要求メッセージを送信する手順と、
第１のSIPサーバが、ユーザ側I/Fから前記第１の要求メッセージを受信する手順と、
前記第１のSIPサーバが、前記受信した第１の要求メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第１の要求メッセージを隣接ノードから受信した各ノードが、当該第１の要求メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記ユーザ端末のセッション情報を管理する第２のSIPサーバが、前記第１の要求メッセージを隣接ノードへ転送する際に、当該第１の要求メッセージの送信元IPアドレスを自身のIPアドレスに付け替え、宛先IPアドレスを着信者アドレスに基づいて外部ドメインのIPアドレスに付け替える手順と、
前記第１の要求メッセージの宛先がARPキャッシュに存在するゲートウエイが、当該第１の要求メッセージをユーザ側I/Fから送信する手順と、
前記ゲートウエイが、ユーザ側I/Fから前記第１の要求メッセージに対する第１の応答メッセージを受信する手順と、
前記ゲートウエイが、受信した前記第１の応答メッセージの宛先IPアドレスをAnyに付け替えてリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第１の応答メッセージを隣接ノードから受信した各ノードが、当該第１の応答メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第２のSIPサーバが、隣接ノードから受信した前記第１の応答メッセージの宛先IPアドレスをユーザ端末のIPアドレスに付け替え、送信元アドレスを自身のIPアドレスに付け替える手順と、
前記第１のSIPサーバが、前記アドレスの付け替えられた第１の応答メッセージを受信してユーザ側I/Fへ送信する手順とを含むことを特徴とするSIPネットワークシステムのメッセージ交換方法。
【請求項２】
前記ゲートウエイが、送信元IPアドレスに外部ドメインのIPアドレス、宛先IPアドレスに自身のIPアドレスが登録され、発信者アドレスに外部ドメインのURI、着信者アドレスにユーザ端末のURIが登録された第２の要求メッセージをユーザ側I/Fから受信する手順と、
前記ゲートウエイが、受信した前記第２の要求メッセージの宛先IPアドレスを「Any」に書き替えてリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第２の要求メッセージを隣接ノードから受信した各ノードが、当該第２の要求メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第２のSIPサーバが、隣接ノードから受信した前記第２の要求メッセージの送信元IPアドレスを自身のIPアドレスに付け替え、宛先IPアドレスを第１ユーザ端末のIPアドレスに付け替える手順と、
前記第２の要求メッセージの宛先がARPキャッシュに存在する第１のSIPサーバが、当該第２の要求メッセージを受信してユーザ側I/Fへ送信する手順と、
前記ユーザ端末が、前記第２の要求メッセージに対する第２の応答メッセージを返信する手順と、
前記第１のSIPサーバが、ユーザ側I/Fから前記第２の応答メッセージを受信する手順と、
前記第１のSIPサーバが、前記受信した第２の応答メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第２の応答メッセージを隣接ノードから受信した各ノードが、当該第２の応答メッセージをリング側I/Fから一方側の隣接サーバへ転送する手順と、
前記第２のSIPサーバが、隣接ノードから受信した前記第２の応答メッセージの送信元アドレスを自身のIPアドレスに付け替え、宛先IPアドレスを外部ドメインのIPアドレスに付け替える手順と、
前記ゲートウエイが、隣接ノードから受信した前記第２の応答メッセージをユーザ側I/Fから送信する手順とを含むことを特徴とする請求項１に記載のSIPネットワークシステムのメッセージ交換方法。
【請求項３】
ユーザ端末が、送信元IPアドレスに自身のIPアドレス、宛先IPアドレスに自身のセッション情報を管理するSIPサーバのIPアドレスが登録され、発信者アドレスにユーザ端末のURI、着信者アドレスに内部ドメインのURIが登録された第３の要求メッセージを送信する手順と、
第１のSIPサーバが、ユーザ側I/Fから前記第３の要求メッセージを受信する手順と、
前記第１のSIPサーバが、前記受信した第３の要求メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第３の要求メッセージを隣接ノードから受信した各ノードが、当該第３の要求メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記ユーザ端末のセッション情報を管理する第２のSIPサーバが、前記第３の要求メッセージを隣接ノードへ転送する際に、当該第３の要求メッセージの送信元IPアドレスを自身のIPアドレスに付け替え、宛先IPアドレスをAnyに付け替える手順と、
前記第３の要求メッセージの宛先がARPキャッシュに存在する第３のSIPサーバが、当該第３の要求メッセージをユーザ側I/Fから送信する手順と、
前記第３のSIPサーバが、ユーザ側I/Fから前記第３の要求メッセージに対する第３の応答メッセージを受信する手順と、
前記第３のSIPサーバが、前記第３の応答メッセージの宛先IPアドレスを前記第２のSIPサーバのIPアドレスに付け替え、送信元IPアドレスを自身のIPアドレスに付け替えてリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第３の応答メッセージを隣接ノードから受信した各ノードが、当該第３の応答メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第２のSIPサーバが、隣接ノードから受信した前記第３の応答メッセージの宛先IPアドレスをユーザ端末のIPアドレスに付け替え、送信元アドレスを自身に固有のIPアドレスに付け替える手順と、
前記第１のSIPサーバが、隣接ノードから受信した前記第３の応答メッセージをユーザ側I/Fから送信する手順とを含むことを特徴とする請求項１または２に記載のSIPネットワークシステムのメッセージ交換方法。
【請求項４】
ユーザ端末が、送信元IPアドレスに自身のIPアドレス、宛先IPアドレスに自身のセッション情報を管理するSIPサーバのIPアドレスが登録され、発信者アドレスおよび着信者アドレスにユーザ端末のURIが登録された登録メッセージを送信する手順と、
第１のSIPサーバが、ユーザ側I/Fから前記登録メッセージを受信する手順と、
前記第１のSIPサーバが、前記受信した登録メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記登録メッセージを隣接ノードから受信した各ノードが、当該登録メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記ユーザ端末のセッション情報を管理する第２のSIPサーバが、前記登録メッセージを処理する手順と、
前記第２のSIPサーバが、前記登録メッセージに対する第４の応答メッセージを隣接ノードへ転送する際に、当該第４の応答メッセージの送信元IPアドレスを自身のIPアドレスに付け替え、宛先IPアドレスをユーザ端末のIPアドレスに付け替える手順と、
前記第１のSIPサーバが、隣接ノードから受信した前記第４の応答メッセージをユーザ側I/Fから送信する手順とを含むことを特徴とする請求項１ないし３のいずれかに記載のSIPネットワークシステムのメッセージ交換方法。
【請求項５】
前記ユーザ端末のセッション情報を管理する第２のSIPサーバが、送信元IPアドレスに自身のIPアドレス、宛先IPアドレスにユーザ端末のIPアドレスが登録され、発信者アドレスおよび着信者アドレスにユーザ端末のURIが登録された通知メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記通知メッセージを隣接ノードから受信した各ノードが、当該通知メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記通知メッセージの宛先がARPキャッシュに存在する第１のSIPサーバが、当該通知メッセージをユーザ側I/Fから送信する手順と、
前記ユーザ端末が、前記通知メッセージを受信して、送信元IPアドレスに自身のIPアドレス、宛先IPアドレスに前記第２のSIPサーバのIPアドレスが登録され、発信者アドレスおよび着信者アドレスにユーザ端末のURIが登録された第５の応答メッセージを返信する手順と、
前記第１のSIPサーバが、前記第５の応答メッセージをユーザ側I/Fから受信する手順と、
前記第１のSIPサーバが、前記第５の応答メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第５の応答メッセージを隣接ノードから受信した各ノードが、当該第５の応答メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、
前記第２のSIPサーバが、隣接ノードから受信した前記第５の応答メッセージを受信する手順とを含むことを特徴とする請求項１ないし４のいずれかに記載のSIPネットワークシステムのメッセージ交換方法。
【請求項６】
前記第１のSIPサーバと第２のSIPサーバとが同じであることを特徴とする請求項１ないし５のいずれかに記載のSIPネットワークシステムのメッセージ交換方法。
【請求項７】
前記第１のSIPサーバと第２のSIPサーバとが異なることを特徴とする請求項１ないし５のいずれかに記載のSIPネットワークシステムのメッセージ交換方法。
【請求項８】
前記メッセージは、ノード間での転送回数が所定の上限値を超えると破棄されることを特徴とする請求項１ないし７のいずれかに記載のSIPネットワークシステムのメッセージ交換方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、SIP（Session Initiation Protocol）ネットワークシステムのメッセージ交換方法に係り、特に、複数のSIPサーバおよびゲートウエイを含む複数のノードがリング状に接続され、各ノードに固有のIPアドレスが割り当てられたSIPネットワークシステムのメッセージ交換方法に関する。
【背景技術】
【０００２】
IPネットワーク上で電話の呼設定や、インターネットを介した音声や映像等のメディアの伝達を行うマルチメディアサービスを実現するプロトコルとしてSIP が事実上の標準（Defact Standard）として普及している。SIPによれば、一般の電話サービスが持つ基本的な呼設定機能のほか、着信課金機能や転送機能、発信者番号通知機能などをIPネットワーク上で実現できる。しかしながら、SIPをフルステート方式で動作させるためには、ユーザごとにセッション情報や課金情報に関するダイアログ（以下、セッション情報で総称する）を生成し、これをSIPに準拠した登録処理やアドレス変換処理などで呼接続をサポートするノード（SIPサーバ）に登録する必要がある。SIPサーバを経由してSIPのメッセージの送受信する技術に関しては、特許文献１に開示されている。
【特許文献１】特開２００５−１９８１８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
SIPをフルステート方式で動作させるとユーザのセッション情報が増えるのでSIPサーバに大きな負荷が生じる。SIPサーバの負荷分散方法として複数のSIPサーバを配置して各SIPサーバに負荷を分散させる方法がある。しかしながら、このような負荷分散方法では各SIPサーバに固有のホスト名およびIPアドレスを設定する必要がある。したがって、SIPサーバを追加するような場合にはDNSサーバの情報に更新が必要となるのみならず、外部ネットワークでホスト名やIPアドレスでアクセス制限が行われているような場合には、変更のたびに設定を変える必要がある。
【０００４】
また、SIPサーバが複数存在する環境でユーザがSIPサーバ間を移動（ハンドオフ）する場合、SIPサーバのホスト名およびIPアドレスが変わるので、その旨を相手端末や経路上の他のSIPサーバに通知する必要がある。さらに、課金情報については各々のサーバで収集、保持される。これにより不要なメッセージの発生及び内部ドメイン情報の通知等によるセキュリティの問題等を引き起こす可能性がある。
【０００５】
本発明の目的は、上記した従来技術の課題を解決し、SIPサーバの負荷を簡単に分散でき、かつユーザ端末のハンドオフを簡単に実現できるSIPネットワークシステムのメッセージ交換方法を提供することにある。
【課題を解決するための手段】
【０００６】
上記した目的を達成するために、本発明は、複数のSIPサーバおよびゲートウエイを含む複数のノードがリング状に接続され、前記各ノードに固有のIPアドレスが割り当てられたSIPネットワークシステムのメッセージ交換方法において、前記各ノードが、メッセージをSIPネットワークと送受信するリング側インターフェース(I/F)と、メッセージをユーザ側ネットワークと送受信するユーザ側I/Fとを具備している。
【０００７】
そして、ユーザ端末が送信したメッセージを第１のSIPサーバがユーザ側I/Fから前記メッセージを受信する手順と、前記第１のSIPサーバが前記受信したメッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、前記メッセージを隣接ノードから受信した各ノードが、当該メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、前記メッセージの宛先がARPキャッシュに存在するゲートウエイが、当該メッセージをユーザ側I/Fから送信する手段と、前記ゲートウエイが、ユーザ側I/Fから前記メッセージに対する応答メッセージを受信する手順と、前記ゲートウエイが、受信した応答メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、前記応答メッセージを隣接ノードから受信した各ノードが、当該応答メッセージをリング側I/Fから一方側の隣接ノードへ転送する手順と、前記第１のSIPサーバが、前記応答メッセージを受信してユーザ側I/Fへ送信する手順とを含む。
【発明の効果】
【０００８】
上記した特徴によれば、負荷分散を目的としてSIPサーバを追加する場合でも、DNSサーバや外部ネットワークへの追加サーバの登録が不要なので、負荷分散環境を容易に構築できる。
【０００９】
また、発信端末が同一ドメイン内で移動した場合でも、外部ドメインへSIPサーバ変更の旨の通知を行う必要がなく、SIPサーバのIPアドレスを変更する必要もない。さらに、課金情報を同一のSIPサーバで継続して収集できるようになり、SIPサーバ間のハンドオフ時でもユーザのデフォルトゲートウェイアドレス（Next Hopアドレス）を変更する必要がない。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して本発明の最良の実施の形態について詳細に説明する。図１は、本発明に係るSIPサーバシステムのネットワーク構成を示したブロック図であり、第１のネットワーク(domain1.net)では、複数のSIPサーバSV#1，SV#2およびSV#3、ならびにゲートウエイGWを含む複数のノードがリング状に接続され、各SIPサーバおよびゲートウエイGWには固有のIPアドレス「ip1」、「ip2」、「ip3」、「ip5」および同一の共通ホスト名「ps1」が割り当てられている。第２のネットワーク(domain2.net)にはSIPサーバSV#4が収容されている。このSIPサーバSV#4には、固有のIPアドレス「ip4」およびホスト名「ps4」が割り当てられている。
【００１１】
各SIPサーバには、各ユーザのセッション情報を各ユーザに固有のURIで管理するセッション管理テーブルが設けられており、SIPサーバSV#1の管理テーブルにはユーザE，Fのセッション情報が登録されている。同様に、SIPサーバSV#2の管理テーブルにはユーザAのセッション情報が登録され、IPサーバSV#3の管理テーブルにはユーザC，Dのセッション情報が登録されている。全てのノードは、メッセージをSIPネットワークと送受信するリング側インターフェースと、メッセージをユーザ側ネットワークと送受信するユーザ側I/Fとを備えている。
【００１２】
次いで、図２，３，４のフローチャートおよび図６のブロック図を参照して、第１ドメイン(domain1.net)のユーザAから外部の第２ドメイン(domain2.net)のユーザBへ発信する際の呼接続手順を説明する。
【００１３】
図６に示したように、ユーザAはSIPフォン#1から、宛先(target)IPアドレスがSIPサーバSV#2に固有のIPアドレス「ip2」、送信元(source)IPアドレスが自身のIPアドレス「ipA」、種別がSIP-INVITE（呼び出し）、発信者アドレス(Fromヘッダ)が自身のURI「UserA@domain1.net」、着信者アドレス(Toヘッダ)がユーザBのURI「UserB@domain2.net」であり、Viaヘッダに自身のホスト名「hostA@domain1.net」が登録されているイーサネット（登録商標）フレームを送信する。
【００１４】
SIPサーバSV#2は、図２のステップＳ１で前記フレームを受信すると、ステップＳ２では、その発信者アドレスに基づいて受信インターフェースがユーザ側およびリング側の何れであるかが判定される。ここではユーザ側と判定されるのでステップＳ３へ進み、当該受信フレームからパケットが取り込まれる。ステップＳ４では、宛先IPアドレスに基づいて宛先が判定され、ここでは「自分宛」と判定されるのでステップＳ１８へ進む。
【００１５】
ステップＳ１８では、受信パケットがSIPアプリケーションポートより受信される。ステップＳ１９ではメソッドタイプが判定され、ここではユーザ／ユーザ間の通信と判定されるのでステップＳ２０へ進む。ステップＳ２０では、受信パケットがリクエストおよびレスポンスの何れであるかが判定され、ここではリクエストと判定されるので図３のステップＳ５０へ進む。
【００１６】
ステップＳ５０では、発信者アドレスが自ドメインであるか否かが判定され、ここでは自ドメインと判定されるのでステップＳ５１へ進む。ステップＳ５１では、発信者アドレスのURIが管理テーブルに存在するか否かが判定され、ここでは存在すると判定されるのでステップＳ５２へ進む。ステップＳ５２では、受信パケットのVaiヘッダに自身のホスト名「ps1.domain1.net」が追加される。ステップＳ５３では、着信者のアドレスが自ドメインであるか否かが判定され、ここでは自ドメイン以外と判定されるのでステップＳ５６へ進む。ステップＳ５６では、宛先IPアドレスがSIPサーバSV#4のIPアドレス「ip4」に付け替えられると共に、送信元IPアドレスが自身のIPアドレス「ip2」に付け替えられる。ステップＳ５７では、前記IPアドレスの付け替えられたパケットがリング側インターフェースから一方側の隣接ノードへ転送される。
【００１７】
SIPサーバSV#3は、このパケットを図２のステップＳ１で受信すると、ステップＳ２では、受信インターフェースがリング側と判定されるのでステップＳ１０へ進む。ステップＳ１０では、受信パケットの転送回数の残数Tnが「０」であるか否かに基づいて、受信パケットの転送回数が所定の最大転送回数に達しているか否かが判定される。本実施形態では、最大転送回数が４回に設定されており、残数Tnが「０」であれば、最大転送回数に達したと判定されてステップＳ２１へ進み、受信パケットが破棄される。残数Tnが「０」以外であれば、最大転送回数に達していないと判定されてステップＳ１１へ進み、残数Tnが「１」だけデクリメントされる。
【００１８】
ステップＳ１２では、受信パケットがリング側インターフェースから一方側の隣接サーバへ転送され、これと並行して、ステップＳ１３では受信パケットが取り込まれる。ステップＳ１４では、受信パケットの宛先IPアドレスが参照され、ここでは「自分宛」および「Any」のいずれでもないと判定されるのでステップＳ１５へ進む。ステップＳ１５では、自身のARPキャッシュエントリに宛先IPアドレスが存在するか否かが判定され、ここでは存在しないと判定されるので、ステップＳ１７へ進んで当該パケットが破棄される。
【００１９】
ゲートウエイGWは、SIPサーバSV#3がステップＳ１２で転送したフレームを受信すると、その宛先IPアドレス「ip4」がARPキャッシュエントリに存在する、換言すれば、ユーザ側インターフェース上にSIPサーバSV#4が存在するので、これをユーザ側インターフェースからSIPサーバSV#4へ送信する。
【００２０】
SIPサーバSV#4は、図６に示したように、受信パケットの宛先IPアドレスをSIPフォン#2のIPアドレス「ipB」に付け替えると共に、送信元IPアドレスを自身のIPアドレス「ip4」に付け替え、これをSIPフォン#2へ送信する。SIPサーバSV#4はさらに、200OKレスポンスをSIPフォン#2から受信すると、その宛先IPアドレスをゲートウエイGWのIPアドレス「ip5」に付け替えると共に、送信元IPアドレスを自身のIPアドレス「ip4」に付け替えてゲートウエイGWへ送信する。domain1.netのゲートウエイGWは、受信した応答メッセージの宛先IPアドレスを「Any」に付け替えて一方側の隣接サーバへ転送する。
【００２１】
SIPサーバSV#1は、このゲートウエイGWから転送されたフレームを図２のステップＳ１で受信すると、ステップＳ２では受信インターフェースがリング側と判定されるので、ステップＳ１０，Ｓ１１を経てステップＳ１２へ進む。ステップＳ１２では、受信パケットがリング側インターフェースから一方側の隣接サーバへ転送され、これと並行して、ステップＳ１３では受信パケットが取り込まれる。
【００２２】
ステップＳ１４では、宛先IPアドレスが参照され、ここでは「Any」と判定されるのでステップＳ１８へ進む。ステップＳ１８では、パケットがSIPアプリケーションポートより受信される。ステップＳ１９ではメソッドタイプが判定され、ここではユーザ／ユーザ間の通信と判定されるのでステップＳ２０へ進む。ステップＳ２０では、受信パケットがリクエストおよびレスポンスの何れであるかが判定され、ここではレスポンスと判定されるので、図４のステップＳ３０へ進む。
【００２３】
ステップＳ３０では、着信者アドレスが自ドメインであるか否かが判定され、ここでは自ドメイン以外と判定されるのでステップＳ４４へ進む。ステップＳ４４では、発信者アドレスが自ドメインであるか否かが判定され、ここでは自ドメインと判定されるのでステップＳ４５へ進む。ステップＳ４５では、発信者アドレスのURIが管理リストに存在するか否かが判定され、ここでは存在しないと判定されるので、ステップＳ４３へ進んでパケットが破棄される。
【００２４】
SIPサーバSV#2は、SIPサーバSV#1がステップＳ１２でリング側へ転送したパケットをステップＳ１で受信すると、前記SIPサーバSV#1における手順と同様の手順を経てステップＳ４５まで進む。ステップＳ４５では、発信者アドレスのURIが管理テーブルに存在すると判定されるのでステップＳ３５へ進み、自身のURI「ps1.domaini.net」がViaヘッドから削除される。ステップＳ３６では、受信パケットの宛先IPアドレスが、前記発信者アドレスのURIに対応したSIPフォン#1のIPアドレス「ipA」に付け替えられ、送信元IPアドレスが、自身のIPアドレス「ip2」に付け替えられる。ステップＳ３７では、宛先IPアドレスがARPキャッシュエントリに存在するか否かが判定され、ここでは存在すると判定されるのでステップＳ３９へ進む。ステップＳ３９では、前記IPアドレスを付け替えられたパケットがユーザ側インターフェースからSIPフォン#1へ送信される。
【００２５】
次いで、外部ドメインからの着信時の動作を、図７のブロック図および各フローチャートを参照して説明する。ここでは、ユーザBのSIPフォン#2からSIPサーバSV#2の配下にあるユーザAのSIPフォン#1への発信を例にして説明する。
【００２６】
図７に示したように、ユーザBはSIPフォン#2からは、宛先(target)IPアドレスがSIPサーバ#4のIPアドレス「ip4」、送信元(source)IPアドレスが自身のIPアドレス「ipB」、種別がSIP-INVITE（呼び出し）、発信者アドレス(Fromヘッダ)が自身のURI「UserB@domain2.net」、着信者アドレス(Toヘッダ)がユーザAのURI「UserA@domain1.net」であり、Viaヘッダに自身のホスト名「hostB@domain2.net」が登録されているイーサネット（登録商標）フレームを送信する。
【００２７】
SIPサーバSV#4では、受信パケットの宛先IPアドレスがdomainnet1.netのゲートウエイGWのIPアドレス「ip5」に付け替えられ、送信元IPアドレスが自身のIPアドレス「ip4」に付け替えられ、Viaヘッダに自身のホスト名「ps4.domain2.net」が追加される。
【００２８】
ゲートサーバGWはSIPサーバSV#4からイーサネット（登録商標）フレームを受信すると、その宛先IPアドレスを「Any」に付け替えてリング側インターフェースから一方側の隣接サーバへ転送する。SIPサーバSV#1は、このパケットを図２のステップＳ１で受信すると、ステップＳ２では受信インターフェースがリング側と判定されるので、ステップＳ１０，Ｓ１１を経てステップＳ１２へ進む。ステップＳ１２では、受信パケットがリング側インターフェースから一方側の隣接サーバへ転送され、これと並行して、ステップＳ１３では、受信パケットが取り込まれる。
【００２９】
ステップＳ１４では、受信パケットの宛先IPアドレスが参照され、ここでは「Any」と判定されるので、ステップＳ１８，Ｓ１９を経てステップＳ２０へ進む。ステップＳ２０では、受信パケットがリクエストおよびレスポンスの何れであるかが判定され、ここではリクエストと判定されるので、図３のステップＳ５０へ進む。
【００３０】
ステップＳ５０では、受信パケットのFromヘッダに登録されている発信者アドレスが自ドメインであるか否かが判定され、ここでは自ドメイン以外と判定されるのでステップＳ６６へ進む。ステップＳ６６では、着信者アドレスが自ドメインであるか否かが判定され、ここでは自ドメインと判定されるのでステップＳ６７へ進む。ステップＳ６７では、着信者アドレスのURIが管理テーブルに存在するか否かが判定され、ここでは存在しないと判定されるので、ステップＳ６４へ進んでパケットが破棄される。
【００３１】
SIPサーバSV#2は、SIPサーバSV#1がステップＳ１２でリング側へ転送したパケットをステップＳ１で受信すると、前記SIPサーバSV#1における手順と同様の手順を経てステップＳ６７まで進む。ステップＳ６７では、着信者アドレスのURIが管理テーブルに存在すると判定されるのでステップＳ５５へ進み、自身のホスト名をViaヘッダに追加する。
【００３２】
その後、当該処理は図４のステップＳ３６へ進み、受信パケットの宛先IPアドレスが、着信者アドレスのURIに対応したSIPフォン#1のIPアドレス「ipA」に付け替えられ、送信元IPアドレスがSIPサーバSV#2に固有のIPアドレス「ip2」に付け替えられる。ステップＳ３７では、宛先IPアドレスがARPキャッシュエントリに存在するか否かが判定され、ここでは存在すると判定されるのでステップＳ３９へ進む。ステップＳ３９では、前記IPアドレスを付け替えられたパケットがユーザ側インターフェースからSIPフォン#1へ送信される。
【００３３】
SIPサーバSV#2は、図２のステップＳ１でSIPフォン#1から応答パケットを受信すると、前記と同様にステップＳ２，Ｓ３，Ｓ４，S５，Ｓ１８，Ｓ１９を経由してステップＳ２０まで進む。ステップＳ２０では、受信パケットがレスポンスと判定されるので、図４のステップＳ３０へ進む。
【００３４】
ステップＳ３０では、着信者アドレスが自ドメインと判定されるのでステップＳ３１へ進む。ステップＳ３１では、着信者アドレスのURIが管理テーブルに存在するか否かが判定され、ここでは存在すると判定されるのでステップＳ３２へ進み、Viaヘッダから自身のドメイン「ps1.domain1.net」が削除される。ステップＳ３３では、発信者アドレスが自ドメインであるか否かが判定され、ここでは自ドメイン以外と判定されるのでステップＳ４６へ進む。ステップＳ４６では、宛先IPアドレスがSIPサーバSV#4のIPアドレス「ip4」に付け替えられ、送信元IPアドレスが自身のIPアドレス「ip2」に付け替えられる。ステップＳ４７では、前記IPアドレスを付け替えられたパケットがリング側インターフェースから一方側の隣接ノードへ転送される。
【００３５】
SIPサーバSV#3は、SIPサーバSV#2がステップＳ４７でリング側へ転送したパケットをステップＳ１で受信すると、ステップＳ２では、受信インターフェースがリング側と判定されるので、ステップＳ１０，Ｓ１１を経てステップＳ１２へ進む。ステップＳ１２では、受信パケットがリング側インターフェースから一方側の隣接サーバへ転送され、これと並行して、ステップＳ１３では受信パケットが取り込まれる。
【００３６】
ステップＳ１４では、受信パケットが「自分宛」および「Any」のいずれでもないと判定されるのでステップS１５へ進む。ステップS１５では、自身のARPキャッシュエントリに宛先IPアドレスが存在するか否かが判定され、ここでは存在しないと判定されるので、ステップＳ１７へ進んで当該パケットが破棄される。
【００３７】
ゲートウエイGWは、SIPサーバSV#3がステップＳ１２で転送したフレームを受信すると、その宛先IPアドレス「ip4」がARPキャッシュエントリに存在する、換言すれば、ユーザ側インターフェース上にSIPサーバSV#4が存在するので、これをユーザ側インターフェースからSIPサーバSV#4へ送信する。SIPサーバSV#4では、受信パケットの宛先IPアドレスがユーザBのIPアドレス「ipB」に付け替えられ、送信元IPアドレスが自身のIPアドレス「ip4」に付け替えられる。前記IPアドレスを付け替えられたパケットは、ユーザ側インターフェースからユーザBへ転送される。
【００３８】
次いで、図８のブロック図および各フローチャートを参照して、第１ドメイン(domain1.net)のユーザAが同一ドメイン内で他のSIPサーバの配下に移動して第２ドメイン(domain2.net)のユーザBへ発信する際の呼接続手順を説明する。ここでは、SIPサーバSV#2に自身のセッション情報が登録されているユーザAが、SIPサーバSV#3を経由して発信する場合を例にして説明する。
【００３９】
図８に示したように、ユーザAはSIPフォン#1から、宛先(target)IPアドレスがSIPサーバSV#2ｎｉ固有のIPアドレス「ip2」、送信元(source)IPアドレスが自身のIPアドレス「ipA」、種別がSIP-INVITE（呼び出し）、発信者アドレス(Fromヘッダ)が自身のURI「UserA@domain1.net」、着信者アドレス(Toヘッダ)がユーザBのURI「UserB@domain2.net」であり、Viaヘッダに自身のホスト名「hostA@domain1.net」が登録されているフレームを送信する。
【００４０】
SIPサーバSV#3は、図２のステップＳ１で前記フレームを受信すると、前記と同様に、ステップＳ２を経由してステップＳ４へ進む。ステップＳ４では、宛先が自分宛および「Any」のいずれでもないと判定されるのでステップS６へ進む。ステップS６では、宛先IPアドレスが自身のARPキャッシュエントリに存在するか否かが判定され、ここでは存在しないと判定されるので、ステップS９へ進んで受信パケットを一方側の隣接サーバへ転送する。
【００４１】
ゲートウエイサーバGWは、SIPサーバSV#3が前記ステップS９で転送したパケットを受信すると、その宛先IPアドレス「ip2」が自身のARPキャッシュエントリに存在しないので、そのまま一方側の隣接サーバへ転送する。
【００４２】
SIPサーバSV#1は、このゲートウエイGWから転送されたフレームを図２のステップＳ１で受信すると、ステップＳ２、Ｓ１０，Ｓ１１を経てステップＳ１２へ進む。ステップＳ１２では、受信パケットがリング側インターフェースから一方側の隣接サーバへ転送され、これと並行して、ステップＳ１３では受信パケットが取り込まれる。ステップＳ１４では、宛先IPアドレスが「自分宛」以外と判定されるのでステップＳ１５へ進む。ステップＳ１５では、宛先IPアドレス「ip2」が自身のARPキャッシュエントリに存在しないと判定されるので、ステップS１７へ進んでパケットが破棄される。
【００４３】
SIPサーバSV#2は、SIPサーバSV#1が前記ステップS１２で転送したパケットを図２のステップS１で受信すると、SIPサーバSV#1の場合と同様にステップS１４まで進む。ステップＳ１４では、宛先が自身と判定されるのでステップS１８へ進む。これ以後は前記と同様に、宛先IPアドレスが着信者アドレスのURIに基づいてSIPサーバSV#4のIPアドレス「ip4」に付け替えられると共に、送信元IPアドレスがSIPサーバSV#2に固有のIPアドレス「ip2」に付け替えられ、前記図６に関して説明した実施形態と同様に、IPアドレスの付け替えられたパケットがゲートウエイGWからユーザBへ転送される。外部ドメインのSIPサーバSV#4から返信されたパケットは、前記と同様にゲートウエイGWで宛先IPアドレスを「Any」に付け替えられ、隣接ノード（SIPサーバSV#1）を経由してSIPサーバSV#2まで転送される。
【００４４】
SIPサーバSV#2が図２のステップS１でパケットを受信すると、ステップＳ２、Ｓ１０、Ｓ１４、Ｓ２０を経て図４のステップＳ３０へ進む。ステップＳ３０では、着信者アドレスが自ドメイン以外と判定されるのでステップＳ４４へ進む。ステップＳ４４では、発信者アドレスが自ドメインと判定されるのでステップＳ４５へ進む。ステップＳ４５では、発信者アドレスのURIが管理テーブルに存在すると判定されるのでステップＳ３５へ進む。ステップＳ３５では、自身のURI「ps1.domaini.net」がViaヘッドから削除される。
【００４５】
ステップＳ３６では、受信パケットの宛先IPアドレスが、前記発信者アドレスのURIに対応したSIPフォン#1のIPアドレス「ipA」に付け替えられ、送信元IPアドレスが自身のIPアドレス「ip2」に付け替えられる。ステップＳ３７では、宛先IPアドレス「ipA」がARPキャッシュエントリに存在するか否かが判定され、ここでは存在しないと判定されるのでステップＳ３８へ進む。ステップＳ３８では、前記IPアドレスを付け替えられたパケットがリング側インターフェースから一方側の隣接サーバへ転送される。
【００４６】
SIPサーバSV#3は、このパケットをステップS１で受信すると、前記SIPサーバSV#2の場合と同様にステップS１４まで進む。ステップS１４では、宛先が自分宛およびAnyのいずれでもないのでステップS１５へ進む。ステップS１５では、宛先IPアドレスがARPキャッシュエントリに存在するか否かが判定され、ここでは存在すると判定されるのでステップS１６へ進み、受信パケットがユーザ側インターフェースからSIPフォン#1へ送信される。
【００４７】
次いで、図９図のブロック図を参照して、第１ドメイン(domain1.net)のユーザAが同一ドメイン内の他のSIPサーバの配下に移動して第２ドメイン(domain2.net)のユーザBから着信する際の呼接続手順を説明する。ここでは、SIPサーバSV#2に自身のセッション情報が登録されているユーザAが、SIPサーバSV#3を経由して着信する場合を例にして説明する。なお、ユーザBから送信されたパケットがゲートウエイGWおよびSIPサーバSV#1を経由してSIPサーバSV#2に至る手順は、前記図７に関して説明した実施形態と同一なので、その説明は省略する。
【００４８】
SIPサーバSV#2は、SIPサーバSV#1がステップＳ１２でリング側へ転送したフレームをステップＳ１で受信すると、SIPサーバSV#1における手順と同様の手順を経て図３のステップＳ６７まで進む。ステップＳ６７では、着信者アドレスのURIが管理テーブルに存在すると判定されるのでステップＳ５５へ進み、自身のホスト名をViaヘッダに追加する。
【００４９】
その後、当該処理は図４のステップＳ３６へ進み、受信パケットの宛先IPアドレスが、着信者アドレスのURIに対応したSIPフォン#1のIPアドレス「ipA」に付け替えられ、送信元IPアドレスが、自身に固有のIPアドレス「ip2」に付け替えられる。ステップＳ３７では、宛先IPアドレスがARPキャッシュエントリに存在するか否かが判定され、ここではSIPフォン#1が既に移動しており、存在しないと判定されるのでステップＳ３８へ進む。ステップＳ３８では、前記IPアドレスを付け替えられたパケットがリング側インターフェースから一方側の隣接サーバへ転送される。
【００５０】
SIPサーバSV#3は、このパケットをステップS１で受信すると、前記SIPサーバSV#2の場合と同様にステップS１４まで進む。ステップS１４では、宛先が自分宛でもAnyでもないと判定されるのでステップS１５へ進む。ステップS１５では、宛先IPアドレスがARPキャッシュエントリに存在するか否かが判定され、ここでは存在すると判定されるのでステップS１６へ進み、受信パケットがユーザ側インターフェースからSIPフォン#1へ送信される。
【００５１】
SIPサーバSV#3は、図２のステップＳ１でSIPフォン#1から応答パケットを受信すると、前記と同様にステップＳ２，Ｓ３，Ｓ４，S６を経由してステップＳ９へ進み、受信パケットをリング側インターフェースから一方側の隣接サーバへ転送する。ゲートウエイサーバGWは、SIPサーバSV#3が前記ステップS９で転送したパケットを受信すると、その宛先IPアドレス「ip2」が自身のARPキャッシュエントリに存在しないので、そのまま一方側の隣接サーバへ転送する。
【００５２】
SIPサーバSV#1は、このゲートウエイGWから転送されたフレームを図２のステップＳ１で受信すると、ステップＳ２、Ｓ１０，Ｓ１１を経てステップＳ１２へ進む。ステップＳ１２では、受信パケットがリング側インターフェースから一方側の隣接サーバへ転送され、これと並行して、ステップＳ１３では受信パケットが取り込まれる。ステップＳ１４では、宛先IPアドレスが「その他」と判定されるのでステップＳ１５へ進む。ステップS１５では、宛先IPアドレスがARPキャッシュエントリに存在するか否かが判定され、ここでは存在しないと判定されるのでステップS１７へ進み、受信パケットが破棄される。
【００５３】
SIPサーバSV#2は、SIPサーバSV#1が前記ステップS１２で転送したパケットを図２のステップS１で受信すると、SIPサーバSV#1の場合と同様にステップS１４まで進む。ステップＳ１４では、宛先が自身と判定されるのでステップS１８移行へ進み、これ以後は前記と同様に、当該パケットがSIPサーバSV#3、ゲートウエイGWおよびdomain2.netのSIPサーバ#4を経由してユーザBのSIPフォン#2へ返信される。
【００５４】
次いで、図１０のブロック図および各フローチャートを参照して、同一ドメイン内でのユーザ／ユーザ間のメッセージ交換手順について説明する。
【００５５】
ユーザAはSIPフォン#1から、宛先IPアドレスがSIPサーバSV#2に固有のIPアドレス「ip2」、送信元IPアドレスが自身のIPアドレス「ipA」、種別がSIP-INVITE、発信者アドレス(Fromヘッダ)が自身のURI「UserA@domain1.net」、着信者アドレス(Toヘッダ)がユーザBのURI「UserB@domain1.net」であり、Viaヘッダに自身のホスト名「hostA@domain1.net」が登録されているフレームを送信する。
【００５６】
SIPサーバSV#2は、図２のステップＳ１で前記フレームを受信すると、ステップＳ２では、その発信者アドレスに基づいて、受信インターフェースがユーザ側と判定されるのでステップＳ３へ進み、当該受信フレームからパケットが取り込まれる。ステップＳ４では、パケットの宛先が「自分宛」と判定されるのでステップＳ１８へ進む。ステップＳ１８では受信パケットがSIPアプリケーションポートで受信され、ステップＳ１９を経てステップＳ２０へ進む。ステップＳ２０では、メッセージがリクエストと判定されるので、図３のステップＳ５０へ進む。
【００５７】
ステップＳ５０では発信者アドレスが自ドメインと判定されるのでステップＳ５１へ進み、ここでは発信者アドレスのURIが管理テーブルに存在すると判定されるのでステップＳ５２へ進む。ステップＳ５２では、受信フレームのVaiヘッダに自ホスト名「ps1.domain1.net」が追加される。ステップＳ５３では、着信者アドレスの宛先が自ドメインと判定されるのでステップＳ５４へ進み、ここでは、着信者アドレスのURIが管理テーブルに存在しないと判定されるのでステップＳ５８へ進む。ステップＳ５８では、宛先IPアドレスが「Any」に付け替えられ、送信元IPアドレスが自身のIPアドレス「ip2」に付け替えられる。ステップＳ５９では、前記アドレスの付け替えられたパケットがリング側インターフェースから一方側の隣接ノードへ転送される。
【００５８】
SIPサーバSV#3は、SIPサーバSV#2がステップＳ５９でリング側へ転送したパケットを図２のステップＳ１で受信すると、ステップＳ２では、受信インターフェースがリング側と判定されるので、ステップＳ１０，Ｓ１１を経てステップＳ１２へ進み、受信パケットがリング側インターフェースから隣接ノードへ転送される。これと並行して、ステップＳ１３では受信パケットが取り込まれ、ステップＳ１４において、その宛先IPアドレスが識別される。ここでは宛先が「Any」と判定されるので、ステップＳ１８，Ｓ１９，Ｓ２０を経て図３のステップＳ５０へ進む。
【００５９】
ステップＳ５０では、発信者アドレスが自ドメインと判定されるのでステップＳ５１へ進み、ここでは、発信者アドレスのURIが管理テーブルに存在しないと判定されるのでステップＳ６１へ進む。ステップＳ６１では、着信者アドレスが自ドメインと判定されるのでステップＳ６２へ進み、ここでは、着信者アドレスのURIが管理テーブルに存在しないと判定されるので、ステップＳ６４へ進んで受信パケットが破棄される。
【００６０】
SIPサーバSV#4は、SIPサーバSV#3がステップＳ１２でリング側へ転送したパケットをステップＳ１で受信すると、前記SIPサーバSV#3の場合と同様にステップＳ６２まで進む。ステップＳ６２では、着信者アドレスのURIが管理テーブルに存在すると判定されるのでステップＳ６３へ進む。
【００６１】
ステップＳ６３では、自ホスト名のViaヘッダが存在するか否かが判定され、ここでは存在すると判定されるので、ステップＳ５５で自身のホスト名をViaヘッダに追加した後に図４のステップＳ３６へ進む。ステップS３６では、宛先IPアドレスが前記着信者アドレスのURIに対応したSIPフォン#2のIPアドレス「ipB」に付け替えられ、送信元IPアドレスが自身のIPアドレス「ip4」に付け替えられる。ステップＳ３７では、宛先IPアドレスがARPキャッシュエントリに存在すると判定されるのでステップＳ３９へ進み、前記アドレスの付け替えられたパケットがユーザ側インターフェースからSIPフォン#2へ送信される。
【００６２】
SIPフォン#2が前記リクエストメッセージに対するレスポンスを送信し、SIPサーバSV#4が、このメッセージをステップＳ１で受信すると、ステップＳ１，Ｓ２，Ｓ３，Ｓ４，Ｓ１８，Ｓ１９を経由してステップＳ２０へ進む。ステップＳ２０では、メッセージタイプがレスポンスと判定されるので図４のステップＳ３０へ進む。
【００６３】
ステップＳ３０では、着信者アドレスが自ドメインと判定され、ステップＳ３１では、着信者アドレスのURIが管理テーブルに存在すると判定されるのでステップＳ３２へ進む。ステップＳ３２では、Viaヘッダから自ホスト名「ps1.domain1.net」が一つだけ削除される。ステップＳ３３では発信者アドレスが自ドメインと判定され、ステップＳ３４では、発信者アドレスのURIが管理テーブルに存在しないと判定されるのでステップＳ４８へ進む。ステップＳ４８では、宛先IPアドレスが発信者アドレスに基づいてSIPサーバSV#2のIPアドレス「ip2」に付け替えられ、送信元IPアドレスが自身のIPアドレス「ip4」に付け替えられる。ステップＳ４９では、前記アドレスの付け替えられたフレームがリング側インターフェースから一方側の隣接サーバへ転送される。
【００６４】
SIPサーバ#5は、前記SIPサーバSV#4がステップＳ４９でリング側へ転送したパケットをステップＳ１で受信すると、ステップＳ２，Ｓ１０，Ｓ１２，Ｓ１４，Ｓ２０を経由して図４のステップＳ３０まで進む。ステップＳ３０では、着信者アドレスが自ドメインと判定され、ステップＳ３１では、着信者アドレスのURIが管理テーブルに存在しないと判定されるのでステップＳ４０へ進む。ステップＳ４０では、発信者アドレスが自ドメインと判定され、ステップＳ４１では、発信者アドレスのURIが管理テーブルに存在しないと判定されるので、ステップＳ４３へ進んで受信パケットが破棄される。上記した各手順は、ゲートウエイGWおよびSIPサーバSV#1でも同様に実行される。
【００６５】
SIPサーバSV#2は、SIPサーバSV#1がステップＳ１２でリング側へ転送したパケットをステップＳ１で受信すると、前記SIPサーバSV#5と同様の手順でステップＳ４１まで進む。ステップＳ４１では、発信者アドレスのURIが管理テーブルに存在するか否かが判定され、ここでは存在すると判定されるのでステップＳ４２へ進む。ステップＳ４２では、自ホスト名がViaヘッダに登録されていると判定されるので、ステップＳ３５，Ｓ３６，Ｓ３７を経由してステップＳ３９へ進む。ステップＳ３９では、アドレスの付け替えられたフレームがユーザ側インターフェースからSIPフォン#1へ送信される。
【００６６】
図１１、図１２、図１３は、同一ドメイン内でのユーザ／ユーザ間のメッセージ交換手順の他の例を示した図であり、図１１は、ユーザBの着信端末が、自身のセッション情報が存在しないSIPサーバ#5の配下に移動して着信する場合の手順を示している。図１２は、ユーザAの送信端末が、自身のセッション情報が存在しないSIPサーバ#3の配下に移動して発信する場合の手順を示している。図１３は、ユーザAの送信端末およびユーザBの着信端末が、いずれも自身のセッション情報が存在しないSIPサーバ#3、#5の配下に移動して発着信する場合の手順を示している。
【００６７】
各SIPサーバの動作は、図２，３，４，５の各フローチャートを参照すれば明らかなので、ここではサーバ間およびサーバ／ユーザ端末間で送受信されるフレームおよびパケットのヘッダの内容のみを示し、その動作説明は省略する。
【００６８】
次いで、図１４のブロック図および各フローチャートを参照して、同一ドメイン内でのユーザ／サーバ間での位置登録手順について説明する。
【００６９】
ユーザAはSIPフォン#1から、宛先IPアドレスがSIPサーバSV#2に固有のIPアドレス「ip2」、送信元IPアドレスが自身のIPアドレス「ipA」、種別がREGISTER（位置登録要求）、発信者アドレス(Fromヘッダ)および着信者アドレス(Toヘッダ)がいずれも自身のURI「UserA@domain1.net」であり、Viaヘッダに自身のホスト名「hostA@domain1.net」が登録されているフレームを送信する。
【００７０】
SIPサーバSV#2は、図２のステップＳ１で前記フレームを受信すると、ステップＳ２では、その発信者アドレスに基づいて、受信インターフェースがユーザ側と判定されるのでステップＳ３へ進み、当該受信フレームからパケットが取り込まれる。ステップＳ４では、パケットの宛先が「自分宛」と判定されるのでステップＳ１８へ進む。ステップＳ１８では受信パケットがSIPアプリケーションポートで受信される。ステップＳ１９では、メッセージのMethodタイプが判定され、ここではユーザ／サーバ間の通信と判定されるので図５のステップＳ８１へ進む。
【００７１】
ステップＳ８１では、メッセージがリクエストと判定されるのでステップＳ８２へ進み、ここでは着信者アドレスが自ドメインと判定されるのでステップＳ８３へ進む。ステップＳ８３では、着信者アドレスのURIが管理テーブルに存在するか否かが判定され、ここでは存在すると判定されるのでステップＳ８４へ進み、所定の位置登録処理が実行されると共に応答メッセージが生成される。ステップＳ８５では、宛先IPアドレスがSIPフォン#1のIPアドレス「ipA」に付け替えられ、送信元IPアドレスが自身のIPアドレス「ip2」に付け替えられる。
【００７２】
ステップＳ８６では、宛先IPアドレスがARPキャッシュエントリに存在するか否かが判定され、ここでは存在すると判定されるのでステップＳ８７へ進む。ステップＳ８７では、前記アドレスの付け替えられた応答メッセージがユーザ側インターフェースからSIPフォン#1へ送信される。
【００７３】
なお、ユーザAのセッション管理情報がSIPサーバSV#2ではなくSIPサーバSV#3に存在すると、SIPサーバSV#2ではステップS８３からＳ９２へ進んでパケットが破棄される。SIPサーバSV#3は、SIPサーバSV#2から転送されたパケットを受信してステップＳ８３まで進み、さらにステップＳ８６まで進むが、宛先IPアドレスがARPキャッシュエントリに存在しないと判定されるので、このパケットはステップS８８でリング側インターフェースから一方側の隣接ノードへ転送される。当該パケットは、SIPサーバSV#4、#5、ゲートウエイGWおよびSIPサーバSV#1を経由してSIPサーバSV#2まで転送され、このSIPサーバSV#2からSIPフォン#1へ送信される。
【００７４】
図１５、図１６、図１７は、同一ドメイン内でのユーザ／サーバ間での登録および通知手順の他の例を示した図であり、図１５は、ユーザAの端末が、自身のセッション情報が存在しないSIPサーバ#4の配下に移動して位置登録を行う場合の手順を示している。図１６は、ユーザAの端末が、自身のセッション情報が存在するSIPサーバ#2の配下で通知を受信する場合の手順を示している。図１７は、ユーザAの端末が、自身のセッション情報が存在しないSIPサーバ#4の配下に移動して通知を受信する場合の手順を示している。
【００７５】
各サーバの動作は、図２，３，４，５の各フローチャートを参照すれば明らかなので、ここではサーバ間およびサーバ／ユーザ端末間で送受信されるフレームおよびパケットのヘッダの内容のみを示し、その動作説明は省略する。
【図面の簡単な説明】
【００７６】
【図１】本発明に係るSIPサーバシステムのネットワーク構成を示したブロック図である。
【図２】SIPサーバシステムの制御手順を示したフローチャート（その１）である。
【図３】SIPサーバシステムの制御手順を示したフローチャート（その２）である。
【図４】SIPサーバシステムの制御手順を示したフローチャート（その３）である。
【図５】SIPサーバシステムの制御手順を示したフローチャート（その４）である。
【図６】ユーザが自身のセッション情報を管理するSIPサーバの配下から外部ドメインへ発信する際のメッセージの転送経路を模式的に示したブロック図である。
【図７】ユーザが自身のセッション情報を管理するSIPサーバの配下で外部ドメインから着信する際のメッセージの転送経路を模式的に示したブロック図である。
【図８】ユーザが自身のセッション情報を管理するSIPサーバ以外の配下から外部ドメインへ発信する際のメッセージの転送経路を模式的に示したブロック図である。
【図９】ユーザが自身のセッション情報を管理するSIPサーバ以外の配下で外部ドメインから着信する際のメッセージの転送経路を模式的に示したブロック図である。
【図１０】同一ドメイン内でのユーザ／ユーザ間のメッセージ交換手順（送受信端末がいずれも固定）を模式的に示したブロック図である。
【図１１】同一ドメイン内でのユーザ／ユーザ間のメッセージ交換手順（着信端末が移動）を模式的に示したブロック図である。
【図１２】同一ドメイン内でのユーザ／ユーザ間のメッセージ交換手順（送信端末が移動）を模式的に示したブロック図である。
【図１３】同一ドメイン内でのユーザ／ユーザ間のメッセージ交換手順（送受信端末がいずれも移動）を模式的に示したブロック図である。
【図１４】同一ドメイン内でのユーザ／サーバ間の登録手順（移動元での登録）を模式的に示したブロック図である。
【図１５】同一ドメイン内でのユーザ／サーバ間の登録手順（移動先での登録）を模式的に示したブロック図である。
【図１６】同一ドメイン内でのユーザ／サーバ間の通知手順（移動元での通知）を模式的に示したブロック図である。
【図１７】同一ドメイン内でのユーザ／サーバ間の通知手順（移動先での通知）を模式的に示したブロック図である。
【図１】
0004582646.tif 000002
【図２】
0004582646.tif 000003
【図３】
0004582646.tif 000004
【図４】
0004582646.tif 000005
【図５】
0004582646.tif 000006
【図６】
0004582646.tif 000007
【図７】
0004582646.tif 000008
【図８】
0004582646.tif 000009
【図９】
0004582646.tif 000010
【図１０】
0004582646.tif 000011
【図１１】
0004582646.tif 000012
【図１２】
0004582646.tif 000013
【図１３】
0004582646.tif 000014
【図１４】
0004582646.tif 000015
【図１５】
0004582646.tif 000016
【図１６】
0004582646.tif 000017
【図１７】
0004582646.tif 000018