(57)【要約】【課題】  冗長化されたＧＷは状態遷移中のセッション等のメモリの書き換えが頻繁に行われるセッションに関しては、障害等により現用系と待機系が切り替わった場合に現用系と状態が一致していない場合があり、セッションが救済できないという課題がある。【解決手段】  ＧＷの現用系と待機系が入れ替わったときに、ＳＩＰサーバからの状態通知の内容からセッション接続情報を取得して、ＳＩＰのセッション接続を継続する機能を具備するＧＷと、ＧＷからのセッション接続の状態の問い合わせにより、問い合わせ元のＵＲＩより、該当ＧＷのセッション接続状態を検索し、旧現用系とのセッション接続状態とセッション接続に必要な情報をＧＷの新現用系に状態通知を行う。【選択図】  図１
2011091589.tif 000002
【特許請求の範囲】
【請求項１】
音声通信端末と通信する第１の通信部と、
前記音声通信端末の呼接続を行う呼接続装置と通信する第２の通信部と、
前記音声通信端末の呼接続を行う呼接続装置と通信する第３の通信部と、
前記第１の通信部から通信要求を受信すると、前記第２の通信部を介して前記呼接続装置と前記音声通信端末の呼接続処理を行う第１の呼接続処理部と、
予備の前記第３の通信部を介して前記呼接続装置と前記音声通信端末の呼接続処理を行う第２の呼接続処理部と、
障害発生時に、前記呼接続装置に対し前記第１の呼接続処理部が行っていた呼接続処理の接続情報を問い合わせる状態問い合わせ部と、
前記呼接続装置から通知された接続通知を処理する状態通知処理部を有し、
前記第１の呼接続処理部に障害が発生した場合、前記第２の呼接続処理部が前記第３の通信部を介して前記状態問い合わせ部により接続情報の要求メッセージを送信し、前記状態通知処理部により取得した呼接続処理の接続情報を基に呼接続処理を再開することを特徴とする通信装置。
【請求項２】
音声通信端末と通信する第１の通信部と、
前記音声通信端末の呼接続を行う呼接続装置と通信する第２の通信部と、
前記音声通信端末の呼接続を行う呼接続装置と通信する第３の通信部と、
前記第１の通信部から通信要求を受信すると、前記第２の通信部を介して前記呼接続装置と前記音声通信端末の呼接続処理を行う第１の呼接続処理部と、
予備の前記第３の通信部を介して前記呼接続装置と前記音声通信端末の呼接続処理を行う第２の呼接続処理部と、
障害発生時に、前記呼接続装置に対し前記第１の呼接続処理部が行っていた呼接続処理の接続情報を問い合わせる状態問い合わせ部と、
前記呼接続装置から通知された接続通知を処理する状態通知処理部を有し、
前記第１の呼接続処理部に障害が発生した場合、前記第２の呼接続処理部が前記第３の通信部を介して前記呼接続装置に対し登録要求を送信し、前記状態問い合わせ部により接続情報の要求メッセージを送信し、前記状態通知処理部により取得した呼接続処理の接続情報を基に呼接続処理を再開することを特徴とする通信装置。
【請求項３】
請求項１記載の通信装置であって、
前記第２の呼接続処理部により呼接続処理を再開する場合には、障害発生前に前記第２の通信部で使用していたアドレスを前記第３の通信部に設定することを特徴とする通信装置。
【請求項４】
請求項２記載の通信装置であって、
前記第２の呼接続処理部により呼接続処理を再開する場合には、障害発生前に前記第２の通信部で使用していたアドレスと異なるアドレスを前記第３の通信部に設定することを特徴とする通信装置。
【請求項５】
請求項１乃至４記載の通信装置であって、
前記第１の呼接続処理部による呼接続処理、又は、呼接続が確立している通話における接続情報を格納する接続管理テーブルを有し、
呼接続状態が変化するごとに前記接続管理テーブルを更新することを特徴とする通信装置。
【請求項６】
請求項５記載の通信装置であって、
呼接続処理が確立した通話の接続情報を前記接続管理テーブルに格納する場合は、予備の接続管理テーブルにも当該呼接続処理が確立した通話の接続情報を格納することを特徴とする通信装置。
【請求項７】
請求項６記載の通信装置であって、
前記接続情報は、前記発信者情報と、前記着信者情報と、前記呼接続状態と、前記呼接続の識別情報を含むことを特徴とする通信装置。
【請求項８】
請求項７記載の通信装置であって、
前記第２の呼接続処理部は、前記第１の呼接続処理部に障害が発生した場合、前記予備の接続管理テーブルを用いて呼接続処理を行うことを特徴とする通信装置。
【請求項９】
請求項１乃至８記載の通信装置であって、
前記通知された呼接続処理の接続情報には、障害発生前の呼接続処理で使用していた発信者情報、着信者情報、呼接続の状態、呼接続の識別情報が含まれることを特徴とする通信装置。
【請求項１０】
請求項９記載の通信装置であって、
前記状態通知処理部は、前記受信した呼接続処理の接続情報を前記予備の接続管理テーブルに格納し、
前記第２の呼接続処理部は、当該格納された呼接続処理の接続情報を用いて中断された呼接続処理を再開することを特徴とする通信装置。
【請求項１１】
請求項１乃至２記載の通信装置であって、
前記問い合わせはＳＩＰのＳＵＢＳＣＲＩＢＥメッセージにより送信することを特徴とする通信装置。
【請求項１２】
請求項１１記載の通信装置であって、
前記接続情報はＳＩＰのＮＯＴＩＦＹメッセージにより受信することを特徴とする通信装置。
【請求項１３】
請求項７記載の通信装置であって、
前記呼接続の識別情報は、ＣＡＬＬ−ＩＤとＣｓｅｑであることを特徴とする通信装置。
【請求項１４】
請求項２記載の通信装置であって、
前記登録要求は、ＳＩＰのＲＥＧＩＳＴＥＲメッセージであることを特徴とする通信装置。
【請求項１５】
音声通信端末同士の呼接続処理を行う呼接続装置であって、
前記音声通信端末と通信する通信部と、
前記音声通信端末同士の呼接続処理を行う呼接続処理部と、
前記音声通信端末同士の呼接続処理の接続情報を管理する呼接続中状態管理テーブルと、
前記呼接続中状態管理テーブルに格納された接続情報の要求メッセージを受信処理する状態問い合わせ処理部とを有し、
前記呼接続中状態管理テーブルは、前記呼接続処理部が前記通信部を介して行う呼接続処理の接続情報が更新される毎に当該呼接続処理の接続情報が格納され、
前記状態問い合わせ処理部は、前記格納した呼接続の接続情報の要求メッセージを受信すると当該格納した呼接続の接続情報を要求元装置に通知することを特徴とする呼接続装置。
【請求項１６】
請求項１５記載の呼接続装置であって、
前記状態問い合わせ処理部は、前記受信した要求メッセージの送信元アドレスを検索キーとして前記呼接続中状態管理テーブルを検索し、前記要求元装置に通知する接続情報を取り出すことを特徴とする呼接続装置。
【請求項１７】
請求項１６記載の呼接続装置であって、
前記状態問い合わせ処理部は、前記呼接続中状態管理テーブルを検索して前記要求元装置が要求する接続情報が見つからない場合はその旨を前記要求元装置に通知することを特徴とする呼接続装置。
【請求項１８】
請求項１５乃至１６記載の呼接続装置であって、
前記呼接続中状態テーブルに格納される呼接続の接続情報には、発信者情報、着信者情報、呼接続の状態、呼接続の識別情報が含まれることを特徴とする呼接続装置。
【請求項１９】
請求項１５乃至１８記載の呼接続装置であって、
前記要求メッセージはＳＩＰのＳＵＢＳＣＲＩＢＥメッセージであることを特徴とする呼接続装置。
【請求項２０】
請求項１５乃至１９記載の呼接続装置であって、
前記前記要求元装置への通知はＳＩＰのＮＯＴＩＦＹメッセージであることを特徴とする呼接続装置。
【請求項２１】
音声通信端末の呼接続処理を中継する通信装置と、音声通信端末同士の呼接続処理を行う呼接続装置からなる呼接続システムにおいて、
前記通信装置は、
音声通信端末と通信する第１の通信部と、前記音声通信端末の呼接続を行う呼接続装置と通信する第２の通信部と、前記音声通信端末の呼接続を行う呼接続装置と通信する第３の通信部と、前記第１の通信部から通信要求を受信すると、前記第２の通信部を介して前記呼接続装置と前記音声通信端末の呼接続処理を行う第１の呼接続処理部と、予備の前記第３の通信部を介して前記呼接続装置と前記音声通信端末の呼接続処理を行う第２の呼接続処理部と、障害発生時に、前記呼接続装置に対し前記第１の呼接続処理部が行っていた呼接続処理の接続情報を問い合わせる状態問い合わせ部と、前記呼接続装置から通知された接続通知を処理する状態通知処理部を有し、
前記第１の呼接続処理部に障害が発生した場合、前記第２の呼接続処理部が前記第３の通信部を介して前記状態問い合わせ部により接続情報の要求メッセージを送信し、前記状態通知処理部により取得した呼接続処理の接続情報を基に呼接続処理を再開し、
前記呼接続装置は、
前記音声通信端末と通信する通信部と、前記音声通信端末同士の呼接続処理を行う呼接続処理部と、前記音声通信端末同士の呼接続処理の接続情報を管理する呼接続中状態管理テーブルと、前記呼接続中状態管理テーブルに格納された接続情報の要求メッセージを受信処理する状態問い合わせ処理部とを有し、
前記呼接続中状態管理テーブルは、前記呼接続処理部が前記通信部を介して行う呼接続処理の接続情報が更新される毎に当該呼接続処理の接続情報が格納され、前記状態問い合わせ処理部は、前記格納した呼接続の接続情報の要求メッセージを受信すると当該格納した呼接続の接続情報を要求元装置に通知することを特徴とする呼接続システム。
【請求項２２】
請求項２１記載の呼接続システムであって、
前記呼接続装置の前記状態問い合わせ処理部は、前記受信した要求メッセージの送信元アドレスを検索キーとして前記呼接続中状態管理テーブルを検索し、前記要求元装置に通知する接続情報を取り出すことを特徴とする呼接続システム。
【請求項２３】
請求項２２記載の呼接続システムであって、
前記接続情報は、発信者情報と、着信者情報と、呼接続状態と、呼接続の識別情報を含むことを特徴とする呼接続システム。
【請求項２４】
請求項２３記載の呼接続システムであって、
前記通信装置が送信する要求メッセージはＳＩＰのＳＵＢＳＣＲＩＢＥメッセージであり、
前記呼接続装置が送信する通知はＳＩＰのＮＯＴＩＦＹメッセージであることを特徴とする呼接続システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ網における電話サービスのセッション救済方法に係わり、特にセッション制御及び管理を行う装置の障害時に、セッション情報を復旧するシステム及び装置に関する。
【背景技術】
【０００２】
大容量回線の低価格化や通信業界の規制緩和などにより、安価に電話を行うことのできるＶｏＩＰ（ＶｏＩＰ：Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）技術を基盤としたＩＰ（ＩＰ：Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）電話が普及し、ＩＰ電話の利用者が増加傾向にある。また、従来の通信ネットワークは電話網、移動網、専用線網、放送網などサービス毎に垂直統合された独立したネットワークであったが、近年、複数存在していたネットワークを一つに統合してオペレーションコストを低減させる動きがある。統合後のネットワークは、ＩＰ網で構成されることが考えられ、従来の公衆回線電話網（ＰＳＴＮ：Ｐｕｂｌｉｃ  Ｓｗｉｔｃｈｉｎｇ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋ）もＩＰで構成されたネットワークへ移行することが想定され、従来の公衆回線電話網の中継網がＩＰとなることが考えられる。
【０００３】
インターネット上でＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）やインスタントメッセージング等のリアルタイムサービスに用いられるプロトコルとして、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の標準化が行われ、ＩＥＴＦ ＲＦＣ３２６１（非特許文献１）として制定されている。サービスの実現に当たっては、センタ側でＳＩＰプロキシー（Ｐｒｏｘｙ）の機能とＳＩＰ登録（Ｒｅｇｉｓｔｒａｒ）の機能を併せ持つＳＩＰサーバと、ＰＳＴＮのＳＴＭ（Ｓｙｎｃｒｏｎｏｕｓ  Ｔｒａｎｓｆｅｒ  Ｍｏｄｅ：同期転送モード）音声信号データとＩＰ音声パケットとの相互変換や、ＳＩＰを使用して対向装置とセッション制御を行い、ＰＳＴＮとＩＰ網を接続するゲートウェイ（ＧＷ：Ｇａｔｅｗａｙ）の提供が必要となる。
【０００４】
ＳＩＰサーバやＧＷは、複数の端末からの接続要求を受け付け、相手端末との通信（以降セッションと呼ぶ）の状態を管理している。従って、システムの実現に当たってはその信頼性および可用性に配慮した設計が重要となる。
【０００５】
一般に、システムの信頼性・可用性を確保する技術としてホットスタンバイ方式とコールドスタンバイ方式が知られている。ホットスタンバイは、同じ構成のシステムを２系統用意しておき、片方（現用系）を作動させ、もう一方（待機系）は同じ動作を行ないながら待機状態にしておく。待機系は現用系と常に同じ状態を保っておき、現用系に障害が発生すると即座に待機系に処理が引き継がれる。一方、コールドスタンバイは、同じ構成の２つのシステムを構築し、片方は通常通りに動作させておき、もう一方は待機として動作させずに待機させておく。通常動作を行っているシステムに障害が発生した場合に、待機のシステムを起動し、通常動作のシステムと同じ状態にした後に切り替える方式である。
【０００６】
コールドスタンバイでは、障害が発生してから待機のシステムを起動して切り替えるため、障害発生時にはシステム全体の停止時間が長くなる。通常時には待機のシステムを稼動しておく必要がないため、コストを安く抑えられるというメリットがある。一方、ホットスタンバイは、常に待機のシステムも動作させているためコストがかかるが、障害発生時には瞬時に切り替えられるため、システム全体の停止時間は短くなり、耐障害性が高まるというメリットがある。
【０００７】
電子交換機の分野においては、制御系装置内の異常でもセッション救済を実現し、現用系と待機系と、それらの系間で共有が必要なデータを記憶する領域を有する外部記憶装置と、外部記憶装置の接続系を切り替える切替スイッチを設け、系間の情報転送、運転同期を取る方式が開示されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平５−２４４２６０号公報
【非特許文献】
【０００９】
【非特許文献１】ＩＥＴＦ（ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ） ＲＦＣ３２６１
【発明の概要】
【発明が解決しようとする課題】
【００１０】
従来の技術ではホットスタンバイ方式とコールドスタンバイ方式があるが、それぞれに課題がある。ホットスタンバイ方式では、ＣＰＵ、メモリ、ディスク、ネットワークといった全てのハードウエアを二重化してこれを同時に動作させることでセッション救済を行う。コールドスタンバイ方式における引継ぎ方式として現用系システムの全メモリ内容を外部記憶装置にバックアップし、待機系システムはこれを再ロードして再開することでセッション救済を行う。
【００１１】
しかし、ホットスタンバイ方式及びコールドスタンバイ方式ともに、状態遷移中のセッション等のメモリの書き換えが頻繁に行われるセッションに関しては、障害等により現用系と待機系が切り替わった場合にホットスタンバイ方式のスタンバイ側へのメモリのコピーや、コールドスタンバイ方式の外部記憶装置へのバックアップが現用系と状態が一致していない場合があり、状態遷移中のセッションが救済できないといった課題がある。
【００１２】
本発明は、以上の点に鑑み、ＧＷが障害等により現用系と待機系が切り替わった場合においても、状態遷移中のセッションを救済する方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
音声通信端末と通信する第１の通信部と、前記音声通信端末の呼接続を行う呼接続装置と通信する第２の通信部と、前記音声通信端末の呼接続を行う呼接続装置と通信する第３の通信部と、前記第１の通信部から通信要求を受信すると、前記第２の通信部を介して前記呼接続装置と前記音声通信端末の呼接続処理を行う第１の呼接続処理部と、予備の記第３の通信部を介して前記呼接続装置と前記音声通信端末の呼接続処理を行う第２の呼接続処理部と、障害発生時に、前記呼接続装置に対し前記第１の呼接続処理部が行っていた呼接続処理の接続情報を問い合わせる状態問い合わせ部と、前記呼接続装置から通知された接続通知を処理する状態通知処理部を有し、前記第１の呼接続処理部に障害が発生した場合、前記第２の呼接続処理部が前記第３の通信部を介して前記状態問い合わせ部により接続情報の要求メッセージを送信し、前記状態通知処理部により取得した呼接続処理の接続情報を基に呼接続処理を再開することを特徴とする通信装置およびシステムを提供する。
【発明の効果】
【００１４】
本発明によると、ＧＷが障害等により現用系と待機系が切り替わった場合においても、状態遷移中のセッションの救済を行うことにより、継続して接続処理を行うことができる。
【図面の簡単な説明】
【００１５】
【図１】ＩＰ電話ネットワーク構成例を示す図
【図２】ＳＩＰサーバの主要部のブロック構成を示す図
【図３】ＧＷの主要部のブロック構成を示す図
【図４】ＧＷ（現用系）の接続管理テーブルの構成を示す図
【図５】ＧＷ（待機系）の接続管理テーブルの構成を示す図
【図６】ＳＩＰサーバの加入者管理テーブルの構成を示す図
【図７】ＳＩＰサーバのセッション接続中情報管理テーブルの構成を示す図
【図８】ＳＩＰサーバの接続管理テーブルの構成を示す図
【図９】ＧＷの現用系と待機系で固定のＩＰアドレスで動作する場合のセッション救済提供時の動作シーケンスの例を示す図
【図１０】ＳＩＰサーバにおけるＳＩＰ処理部フローを示す図
【図１１】ＳＩＰサーバにおける状態問合せ及び状態通知処理フローを示す図
【図１２】ＧＷにおける待機系の系切替え処理フローを示す図
【図１３】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ１０１）
【図１４】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ１０３/ＳＱ１０４）
【図１５】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ１０６）
【図１６】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ１０８）
【図１７】ＧＷ（待機系）の接続管理テーブルの構成を示す図
【図１８】ＳＩＰサーバの加入者管理テーブルの構成を示す図
【図１９】ＳＩＰサーバのセッション接続中情報管理テーブルの構成を示す図
【図２０】ＳＩＰサーバのセッション接続中情報管理テーブルの構成を示す図
【図２１】ＳＩＰサーバのセッション接続中情報管理テーブルの構成を示す図
【図２２】ＳＩＰサーバのセッション接続中情報管理テーブルの構成を示す図
【図２３】ＳＩＰサーバの接続管理テーブルの構成を示す図
【図２４】ＧＷの現用系と待機系で個別のＩＰアドレスで動作する場合のセッション救済提供時の動作シーケンスの例を示す図
【図２５】ＳＩＰサーバにおける状態問合せ及び状態通知処理フローを示す図
【図２６】ＧＷにおける待機系の系切替え処理フローを示す図
【図２７】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ２０１）
【図２８】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ２０３/ＳＱ２０４）
【図２９】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ２０８）
【図３０】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ２１０）
【図３１】ＧＷとＳＩＰサーバ間のＳＩＰメッセージの記述例（ＳＱ２０６）
【図３２】セッション制御プロトコルのデータフォーマットを示す図
【発明を実施するための形態】
【実施例１】
【００１６】
以下、図面を用いて実施例について詳細に説明する。図１は、セッション制御プロトコルとしてＳＩＰを用いた場合のＩＰ電話ネットワークを示す構成例を示す図である。ネットワークでは、複数のＩＰ電話端末１（１−２Ａ、２Ｂ）、ＳＩＰサーバ２、各ＩＰ電話端末１とルータ（Ｒ）４（４−１〜３）を接続するためのＬ２ＳＷ３（３−１、２）および、ＰＳＴＮで使用するアナログ電話端末や、ＩＳＤＮ端末（１−１Ａ、２Ｂ）、ＰＳＴＮのＳＴＭ音声信号データとＩＰ音声パケットとの相互変換を行うＧＷ５から構成される。
【００１７】
ＩＰ電話端末１（１−２Ａ、２Ｂ）はＩＰネットワーク上で音声通話することができる電話機に相当するものである。ＳＩＰサーバ２は、インターネットなどのＩＰネットワーク上で、従来の電話交換機の役割を果たす装置である。（Ｒ）４（４−１〜３）とＬ２ＳＷ３（３−１、２）はＩＰネットワーク上でデータの転送を行う装置である。ＧＷ５はこのＩＰネットワークにアナログ電話末などを接続するために使用する装置である。
【００１８】
各電話端末間で通信を行う場合、まず、発呼端末１-１ＡからＳＩＰサーバ２に対して登録を行う。次に、ＳＩＰサーバ２に対して、通信相手と通話するために、ＳＩＰサーバ２を介してＳＩＰメッセージにて接続制御を行い、セッション接続完了後、発呼端末１−１Ａと着呼端末１‐２Ｂ間にて通話が行われる。図２は、ＳＩＰサーバ２の主要部を示すブロック構成図である。
【００１９】
ＳＩＰサーバ２は、主にＳＩＰ処理部部２０、回線ＩＦ２１、制御部２２、状態問合せ処理部２３、接続管理テーブル２４、セッション接続中情報管理テーブル２５、加入者管理テーブル２６から構成される。ＳＩＰ処理部部２０は、主にＳＩＰのＲＥＧＩＳＴＥＲ処理（Ｆ２１）、接続・切断登録処理（Ｆ２２）、ＳＵＢＳＣＲＩＢＥ受信処理（Ｆ２３）、ＮＯＴＩＦＹ送信処理（Ｆ２４）が行われる。
【００２０】
回線ＩＦ２１は、ネットワークとのインターフェース部であり、ＧＷ５やＩＰ電話端末１−２Ａ等と通信する呼制御プロトコルの送受信を行う。状態問合せ処理部２３は、ＳＩＰサーバ２と接続される装置から受信した状態問合せメッセージから、メッセージの送信元アドレス２２２０を検索キーとしてセッション接続中情報管理テーブル２５のＵＲＩ７１０を検索し、該当のＵＲＩ７１０のテーブル情報から状態通知メッセージを生成して、状態問合せメッセージの送信元へ生成した状態通知メッセージを送信する。
【００２１】
接続管理テーブル２４は、セッションの接続管理テーブルを持ち、課金に必要な接続開始時間や切断時間や発信者情報、着信者情報を管理する。セッション接続中情報管理テーブル２５は、セッションの接続要求から切断要求までの１つのセッションの一連の状態を管理する。加入者管理テーブル２６は、電話番号と該当電話番号を収容する装置のアドレスを管理する。制御部２２は、ＳＩＰサーバ２内のＳＩＰ処理部２０、回線ＩＦ２１、状態問合せ処理部２３、接続管理テーブル２４、セッション接続中情報管理テーブル２５、加入者管理テーブル２６の制御を行う。
【００２２】
図３は、ＧＷ５の主要部を示すブロック構成図である。ＧＷ５は、ＰＳＴＮで使用するアナログ電話端末やＩＳＤＮ端末をＩＰネットワークに接続し、ＩＰネットワークを介して通話可能にするための装置である。通話相手はＩＰネットワークに接続されたＩＰ電話以外にも、同様にＧＷを介して接続されているアナログ電話端末やＩＳＤＮ端末の場合もある。
【００２３】
ＧＷ５は、主に回線ＩＦ（インタフェース）３１と、現用系３０Ａと待機系３０Ｓで構成される。現用系３０Ａは、制御部３２、ＳＩＰ処理部３３、ＶｏＩＰ処理部３４、接続管理テーブル３５、状態問合せ部３６、状態通知処理部３７、ＩＰ回線ＩＦ３８から構成される。ＳＩＰ処理部３３は、主に登録処理（Ｆ３１）、接続・切断処理（Ｆ３２）、ＳＵＢＳＣＲＩＢＥ送信処理（Ｆ３３）、ＮＯＴＩＦＹ受信処理（Ｆ３４）が行われる。
【００２４】
ＶｏＩＰ処理３４は、ＩＰ回線ＩＦ３８から受信したＲＴＰパケットのデコード処理を行い電話回線ＩＦ３１にＴＤＭデータを出力する。また、電話回線ＩＦ３１から受信したＴＤＭデータをＲＴＰパケットに変換してＩＰ回線ＩＦ３８にＲＴＰパケットを出力する。電話回線ＩＦ３１では、現用系３０Ａと待機系３０Ｓの両方からデコード処理されたＴＤＭ信号が出力されるので現用系を選択して外部の電話端末へＴＤＭデータを出力する。
【００２５】
接続管理テーブル３５は、セッションの接続管理テーブルを持ち、セッションに必要な発信者情報や着信者情報、セッション情報を管理する。状態問合せ部３６は、故障が発生した場合に新現用系からセッション状態をＳＩＰサーバ２へ問い合わせるために状態問合せメッセージを生成する。
【００２６】
状態通知処理部３７は、ＳＩＰサーバ２から返信された状態通知メッセージを受信し、状態通知メッセージに含まれるセッション情報を抽出して接続管理テーブル３５の空きのエントリに受信したセッション情報を格納する。制御部３２は、ＳＩＰ処理部３３、ＶｏＩＰ処理部３４、接続管理テーブル３５、状態問合せ部３６、状態通知処理部３７、ＩＰ回線ＩＦ３８の制御を行う。待機系３０Ｓは現用系３０Ａと同じ構成となる。
【００２７】
図４は、ＧＷ５の現用系３０ＡのＳＩＰ処理部部３３Ａの接続・切断処理（Ｆ３２Ａ）にてＳＩＰサーバ２との接続処理の状態を管理する接続管理テーブル３５Ａのデータフォーマットの一例を示す図である。
【００２８】
接続管理テーブル３５ＡはＧＷ５を介して行われる呼接続処理、音声通信の状態を管理するためのテーブルである。
【００２９】
接続管理テーブル３５Ａは、発信者の情報である電話番号と、発信者の電話番号を収容している装置のアドレス（ＩＰアドレス）、セッション処理中に該当電話番号の端末又はＧＷがセッションを識別するための情報（Ｔａｇ情報）を格納する発信者情報４１０と、着信者の情報である電話番号と、着信者の電話番号を収容している装置のアドレス（ＩＰアドレス）、セッション処理中に該当電話番号の端末又はＧＷがセッションを識別するための情報（Ｔａｇ情報）を格納する着信者情報４２０と、ＳＩＰの接続処理の状態を示すＳＩＰステータス４３０と１つのセッションの一連の接続処理をグループ化して他の呼のセッションと区別するための識別情報（Ｃａｌｌ−ＩＤ４４０）と新たなリクエストの発行毎に増加するシーケンス番号（ＣＳｅｑ４５０）から構成される。
【００３０】
本実施例では、ＩＰとＳＩＰを用いて説明する。例えば、エントリ４８０−１は、発信者情報４１０のユーザーと着信者情報４２０のユーザーがＣａｌｌ−ＩＤ：２２２２２２＠ＢとＣＳｅｑ：５５５５ＡＣＫを使用して、セッションが確立して発信者情報４１０のユーザーと着信者情報４２０のユーザー間で通話していることを示している。エントリ４８０−２は、発信者情報４１０のユーザーが着信者情報４２０のユーザーに発呼して、Ｃａｌｌ−ＩＤ：１１１１１１＠ＡとＣＳｅｑ：１０１１ ＩＮＶＩＴＥを使用してセッション確立中であり、着信者情報４２０のユーザーに対して、呼び出ししている状態であることを示している。
【００３１】
図５は、ＧＷ５の待機系３０Ｓの接続管理テーブル３５Ｓのデータフォーマットの一例を示す図である。データフォーマットの内容は現用系３０Ａと同じである。エントリ５８０−１は通話中の状態であり、状態が確立したため現用系の接続管理テーブル３５Ａから情報をコピーして情報を一致させている。
【００３２】
図６は、ＳＩＰサーバ２のＳＩＰ処理部部２０のＲＥＧＩＳＴＥＲ処理（Ｆ２１）にてＳＩＰサーバ２に登録される各加入者情報を管理する加入者管理テーブル２６のテーブル構成を示す図である。加入者管理テーブル２６は、ＳＩＰサーバ２が提供する呼接続サービスに参加する利用者または電話端末に割り振られた電話番号とＩＰアドレスとの対応を格納する。
【００３３】
ＳＩＰサーバ２が交換機としての役割を果たす際には、発信側電話端末から受信側電話端末の電話番号を受信し、当該受信した電話番号を検索キーとして加入者管理テーブル２６から受信側電話端末のＩＰアドレスを取り出し、呼接続メッセージを転送する。
【００３４】
加入者管理テーブル２６は、加入者の電話番号６１０、加入者の電話番号６１０を収容している装置のアドレス（ＩＰアドレス６３０）から構成される。本実施例では一例としてＩＰアドレスを用いて説明する。
【００３５】
図８は、ＳＩＰサーバ２のＳＩＰ処理部部２０の接続・切断登録処理（Ｆ２２）にてＧＷ５やＩＰ電話端末１-２Ａ、１‐２Ｂとのセッション制御におけるＩＮＶＩＴＥや、接続登録処理および切断登録処理の各処理によりＳＩＰサーバ２にて管理する接続管理テーブル２４のテーブル構成を示す図である。ＳＩＰサーバ２が処理する呼接続に関する情報を管理するテーブルである。
【００３６】
接続管理テーブル２４は、接続開始時間８１０、切断時間８２０、セッションの接続処理の状態を示すステータス８３０、発信者の電話番号と該当電話番号を収容する装置のアドレス（ＩＰアドレス）を格納する発信者情報８４０、着信者の電話番号と該当電話番号を収容する装置のアドレス（ＩＰアドレス）を格納する着信者情報８５０から構成される。
【００３７】
図７は、ＳＩＰサーバ２のＳＩＰ処理部部２０の接続・切断登録処理（Ｆ２３）にてＧＷ５やＩＰ電話端末１-２Ａ、１‐２Ｂとの接続処理の状態を管理するセッション接続中情報管理テーブル２５のデータフォーマットの一例を示す図である。セッション接続中情報管理テーブル２５は、先ほど説明した接続管理テーブル２４の管理する呼接続処理のセッションの毎に現在どのシーケンス処理を行っているかまでを管理しており、後に説明するＧＷ５でのセッション救済に利用されるものである。
【００３８】
セッション接続中情報管理テーブル２５は、端末を収容している装置の場所を示すＵＲＩ７１０（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）とＵＲＩ単位にセッション接続中の端末情報を保持し、端末の情報である電話番号と、該当電話番号を収容している装置のアドレス（ＩＰアドレス）、セッション処理中に該当電話番号の端末又はＧＷがセッションを識別するための情報（Ｔａｇ情報）を格納する発信者情報７２０と、接続先の情報である電話番号と、該当電話番号を収容している装置のアドレス（ＩＰアドレス）、セッション処理中に該当電話番号の端末又はＧＷがセッションを識別するための情報（Ｔａｇ情報）を格納する着信者情報７３０と、ＳＩＰの接続処理の状態を示すＳＩＰステータス７４０と１つのセッションの一連の接続処理をグループ化して他の呼のセッションと区別するための識別情報（Ｃａｌｌ−ＩＤ７５０）と新たなリクエストの発行毎に増加するシーケンス番号（ＣＳｅｑ７６０）と保持している端末情報が発信者か着呼者かを示すＤＩＲ７７０から構成される。
【００３９】
本実施例では、ＩＰとＳＩＰを用いて説明する。例えば、エントリ７８０−１は、ＵＲＩ：２０．０．０．１に収容する電話番号０４５−１１１−２２２２の端末から電話番号０３−５０００−１１１１の端末に発呼して通話していることを示している。このときの発呼で使用するＳＩＰのＣａｌｌ−ＩＤとＣＳｅｑは、それぞれＣａｌｌ−ＩＤ：２２２２２２＠ＢとＣＳｅｑ：５５５５ ＡＣＫを使用していることを示す。
【００４０】
図３２は、ＧＷ５とＳＩＰサーバ２の間で通信されるセッション制御プロトコルのデータフォーマットの一例を示す図である。図１３〜図１６で示すデータはデータ領域２２３０に格納される。
【００４１】
セッション制御プロトコルのデータフォーマットは、送信先の装置のアドレスを示す送信先アドレス２２１０と、送信元の装置のアドレスを示す送信元アドレス２２２０と、送信するセッション制御プロトコルの情報を格納するデータ領域２２３０と、送信先アドレス２２１０と送信元アドレス２２２０とデータ領域２２３０のデータの誤り検出を行うためのＦＣＳ２２４０（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）で構成する。
【００４２】
例えば、ＧＷ５からＳＩＰサーバ２へＩＮＶＩＴＥのセッション制御プロトコル（図９のＳＱ１０１）を送信するとき、送信先アドレス２２１０にＳＩＰサーバ２のアドレスを格納し、送信元アドレス２２２０にＧＷ５のアドレスを格納し、データ領域２２３０には、図１３のＳＱ１０１のメッセージを格納する。ＦＣＳ２２４０には、送信先アドレス２２１０と送信元アドレス２２２０とデータ領域２２３０の情報から生成多項式で算出した計算値を格納する。
【００４３】
次に、図１のシステムにおいてどのように呼接続処理が行われるか、および、障害時にどのように途中で中断された呼接続処理を救済するかを説明する。
【００４４】
具体的にはＧＷ５に接続される電話端末１‐１Ａと電話端末１‐１ＢのＩＰアドレスをＧＷ５の現用系ＩＰアドレスとし、待機系が現用系に変化した場合においても旧現用系３０Ａで使用していたＩＰアドレスを新現用系３０Ｓで使用する場合の動作について説明する。
【００４５】
図９は本システムにおけるセッション救済提供時の動作シーケンスの一例である。故障時に新現用系３０Ｓから状態を問い合わせる、状態問合せ信号は、ＳＩＰのＳＵＢＳＣＲＩＢＥを例として以下に説明する。また、ＳＩＰサーバからの状態通知信号は、ＳＩＰのＮＯＴＩＦＹを例として以下に説明する。ＳＵＢＳＣＲＩＢＥとＮＯＴＩＦＹは一例であり、その他のメッセージでも状態問合せと状態通知を行うことで実現可能である。
【００４６】
図１０は、本システムにおけるセッション救済提供時のＳＩＰサーバ２のＳＩＰ処理部の動作フローを示したフローチャートの一例である。図１１は、本システムにおけるセッション救済提供時の状態問合せと状態通知処理の動作フローを示したフローチャートの一例である。図１２は、本システムにおけるセッション救済提供時のＧＷ５の待機系が現用系に系切替えしたときの新現用系３０Ｓの動作フローを示したフローチャートの一例である。図１３〜図１６は、ＧＷ５とＳＩＰサーバ２の間で通信するＳＩＰ信号のメッセージ情報である。以下、図１〜図１６を用いてセッション救済方法の動作を説明する。
【００４７】
まず、ＧＷ５及びＩＰ電話端末１‐２Ａ、ＩＰ電話端末１‐２Ｂの電源を入れた場合等、通話を可能とするために予めＳＩＰサーバ２に対してＲＥＧＩＳＴＥＲリクエストを送出して加入者管理テーブル２６に電話番号６１０とＩＰアドレス６３０を登録する。
【００４８】
発呼端末１‐１Ａから着呼端末１‐２Ｂの電話番号をダイヤルする（ＳＱ１００）。ＧＷ５ではダイヤルされた電話番号（Ｍ１３１‐１）と、発呼端末の情報（Ｍ１３１‐２）と、ＧＷ５のＩＰアドレス（Ｍ１３１‐３）から、ＳＩＰのＩＮＶＩＴＥリクエスト（Ｍ１３１）を生成してＳＩＰサーバ２に送出する（ＳＱ１０１）。ＳＩＰサーバ２では、ＳＩＰメッセージを受信するまで待機して、セッション処理関係のＳＩＰメッセージを受信した場合（Ｆ１０１）、受信したＳＩＰメッセージがＩＮＶＩＴＥリクエストかを判断して、ＩＮＶＩＴＥリクエストの場合（Ｆ１０２）、ＩＮＶＩＴＥリクエスト（Ｍ１３１）の着信者情報（Ｍ１３１‐１）の値である「０３５０００２２２２」を検索キー情報として加入者管理テーブル２６を検索し、「０３５０００２２２２」が登録されているエントリ６５０−ｎのテーブルの中から着信者側のＩＰアドレス「ＩＰ４＝１１．０.０．２」を抽出する（Ｆ１０３）。
【００４９】
更にＳＩＰサーバ２は、検索した着信者のＩＰアドレスとＩＮＶＥＴＥリクエスト（Ｍ１３１）に含まれる情報から接続管理テーブル２４の発呼端末と着呼端末の情報を図８（ａ）から図８（ｂ）に更新する（Ｆ１０４）。具体的にはＩＮＶＩＴＥリクエスト（Ｍ１３１）のＦＲＯＭ情報の電話番号「０４５１１１１１１１」（Ｍ１３１−２）と、ＩＰアドレス「２０．０.０．１」（Ｍ１３１−３）をＳＩＰサーバ２の接続管理テーブル２４の発信者情報８４０に格納する。
【００５０】
また、ＩＮＶＩＴＥリクエスト（Ｍ１３１）のＴＯ情報の電話番号「０３５０００２２２２」（Ｍ１３１−１）と、加入者管理テーブル２６から抽出した着信先のＩＰアドレス「１１．０.０．２」（Ｆ１０３）をＳＩＰサーバ２の接続管理テーブル２４の着信者情報８５０に格納する。更に、受信ステータス８３０にＩＮＶＩＴＥ受信  １８０ＲＩＮＧＩＮＧ待ちに設定する。
【００５１】
次にＳＩＰサーバ２は、セッション接続中情報管理テーブル２５の発呼端末情報と着呼端末情報とＳＩＰメッセージの情報を図７（ａ）から図７（ｂ）に更新する（Ｆ１０５）。セッション接続中情報管理テーブル２５は状態問合せ時に問合せ元のＩＰアドレスを検索キー情報としてＵＲＩ７１０を検索するため、問合せ元のＩＰアドレスを端末情報として情報を格納する。
【００５２】
従って、１つセッション接続で、発呼端末の端末情報としたエントリ７８０‐３の情報と着呼端末の端末情報としたエントリ７８０‐４の情報の２つの情報を管理する。なお、問合せ元のＩＰアドレスを検索キー情報として検索する箇所を端末情報７２０と接続先情報７３０とすることで、エントリ数を１つに減らすことも可能である。
【００５３】
セッション接続中情報管理テーブル２５の具体的な更新方法は、ＩＮＶＩＴＥリクエスト（Ｍ１３１）のＦＲＯＭ情報の電話番号「０４５１１１１１１１」（Ｍ１３１−２）と、ＩＰアドレス「２０．０.０．１」（Ｍ１３１−３）と、ｔａｇ情報「ｔａｇ＝ｑｑｑｑｑｑ」（Ｍ１３１−４）をＳＩＰサーバ２のセッション接続中情報管理テーブル２５の端末情報７２０に格納すると共に、セッション接続の方向を示すＤＩＲ７７０に発呼を格納する。
【００５４】
また、ＩＮＶＩＴＥリクエスト（Ｍ１３１）のＴＯ情報の電話番号「０３５０００２２２２」（Ｍ１３１−１）と、加入者管理テーブル２６から抽出した着信先のＩＰアドレス「１１．０.０．２」（Ｆ１０３）をＳＩＰサーバ２のセッション接続中情報管理テーブル２５の接続先情報７３０に格納する。ＩＮＶＩＴＥリクエスト（Ｍ１３１）のＣａｌｌ‐ＩＤ情報「１１１１１１＠Ａ」（Ｍ１３１‐５）とＣＳｅｑ情報「１０１１  ＩＮＶＩＴＥ」（Ｍ１３１‐６）をそれぞれセッション接続中情報管理テーブル２５のＣａｌｌ‐ＩＤ７５０とＣＳｅｑ情報７６０に登録する。受信ステータス７４０にＩＮＶＩＴＥ受信  １８０ＲＩＮＧＩＮＧ待ちとして、エントリ７８０‐３に登録する。
【００５５】
更に、端末情報７２０と接続先情報７３０の登録内容を入れ替えと、セッション接続の方向を示すＤＩＲ７７０を発呼から着呼に変更した内容をエントリ７８０‐４を追加登録する。なお、ＵＲＩ７１０には、端末情報７２０の電話番号を検索キー情報として加入者管理テーブル２６に格納されているＩＰアドレス「１１．０.０．２」が格納される。上記の処理により、セッション接続中情報管理テーブル２５のエントリ７８０‐３とエントリ７８０‐４の情報を図７（ａ）の状態から図７（ｂ）の状態に内容を更新する。
【００５６】
次にＳＩＰサーバ２は、着信先のＩＰアドレスを使用してＩＮＶＩＴＥリクエストを着呼端末１‐２Ｂへ送信する（Ｆ１０６，ＳＱ１０２）。着呼端末１‐２Ｂは、ＩＮＶＩＴＥリクエスト（ＳＱ１０２）を受信すると、１８０ ＲＩＮＧＩＮＧをＳＩＰサーバ２に返信する（ＳＱ１０３）。ＳＩＰサーバ２では、受信したＳＩＰメッセージより、ＩＮＶＩＴＥリクエスト（ＳＱ１０１）を受信したときと同様の処理を行う。
【００５７】
このとき、ＳＩＰサーバ２では、受信したセッション処理関係のＳＩＰメッセージがＩＮＶＩＴＥではないため、Ｆ１０３の処理は行わない。また、１８０ ＲＩＮＧＩＮＧのＳＩＰメッセージには、着信側の端末からＳＩＰメッセージのＴＯ情報にｔａｇ情報「ｔａｇ＝４５６ａｂｃ」（Ｍ１３２−１）を追記してくるので、ＳＩＰサーバ２ではセッション接続中情報管理テーブル２５のエントリ７８０‐３の接続先情報７３０のｔａｇ情報とエントリ７８０‐４の端末情報７２０のｔａｇ情報の更新とＳＩＰステータスの更新を行うことで、セッション接続中情報管理テーブル２５を図７（ｂ）から図７（ｃ）に変更する。
【００５８】
また、接続管理テーブル２４のステータスも同様に更新し、接続管理テーブル２４を図８（ｂ）から図８（ｃ）に変更する。
【００５９】
次に故障等によるＧＷの系切替えについて説明する。まず、系切替え前のＧＷ５の現用系接続管理テーブル３５Ａについて説明する。ＧＷ５の現用系接続管理テーブル３５Ａは、ＳＩＰサーバ２とのＳＩＰメッセージとＧＷ５で予め持っている加入者の情報からテーブルを生成している。本実施例では、エントリ４８０‐１とエントリ４８０‐２が登録されている。
【００６０】
一方、ＧＷ５の待機系接続管理テーブル３５Ｓは、エントリ５８０‐１のみが登録されている。ＧＷ５の待機系３０Ｓは通常は動作しないため、待機系３０ＳでＳＩＰメッセージを処理することはないが、エントリ５８０−１は発呼端末と着呼端末の間で通話中の状態に遷移したものであり、状態が確立したため現用系３０Ａの接続管理テーブル３５Ａからセッション情報をコピーして情報を一致させている。エントリ５８０−２は、現用系３０Ａでセッションの状態が確立していないため、現用系３０Ａからコピーしても状態が短期間で変化するため現用系３０Ａから状態のコピーをしていないため、エントリ５８０−２は空きエントリとなっている。
【００６１】
待機系３０Ｓの接続管理テーブル３５Ｓが図５（ａ）の状態でＧＷ５の現用系と待機系が切り替わったとき、現用系の接続管理テーブル３５Ａと待機系の接続管理テーブル３５Ｓの状態が一致しておらず、セッションを救済するために待機系の接続管理テーブル３５Ｓの状態を現用系の接続管理テーブル３５Ａと同じ内容（図５（ｂ））にする必要がある。以下にＳＩＰサーバ２から１８０ ＲＩＮＧＩＮＧのＳＩＰメッセージを受信したときに故障が発生したケースを一例としてＧＷ５の系切替え動作について説明する。
【００６２】
まず、ＧＷ５の現用系３０Ａで障害が発生したとき、ＧＷ５の現用系３０Ａから待機系３０Ｓに対して故障の通知と運用系の切替え指示を行う（ＳＱ１０５）。ＧＷ５の待機系３０Ｓでは、運用系の切替え指示が現用系からあった場合（Ｆ１２１）、ＧＷ５の現用系３０Ａを待機系に変更し、待機系３０Ｓを現用系に装置状態を変更することで系の切り替えを行う。なお、以下の説明では、新しく現用系となった切替え前の待機系を新現用系３０Ｓと記載し、新しく待機系となった切替え前の現用系を旧現用系３０Ａと記載する。
【００６３】
系を切り替えたとき、現用系３０ＡでＳＩＰサーバ２と通信していたときのＩＰアドレスを新現用系３０Ｓに引き継ぎ、旧現用系３０Ａは、ＳＩＰサーバ２と通信していたＩＰアドレス以外のＩＰアドレスに変更する（Ｆ１２２）。
ＧＷ５の新現用系３０Ｓは、ＳＩＰサーバ２に対して旧現用系３０ＡでＳＩＰサーバ２と通信していたときの状態の問合せを行う（Ｆ１２３）。状態の問合せは、ＧＷ５の状態問合せ部３６Ｓで行い、例えば、ＳＩＰのＳＵＢＳＣＲＩＢＥメッセージのフォーマットでＥｖｅｎｔ情報に状態の問合せを示す「ｓｔａｔｕｓ  ｒｅｑｕｅｓｔ」情報（Ｍ１３３‐１）を入れて状態問合せメッセージを生成して（Ｍ１３３）、ＳＵＢＳＣＲＩＢＥ送信処理Ｆ３３ＳがＳＩＰサーバ２へ状態問合せメッセージを送信する（Ｆ１２３,ＳＱ１０６）。ＳＩＰサーバ２ではＳＵＢＳＣＲＩＢＥ受信後、２００ ＯＫを返信する（ＳＱ１０７）。
【００６４】
ＳＩＰサーバ２では、ＳＵＢＳＣＲＩＢＥ受信処理Ｆ２３が状態問合せメッセージが他の装置から受信しないかを監視しており（Ｆ１１１）、状態問合せメッセージを受信した場合、状態問合せ処理部２３に状態問合せメッセージの内容を通知する。状態問合せ処理部２３では、問合せ元のＩＰアドレスを検索キー情報として、セッション接続中情報管理テーブル２５のＵＲＩ７１０を検索する（Ｆ１１２）。検索した結果、セッション接続中の端末情報がなかった場合（Ｆ１１３）、セッション接続中の端末情報がないことを問合せ元の装置に通知する（Ｆ１１５）。セッション接続中の端末情報がある場合（Ｆ１１３）、セッション接続状態の状態通知を行う。
【００６５】
状態通知処理は、状態問合せ処理部２３で行い、例えば、ＮＯＴＩＦＹメッセージのフォーマットでＥｖｅｎｔ情報に状態問合せに対する状態通知であることを示す「ｓｔａｔｕｓ  ｒｅｑｕｅｓｔ」情報（Ｍ１３５‐１）を入れてＳＩＰヘッダ（Ｍ１３５‐２）を生成する。セッション接続中の情報は、ＳＩＰのボディ（Ｍ１３５‐３）に格納する。状態問合せ処理部２３では、セッション接続中の情報は、セッション接続中情報管理テーブル２５に登録されている情報から生成する。
【００６６】
例えば、セッション接続中情報管理テーブル２５の図７（ｃ）のエントリ７８０‐３の場合、Ｄｉｒ７７０からセッション接続の方向を確認し、端末情報７２０が発呼端末であり、接続先情報７３０が着呼端末であることを確認する。状態通知の内容は、ＳＩＰのステータス７４０と、発信者情報、着信者情報、ＳＩＰ情報であるＣａｌｌ‐ＩＤ７５０とＣＳｅｑ７６０情報から構成する。まず、ＳＩＰステータス７４０に格納されている「１８０ ＲＩＮＧＩＮＧ ２００ ＯＫ待ち」の情報とＣａｌｌ-ＩＤ７５０に格納されている「１１１１１１＠Ａ」の情報とＣＳｅｑ６６０に格納されている「１０１１ ＩＮＶＩＴＥ」の情報から、ｓｉｐ_ｓｔａｔｕｓ情報を生成する（Ｍ１３５‐４）。
【００６７】
発信者情報であるＦｒｏｍ情報には、Ｄｉｒ７７０より発呼端末と判断した端末情報７２０に格納されている電話番号とＩＰアドレスと、Ｔａｇの情報から、Ｆｒｏｍ情報を生成する（Ｍ１３５‐５）。着信者情報であるＴｏ情報には、Ｄｉｒ７７０より着呼端末と判断した接続先情報７３０に格納されている電話番号とＩＰアドレスと、Ｔａｇの情報から、Ｔｏ情報を生成する（Ｍ１３５‐６）。
【００６８】
生成したｓｉｐ_ｓｔａｔｕｓ情報（Ｍ１３５−４）とＦｒｏｍ情報（Ｍ１３５‐５）とＴｏ情報（Ｍ１３５‐６）をＳＩＰのボディ（Ｍ１３５‐３）情報として、ＳＩＰサーバ２では状態通知用に生成したＳＩＰヘッダ（Ｍ１３５‐２）とＳＩＰボディ（Ｍ１３５‐３）を１つのＮＯＴＩＦＹメッセージとしてＮＯＴＩＦＹ送信処理Ｆ２４から問合せ元であるＧＷ５へ状態通知メッセージを送信する（Ｆ１１４，ＳＱ１０８）。例えば、セッション接続中の端末が複数あった場合は、ＮＯＴＩＦＹメッセージを端末の台数分のメッセージ送信や、１つのＮＯＴＩＦＹメッセージに複数の端末の情報を入れることもできる。
【００６９】
ＧＷ５の新現用系３０Ｓでは、ＳＩＰサーバからの状態通知があるまで待機して（Ｆ１２４）、ＮＯＴＩＦＹ受信処理Ｆ３４Ｓが状態通知メッセージを受信すると、２００ ＯＫをＳＩＰサーバ２に返信する（ＳＱ１０９）。ＧＷ５の新現用系３０Ｓは、状態通知メッセージの内容（Ｍ１３５）を状態通知処理部３７Ｓへ引き渡し、状態通知処理部３７Ｓでは受信した状態通知内容（Ｍ１３５）の情報から接続管理テーブル３５Ｓの図５（ａ）の空きのエントリであるエントリ５８０‐２を図５（ｂ）に更新する。
【００７０】
具体的には、状態通知メッセージ（Ｍ１３５）のＦｒｏｍ情報（Ｍ１３５‐５）から発信者情報５１０に発信者の電話番号とＩＰアドレスと、Ｔａｇの情報を格納する。状態通知メッセージ（Ｍ１３５）のＴｏ情報（Ｍ１３５‐６）から着信者情報５２０に着信者の電話番号とＩＰアドレスと、Ｔａｇの情報を格納する。
【００７１】
更に、状態通知メッセージ（Ｍ１３５）のｓｉｐ＿ｓｔａｔｕｓ情報（Ｍ１３５‐４）からＳＩＰステータス５３０と、ＳＩＰ情報であるＣａｌｌ‐ＩＤ５４０とＣＳｅｑ５５０の情報を格納することで、空きエントリ５８０‐２にセッション情報を格納して接続管理テーブル３５Ｓの図５（ａ）の状態から接続管理テーブル３５Ｓの図５（ｂ）の状態とし、旧現用系３０Ａの接続管理テーブル３５Ａと状態を一致させる（Ｆ１２５）。
【００７２】
ＧＷ５は接続管理テーブル３５Ｓの図５（ｂ）の情報から装置内の動作状態を比較して、加入者に対して音源を正常に送出できているか等、系切替えをしなかった場合に本来動作すべき内容を実行できているかを確認する（Ｆ１２６）。動作状態に差分があった場合（Ｆ１２７）、装置内の状態を変更して系切替えを実行していなかった場合に本来動作すべき状態とする（Ｆ１２８）。
【００７３】
例えば、接続管理テーブル３５Ｓの図５（ｂ）のエントリ５８０‐２の場合、ＳＩＰのステータスが１８０  ＲＩＮＧＩＮＧであるため、１８０  ＲＩＮＧＩＮＧを受信するとＧＷ５は発呼端末１‐１ＡにＲＢＴ（呼び出し音）を送出する必要があるが、新現用系３０Ｓで発呼端末１‐１Ａに対してＲＢＴ（呼び出し音）を送出しているか状態の比較を行い、送出していない場合、ＲＢＴ（呼び出し音）の送出を行う。
【００７４】
以上の動作を行うことで、ＧＷ５は接続管理テーブル３５Ａと接続管理テーブル３５Ｓの状態を合わせて、系切替え後のセッション接続中のセッションを救済する。状態を一致させた後は、通常状態のときと同じ動作である動作シーケンスＳＱ１１１〜ＳＱ１２１の切断処理までを行う。
【実施例２】
【００７５】
実施例２では、実施例１とは異なり、現用系３０Ａと待機系３０Ｓのそれぞれで使用するＩＰアドレスが変わる場合において、待機系が現用系に変化したときの動作について説明する。
【００７６】
図１７は、ＧＷ５の待機系３０Ｓの接続管理テーブル３５Ｓのデータフォーマットの一例を示す図である。データフォーマットの内容は現用系３０Ａと同じである。エントリ１４８０−１は通話中の状態であり、状態が確立したため現用系の接続管理テーブル３５Ａから情報をコピーして情報を一致させている。
【００７７】
図１８は、ＳＩＰサーバ２のＳＩＰ処理部部２０のＲＥＧＩＳＴＥＲ処理（Ｆ２１）にてＳＩＰサーバ２に登録される各加入者情報を管理する加入者管理テーブル２６のテーブル構成を示す図である。加入者管理テーブル２６は、加入者の電話番号１５１０、加入者の電話番号１５１０を収容している装置のアドレス（ＩＰアドレスＡ１５２０、ＩＰアドレスＢ１５３０）、複数のアドレスが登録されている場合（ＩＰアドレスＡとＩＰアドレスＢ）に有効となっているアドレスを示す有効ＩＰアドレス１５４０から構成される。
【００７８】
ＩＰアドレスＡとＩＰアドレスＢの組み合わせは装置運用時に予め装置情報として装置に登録されており、ＲＥＧＩＳＴＥＲリクエストにより、有効ＩＰアドレスをＩＰアドレスＡ１５２０とＩＰアドレスＢ１５３０から選択して、選択した結果を有効ＩＰアドレス１５４０に登録する。ＩＮＶＩＴＥ受信時は、有効ＩＰアドレス１５４０を参照して、有効となっているＩＰアドレスを使用する。
【００７９】
図１９〜図２２は、ＳＩＰサーバ２のＳＩＰ処理部部２０の接続・切断登録処理（Ｆ２３）にてＧＷ５やＩＰ電話端末１-２Ａ、１‐２Ｂとの接続処理の状態を管理するセッション接続中情報管理テーブル２５のデータフォーマットの一例を示す図である。セッション接続中情報管理テーブル２５は、端末を収容している装置の場所を示すＵＲＩ１６１０の情報を保持する。
【００８０】
ＵＲＩは複数登録でき、例えば現用系３０ＡのＩＰアドレスと待機系３０ＳのＩＰアドレスの２つを登録する。本登録情報は、現用系３０ＡのＩＰアドレスと待機系３０ＳのＩＰアドレスの組み合わせは加入者管理テーブル２６に登録されているものとする。予めセッション接続中情報管理テーブル２５は、ＵＲＩ単位にセッション接続中の端末情報を保持し、端末の情報である電話番号と、該当電話番号を収容している装置のアドレス（ＩＰアドレス）、セッション処理中に該当電話番号の端末又はＧＷがセッションを識別するための情報（Ｔａｇ情報）を格納する発信者情報１６２０と、接続先の情報である電話番号と、該当電話番号を収容している装置のアドレス（ＩＰアドレス）、セッション処理中に該当電話番号の端末又はＧＷがセッションを識別するための情報（Ｔａｇ情報）を格納する着信者情報１６３０と、ＳＩＰの接続処理の状態を示すＳＩＰステータス１６４０と１つのセッションの一連の接続処理をグループ化して他の呼のセッションと区別するための識別情報（Ｃａｌｌ−ＩＤ１６５０）と新たなリクエストの発行毎に増加するシーケンス番号（ＣＳｅｑ１６６０）と保持している端末情報が発信者か着呼者かを示すＤＩＲ１６７０から構成される。本実施例では、ＩＰとＳＩＰを用いて説明する。
【００８１】
例えば、エントリ１６８０−１は、ＵＲＩ：２０．０．０．１と２０．０．０．１０に収容される電話番号０４５−１１１−２２２２の端末から電話番号０３−５０００−１１１１の端末に発呼して通話していることを示している。このときの発呼で使用するＳＩＰのＣａｌｌ−ＩＤとＣＳｅｑは、それぞれＣａｌｌ−ＩＤ：２２２２２２＠ＢとＣＳｅｑ：５５５５ ＡＣＫを使用していることを示す。
【００８２】
図２３は、ＳＩＰサーバ２のＳＩＰ処理部部２０の接続・切断登録処理（Ｆ２２）にてＧＷ５やＩＰ電話端末１-２Ａ、１‐２Ｂとのセッション制御におけるＩＮＶＩＴＥや、接続登録処理および切断登録処理の各処理によりＳＩＰサーバ２にて管理する接続管理テーブル２４のテーブル構成を示す図である。接続管理テーブル２４は、接続開始時間１７１０、切断時間１７２０、セッションの接続処理の状態を示すステータス１７３０、発信者の電話番号と該当電話番号を収容する装置のアドレス（ＩＰアドレス）を格納する発信者情報１７４０、着信者の電話番号と該当電話番号を収容する装置のアドレス（ＩＰアドレス）を格納する着信者情報１７５０から構成される。  次に、運用系が待機系に切り替わる際の動作を説明する。
【００８３】
具体的にはＧＷ５に接続される電話端末１‐１Ａと電話端末１‐１ＢのＩＰアドレスをＧＷ５の現用系３０ＡのＩＰアドレス  ２０．０．０．１と待機系３０ＳのＩＰアドレス  ２０．０．０．１０で運用系によって使用するＩＰアドレスが変わる場合において、待機系が現用系に変化したときの動作について説明する。
【００８４】
図２４は本実施例における本システムのセッション救済提供時の動作シーケンスの一例である。実施例１の図９から故障通知を示すＲＥＧＩＳＴＥＲ（ＳＱ２０６）と２００  ＯＫ（ＳＱ２０８）が追加される。故障時に新現用系３０Ｓから状態を問い合わせる状態問合せ信号は、ＳＩＰのＳＵＢＳＣＲＩＢＥを例として以下に説明する。また、ＳＩＰサーバからの状態通知信号は、ＳＩＰのＮＯＴＩＦＹを例として以下に説明する。ＳＵＢＳＣＲＩＢＥとＮＯＴＩＦＹは一例であり、その他のメッセージでも状態問合せと状態通知を行うことで実現可能である。
【００８５】
図２５は、本システムにおけるセッション救済提供時の状態問合せと状態通知処理の動作フローを示したフローチャートの一例である。図２６は、本システムにおけるセッション救済提供時のＧＷ５の待機系が現用系に系切替えしたときの新現用系３０Ｓの動作フローを示したフローチャートの一例である。図２７〜３１は、ＧＷ５とＳＩＰサーバ２の間で通信するＳＩＰ信号のメッセージ情報である。以下、図１〜図４と、図１０と、図１４〜図３２を用いてセッション救済方法の動作を説明する。
【００８６】
まず、ＧＷ５及びＩＰ電話端末１‐２Ａ、ＩＰ電話端末１‐２Ｂの電源を入れた場合等、通話を可能とするために予めＳＩＰサーバ２に対してＲＥＧＩＳＴＥＲリクエストを送出して加入者管理テーブル２６に電話番号１５１０と現用系３０Ａと待機系３０ＳのＩＰアドレスのうち有効なＩＰアドレスを有効ＩＰアドレス１５４０に登録する。
（ＳＩＰ処理部）
発呼端末１‐１Ａから着呼端末１‐２Ｂの電話番号をダイヤルする（ＳＱ２００）。ＧＷ５ではダイヤルされた電話番号（Ｍ２３１‐１）と、発呼端末の情報（Ｍ２３１‐２）と、ＧＷ５のＩＰアドレス（Ｍ２３１‐３）から、ＳＩＰのＩＮＶＩＴＥリクエスト（Ｍ２３１）を生成してＳＩＰサーバ２に送出する（ＳＱ２０１）。
【００８７】
ＳＩＰサーバ２では、ＳＩＰメッセージを受信するまで待機して、セッション処理関係のＳＩＰメッセージを受信した場合（Ｆ１０１）、受信したＳＩＰメッセージがＩＮＶＩＴＥリクエストかを判断して、ＩＮＶＩＴＥリクエストの場合（Ｆ１０２）、ＩＮＶＩＴＥリクエスト（Ｍ２３１）の着信者情報（Ｍ２３１‐１）の値である「０３５０００２２２２」を検索キー情報として加入者管理テーブル２６を検索し、「０３５０００２２２２」が登録されているエントリ１５５０−ｎのテーブルの中から有効ＩＰアドレス１５４０を参照し、複数あるＩＰアドレスの中から有効なＩＰアドレスＡの「ＩＰ４＝１１．０.０．２」の着信者側のＩＰアドレス情報を抽出する（Ｆ１０３）。
【００８８】
更にＳＩＰサーバ２は、検索した着信者のＩＰアドレスとＩＮＶＥＴＥリクエスト（Ｍ２３１）に含まれる情報から接続管理テーブル２４の発呼端末と着呼端末の情報を図２３（ａ）から図２３（ｂ）に更新する（Ｆ１０４）。具体的にはＩＮＶＩＴＥリクエスト（Ｍ２３１）のＦＲＯＭ情報の電話番号「０４５１１１１１１１」（Ｍ２３１−２）と、ＩＰアドレス「２０．０.０．１」（Ｍ２３１−３）をＳＩＰサーバ２の接続管理テーブル２４の発信者情報１７４０に格納する。
【００８９】
また、ＩＮＶＩＴＥリクエスト（Ｍ１３１）のＴＯ情報の電話番号「０３５０００２２２２」（Ｍ２３１−１）と、加入者管理テーブル２６から抽出した着信先のＩＰアドレス「１１．０.０．２」（Ｆ１０３）をＳＩＰサーバ２の接続管理テーブル２４の着信者情報１７５０に格納する。更に、受信ステータス１７３０にＩＮＶＩＴＥ受信  １８０ＲＩＮＧＩＮＧ待ちに設定する。
【００９０】
次にＳＩＰサーバ２は、セッション接続中情報管理テーブル２５の発呼端末情報と着呼端末情報とＳＩＰメッセージの情報を図１９から図２０に更新する（Ｆ１０５）。セッション接続中情報管理テーブル２５は状態問合せ時に問合せ元のＩＰアドレスを検索キー情報としてＵＲＩ１６１０を検索するため、問合せ元のＩＰアドレスを端末情報として情報を格納する。
【００９１】
従って、１つセッション接続で、発呼端末の端末情報としたエントリ１６８０‐３の情報と着呼端末の端末情報としたエントリ１６８０‐４の情報の２つの情報を管理する。問合せ元のＩＰアドレスを検索キー情報として検索する箇所を端末情報１６２０と接続先情報１６３０とすることで、エントリ数を１つに減らすことも可能である。
【００９２】
セッション接続中情報管理テーブル２５の具体的な更新方法は、ＩＮＶＩＴＥリクエスト（Ｍ２３１）のＦＲＯＭ情報の電話番号「０４５１１１１１１１」（Ｍ２３１−２）と、ＩＰアドレス「２０．０.０．１」（Ｍ２３１−３）と、ｔａｇ情報「ｔａｇ＝ｑｑｑｑｑｑ」（Ｍ２３１−４）をＳＩＰサーバ２のセッション接続中情報管理テーブル２５の端末情報１６２０に格納すると共に、セッション接続の方向を示すＤＩＲ１６７０に発呼を格納する。
【００９３】
また、ＩＮＶＩＴＥリクエスト（Ｍ２３１）のＴＯ情報の電話番号「０３５０００２２２２」（Ｍ２３１−１）と、加入者管理テーブル２６から抽出した着信先のＩＰアドレス「１１．０.０．２」（Ｆ１０３）をＳＩＰサーバ２のセッション接続中情報管理テーブル２５の接続先情報１６３０に格納する。ＩＮＶＩＴＥリクエスト（Ｍ２３１）のＣａｌｌ‐ＩＤ情報「１１１１１１＠Ａ」（Ｍ２３１‐５）とＣＳｅｑ情報「１０１１  ＩＮＶＩＴＥ」（Ｍ２３１‐６）をそれぞれセッション接続中情報管理テーブル２５のＣａｌｌ‐ＩＤ１６５０とＣＳｅｑ情報１６６０に登録する。
【００９４】
受信ステータス１６４０にＩＮＶＩＴＥ受信  １８０ＲＩＮＧＩＮＧ待ちとして、エントリ１６８０‐３に登録する。更に、端末情報１６２０と接続先情報１６３０の登録内容を入れ替えと、セッション接続の方向を示すＤＩＲ１６７０を発呼から着呼に変更した内容をエントリ１６８０‐４を追加登録する。なお、ＵＲＩ１６１０には、端末情報１６２０の電話番号を検索キー情報として加入者管理テーブル２６に格納されているＩＰアドレスＡ１５２０とＩＰアドレスＢ１５３０が格納される。
【００９５】
上記の処理により、セッション接続中情報管理テーブル２５のエントリ１６８０‐３とエントリ１６８０‐４の情報を図１９の状態から図２０の状態に内容を更新する。次にＳＩＰサーバ２は、着信先のＩＰアドレスを使用してＩＮＶＩＴＥリクエストを着呼端末１‐２Ｂへ送信する（Ｆ１０６，ＳＱ２０２）。
【００９６】
着呼端末１‐２Ｂは、ＩＮＶＩＴＥリクエスト（ＳＱ２０２）を受信すると、１８０ ＲＩＮＧＩＮＧをＳＩＰサーバ２に返信する（ＳＱ２０３）。ＳＩＰサーバ２では、受信したＳＩＰメッセージより、ＩＮＶＩＴＥリクエスト（ＳＱ２０１）を受信したときと同様の処理を行う。このとき、ＳＩＰサーバ２では、受信したセッション処理関係のＳＩＰメッセージがＩＮＶＩＴＥではないため、Ｆ１０３の処理は行わない。
【００９７】
また、１８０ ＲＩＮＧＩＮＧのＳＩＰメッセージには、着信側の端末からＳＩＰメッセージのＴＯ情報にｔａｇ情報「ｔａｇ＝４５６ａｂｃ」（Ｍ２３２−１）を追記してくるので、ＳＩＰサーバ２ではセッション接続中情報管理テーブル２５のエントリ１６８０‐３の接続先情報１６３０のｔａｇ情報とエントリ１６８０‐４の端末情報１６２０のｔａｇ情報の更新とＳＩＰステータスの更新を行うことで、セッション接続中情報管理テーブル２５を図２０から図２１に変更する。また、接続管理テーブル２４のステータスも同様に更新し、接続管理テーブル２４を図２３（ｂ）から図２３（ｃ）に変更する。
【００９８】
次に故障等によるＧＷの現用系と待機系の切換えについて説明する。まず、系切替え前のＧＷ５の現用系接続管理テーブル３５Ａについて説明する。ＧＷ５の現用系接続管理テーブル３５Ａは、ＳＩＰサーバ２とのＳＩＰメッセージとＧＷ５で予め持っている加入者の情報からテーブルを生成している。本実施例では、エントリ４８０‐１とエントリ４８０‐２が登録されている。
【００９９】
一方、ＧＷ５の待機系接続管理テーブル３５Ｓは、エントリ１４８０‐１のみが登録されている。ＧＷ５の待機系３０Ｓは通常は動作しないため、待機系３０ＳでＳＩＰメッセージを処理することはないが、エントリ１４８０−１は発呼端末と着呼端末の間で通話中の状態に遷移したものであり、状態が確立したため現用系３０Ａの接続管理テーブル３５Ａからセッション情報をコピーして情報を一致させている。このとき、ＧＷ５に収容している電話端末１‐１Ａは現用系のＩＰアドレス２０．０．０．１と待機系のＩＰアドレス２０．０．０．１０でＩＰアドレスが異なるため、待機系３０Ｓでは待機系で使用するＩＰアドレス  ２０．０．０．１０にＩＰアドレスを書き換えて、エントリ１４８０−１の発信者情報１４１０のＩＰアドレスを登録する。
【０１００】
エントリ１４８０−２は、現用系３０Ａでセッションの状態が確立していないため、現用系３０Ａからコピーしても状態が短期間で変化するため現用系から状態のコピーをしていないため、エントリ１４８０−２は空きエントリとなっている。待機系３０Ｓの接続管理テーブル３５Ｓが図１７（ａ）の状態でＧＷ５の現用系と待機系が切り替わったとき、現用系の接続管理テーブル３５Ａと待機系の接続管理テーブル３５Ｓの状態が一致しておらず、セッションを救済するために待機系の接続管理テーブル３５Ｓの状態を現用系の接続管理テーブル３５Ａと同じ内容（図１７（ｂ））にする必要がある。
【０１０１】
以下にＳＩＰサーバ２から１８０ ＲＩＮＧＩＮＧのＳＩＰメッセージを受信したときに故障が発生したケースを一例としてＧＷ５の系切替え動作について説明する。
【０１０２】
まず、ＧＷ５の現用系３０Ａで障害が発生したとき、ＧＷ５の現用系３０Ａから待機系３０Ｓに対して故障の通知と系の切替え指示を行う（ＳＱ２０５）。ＧＷ５の待機系３０Ｓでは、運用系の切替え指示が現用系からあった場合（Ｆ２２０）、ＧＷ５の現用系３０Ａを待機系に変更し、待機系３０Ｓを現用系に装置状態を変更することで系の切り替えを行う（Ｆ２２１）。
【０１０３】
なお、以下の説明では、新しく現用系となった切替え前の待機系を新現用系３０Ｓと記載し、新しく待機系となった切替え前の現用系を旧現用系３０Ａと記載する。ＧＷ５の新現用系３０Ｓは、系が切り替わったことでＧＷ５のＩＰアドレスが２０．０．０．１から２０．０．０．１０に変更となったことをＳＩＰサーバ２に通知するために、ＲＥＧＩＳＴＥＲメッセージを生成してＳＩＰサーバ２へ送信する（ＳＱ２０６，Ｆ２２２）。
【０１０４】
ＳＩＰサーバ２ではＲＥＧＩＳＴＥＲリクエストを受信した場合（Ｆ２００）、２００ ＯＫを返信すると共に（ＳＱ２０７）、ＲＥＧＩＳＴＥＲリクエスト内に記載されているＴｏ情報の電話番号「０４５１１１１１１１」（Ｍ２３６‐１）を検索キー情報として加入者管理テーブル２６の電話番号１５１０を検索して、該当の電話番号のエントリ情報を図１８（ａ）から図１８（ｂ）に更新する。
【０１０５】
例えば、発呼端末１−１Ａの場合、エントリ１５５０−１が該当するので、ＲＥＧＩＳＴＥＲリクエスト内に記載されているＴｏ情報のＩＰアドレス「２０．０.０．１０」（Ｍ２３６‐２）と予め登録されているＩＰアドレスＡ１５２０とＩＰアドレスＢ１５３０と比較して、一致したＩＰアドレス「２０．０．０．１０」のＩＰアドレスＢを有効ＩＰアドレスとしてＩＰアドレス１５４０に内容を更新する（Ｆ２０５）。
【０１０６】
ＲＥＧＩＳＴＥＲリクエストの処理は、ＧＷ５に収容している全加入者について実行し、加入者管理テーブル２６のテーブルの状態を図１８（ａ）から図１８（ｂ）の状態に変更する。
【０１０７】
更にＳＩＰサーバ２では、ＧＷ５のＩＰアドレスが２０．０．０．１から２０．０．０．１０に変更となるので、接続管理テーブル２４の発信者情報１７４０と着信者情報１７５０と、セッション接続中情報管理テーブル２５の端末情報１６２０と接続先情報１６３０に既に登録されているＩＰアドレス２０．０．０．１のエントリ情報をＩＰアドレス２０．０．０．１０に情報を更新するため、接続管理テーブル２４を図２３（ｃ）から図２３（ｄ）と変更し、更にセッション接続中情報管理テーブル２５を図２１から図２２に変更する（Ｆ２１０）。
【０１０８】
ＧＷ５の新現用系３０Ｓは、ＳＩＰサーバ２に対して旧現用系３０ＡでＳＩＰサーバ２と通信していたときの状態の問合せを行う（Ｆ２２３）。状態の問合せは、ＧＷ５の状態問合せ部３６Ｓで行い、例えば、ＳＵＢＳＣＲＩＢＥメッセージのフォーマットでＥｖｅｎｔ情報に状態の問合せを示す「ｓｔａｔｕｓ  ｒｅｑｕｅｓｔ」情報（Ｍ２３３‐１）を入れて状態問合せメッセージを生成して（Ｍ２３３）、ＳＵＢＳＣＲＩＢＥ送信処理Ｆ３３ＳがＳＩＰサーバ２へ状態問合せメッセージを送信する（Ｆ２２３,ＳＱ２０８）。ＳＩＰサーバ２ではＳＵＢＳＣＲＩＢＥ受信後、２００ ＯＫを返信する（ＳＱ２０９）。
【０１０９】
ＳＩＰサーバ２では、ＳＵＢＳＣＲＩＢＥ受信処理Ｆ２３が状態問合せメッセージが他の装置から受信しないかを監視しており（Ｆ２１１）、状態問合せメッセージを受信した場合、状態問合せ処理部２３に状態問合せメッセージの内容を通知する。
【０１１０】
状態問合せ処理部２３では、問合せ元のＩＰアドレスを検索キー情報として、セッション接続中情報管理テーブル２５のＵＲＩ１６１０を検索する（Ｆ２１２）。検索した結果、セッション接続中の端末情報がなかった場合（Ｆ２１３）、セッション接続中の端末情報がないことを問合せ元の装置に通知する（Ｆ２１５）。セッション接続中の端末情報がある場合（Ｆ２１３）、セッション接続状態の状態通知を行う。
【０１１１】
状態通知処理は、状態問合せ処理部２３で行い、例えば、ＮＯＴＩＦＹメッセージのフォーマットでＥｖｅｎｔ情報に状態問合せに対する状態通知であることを示す「ｓｔａｔｕｓ  ｒｅｑｕｅｓｔ」情報（２３５‐１）を入れてＳＩＰヘッダ（Ｍ２３５‐２）を生成する。セッション接続中の情報は、ＳＩＰのボディ（Ｍ２３５‐３）に格納する。状態問合せ処理部２３では、セッション接続中の情報は、セッション接続中情報管理テーブル２５に登録されている情報から生成する。
【０１１２】
例えば、セッション接続中情報管理テーブル２５の図２２のエントリ１６８０‐３の場合、Ｄｉｒ１６７０からセッション接続の方向を確認し、端末情報１６２０が発呼端末であり、接続先情報１６３０が着呼端末であることを確認する。状態通知の内容は、ＳＩＰのステータス１６４０と、発信者情報、着信者情報、ＳＩＰ情報であるＣａｌｌ‐ＩＤ１６５０とＣＳｅｑ１６６０情報から構成する。まず、ＳＩＰステータス１６４０に格納されている「１８０ ＲＩＮＧＩＮＧ ２００ ＯＫ待ち」の情報とＣａｌｌ-ＩＤ１６５０に格納されている「１１１１１１＠Ａ」の情報とＣＳｅｑ１６６０に格納されている「１０１１ ＩＮＶＩＴＥ」の情報から、ｓｉｐ_ｓｔａｔｕｓ情報を生成する（Ｍ２３５‐４）。
【０１１３】
発信者情報であるＦｒｏｍ情報には、Ｄｉｒ１６７０より発呼端末と判断した端末情報１６２０に格納されている電話番号とＩＰアドレスと、Ｔａｇの情報から、Ｆｒｏｍ情報を生成する（Ｍ２３５‐５）。着信者情報であるＴｏ情報には、Ｄｉｒ１６７０より着呼端末と判断した接続先情報１６３０に格納されている電話番号とＩＰアドレスと、Ｔａｇの情報から、Ｔｏ情報を生成する（Ｍ２３５‐６）。生成したｓｉｐ_ｓｔａｔｕｓ情報（Ｍ２３５−４）とＦｒｏｍ情報（Ｍ２３５‐５）とＴｏ情報（Ｍ２３５‐６）をＳＩＰのボディ（Ｍ２３５‐３）情報として、ＳＩＰサーバ２では状態通知用に生成したＳＩＰヘッダ（Ｍ２３５‐２）とＳＩＰボディ（Ｍ２３５‐３）を１つのＮＯＴＩＦＹメッセージとして、ＮＯＴＩＦＹ送信処理Ｆ２４から問合せ元であるＧＷ５へ状態通知メッセージを送信する（Ｆ２１４，ＳＱ２１０）。
【０１１４】
例えば、セッション接続中の端末が複数あった場合は、ＮＯＴＩＦＹメッセージを端末の台数分のメッセージ送信や、１つのＮＯＴＩＦＹメッセージに複数の端末の情報を入れることもできる。
【０１１５】
ＧＷ５の新現用系３０Ｓでは、ＳＩＰサーバからの状態通知があるまで待機して（Ｆ２２４）、ＮＯＴＩＦＹ受信処理Ｆ３４Ｓが状態通知メッセージを受信すると、２００ ＯＫをＳＩＰサーバ２に返信する（ＳＱ２１１）。ＧＷ５の新現用系３０Ｓは、状態通知メッセージの内容（Ｍ２３５）を状態通知処理部３７Ｓへ引き渡し、状態通知処理部３７Ｓでは受信した状態通知内容（Ｍ２３５）の情報から接続管理テーブル３５Ｓの図１７（ａ）の空きのエントリであるエントリ１４８０‐２を図１７（ｂ）に更新する。
【０１１６】
具体的には、状態通知メッセージ（Ｍ２３５）のＦｒｏｍ情報（Ｍ２３５‐５）から発信者情報１４１０に発信者の電話番号とＩＰアドレスと、Ｔａｇの情報を格納する。状態通知メッセージ（Ｍ２３５）のＴｏ情報（Ｍ２３５‐６）から着信者情報１４２０に着信者の電話番号とＩＰアドレスと、Ｔａｇの情報を格納する。更に、状態通知メッセージ（Ｍ２３５）のｓｉｐ＿ｓｔａｔｕｓ情報（Ｍ２３５‐４）からＳＩＰステータス１４３０と、ＳＩＰ情報であるＣａｌｌ‐ＩＤ１４４０とＣＳｅｑ１４５０の情報を格納することで、空きエントリ１４８０‐２にセッション情報を格納して接続管理テーブル３５Ｓの図１７（ａ）の状態から接続管理テーブル３５Ｓの図１７（ｂ）の状態とし、旧現用系３０Ａの接続管理テーブル３５Ａと状態を一致させる（Ｆ２２５）。
【０１１７】
ＧＷ５は接続管理テーブル３５Ｓの図１７（ｂ）の情報から装置内の動作状態を比較して、加入者に対して音源を正常に送出できているか等、系切替えをしなかった場合に本来動作すべき内容を実行できているかを確認する（Ｆ２２６）。動作状態に差分があった場合（Ｆ２２７）、装置内の状態を変更して系切替えを実行していなかった場合に本来動作すべき状態とする（Ｆ２２８）。
【０１１８】
例えば、接続管理テーブル３５Ｓの図１７（ｂ）のエントリ１４８０‐２の場合、ＳＩＰのステータスが１８０  ＲＩＮＧＩＮＧであるため、１８０  ＲＩＮＧＩＮＧを受信するとＧＷ５は発呼端末１‐１ＡにＲＢＴ（呼び出し音）を送出する必要があるが、新現用系３０Ｓで発呼端末１‐１Ａに対してＲＢＴ（呼び出し音）を送出しているか状態の比較を行い、送出していない場合、ＲＢＴ（呼び出し音）の送出を行う。以上の動作を行うことで、ＧＷ５は接続管理テーブル３５Ａと接続管理テーブル３５Ｓの状態を合わせて、系切替え後のセッション接続中のセッションを救済する。状態を一致させた後は、通常状態のときと同じ動作である動作シーケンスＳＱ２１２〜ＳＱ２２３の切断処理までを行う。
【符号の説明】
【０１１９】
１：電話端末  ２：ＳＩＰサーバ  ３：Ｌ２ＳＷ  ４：ルータ  ５：ＧＷ
【図１】
2011091589.tif 000003
【図２】
2011091589.tif 000004
【図３】
2011091589.tif 000005
【図４】
2011091589.tif 000006
【図５】
2011091589.tif 000007
【図６】
2011091589.tif 000008
【図７】
2011091589.tif 000009
【図８】
2011091589.tif 000010
【図９】
2011091589.tif 000011
【図１０】
2011091589.tif 000012
【図１１】
2011091589.tif 000013
【図１２】
2011091589.tif 000014
【図１３】
2011091589.tif 000015
【図１４】
2011091589.tif 000016
【図１５】
2011091589.tif 000017
【図１６】
2011091589.tif 000018
【図１７】
2011091589.tif 000019
【図１８】
2011091589.tif 000020
【図１９】
2011091589.tif 000021
【図２０】
2011091589.tif 000022
【図２１】
2011091589.tif 000023
【図２２】
2011091589.tif 000024
【図２３】
2011091589.tif 000025
【図２４】
2011091589.tif 000026
【図２５】
2011091589.tif 000027
【図２６】
2011091589.tif 000028
【図２７】
2011091589.tif 000029
【図２８】
2011091589.tif 000030
【図２９】
2011091589.tif 000031
【図３０】
2011091589.tif 000032
【図３１】
2011091589.tif 000033
【図３２】
2011091589.tif 000034