JP5173607B2 - 通信システム - Google Patents

Description

本発明は、通信システムに関し、特に、ＳＩＰによるセッション制御が適用された通信システムに関する。

第３世代移動通信システムは、音声、データ、及び動画像など多様なマルチメディア・サービスの高速かつ高品質な提供を目指している。３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）は、パケット交換網上でＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）技術を活用したマルチメディア・サービスを提供するため「Ａｌｌ ＩＰベース移動通信網」の標準化を進めている。

Ａｌｌ ＩＰベース移動通信網におけるセッション制御システムは、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）と呼ばれる。ＩＭＳは、次世代ネットワーク（ＮＧＮ：Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）におけるセッション制御技術にも採用されている。

セッション制御プロトコルとしては、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が利用される（例えば、非特許文献２参照）。ＳＩＰは、ＩＥＴＦで仕様化されたＩＰマルチメディア通信のセッション制御を行うプロトコルである。

ＳＩＰを用いた代表サービスにＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）がある。ＶｏＩＰは、音声情報をＩＰネットワーク上で送受信する技術である。ＳＩＰによるＶｏＩＰ通信は、通信開始前に、音声情報を送受信する通信装置間に仮想的な通話路（セッション）が設定される。ＩＰパケット化された音声データは、設定された仮想的な通信路上に転送される。ＶｏＩＰ通信において、ＳＩＰは、通信装置間のセッション確立、維持、及び切断を制御する。

音声データの属性などのメディア情報は、セッション確立時に決定される。通信装置は、メディア情報を、ＳＩＰメッセージに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）によって通知する。ＳＤＰは、セッションに関する様々な情報（例えば、ＩＰアドレス、ポート番号、メディア種別など）を記述する。

さらに、第三者が提供するＷｅｂサービスから通信事業者が提供する通信サービスを利用可能にするため、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の検討が進んでいる。

ネットワーク及びベンダに依存しないオープンＡＰＩを規定する業界団体としてＰａｒｌａｙ Ｇｒｏｕｐがある。Ｐａｒｌａｙ Ｇｒｏｕｐは、オープンＡＰＩとして「Ｐａｒｌａｙ−Ｘ」を策定中である。「Ｐａｒｌａｙ−Ｘ」は、Ｗｅｂサービス環境での使用を目的として、実装言語に限定しないＷｅｂサービスのＡＰＩを規定している。「Ｐａｒｌａｙ−Ｘ」は、Ｗｅｂ開発者向けに抽象化された通信ＡＰＩを提供する。

「Ｐａｒｌａｙ−Ｘ」で規定されるＡＰＩとして、例えば、Ｗｅｂアプリケーション側からの起動によって、二者間の通話サービスを提供する３ＰＣＣ（３ｒｄ Ｐａｒｔｙ Ｃａｌｌ Ｃｏｎｔｒｏｌ）がある（例えば、非特許文献１参照）。

Ｐａｒｌａｙ Ｇｒｏｕｐは、欧州電気通信標準化ＥＴＳＩ及び第３世代移動通信標準化団体と連携している。「Ｐａｒｌａｙ−Ｘ」は、この３団体から共同で発行されている。「Ｐａｒｌａｙ−Ｘ」は、標準のオープンインタフェースを定義するが、その実装方法は規定されていない。
５ｔｈ Ｄｒａｆｔ ＥＳ ２０２ ５０４−２ Ｐａｒｌａｙ Ｘ ３．０、「Ｐａｒｔ ２：Ｔｈｉｒｄ Ｐａｒｔｙ Ｃａｌｌ」、［ｏｎｌｉｎｅ］、２００７年８月、［２００８年４月１７日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｐｏｒｔａｌ．ｅｔｓｉ．ｏｒｇ．／ｄｏｃｂｏｘ／ＴＩＳＰＡＮ／Ｏｐｅｎ／ＯＳＡ／ＰａｒｌａｙＸ／ＥＳ＿２０２＿５０４＿ＰａｒｌａｙＸ＿３．０／ｌａｔｅｓｔ／ｅｓ＿２０２５０４０２ｖ００５．ｚｉｐ＞ ＩＥＴＦ ＲＦＣ３２６１、「ＳＩＰ： Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ§４」、［ｏｎｌｉｎｅ］、２００２年６月、［２００８年４月１７日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ａｐｐｓ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｈｔｍｌ＞

「Ｐａｒｌａｙ−Ｘ」では、サービス毎にＡＰＩのセットが規定されている。３ＰＣＣ用のＡＰＩとして、Ｗｅｂアプリケーションサーバから通信システムへの要求メッセージ（セッションの開始、セッションの終了、呼情報問い合わせ）とその応答メッセージとが規定されている。

しかし、前記要求メッセージ及び前記応答メッセージの送信間隔など実装方法は規定されていない。このため、３ＰＣＣサービスの提供中に通信が切断した場合、通信システムからＷｅｂアプリケーションを実現するサーバに通信が切断したことを通知するメカニズムは提供されていない。例えば、通信が切断された時、通信システム側からＷｅｂサーバへの切断通知ができない。このため、通信が切断しているにも関わらず、Ｗｅｂサーバが通信の切断を検知できないことによって、通信ネットワークのリソースが無駄に消費されたり、また、３ＰＣＣサービスに伴う料金の誤課金が発生したりする。

本発明は、Ｗｅｂサーバが通信セッションの切断を検知する方法を提供することを目的とする。

本発明の代表的な一例を示せば以下の通りである。すなわち、複数の端末の通信セッションを制御するセッション制御サーバと、前記セッション制御サーバと通信するアプリケーションサーバと、前記アプリケーションサーバと通信するウェブサーバと、前記各サーバを接続するネットワークとを備えた通信システムであって、前記アプリケーションサーバは、前記複数の端末の各々の通信セッションの状態の情報を周期的に検出し、前記検出された複数の端末の各々の通信セッションの状態の情報に基づいて前記通信セッションの切断を検出し、前記通信セッションの切断されたことを示す情報、及び、前記複数の端末の各々の通信セッションの状態の情報を含む状態関連情報を前記ウェブサーバに送信し、前記ウェブサーバは、受信した前記状態関連情報に基づいて通信セッションの状態を検出し、前記アプリケーションサーバは、前記状態関連情報に基づいて、前記ウェブサーバから前記アプリケーションサーバへの前記状態関連情報の問い合わせである呼制御の時間周期を制御する場合に、前記複数の端末の各々の通信セッションの状態の情報を検出するための周期を参照し、前記参照された周期のうち、最小の周期以下の値に前記呼制御の時間周期を決定し、前記決定された呼制御の時間周期を含む前記状態関連情報を前記ウェブサーバに送信し、前記ウェブサーバは、受信した前記状態関連情報に含まれる前記決定された呼制御の時間周期に基づいて、前記呼制御の時間周期を制御することを特徴とする。

本発明の一実施の形態によれば、Ｗｅｂサーバが通信システム側の通信セッションの切断を検出することができる。

本発明の第１の実施の形態を、図面を用いて説明する。

代表例として、第三者呼制御（３ＰＣＣ）サービスを利用する場合の通信方法を詳細に説明する。

図１は、本発明の第１の実施の形態の通信網の構成図である。

本実施の形態における通信網は、ＩＰ網Ｎ１と、アクセス網Ｎ２Ａ、Ｎ２Ｂ、Ｎ２Ｃとによって構成される。

図１には、端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）７の例として固定端末７Ａ〜７Ｄを示す。以下、端末７を区別して記載する場合、符号に添字「Ａ」「Ｂ」「Ｃ」「Ｄ」を付して、例えば、端末７Ａ及び端末７Ｂのように記載する。その他の構成要素も、同様の規則に従って記載される。

ＩＰ網Ｎ１とアクセス網Ｎ２とは、アクセスゲートウェイ装置（ＡＧＷ）６（６Ａ、６Ｂ、６Ｃ）を介して接続される。アクセスゲートウェイ装置６の代わりに、ルータなど、他の通信装置を介して、ＩＰ網Ｎ１とアクセス網Ｎ２とが接続されてもよい。アクセスゲートウェイ装置６は、端末７とＩＰ網Ｎ１との間で送受信されるＩＰパケットを転送する。ＩＰ網Ｎ１は、少なくてもＳＩＰサーバ１を備える。

Ｗｅｂサーバ２は、３ＰＣＣサービスを起動するためのユーザインタフェース機能、３ＰＣＣサービスの起動に必要な機能、及びＷｅｂサーバ２とＳＩＰアプリケーションサーバ３との相互接続機能を備える。

ＳＩＰアプリケーションサーバ３は、ＩＭＳアプリケーション（ＳＩＰアプリケーション）の実行を制御する機能を備える。

なお、図１には、例として、ＳＩＰサーバ１、Ｗｅｂサーバ２、及びＳＩＰアプリケーションサーバ３を、それぞれ一つずつ示した。しかし、本発明を実施する場合、これらの構成要素の数は任意であってよい。

図２は、本発明の第１の実施の形態のＷｅｂサーバ２の構成例を示すブロック図である。

Ｗｅｂサーバ２は、回線２２（２２Ａ、２２Ｂ）を収容するインタフェース部（ＩＦ）２１（２１Ａ、２１Ｂ）と、ＣＰＵ２４と、メモリ２５と、データベース（ＤＢ）２６とによって構成される。各構成要素は、バス２３で接続される。

メモリ２５は、プロトコル処理を実行するプログラム２８、及びＷｅｂサーバ２とＳＩＰアプリケーションサーバ３との間の相互接続機能を実行するプログラム２９を記憶する。なお、メモリ２５は、さらに他のプログラムを記憶してもよい。

ＣＰＵ２４は、メモリ２５に記憶されたプログラムを実行するプロセッサである。以下の説明においてＷｅｂサーバ２が実行する処理は、実際には、ＣＰＵ２４がメモリ２５に記憶されているいずれかのプログラムを実行することによってなされる。

プロトコル処理を実行するプログラム２８は、Ｗｅｂサーバ２とＳＩＰアプリケーションサーバ３との間で信号を送受信するための機能を備えるプログラム（ＳＯＡＰ制御２８０１）、及び、Ｗｅｂサーバ２と端末７との間で信号を送受信するための機能を備えるプログラム（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ制御２８０２）を含む。

相互接続機能を実行するプログラム２９は、タイマ受信を行う処理プログラム２７、及び、セッション毎の情報が格納されるセッション情報テーブル２３０を含む。なお、データベース２６が、セッション情報テーブル２３０を含んでもよい。

Ｗｅｂサーバ２がタイマ受信処理プログラム２７とセッション情報テーブル２３０とを備えることによって、Ｗｅｂサーバ２は、ＳＩＰアプリケーションサーバ３から受信したタイマ値を用いて、呼情報問い合わせ要求を送信する周期を制御することができる。詳細については、図８〜図１１を用いて後述する。

図３は、本発明の第１の実施のＷｅｂサーバ２におけるセッション情報テーブル２３０の構成の一例を示す説明図である。

Ｗｅｂサーバ２は、ＳＩＰアプリケーションサーバ３から送信されたメッセージを受信すると、セッション情報テーブル２３０を参照し、前記要求に含まれる情報に基づいてセッション情報テーブル２３０を更新する。

セッション情報テーブル２３０は、少なくてもＰａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２３１、ＳＩＰ ＡＳ ＩＰ ａｄｄｒｅｓｓ２３４、３ＰＣＣ識別子２３５、及びタイマ２３７を含む。

Ｐａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２３１は、Ｗｅｂサーバ２とＳＩＰアプリケーションサーバ３との間の通信セッションを一意に識別するための識別子を格納する。これは、後述する図５のＰａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１と同一のものである。

ＳＩＰ ＡＳ ＩＰ ａｄｄｒｅｓｓ２３４は、Ｐａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１に対応するＳＩＰアプリケーションサーバを識別するための識別子を格納する。

３ＰＣＣ識別子２３５は、ＳＩＰアプリケーションサーバ３が提供する３ＰＣＣサービスによって接続された（ＳＩＰアプリケーションサーバ３と端末７との間の）通信セッションを識別するための識別子を格納する。これは、逗で後述する３ＰＣＣ識別子と同一のものである。

タイマ２３７は、Ｗｅｂサーバ２がＳＩＰアプリケーションサーバ３に呼情報問い合わせ要求を送信する周期（タイマ値）を格納する。

セッション情報テーブル２３０がタイマ値２３７を含むことによって、Ｗｅｂサーバ２は、端末間の通信の終了、または通信セッションの切断を迅速に検出することができる。

図４は、本発明の第１の実施の形態のＳＩＰアプリケーションサーバ３の構成例を示すブロック図である。

ＳＩＰアプリケーションサーバ３は、回線３２（３２Ａ、３２Ｂ）を収容するインタフェース部（ＩＦ）３１（３１Ａ、３１Ｂ）と、ＣＰＵ３４と、メモリ３５と、データベース（ＤＢ）３６とによって構成される。各構成要素は、バス３３で接続される。

メモリ３５は、プロトコル処理を実行するプログラム３８（ＳＩＰプロトコル制御３８０１、ＨＴＴＰプロトコル制御３８０２、ＳＯＡＰ制御３８０３）、３ＰＣＣサーバを実現するための処理を実行するプログラム３９（ＳＩＰ Ｕｓｅｒ Ａｇｅｎｔ処理を行うプログラム３９０１、３ＰＣＣ制御処理を行うプログラム３９０２）、タイマ通知処理を行うプログラム（セッションタイマ通知ルーチン３７０）、セッション毎の情報が格納されるセッション情報テーブル２１０、及びプロトコル変換（ＳＯＡＰ−ＳＩＰ）を行う処理プログラム４０を記憶する。なお、メモリ３５は、さらに他のプログラムを記憶してもよい。

ＣＰＵ３４は、メモリ３５に記憶されたプログラムを実行するプロセッサである。以下の説明においてＳＩＰアプリケーションサーバ３が実行する処理は、実際には、ＣＰＵ３４がメモリ３５に記憶されているいずれかのプログラムを実行することによってなされる。

プロトコル処理を実行するプログラム３８は、ＳＩＰアプリケーションサーバ３とＳＩＰサーバ１との間で信号を送受信するための機能を備えるプログラム（ＳＩＰプロトコル制御３８０１）、及び、ＳＩＰアプリケーションサーバ３とＷｅｂサーバ２との間で信号を送受信するための機能を備えるプログラム（ＨＴＴＰプロトコル制御３８０２、ＳＯＡＰ制御３８０３）を含む。

３ＰＣＣサーバを実現するための処理を実行するプログラム３９は、ＳＩＰ Ｕｓｅｒ Ａｇｅｎｔ処理を行うプログラム３９０１、及び３ＰＣＣ制御の処理を行うプログラム３９０２を含む。

前記３ＰＣＣ制御の処理を行うプログラム３９０２は、２つ以上の端末間の通信を制御するプログラムである。例えば、３ＰＣＣ制御の処理は、端末７Ａと端末７Ｂとの間の通信を可能にするため、端末７ＡとＳＩＰアプリケーションサーバ３との間の通信セッションと、端末７ＢとＳＩＰアプリケーションサーバ３との間の通信セッションとの対応情報を保持する。さらに、セッションタイマ通知ルーチン３７０、セッション毎の情報の格納に利用されるセッション情報テーブル２１０、プロトコル変換（ＳＯＡＰ−ＳＩＰ）を行う処理プログラムを含む。なお、データベース３６が、セッション情報テーブル２１０を含んでもよい。

ＳＩＰアプリケーションサーバ３がセッションタイマ通知ルーチン３７０とセッション情報テーブル２１０とを備えることによって、ＳＩＰアプリケーションサーバ３は、Ｗｅｂサーバ２に呼情報問い合わせ要求を送信する周期（タイマ値）を通知することができる。

図５は、本発明の第１の実施のＳＩＰアプリケーションサーバ３におけるセッション情報テーブル２１０の構成の一例を示す説明図である。

ＳＩＰアプリケーションサーバ３は、ＳＩＰサーバ１から送信されるメッセージを受信すると、セッション情報テーブル２１０を参照し、前記メッセージに含まれる情報に基づいてセッション情報テーブル２１０を更新する。

セッション情報テーブル２１０は、少なくてもＰａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１、Ｗｅｂサーバ ＩＰ ａｄｄｒｅｓｓ２１２、３ＰＣＣ識別子２１３、タイマＴ１（２１４）、タイマＴ２（２１５）、及びタイマＴ３（２１７）を含む。

Ｐａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１は、Ｗｅｂサーバ２とＳＩＰアプリケーションサーバ３との間の通信セッションを一意に識別するための識別子を格納する。前記識別子は、ＳＩＰアプリケーションサーバ３がＷｅｂサーバ２からＳＩＰセッション確立の要求を受信した時に生成され、Ｐａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１に格納される。詳細は、図８を用いて後述する。

Ｗｅｂサーバ ＩＰ ａｄｄｒｅｓｓ２１２は、Ｐａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１に対応するＷｅｂサーバ２を識別するための識別子を格納する。

３ＰＣＣ識別子２１３は、ＳＩＰアプリケーションサーバ３が提供する３ＰＣＣサービスによって接続された（ＳＩＰアプリケーションサーバ３と端末７との間の）通信セッションを識別するための識別子を格納する。前記識別子は、ＳＩＰアプリケーションサーバ３がＳＩＰセッションを確立する時に生成され、３ＰＣＣ識別子２１３に格納される。詳細は、図８を用いて後述する。

タイマＴ１（２１４）及びタイマＴ２（２１５）は、ＳＩＰアプリケーションサーバ３が各端末に通信セッションの状態を問い合わせるメッセージを送信する周期（タイマ値）を格納する。なお、本実施の形態では、二者の通信を想定しているが、二者以上の通信の場合、接続される通信端末の数に応じてタイマの数も増える。

状態２１６は、通信セッションの状態を格納する。なお、通信セッションの状態として、セッション確立中、通信中、切断中、及び三者以上の通話への参加中、または、退出中などがある。

タイマＴ３（２１７）は、Ｗｅｂサーバ２がＳＩＰアプリケーションサーバ３に呼情報問い合わせ要求を送信する周期（タイマ値）を格納する。タイマＴ３（２１７）は、後述する方法（図１０参照）によって算出され、セッション情報テーブル２１０に格納される。

セッション情報テーブル２１０がタイマＴ３（２１７）を含むことによって、ＳＩＰアプリケーションサーバ３は、呼情報問い合わせ要求を送信する周期をＷｅｂサーバ２に通知することができる。これによって、Ｗｅｂサーバ２が、通信セッションの切断を迅速に検出することができる。

図６は、本発明の第１の実施の形態のＳＩＰサーバ１の構成例を示すブロック図である。

ＳＩＰサーバ１は、回線１２（１２Ａ、１２Ｂ）を収容するインタフェース部（ＩＦ）１１（１１Ａ、１１Ｂ）と、ＣＰＵ１４と、メモリ１５と、データベース（ＤＢ）１６とによって構成される。各構成要素は、バス１３で接続される。

メモリ１５は、少なくてもＳＩＰサーバ機能１７、セッション状態管理テーブル２７０、及びプロトコル処理を実行するプログラム（ＳＩＰプロトコル制御）１９を記憶する。なお、メモリ１５は、さらに他のプログラムを記憶してもよい。

ＣＰＵ１４は、メモリ１５に記憶されたプログラムを実行するプロセッサである。以下の説明においてＳＩＰサーバ１が実行する処理は、実際には、ＣＰＵ１４がメモリ１５に記憶されているいずれかのプログラムを実行することによってなされる。

図７は、本発明の第１の実施の形態のＳＩＰサーバ１におけるセッション状態管理テーブル２７０の構成の一例を示す説明図である。

ＳＩＰサーバ１は、ＳＩＰアプリケーションサーバ３と端末７との間のセッションタイマを保持する。

セッション状態管理テーブル２７０は、少なくてもＳＩＰメッセージに含まれるＴｏヘッダ２７１、Ｆｒｏｍヘッダ、Ｃａｌｌ ｉｄ２７３、タイマＴ２７４、及び通信状態２７５の対応情報を記憶する。

ＳＩＰサーバ１がセッション状態管理テーブル２７０を保持することによって、ＳＩＰサーバは、ＳＩＰアプリケーションサーバ３と端末７との間で通信が正常に行われているか否かを確認するために送受信されるメッセージを送信する周期（タイマ値）を保持することが可能になる。これによって、例えば、端末７Ａから前記メッセージを受信することなくタイマＴ１の値が経過すると、通信セッションの切断を検出することができる。なお、第１の実施の形態では、ＳＩＰアプリケーションサーバ３が通信セッションの切断を検出する。ＳＩＰサーバ１が通信セッションの切断を検出する場合については、第３の実施の形態で説明する。

図８は、通常の３ＰＣＣサービスを起動させる手順を示すシーケンス図である。Ｗｅｂサーバ２とＳＩＰアプリケーションサーバ３の間で送受信するメッセージは、Ｐａｒｌａｙ−Ｘに規定されている。なお、図８において、ＳＩＰアプリケーションサーバ３が二手に分かれているのはＳＩＰアプリケーションサーバ３の内部の動作が分かりやすいようにするためのものである。以降のシーケンス図についても同様である。

端末７ＡとＷｅｂサーバ２との間でメッセージ（例えば、ＨＴＴＰメッセージ）が送受信されている。３ＰＣＣサービスの起動を要求するメッセージが、端末７ＡからＷｅｂサーバ２へ送信される（Ｓ１）。前記メッセージには、端末７Ａの識別子、及び接続先の端末（この場合は、端末７Ｂ）の識別子が含まれている。なお、３ＰＣＣサービスは、３ＰＣＣ制御３９０２、ＳＩＰ Ｕｓｅｒ Ａｇｅｎｔ制御３９０１、及びＳＩＰプロトコル制御３８０１によって提供される。

前記メッセージを受信したＷｅｂサーバ２は、端末７Ａの識別子、端末７Ｂの識別子、及びＷｅｂサーバ２の識別子を含むセッション確立を要求するメッセージ（ｍａｋｅ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ）をＳＩＰアプリケーションサーバ３に送信する（Ｓ２）。

前記セッション確立を要求するメッセージを受信したＳＩＰアプリケーションサーバ３は、３ＰＣＣサービスを起動する（Ｓ３）。

また、ＳＩＰアプリケーションサーバ３は、Ｗｅｂサーバ２とＳＩＰアプリケーションサーバ３との間の通信セッションを一意に識別するための識別子を生成し、生成された識別子を検索キーとして、セッション情報テーブル２１０のＰａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１を検索する。該当するエントリがなければ、ＳＩＰアプリケーションサーバ３は、新規エントリ２１０−１を生成し、生成されたエントリ２１０−１のＰａｒｌａｙ−Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１に生成された識別子を登録する。該当するエントリがあれば、ＳＩＰアプリケーションサーバ３は、Ｗｅｂサーバ２へエラーを通知する。

また、ＳＩＰアプリケーションサーバ３は、受信した前記セッション確立を要求するメッセージに含まれるＷｅｂサーバ２の識別子をエントリ２１０−１のＷｅｂサーバ ＩＰ ａｄｄｒｅｓｓ２１２に登録する。

また、ＳＩＰアプリケーションサーバ３は、３ＰＣＣサービスよって接続された通信セッションを識別するための識別子を生成し、エントリ２１０−１の３ＰＣＣ識別子２１３に登録する。

ＳＩＰアプリケーションサーバ３は、新規エントリを作成し、作成したエントリに各識別子を登録した後に、応答メッセージ（ｍａｋｅ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ）をＷｅｂサーバに送信する（Ｓ４）。

３ＰＣＣサービスを起動した後に、ＳＩＰアプリケーションサーバ３は、ＳＩＰサーバ１と端末７Ａとの間のセッションを確立するためのメッセージを送受信し（Ｓ５〜Ｓ１０）、端末７Ａが通信可能であるか否かを確認する。また、ＳＩＰアプリケーションサーバ３は、ＳＩＰサーバ１と端末７Ｂとセッションとの間のセッションを確立するためのメッセージを送受信し（Ｓ１１〜Ｓ１６）、端末７Ｂが通信可能であるか否かを確認する。

端末７Ａ及び端末７Ｂ共に通信可能であると確認された場合、ＳＩＰアプリケーションサーバ３は、端末７Ｂと通信を行うために必要なメディア情報を端末７Ａに送信する（Ｓ１７〜Ｓ２２）。以上の処理によって、端末７Ａと端末７Ｂとの間で通信が可能となる（Ｓ２３）。

通信が可能になった後、ＳＩＰアプリケーションサーバ３は、通信状セッションの状態を確認するためのメッセージ（ＩＮＶＩＴＥ）を、端末７に送信する周期（Ｔ１、Ｔ２）を決定する。通信セッションの状態を確認するためのメッセージは、３ＰＣＣサービスによって接続されている端末の通信セッションの状態が正常であるか否かを確認するためのメッセージである。また、Ｔ１は、ＳＩＰアプリケーションサーバ３と端末７Ａとの間の通信セッションの状態を確認するためのメッセージを送信する周期である（図９参照）。Ｔ２は、ＳＩＰアプリケーションサーバ３と端末７Ｂとの間の通信セッションの状態を確認するためのメッセージを送信する周期である（図９参照）。

前述した通信セッションの状態を確認するためのメッセージを送信する周期（Ｔ１、Ｔ２）は、ＩＥＴＦ ＲＦＣ４０２８に規定される手順を用いて決定される。ＩＥＴＦ ＲＦＣ４０２８に記載されている手順では、ＳＩＰ ＩＮＶＩＴＥまたはＳＩＰ ＵＰＤＡＴＥを用いて通信セッションの周期的な更新が可能になる。図９は、ＳＩＰ ＩＮＶＩＴＥを用いて通信セッションの周期的な更新を行う際のシーケンス例を示す。

具体的には、端末７とＳＩＰアプリケーションサーバ３との間でセッションを確立するとき（Ｓ５〜Ｓ２２）、セッションを更新する周期の最小値等を送受信されることによって、通信セッションの状態を確認するためのメッセージ（ＩＮＶＩＴＥ）を送信する周期（Ｔ１、Ｔ２）が決定される。なお、Ｔ１及びＴ２の値は、異なってもよい。

Ｔ１及びＴ２の周期で、ＳＩＰアプリケーションサーバ３と端末７がＳＩＰメッセージの送受信を行うことによって、通信セッションの状態が正常であるか否かを確認することができる。なお、ＳＩＰアプリケーションサーバ３と端末７との間で通信セッションの状態が正常であるか否かを周期的に確認するために送受信されるメッセージは、ｋｅｅｐ ａｌｉｖｅメッセージと呼ばれることもある。

Ｔ１及びＴ２が決まった後、ＳＩＰアプリケーションサーバ３は、３ＰＣＣ識別子２１３を検索キーとしてセッション情報テーブル２１０を検索し、該当するエントリ２１０-１にタイマ値Ｔ１（２１４）及びタイマ値Ｔ２（２１５）を各々設定する。さらに、ＳＩＰアプリケーションサーバ３は、該当するエントリ２１０−１の状態２１６に「通信中」を設定する。

Ｗｅｂサーバ２は、通信セッションの状態を確認するために、呼情報問い合わせ要求（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ）をＳＩＰアプリケーションサーバ３に送信する（Ｓ２４）。前記呼情報問い合わせ要求を受信したＳＩＰアプリケーションサーバ３は、通信セッションの状態を含む応答メッセージ（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）をＷｅｂサーバ２に送信する（Ｓ２５）。これによって、Ｗｅｂサーバ２は、通信セッションの状態を検出することができる。

Ｓ２４及びＳ２５で送信されるメッセージは、Ｐａｒｌａｙ Ｘで規定されている。本実施の形態例において、前記メッセージは、少なくとも、端末間のセッションが確立してから一回は必ず送信される。なお、端末間のセッションが確立する前に前記メッセージが送信されてもよい。

図９は、本発明の第１の実施の形態の３ＰＣＣサービスを起動させ、端末間の通信セッションが確立してから３ＰＣＣサービスが継続するときに行われる通信セッションの状態を確認する手順を示すシーケンス図である。

図９のＳ３１〜Ｓ３６、Ｓ５１〜Ｓ５６は、端末７Ａのセッションの状態を確認するためのメッセージ（ｋｅｅｐ ａｌｉｖｅメッセージ）の送受信を示している。Ｓ３７〜Ｓ４２、Ｓ５７〜Ｓ６２は、端末７Ｂのセッションの状態を確認するためのメッセージ（ｋｅｅｐ ａｌｉｖｅメッセージ）の送受信を示している。

また、ＳＩＰアプリケーションサーバ３と端末７Ａとの間のｋｅｅｐ ａｌｉｖｅメッセージの送信される周期（Ｓ３１とＳ５１との間隔）は、タイマＴ１（２１４）である。同様に、ＳＩＰアプリケーションサーバ３と端末７Ｂとの間のｋｅｅｐ ａｌｉｖｅメッセージの送信される周期（Ｓ３７とＳ５７との間隔）は、タイマＴ２（２１５）である。なお、前述したシーケンス（Ｓ３１〜Ｓ６２）は、３ＰＣＣサービスが通信セッション状態を監視する場合、通常なされる処理である。

Ｓ１〜Ｓ２３までのコールフローについては図８と同様であるが、セッション情報テーブル２１０のタイマＴ３（２１７）及びセッション情報テーブル２３０のタイマ２３７が追加されていることによって、Ｗｅｂサーバ２とＳＩＰアプリケーションサーバ３の間で送受信されるメッセージに含まれる情報が違う。この差異について説明する。

タイマＴ１（２１４）及びタイマＴ２（２１５）が決定された後にＳＩＰアプリケーションサーバ３は、セッション情報テーブル２１０のタイマＴ１（２１４）及びタイマＴ２（２１５）を用いてタイマＴ３（２１７）を算出するため、セッションタイマ通知ルーチン３７０を起動する（Ｓ２６）。以下、図１０を用いてセッションタイマ通知ルーチン３７０について説明する。

図１０は、本発明の第１の実施の形態のセッションタイマ通知ルーチン３７０のフローチャートである。

ＳＩＰアプリケーションサーバ３は、セッション情報テーブル２１０のタイマＴ１（２１４）及びタイマＴ２（２１５）を参照し（３７１）、セッションタイマを算出する（３７２）。具体的には、ＳＩＰアプリケーションサーバ３は、タイマＴ１（２１４）とタイマＴ２（２１５）とを比較し、小さい方のタイマ値以下の値をセッションタイマとして決定する。これによって、Ｗｅｂサーバ２は、算出されたセッションタイマに基づいてＳＩＰアプリケーションサーバ３に通信セッションの状態を問い合わせることができる。なお、算出されたセッションタイマは、Ｔ１及びＴ２と同程度の値が望ましい。これによって、Ｗｅｂサーバ２からＳＩＰアプリケーションサーバ３への問い合わせ要求による通信の負荷を抑制することができる。

前記セッションタイマが算出された後に、ＳＩＰアプリケーションサーバ３は、３ＰＣＣ識別子２１３を検索キーとして該当するエントリをセッション情報テーブル２１０から検索する（３７３）。該当するエントリがある場合、ＳＩＰアプリケーションサーバ３は、算出されたセッションタイマをエントリ２１０-１のタイマ値Ｔ３（２１７）に登録し（３７４、Ｓ２７）、ルーチンを終了する。該当するエントリがない場合、ＳＩＰアプリケーションサーバ３は、そのままルーチンを終了する。

図９に戻り、シーケンス図の説明を続ける。

Ｗｅｂサーバ２は、呼情報問い合わせ要求（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ）をＳＩＰアプリケーションサーバ３に送信する（Ｓ７１）。なお、Ｓ７１は、図８のＳ２４で送信されるメッセージと同一のものである。

前記呼情報問い合わせ要求を受信したＳＩＰアプリケーションサーバ３は、前記呼情報問い合わせ要求に含まれるＰａｒｌａｙ Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１を検索キーとして、セッション情報テーブル２１０を検索し、該当するエントリ２１０−１から、セッション状態２１６とタイマ値２１７とを読み出す。

該当するエントリにタイマ値２１７が設定されていない場合、ＳＩＰアプリケーションサーバ３は、通信セッションの状態を含む応答メッセージ（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）をＷｅｂサーバ２に送信する（Ｓ２５）。

該当するエントリにタイマ値２１７が設定されている場合、ＳＩＰアプリケーションサーバ３は、読み出したセッション状態とタイマ値２１７とを含む応答メッセージ（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）をＷｅｂサーバ２に送信する（Ｓ７２）。

Ｗｅｂサーバ２は、前記応答メッセージを受信すると、前記応答メッセージに含まれるＰａｒｌａｙ Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２３１を検索キーとして、セッション情報テーブル２３０を検索し、該当するエントリを読み出す。該当エントリが存在しない場合、Ｗｅｂサーバ２は、新規エントリを作成し、受信した前記応答メッセージに含まれる通信セッションの状態及びタイマ値２１７に基づいて、Ｐａｒｌａｙ Ｘ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２３１、ＳＩＰ ＡＳ ＩＰ ａｄｄｒｅｓｓ２３４、３ＰＣＣ識別子２３５、及びタイマ２３７を登録する。該当するエントリが存在する場合、Ｗｅｂサーバ２は、受信した前記応答メッセージに含まれるタイマ値２１７を該当するエントリのタイマ２３７に登録する。

以上の手順を用いることによって、Ｗｅｂサーバ２は、タイマ２３７に登録された値に基づいて、呼情報問い合わせ要求（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ）をＳＩＰアプリケーションサーバ３に周期的に送信することができる。これによって、Ｗｅｂサーバ２は、通信セッションの切断等の通信障害を迅速に検出することができる。

図１１は、本発明の第１の実施の形態の３ＰＣＣサービスの起動中に障害が発生した場合の手順を示すシーケンス図である。

３ＰＣＣサービスの起動手順、及び３ＰＣＣサービスが継続するときに行われる通信セッションの状態確認の手順は図８、図９と同様である。ここで、端末７Ａの通信セッションが何らかの理由によって切断されたとする。

ＳＩＰアプリケーションサーバ３は、ＳＩＰアプリケーションサーバ３と端末７Ａとの間でＴ１の周期で送受信されていたｋｅｅｐ ａｌｉｖｅメッセージが受信できなくなる。したがって、ＩＮＶＩＴＥ（Ｓ５１、Ｓ５２）への応答を一定時間（タイマＴ１）内に受信されなかったため、ＳＩＰアプリケーションサーバ３は、通信セッションの状態をセッションが切断したと判定し、３ＰＣＣ識別子２１３を検索キーとして、セッション情報テーブル２１０を検索し、該当エントリ２１０−１のセッション状態２１６を「切断中」に更新する（Ｓ７７）。

Ｗｅｂサーバ２は、タイマ２３７の周期でＳＩＰアプリケーションサーバ３へ呼情報問い合わせ要求（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ）を送信する（Ｓ７８）。

前記呼情報問い合わせ要求を受信したＳＩＰアプリケーションサーバ３は、前記呼情報問い合わせ要求に含まれるＰａｒｌａｙ Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１を検索キーとして、セッション情報テーブル２１０を検索し、該当するエントリ２１０−１から、状態２１６とタイマ値２１７とを読み出す。ＳＩＰアプリケーションサーバ３は、読み出した状態２１６（この場合は、「切断中」）とタイマ値２１７とを含む応答メッセージ（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）をＷｅｂサーバ２に送信する（Ｓ７９）。

状態２１６（「切断中」）を含む前記応答メッセージを受信したＷｅｂサーバ２は、前記応答メッセージに含まれる状態２１６（「切断中」）を参照する。この場合は、状態２１６が「切断中」なので、Ｗｅｂサーバ２は、通信セッションが切断されていると検出し、ＳＩＰアプリケーションサーバ３に３ＰＣＣサービスを終了する要求（ｅｎｄ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ）を送信する（Ｓ８０）。

前記３ＰＣＣサービスを終了する要求を受信したＳＩＰアプリケーションサーバ３は、Ｗｅｂサーバに応答メッセージ(ｅｎｄ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅを送信し（Ｓ８１）、セッションの終了処理を行う（Ｓ８２、８３）。また、ＳＩＰアプリケーションサーバ３は、セッションの終了処理が行われてから一定の時間が経過した後にセッション情報テーブル２１０から状態２１６が「切断中」のエントリを消去する。

Ｗｅｂサーバ２は、ＳＩＰアプリケーションサーバ３が通知したタイマ値（本実施の形態ではＴ３）を用いて、周期的に呼状態問い合わせ要求をＳＩＰアプリケーションサーバ３に送信する。これによって、Ｗｅｂサーバ２は、通信セッションに障害が発生したことを迅速に検出することができる。

次に、本発明の第２の実施の形態を、図面を用いて説明する。第１の実施の形態では、ＳＩＰアプリケーションサーバ３がＷｅｂサーバ２に通信セッションの状態を問い合わせる周期、つまり、タイマ値を通知した。これに対して第２の実施の形態ではＷｅｂサーバ２がＳＩＰアプリケーションサーバ３へ通信セッションの状態の通知を要求することを特徴とする。

Ｗｅｂサーバ２が通信セッションの状態の通知を要求することによって、ＳＩＰアプリケーションサーバ３は、端末間の通信セッションの状態が「切断中」になったことをＷｅｂサーバ２に通知することができる。

第２の実施の形態の通信網の構成は、第１の実施の形態と同じであるため、説明を省略する（図１参照）。以下、本発明の第２の実施の形態が第１の実施の形態と相違する点についてのみ説明する。

図１２は、本発明の第２の実施の形態のＷｅｂサーバ２の構成図である。

第２の実施の形態において、メモリ２５は、タイマ受信を行う処理プログラム２７の代わりにプレゼンス情報の問い合わせを行う処理プログラム２００を含む。

Ｗｅｂサーバ２が前記のプレゼンス情報問い合わせ機能２００を備えることによって、Ｗｅｂサーバ２は、ＳＩＰアプリケーションサーバ３に対しプレゼンス情報の通知を要求することができる。なお、第２の実施の形態において、プレゼンス情報問い合わせ機能２００は３ＰＣＣサービスを開始した後に起動される。

図１３は、本発明の第２の実施の形態のＳＩＰアプリケーションサーバ３の構成例を示すブロック図である。

第２の実施の形態において、メモリ３５は、セッションタイマ通知ルーチン３７０の代わりにプレゼンス情報の通知を行う処理プログラム３００を含む。

ＳＩＰアプリケーションサーバ３が前記のプレゼンス通知機能３００を備えることによって、ＳＩＰアプリケーションサーバ３は通信セッションの状態をプレゼンス情報に含めてＷｅｂサーバ２に通知することができる。

図１４は、本発明の第２の実施のＳＩＰアプリケーションサーバ３におけるセッション情報テーブルの構成の一例を示す説明図である。

セッション情報テーブル２１０はタイマＴ３２１７の代わりに、ＳＩＰアプリケーションサーバ３が監視をしているか否かを示す監視２１８を含む。なお、ＳＩＰアプリケーションサーバ３は、監視２１８が「ｏｎ」に設定されていて、通信セッションの状態が「通信中」から「切断中」に変更された場合、前記プレゼンス通知機能を用いて通信セッションの切断をＷｅｂサーバ２に通知する。

次に、図１５、図１６を参照して、第２の実施例における３ＰＣＣサービス起動シーケンスを説明する。以下、図１５、図１６に示す手順のうち、図８、図９、図１１と同じ手順については説明を省略する。

図１５は、本発明の第２の実施の形態の３ＰＣＣサービスを起動し、３ＰＣＣサービスが継続するときに行われる通信セッションの状態を確認する手順を示すシーケンス図である。

Ｗｅｂサーバ２は、通信セッションの状態を確認するために、呼情報問い合わせ要求（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ）をＳＩＰアプリケーションサーバ３に送信する（Ｓ７１）。

前記呼情報問い合わせ要求を受信したＳＩＰアプリケーションサーバ３は、前記呼情報問い合わせ要求に含まれるＰａｒｌａｙ Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１を検索キーとして、セッション情報テーブル２１０を検索し、該当するエントリ２１０−１から状態２１６を読み出す。ＳＩＰアプリケーションサーバ３は、状態２１６を含む応答メッセージ（ｇｅｔ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）をＷｅｂサーバ２に送信する（Ｓ７２）。

なお、Ｓ７１、Ｓ２７、Ｓ７２、及びＳ３１〜Ｓ６２の処理は、第１の実施の形態と同じである。ＳＩＰアプリケーションサーバ３と端末７Ａとの間の通信セッションの状態を確認するためのメッセージ（ｋｅｅｐ ａｌｉｖｅ）は、タイマＴ１の周期で送受信される。また、ＳＩＰアプリケーションサーバ３と端末７Ｂとの間の通信セッションの状態を確認するためのメッセージ（ｋｅｅｐ ａｌｉｖｅ）は、タイマＴ２の周期で送受信される。

前記応答メッセージＳ７２を受信したＷｅｂサーバ２は、前記応答メッセージに含まれる状態２１６が「通信中」になったことを確認し、ＳＩＰアプリケーションサーバ３に通信セッションの状態を通知する要求（ｓｕｂｓｃｒｉｂｅ Ｐｒｅｓｅｎｃｅ Ｒｅｑｕｅｓｔ）を送信する（Ｓ１０１）。

前記要求を受信したＳＩＰアプリケーションサーバ３は、前記要求に含まれるＰａｒｌａｙ Ｘ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２１１を検索キーとして、セッション情報テーブル２１０を検索する。ＳＩＰアプリケーションサーバ３は、該当するエントリ２１０−１の監視状態２１８を「ｏｎ」に更新した後、前記要求の応答メッセージ（ｓｕｂｓｃｒｉｂｅ Ｐｒｅｓｅｎｃｅ Ｒｅｓｐｏｎｓｅ）をＷｅｂサーバ２に送信する（Ｓ１０２）。

図１６は、本発明の第２の実施の形態の３ＰＣＣサービスの起動中に障害が発生した場合の手順を示すシーケンス図である。

Ｓ３１〜Ｓ５２、及びＳ７７は、第１の実施の形態と同じである。また、端末７Ａに障害がおきたものとする。

Ｓ７７において、ＳＩＰアプリケーションサーバ３は、ｋｅｅｐ ａｌｉｖｅメッセージが受信できないため、３ＰＣＣ識別子２１３を検索キーとして、セッション情報テーブル２１０を検索し、該当するエントリ２１０−１の状態２１６を「切断中」に更新する。さらに、該当するエントリの監視２１７を参照し、該当するエントリの監視２１７が「ｏｎ」である場合、ＳＩＰアプリケーションサーバ３は、Ｗｅｂサーバ２に通信セッションが切断したことを通知するメッセージ（ｎｏｔｉｆｙ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｒｅｑｕｅｓｔ）を送信する（Ｓ１０３）。

前記メッセージを受信したＷｅｂサーバ２は、ＳＩＰアプリケーションサーバ３に３ＰＣＣサービスを終了する要求を含む応答メッセージ（ｎｏｔｉｆｙ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｒｅｓｐｏｎｓｅ）を送信する（Ｓ１０４）。その後セッション終了処理が行われる（図１１ Ｓ８０〜Ｓ８３参照）。

第２の実施の形態によれば、Ｗｅｂサーバ２が前記プレゼンス情報問い合わせ機能を備えることによって、ＳＩＰアプリケーションサーバ３がセッション情報テーブル２１０の状態２１６が「通信中」から「切断中」へ遷移したことを迅速に検出し、通信セッションが切断したと判定し、通信セッションの切断をＷｅｂサーバ２に通知することができる。これによって、Ｗｅｂサーバ２は迅速に通信セッションの切断を検出することが可能になる。

次に、本発明の第３の実施の形態を、図面を用いて説明する。

図１７は、本発明の第３の実施の形態の通信網の構成図である。

第３の実施の形態は、ネットワークＮ１にプレゼンスサーバ４が接続されている。第３の実施の形態において、プレゼンスサーバ４は少なくてもウォッチャー機能を備える。ウォッチャ機能とは指定された端末の状態を監視する機能である。

図１８は、本発明の第３の実施の形態のプレゼンスサーバ４の構成例を示すブロック図である。

プレゼンスサーバ４は、回線４２（４２Ａ、４２Ｂ）を収容するインタフェース部（ＩＦ）４１（４１Ａ、４１Ｂ）とＣＰＵ４４と、メモリ４５と、データベース（ＤＢ）４６とを備える。各構成要素は、バス４３で接続される。

ＣＰＵ４４は、メモリ４５に記憶されたプログラムを実行するプロセッサである。メモリ４５には、例えば、プレゼンス通知を実現するためのプログラム（図示省略）、プレゼンス情報保持などを行うために必要な処理プログラム（例えば、ウォッチャ機能４９）、及びテーブル（ウォッチャ情報テーブル２８０）が記憶される。

図１９は、本発明の第３の実施の形態のプレゼンスサーバ４におけるウォッチャ情報テーブル２８０の構成の一例を示す説明図である。

ウォッチャ情報テーブル２８０は、少なくてもプレゼンティティ２８１、ウォッチャ２８２、及び状態２８３の対応情報を含む。プレゼンティティとは、プレゼンス情報を提供するエンティティを示す。

プレゼンスサーバ４がウォッチャ情報テーブル２８０を保持することによって、プレゼンスサーバ４は端末の通信セッションの状態を検出することができる。これによって、プレゼンスサーバ４がｋｅｅｐ ａｌｉｖｅメッセージが受信できなくなった場合、プレゼンスサーバ４は、通信セッションが切断されたと判定し、Ｗｅｂサーバ２に通信セッションの切断を通知することができる。以下、第３の実施の形態が第２の実施の形態と相違する点についてのみ説明する。

図２０は、本発明の第３の実施の形態のＷｅｂサーバ２の構成例を示すブロック図である。

第３の実施の形態において、メモリ２５はＳＩＰ ＡＳ情報テーブル２４０を含む。

図２１は、本発明の第３の実施のＷｅｂサーバ２におけるＳＩＰ ＡＳ情報テーブル２４０の構成の一例を示す説明図である。

ＳＩＰ ＡＳ情報テーブル２４０は、３ＰＣＣ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２４１と、３ＰＣＣ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２４１に対応するプレゼンスサーバ２４２の情報とを含む。これによって、Ｗｅｂサーバ２は、どの通信セッションの情報をプレゼンスサーバ４が保持するかが分かる。

Ｗｅｂサーバ２が前記ＳＩＰ ＡＳ情報テーブル２４０を備えることによって、Ｗｅｂサーバ２は３ＰＣＣのセッションとプレゼンスサーバの状態を関連付けることができる。これによって、Ｗｅｂサーバ２は、プレゼンスサーバ４から送信された情報に基づいて、通信セッションの状態を検出することができる。

次に、図２２、図２３を参照して、第３の実施の形態における３ＰＣＣサービス起動から障害が起きた場合のシーケンスを説明する。以下、図２２、図２３に示す手順のうち、図８、図９、図１１と同じ手順については説明を省略する。

図２２、図２３は、本発明の第３の実施の形態の３ＰＣＣサービスを起動し、３ＰＣＣサービスが継続するときに行われる通信セッションの状態を確認する手順と、３ＰＣＣサービスの起動中に障害が発生した場合の手順とを示すシーケンス図である。

Ｗｅｂサーバ２は、通信セッションの状態が「通信中」になったことを確認すると（Ｓ７２）、プレゼンスサーバ４に通信セッションの状態を通知する要求（ｓｕｂｓｃｒｉｂｅ Ｐｒｅｓｅｎｃｅ Ｒｅｑｕｅｓｔ）を送信する（Ｓ１２１）。ここで、Ｗｅｂサーバ２は、３ＰＣＣ ｃａｌｌ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ２４１を検索キーとしてＳＩＰ ＡＳ情報テーブル２４０を検索する。該当するエントリが存在しない場合、Ｗｅｂサーバ２は、新規エントリを生成し、プレゼンスサーバ４の識別子を登録する。該当するエントリがある場合、Ｗｅｂサーバ２は、該当するエントリの情報を更新する。

前記要求を受信したプレゼンスサーバ４は、前記要求への応答（ｓｕｂｓｃｒｉｂｅ Ｐｒｅｓｅｎｃｅ Ｒｅｓｐｏｎｓｅ）をＷｅｂサーバ２に送信する（Ｓ１２２）。

続いて、プレゼンスサーバ４は、端末７Ａと端末７Ｂと通信セッションの状態を含むプレゼンス情報を通知する要求（ＳＵＢＳＣＲＩＢＥ）をＳＩＰサーバ１に送信する（Ｓ１３１）。前記プレゼンス情報の通知要求を受信したＳＩＰサーバ１は、前記プレゼンス情報の通知要求への応答（２００ ＯＫ）をプレゼンスサーバに送信する（Ｓ１３２）。

ここで、ＳＩＰサーバ１がｋｅｅｐ ａｌｉｖｅメッセージから、例えば、端末７Ａとの通信セッションの切断を検出したとする（Ｓ１３４）。この場合、ＳＩＰサーバ１は、端末７Ａの通信セッションが切断したことを含むプレゼンス情報（ＮＯＴＩＦＹ）をプレゼンスサーバ４に通知する（Ｓ１３５）。

前記通知を受信したプレゼンスサーバ４は、前記プレゼンス情報通知への応答をＳＩＰサーバ１に送信する（２００、Ｓ１３６）。プレゼンスサーバ４は、端末７Ａのプレゼンス情報を含む通知メッセージ（ｎｏｔｉｆｙ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｒｅｑｅｓｔ）をＷｅｂサーバ２に送信する（Ｓ１２３）。

Ｗｅｂサーバ２は前記通知メッセージへの応答（ｎｏｔｉｆｙ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｒｅｓｐｏｎｓｅ）をプレゼンスサーバ４に送信した後（Ｓ１２４）、セッションを終了する処理を行う。

第３の実施の形態によれば、Ｗｅｂサーバ２がプレゼンスサーバ４と起動中の通信セッションの識別子とを対応付けて管理することによって、Ｗｅｂサーバ２が通信セッションの状態が「通信中」から「切断中」へ遷移したことを迅速に検出することができる。

また、第２の実施の形態と比べ、プレゼンスサーバ４を備えることによって、ＳＩＰアプリケーションサーバ３の負荷を低減できる。また、ＳＩＰアプリケーションサーバ３に新たにプレゼンス通知機能を備えることなく、既存のプレゼンスサーバをそのまま適用でき、コストを削減できる。

本発明の第１の実施の形態の通信網の構成図である。 本発明の第１の実施の形態のＷｅｂサーバの構成例を示すブロック図である。 本発明の第１の実施のＷｅｂサーバにおけるセッション情報テーブルの構成の一例を示す説明図である。 本発明の第１の実施の形態のＳＩＰアプリケーションサーバの構成例を示すブロック図である。 本発明の第１の実施のＳＩＰアプリケーションサーバにおけるセッション情報テーブルの構成の一例を示す説明図である。 本発明の第１の実施の形態のＳＩＰサーバの構成例を示すブロック図である。 本発明の第１の実施の形態のＳＩＰサーバにおけるセッション状態管理テーブルの構成の一例を示す説明図である。 通常の３ＰＣＣサービスを起動させる手順を示すシーケンス図である。 本発明の第１の実施の形態の３ＰＣＣサービスを起動させ、端末間の通信セッションが確立してから３ＰＣＣサービスが継続するときに行われる通信セッションの状態を確認する手順を示すシーケンス図である。 本発明の第１の実施の形態のセッションタイマ通知ルーチンのフローチャートである。 本発明の第１の実施の形態の３ＰＣＣサービスの起動中に障害が発生した場合の手順を示すシーケンス図である。 本発明の第２の実施の形態のＷｅｂサーバの構成図である。 本発明の第２の実施の形態のＳＩＰアプリケーションサーバの構成例を示すブロック図である。 本発明の第２の実施のＳＩＰアプリケーションサーバにおけるセッション情報テーブルの構成の一例を示す説明図である。 本発明の第２の実施の形態の３ＰＣＣサービスを起動し、３ＰＣＣサービスが継続するときに行われる通信セッションの状態を確認する手順を示すシーケンス図である。 本発明の第２の実施の形態の３ＰＣＣサービスの起動中に障害が発生した場合の手順を示すシーケンス図である。 本発明の第３の実施の形態の通信網の構成図である。 本発明の第３の実施の形態のプレゼンスサーバの構成例を示すブロック図である。 本発明の第３の実施の形態のプレゼンスサーバにおけるウォッチャ情報テーブルの構成の一例を示す説明図である。 本発明の第３の実施の形態のＷｅｂサーバの構成例を示すブロック図である。 本発明の第３の実施のＷｅｂサーバにおけるＳＩＰ ＡＳ情報テーブルの構成の一例を示す説明図である。 本発明の第３の実施の形態の３ＰＣＣサービスを起動し、３ＰＣＣサービスが継続するときに行われる通信セッションの状態を確認する手順と、３ＰＣＣサービスの起動中に障害が発生した場合の手順とを示すシーケンス図である。 本発明の第３の実施の形態の３ＰＣＣサービスを起動し、３ＰＣＣサービスが継続するときに行われる通信セッションの状態を確認する手順と、３ＰＣＣサービスの起動中に障害が発生した場合の手順とを示すシーケンス図である。

符号の説明

２ Ｗｅｂサーバ
３ ＳＩＰアプリケーションサーバ
７ 端末
３７０ セッションタイマ通知ルーチン

Claims (7)

1. 複数の端末の通信セッションを制御するセッション制御サーバと、前記セッション制御サーバと通信するアプリケーションサーバと、前記アプリケーションサーバと通信するウェブサーバと、前記各サーバを接続するネットワークとを備えた通信システムであって、
   前記アプリケーションサーバは、前記複数の端末の各々の通信セッションの状態の情報を周期的に検出し、前記検出された複数の端末の各々の通信セッションの状態の情報に基づいて前記通信セッションの切断を検出し、
   前記通信セッションの切断されたことを示す情報、及び、前記複数の端末の各々の通信セッションの状態の情報を含む状態関連情報を前記ウェブサーバに送信し、
   前記ウェブサーバは、受信した前記状態関連情報に基づいて通信セッションの状態を検出し、
   前記アプリケーションサーバは、前記状態関連情報に基づいて、前記ウェブサーバから前記アプリケーションサーバへの前記状態関連情報の問い合わせである呼制御の時間周期を制御する場合に、前記複数の端末の各々の通信セッションの状態の情報を検出するための周期を参照し、
   前記参照された周期のうち、最小の周期以下の値に前記呼制御の時間周期を決定し、
   前記決定された呼制御の時間周期を含む前記状態関連情報を前記ウェブサーバに送信し、
   前記ウェブサーバは、受信した前記状態関連情報に含まれる前記決定された呼制御の時間周期に基づいて、前記呼制御の時間周期を制御することを特徴とする通信システム。
2. 前記状態関連情報はＳＩＰメッセージに含まれ、前記呼制御の時間周期はセッションタイマであることを特徴とする請求項１に記載の通信システム。
3. 前記ウェブサーバは、前記複数の端末の各々の通信セッションの状態を検出する要求を前記アプリケーションサーバに送信し、
   前記アプリケーションサーバは、受信した前記要求に基づいて前記複数の端末の各々の通信セッションの状態を周期的に検出し、前記複数の端末の各々の通信セッションの状態の情報を含む前記状態関連情報を前記ウェブサーバに送信することを特徴とする請求項１に記載の通信システム。
4. 前記セッション制御サーバは、前記検出された複数の端末の各々の通信セッションの状態の情報に基づいて前記通信セッションの切断を検出し、前記状態関連情報に前記通信セッションの切断されたことを含めることを特徴とする請求項３に記載の通信システム。
5. 前記通信システムは、さらに、前記ネットワークに接続されたプレゼンスサーバを備え、
   前記ウェブサーバは、前記複数の端末の各々の通信セッションの状態を検出する要求を前記プレゼンスサーバに送信し、
   前記プレゼンスサーバは、前記要求に基づいて前記複数の端末の各々の通信セッションの状態を検出し、前記検出された複数の端末の各々の通信セッションの状態の情報を含むプレゼンス情報を前記ウェブサーバに送信することを特徴とする請求項１に記載の通信システム。
6. 前記要求に基づいて前記複数の端末の各々の通信セッションの状態を検出する場合に、
   前記プレゼンスサーバは、前記セッション制御サーバに前記要求を送信し、
   前記セッション制御サーバは、前記要求に基づいて前記複数の端末の各々の通信セッションの状態を周期的に検出することを特徴とする請求項５に記載の通信システム。
7. 前記セッション制御サーバは、前記要求に基づいて前記通信セッションの切断を検出し、前記通信セッションの切断を含む前期状態関連情報を前記プレゼンスサーバに送信し、
   前記プレゼンスサーバは、前記状態関連情報に基づいて前記通信セッションの切断を含むプレゼンス情報を前記ウェブサーバに送信することを特徴とする請求項５に記載の通信システム。

Images