(57)【要約】【課題】通話回数等のトラフィックにより通信端末の収容先変更が行われることなく、予め決められた条件に従って、最適な通信端末の収容先変更を行い得る。【解決手段】実施形態によれば、通信システムは、複数の通信端末を収容可能で、複数の通信端末間の呼接続を実行する複数のサーバ装置を備える。複数のサーバ装置のうち第１のサーバ装置は、記憶手段と、判定手段と、変更制御手段とを備える。記憶手段は、第１の通信端末を特定する端末ＩＤと、通話回数とを対応付けた通話管理テーブルを記憶する。判定手段は、通話管理テーブルに基づいて、第１の通信端末の通話回数がしきい値を超えているか否かを判定する。変更制御手段は、判定手段によりしきい値を超えていると判定した場合、予め決められた条件に基づいて、第１の通信端末の収容先を第１のサーバ装置から第２のサーバ装置または別のサーバ装置に変更する。【選択図】      図８
2013232812.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信端末を収容可能で、複数の通信端末間の呼接続を実行する複数のサーバ装置を備え、前記複数のサーバ装置間を通信ネットワークを介して接続する通信システムにおいて、
複数のサーバ装置のうち第１のサーバ装置は、
前記第１のサーバ装置に収容される第１の通信端末と第２のサーバ装置に収容される第２の通信端末間の呼接続が確立されるごとに、前記第１の通信端末を特定する端末ＩＤと、通話回数とを対応付けた通話管理テーブルを記憶する記憶手段と、
前記通話管理テーブルに基づいて、前記第１の通信端末の通話回数がしきい値を超えているか否かを判定する判定手段と、
この判定手段によりしきい値を超えていると判定した場合、予め決められた条件に基づいて、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置または別のサーバ装置に変更する変更制御手段とを具備する通信システム。
【請求項２】
前記変更制御手段は、前記条件として、前記第２のサーバ装置に対し収容可能端末数を問い合わせ、この問い合わせに対し前記第２のサーバ装置が収容可能と判断した場合に、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置に変更する請求項１記載の通信システム。
【請求項３】
前記変更制御手段は、前記条件として、前記第１の通信端末の前記第１のサーバ装置への収容期間がしきい値を超え、収容先変更回数がしきい値以下の場合に、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置または別のサーバ装置に変更する請求項１記載の通信システム。
【請求項４】
前記変更制御手段は、収容先変更を必要とする通信端末の台数が、変更先となる第２のサーバ装置の収容可能台数以上存在した場合に、変更対象となる通信端末に割り当てられた優先度が高い順に収容先変更を行う請求項１記載の通信システム。
【請求項５】
前記判定手段は、前記第１の通信端末の通話回数が保守者により可変設定されたしきい値を超えるか否かを判定する請求項１記載の通信システム。
【請求項６】
前記変更制御手段は、前記第１の通信端末の前記第１のサーバ装置への収容期間が保守者により設定可能なしきい値を超え、収容先変更回数が保守者により設定可能なしきい値以下の場合に、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置または別のサーバ装置に変更する請求項３記載の通信システム。
【請求項７】
前記複数のサーバ装置間の呼制御プロトコルは、ＳＩＰ、Ｍｅｇａｃｏ、ＱＳＩＧの少なくとも１つを用いる請求項１記載の通信システム。
【請求項８】
通信端末を備える複数のユーザ装置に対し通信ネットワークを介して接続され、前記複数のユーザ装置に対し通信端末間または通信端末と通信回線との間の交換処理に係わる任意の通信サービスを提供するデータセンタ装置であって、
通信端末間または通信端末と通信回線との間の交換処理に係わる複数の通信機能を実行するための複数の仮想サーバを有する処理部を具備し、
前記複数の仮想サーバのうち第１の仮想サーバは、
前記第１の仮想サーバに収容される第１の通信端末と第２の仮想サーバに収容される第２の通信端末間の呼接続が確立されるごとに、前記第１の通信端末を特定する端末ＩＤと、通話回数とを対応付けた通話管理テーブルを記憶する記憶手段と、
前記通話管理テーブルに基づいて、前記第１の通信端末の通話回数がしきい値を超えているか否かを判定する判定手段と、
この判定手段によりしきい値を超えていると判定した場合、予め決められた条件に基づいて、前記第１の通信端末の収容先を前記第１の仮想サーバから前記第２の仮想サーバまたは別の仮想サーバに変更する変更制御手段とを備えるデータセンタ装置。
【請求項９】
前記変更制御手段は、前記条件として、前記第２の仮想サーバに対し収容可能端末数を問い合わせ、この問い合わせに対し前記第２の仮想サーバが収容可能と判断した場合に、前記第１の通信端末の収容先を前記第１の仮想サーバから前記第２の仮想サーバに変更する請求項８記載のデータセンタ装置。
【請求項１０】
前記変更制御手段は、前記条件として、前記第１の通信端末の前記第１の仮想サーバへの収容期間がしきい値を超え、収容先変更回数がしきい値以下の場合に、前記第１の通信端末の収容先を前記第１の仮想サーバから前記第２の仮想サーバまたは別の仮想サーバに変更する請求項８記載のデータセンタ装置。
【請求項１１】
前記変更制御手段は、収容先変更を必要とする通信端末の台数が、変更先となる第２の仮想サーバの収容可能台数以上存在した場合に、変更対象となる通信端末に割り当てられた優先度が高い順に収容先変更を行う請求項８記載のデータセンタ装置。
【請求項１２】
前記判定手段は、前記第１の通信端末の通話回数が保守者により可変設定されたしきい値を超えるか否かを判定する請求項８記載のデータセンタ装置。
【請求項１３】
前記変更制御手段は、前記第１の通信端末の前記第１の仮想サーバへの収容期間が保守者により設定可能なしきい値を超え、収容先変更回数が保守者により設定可能なしきい値以下の場合に、前記第１の通信端末の収容先を前記第１の仮想サーバから前記第２の仮想サーバまたは別の仮想サーバに変更する請求項１０記載のデータセンタ装置。
【請求項１４】
複数の通信端末を収容可能で、複数の通信端末間または前記通信端末と通信ネットワークとの間の呼接続を実行するサーバ装置において、
第１の通信端末と前記通信ネットワーク上のサーバ装置に収容される第２の通信端末間の呼接続が確立されるごとに、前記第１の通信端末を特定する端末ＩＤと、通話回数とを対応付けた通話管理テーブルを記憶する記憶手段と、
前記通話管理テーブルに基づいて、前記第１の通信端末の通話回数がしきい値を超えているか否かを判定する判定手段と、
この判定手段によりしきい値を超えていると判定した場合、予め決められた条件に基づいて、前記第１の通信端末の収容先を前記通信ネットワーク上のサーバ装置に変更する変更制御手段とを具備するサーバ装置。
【請求項１５】
前記変更制御手段は、前記条件として、前記第２のサーバ装置に対し収容可能端末数を問い合わせ、この問い合わせに対し前記第２のサーバ装置が収容可能と判断した場合に、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置に変更する請求項１４記載のサーバ装置。
【請求項１６】
前記変更制御手段は、前記条件として、前記第１の通信端末の前記第１のサーバ装置への収容期間がしきい値を超え、収容先変更回数がしきい値以下の場合に、前記第１の通信端末の収容先を前記通信ネットワーク上のサーバ装置に変更する請求項１４記載のサーバ装置。
【請求項１７】
前記変更制御手段は、収容先変更を必要とする通信端末の台数が、変更先となるサーバ装置の収容可能台数以上存在した場合に、変更対象となる通信端末に割り当てられた優先度が高い順に収容先変更を行う請求項１４記載のサーバ装置。
【請求項１８】
前記判定手段は、前記第１の通信端末の通話回数が保守者により可変設定されたしきい値を超えるか否かを判定する請求項１４記載のサーバ装置。
【請求項１９】
前記変更制御手段は、前記第１の通信端末の収容期間が保守者により設定可能なしきい値を超え、収容先変更回数が保守者により設定可能なしきい値以下の場合に、前記第１の通信端末の収容先を前記通信ネットワーク上のサーバ装置に変更する請求項１６記載のサーバ装置。
【請求項２０】
前記通信ネットワーク上のサーバ装置との間で使用される呼制御プロトコルは、ＳＩＰ、Ｍｅｇａｃｏ、ＱＳＩＧの少なくとも１つを用いる請求項１４記載のサーバ装置。
【請求項２１】
複数の通信端末を収容可能で、複数の通信端末間の呼接続を実行する複数のサーバ装置を備え、前記複数のサーバ装置間を通信ネットワークを介して接続する通信システムで使用される端末収容先変更方法において、
複数のサーバ装置のうち第１のサーバ装置は、
前記第１のサーバ装置に収容される第１の通信端末と第２のサーバ装置に収容される第２の通信端末間の呼接続が確立されるごとに、前記第１の通信端末を特定する端末ＩＤと、通話回数とを対応付けた通話管理テーブルをメモリに記憶し、
前記通話管理テーブルに基づいて、前記第１の通信端末の通話回数がしきい値を超えているか否かを判定し、
しきい値を超えていると判定した場合、予め決められた条件に基づいて、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置または別のサーバ装置に変更する端末収容先変更方法。
【請求項２２】
前記変更することは、前記条件として、前記第２のサーバ装置に対し収容可能端末数を問い合わせ、この問い合わせに対し前記第２のサーバ装置が収容可能と判断した場合に、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置に変更する請求項２１記載の端末収容先変更方法。
【請求項２３】
前記変更することは、前記条件として、前記第１の通信端末の前記第１のサーバ装置への収容期間がしきい値を超え、収容先変更回数がしきい値以下の場合に、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置または別のサーバ装置に変更する請求項２１記載の端末収容先変更方法。
【請求項２４】
前記変更することは、収容先変更を必要とする通信端末の台数が、変更先となる第２のサーバ装置の収容可能台数以上存在した場合に、変更対象となる通信端末に割り当てられた優先度が高い順に収容先変更を行う請求項２１記載の端末収容先変更方法。
【請求項２５】
前記判定することは、前記第１の通信端末の通話回数が保守者により可変設定されたしきい値を超えるか否かを判定する請求項２１記載の端末収容先変更方法。
【請求項２６】
前記変更することは、前記第１の通信端末の前記第１のサーバ装置への収容期間が保守者により設定可能なしきい値を超え、収容先変更回数が保守者により設定可能なしきい値以下の場合に、前記第１の通信端末の収容先を前記第１のサーバ装置から前記第２のサーバ装置または別のサーバ装置に変更する請求項２３記載の端末収容先変更方法。
【請求項２７】
前記複数のサーバ装置間の呼制御プロトコルは、ＳＩＰ、Ｍｅｇａｃｏ、ＱＳＩＧの少なくとも１つを用いる請求項２１記載の端末収容先変更方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、例えばＩＰ（Internet Protocol）電話システムといった通信システム、データセンタ装置、サーバ装置及び端末収容先変更方法に関する。
【背景技術】
【０００２】
近年、ＬＡＮ（Local Area Network）やインターネットといったＩＰ(Internet Protocol)網を介して、双方向に画像や音声をパケットデータとして、リアルタイムに送受信するＩＰ電話システムが普及している。このＩＰ電話システムでは、ＩＰ網に複数のサーバ装置が接続され、各サーバ装置ごとにＩＰ電話端末を収容できるようになっている。このようなＩＰ電話システムでは、内線間通信や外線発着信を行えることは勿論のこと、ＩＰ網を経由したサーバ装置間での内線通信や外線発着信を行うことができる。
【０００３】
ところで、上記ＩＰ電話システムでは、サーバ装置起動時に各ノード単位で収容するＩＰ電話端末とサーバ装置間のプロトコルに応じて内線番号やＩＰアドレスの収容処理を行い、ノード単位で収集したトラフィック情報を元にＩＰ電話端末の収容先ノードを変更する。また通常収容されるサーバ装置のダウンや、ネットワーク障害によりサーバ装置−ＩＰ電話端末間の通信ができなくなった場合に、バックアップ先のノードに収容先を自動的に変更して電話サービスを継続して提供する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−１７３７６８号公報
【特許文献２】特開２０１１−９７４６９号公報
【特許文献３】特開２００７−１８１０７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
トラフィック情報のみに基づいた収容先変更方法では、トラフィック情報の内容次第では、ＩＰ電話システムを構成する複数のサーバ装置のうち、特定のサーバ装置への収容が集中したり、特定のサーバ装置間の収容先変更が頻繁に行われてしまう事象が発生する。
【０００６】
本発明の目的は、通話回数等のトラフィックにより通信端末の収容先変更が行われることなく、予め決められた条件に従って、最適な通信端末の収容先変更を行い得る通信システム、データセンタ装置、サーバ装置及び端末収容先変更方法を提供することにある。
【課題を解決するための手段】
【０００７】
実施形態によれば通信システムは、複数の通信端末を収容可能で、複数の通信端末間の呼接続を実行する複数のサーバ装置を備え、複数のサーバ装置間を通信ネットワークを介して接続する通信システムを対象とする。複数のサーバ装置のうち第１のサーバ装置は、記憶手段と、判定手段と、変更制御手段とを備える。記憶手段は、第１のサーバ装置に収容される第１の通信端末と第２のサーバ装置に収容される第２の通信端末間の呼接続が確立されるごとに、第１の通信端末を特定する端末ＩＤと、通話回数とを対応付けた通話管理テーブルを記憶する。判定手段は、通話管理テーブルに基づいて、第１の通信端末の通話回数がしきい値を超えているか否かを判定する。変更制御手段は、判定手段によりしきい値を超えていると判定した場合、予め決められた条件に基づいて、第１の通信端末の収容先を第１のサーバ装置から第２のサーバ装置または別のサーバ装置に変更する。
【図面の簡単な説明】
【０００８】
【図１】第１の実施形態における通信システムの概略構成図。
【図２】上記図１に示した仮想化ホストサーバの具体的構成を示す図。
【図３】本第１の実施形態に係るＣＰコンテナ（仮想サーバ）の機能構成図。
【図４】上記図１に示したユーザデータベースの記憶内容の一例を示す図。
【図５】第２の実施形態に係るＩＰ電話システムの概略構成図。
【図６】図５に示した呼制御サーバの構成を示すブロック図。
【図７】上記図６に示したトラフィック情報テーブルの記憶内容の一例を示す図。
【図８】上記図６に示した収容先情報テーブルの記憶内容の一例を示す図。
【図９】本第２の実施形態において、ＩＰ電話端末と公衆網上の外部端末との通話状態から終話操作をした時の信号シーケンスの例を示す図。
【図１０】本第２の実施形態において、プライベート網をまたがるＩＰ電話端末間の通話状態から終話操作をした時の信号シーケンスの例を示す図。
【図１１】本第２の実施形態において、１つの呼制御サーバに収容されたＩＰ電話端末の収容先変更が発生した時の信号シーケンスの例を示す図。
【図１２】本第２の実施形態において、端末収容先変更確認要求を送信する際の制御部の制御処理手順を示すフローチャート。
【図１３】本第２の実施形態において、ＩＰ電話端末から収容先変更完了を受信するまでの制御部の制御処理手順を示すフローチャート。
【発明を実施するための形態】
【０００９】
以下、実施の形態について、図面を参照して説明する。
【００１０】
（第１の実施形態）  
第１の実施形態は、ＩＰ電話サーバを企業内に設けるのではなく、クラウド上のサーバである仮想化ホストサーバに割り当てるようにし、仮想化ホストサーバにより各企業または各個人ごとにＩＰ電話端末の通話回数をカウントし、収容先変更対象となったＩＰ電話端末の収容先を変更するようにしたものである。
【００１１】
図１は、この第１の実施形態における通信システムの概略構成図であり、ＵＳ１〜ＵＳｍはユーザサイト、クラウド上に設けられるＤＣ１〜ＤＣｉ（ｉは自然数）はデータセンタ、ＭＳはメーカサイトをそれぞれ示している。ここで、データセンタＤＣ１〜ＤＣｉは、例えば電話サービス会社が運営するデータセンタである。また、メーカサイトＭＳは、例えばディーラと呼ばれる会社であり、データセンタＤＣ１〜ＤＣｉを利用して電話サービスを行うユーザを管理する会社である。ユーザは、このメーカと契約することで、データセンタを経由することができるようになる。ここで、データセンタを運営する電話サービス会社とユーザを管理するメーカは、必ずしも別会社である必要はなく、同一会社であっても問題はない。
【００１２】
まず、ユーザサイトについては、ユーザサイトＵＳ１〜ＵＳｍのうち、ユーザサイトＵＳ１を代表して説明する。ユーザサイトＵＳ１は、ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎと、パーソナル・コンピュータＰＣと、ルータＲＴとを備えている。これらは、ＬＡＮ１を介して相互に接続している。このＬＡＮ１には、ゲートウェイＧＷ１が接続されている。なお、ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎは、ハードフォン、ソフトフォン等の電話機で、通話処理機能と映像等のメディア情報処理機能とを備えている。ゲートウェイＧＷ１は、ＬＡＮ１とアナログ電話網等の公衆網ＮＷ１との間を接続するもので、ＬＡＮ１と公衆網ＮＷ１との間における通信プロトコル及び信号フォーマットの変換機能とを備えている。
【００１３】
ルータＲＴは、インターネットＩＮＷに接続され、このインターネットＩＮＷからさらにデータセンタＤＣ１〜ＤＣｉに接続される。ここでは、データセンタＤＣ１を代表として説明する。
【００１４】
メーカサイトＭＳは、ディーラ管理、ユーザ管理及び発注を管理する機能を有する。また、メーカサイトＭＳは、遠隔地からの保守を行うための機能を有する。
【００１５】
データセンタＤＣ１は、クラウド上に設けられたデータセンタである。データセンタＤＣ１は、インターネット等の通信網を介して、既存の公衆ＩＰ電話網ＮＷ２と接続されている。さらに、他社のデータセンタＤＣ２〜ＤＣｉと相互に通話可能となる。また、データセンタＤＣ１は、仮想化ホストサーバ(HW Node:ハードウェアノード)Ｎ１〜Ｎｐ（ｐは自然数）と、電話会議サーバＣＳＶ１と、ウェブ会議サーバＣＳＶ２と、運用支援サーバＣＳＶ３と、課金管理サーバＣＳＶ４と、プロビジョニングサーバＣＳＶ５と、ルータＣＲＴ１〜ＣＲＴｑ（ｑは自然数）と、ユーザデータベースＤＢとを備え、これらをＬＡＮ２を介して相互に接続している。ルータＣＲＴ１〜ＣＲＴｑは、インターネットＩＮＷに接続され、このインターネットＩＮＷからさらにユーザサイトＵＳ１〜ＵＳｍに接続される。なお、仮想化ホストサーバＮ１〜Ｎｐ、電話会議サーバＣＳＶ１、ウェブ会議サーバＣＳＶ２、運用支援サーバＣＳＶ３、課金管理サーバＣＳＶ４、プロビジョニングサーバＣＳＶ５は、物理的に独立している必要はなく、複数の役割りを物理的には１台のサーバで兼ねてもよい。また、仮想化されたリソースとして適用されるため、電話会議サーバＣＳＶ１と、ウェブ会議サーバＣＳＶ２と、運用支援サーバＣＳＶ３と、課金管理サーバＣＳＶ４と、プロビショニングサーバＣＳＶ５のそれぞれの物理的なサーバ構成は、複数のサーバから構成されていてもよい。
【００１６】
アプライアンス型ＩＰ電話サーバをそのまま仮想化して動作させた場合、仮想化に必要な計算機リソース(CPU使用量、メモリ使用量、ディスク使用量)が大きく、単純計算ではアプライアンス型ＩＰ電話サーバの仕様×台数分が必要となる。そのため仮想化しても１台の物理サーバで数台〜１０台程度の台数しか動作させることができない。
【００１７】
そこで、本第１の実施形態では、一般的なアプライアンス型ＩＰ電話サーバの機能を主に、通話機能、電話会議機能、ウェブ会議機能、および運用管理機能に分割する。そして、通話機能は仮想化ホストサーバＮ１〜Ｎｐ各ＣＰコンテナに収容する。また、運用管理機能は、仮想化ホストサーバＮ１〜ＮｐのAdminコンテナに集約する。また、電話会議機能は、データセンタ内に仮想化ホストサーバＮ１〜Ｎｐから分離して設けられた電話会議サーバに集約される。更に、ウェブ会議機能は、データセンタ内に仮想化ホストサーバＮ１〜Ｎｐから分離して設けられたＷｅｂ会議サーバに集約されて構成されている。ここで、電話会議機能とウェブ会議機能を、３者以上の接続を実現するもので、発呼や着呼という電話の基本機能を行うＣＰユニットと分離し、複数のＣＰユニットの共通リソースとして使用することで、流用効率を上げている。
【００１８】
図２は、上記仮想化ホストサーバＮ１〜Ｎｐの具体的構成を示す図である。
【００１９】
仮想化ホストサーバＮ１〜Ｎｐは、契約を結んだ上記ユーザサイトＵＳ１のＩＰ電話端末ＩＰＴ１〜ＩＰＴｎ相互間及びこれらＩＰ電話端末ＩＰＴ１〜ＩＰＴｎと公衆網ＮＷ１の加入者線との間を交換接続する通話機能を基本機能として実現するための仮想サーバである。
【００２０】
ところで、上記仮想化ホストサーバＮ１〜Ｎｐ、電話会議サーバＣＳＶ１及びウェブ会議サーバＣＳＶ２は、各ユーザサイトＵＳ１〜ＵＳｍに配置される一般のアプライアンス型ＩＰ電話サーバの機能を分割して、クラウド上のデータセンタＤＣ１に実現したものである。
【００２１】
ここで、１台の仮想化ホストサーバＮ１内は、その上で仮想サーバが複数動作できるようにするための仮想環境が構築されている。仮想サーバには、機能や容量に応じて、１つまたは複数のＡｄｍｉｎコンテナ、ＣＰコンテナが設けられる。
【００２２】
まず、ＣＰコンテナは、電話機能としての基本機能である通話機能、ボイスメール機能、緊急通話機能などを有する。仮想サーバが提供するリソースの容量や運用方法にもよるが、従来のアプライアンス型ＩＰ電話サーバの１台分の端末間の接続設定機能を１つのＣＰコンテナに収容すると管理が容易になる。もちろん、ＣＰコンテナの収容方法は、これに限られない。
【００２３】
運用管理機能はAdminコンテナに集約する。Adminコンテナは、ＣＰコンテナの設定およびライセンス管理、電話会議、ウェブ会議の設定などの、保守・管理機能を有する。Adminコンテナは、従来のアプライアンス型ＩＰ電話サーバではそれぞれのサーバに設けられていた保守・運用機能を集約して収容したもので、１つのコンテナで複数のＣＰコンテナ、つまりユーザサイトＵＳ１〜ＵＳｍの保守・管理を可能とする。
【００２４】
電話会議サーバＣＳＶ１は、契約を結んだ上記ユーザサイトＵＳ１のＩＰ電話端末ＩＰＴ１〜ＩＰＴｎ間の音声による会議接続を行う機能を有する。電話会議コンテナは、電話会議機能を有し、複数のＣＰコンテナの共通リソースとして使用する。
【００２５】
ウェブ会議サーバＣＳＶ２は、契約を結んだ上記ユーザサイトＵＳ１のＩＰ電話端末ＩＰＴ１〜ＩＰＴｎ間の映像等のメディアを用いた会議接続を行う機能を有する。ウェブ会議コンテナは、ウェブ会議機能を有し、複数のＣＰコンテナの共通リソースとして使用する。
【００２６】
ところで、上記ＣＰコンテナＣＰ１〜ＣＰ１２は、第１の実施形態に係る機能を有している。図３は、本第１の実施形態に係るＣＰコンテナＣＰ１〜ＣＰ１２の機能構成図である。ここでは、ＣＰコンテナＣＰ１を代表して説明する。
【００２７】
ＣＰコンテナＣＰ１は、トラフィック情報テーブル３１０と、収容先情報テーブル３２０と、テーブル更新部３３０と、収容先変更判定部３４０と、収容先制御部３５０とを備えている。トラフィック情報テーブル３１０は、各ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎの通話回数を管理するためのテーブルである。トラフィック情報テーブル３１０には、各ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎの内線番号と、自ノード（内線間）内の通話回数と、他ノード（ＣＰコンテナＣＰ２〜ＣＰ１２）との通話回数との対応関係を表すデータが記憶されている。
【００２８】
収容先情報テーブル３２０は、収容先変更対象となるＩＰ電話端末ＩＰＴ１〜ＩＰＴｎの収容先変更条件を管理するためのテーブルである。収容先情報テーブル３２０には、各ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎの内線番号と、収容先変更優先度と、収容開始日時と、収容先変更回数との対応関係を表すデータが記憶されている。
【００２９】
テーブル更新部３３０は、例えばＩＰ電話端末ＩＰＴ１の終話が検出されるごとに、トラフィック情報テーブル３１０中の自ノード通話回数もしくは他ノード通話回数をインクリメントする。
【００３０】
収容先変更判定部３４０は、トラフィック情報テーブル３１０の記憶内容に基づいて、例えばＩＰ電話端末ＩＰＴ１の他ノードとの通話回数がしきい値を超えているか否かを判定する。
【００３１】
収容先制御部３５０は、上記収容先変更判定部３４０による判定結果から、例えばＩＰ電話端末ＩＰＴ１の他ノードとの通話回数がしきい値（例えば１００回）を超えている場合に、収容先情報テーブル３２０を参照して、ＩＰ電話端末ＩＰＴ１のＣＰコンテナＣＰ１への収容期間がしきい値（例えば１週間）を超え、収容先変更回数がしきい値（２回）以下の場合に、ＩＰ電話端末ＩＰＴ１の収容先をＣＰコンテナＣＰ１から他のノードとなるＣＰコンテナＣＰ２に変更するべく、収容変更先に対し収容変更の旨のメッセージを送信する。この時、例えばＣＰコンテナＣＰ２に対し収容可能端末数を問い合わせ、この問い合わせに対しＣＰコンテナＣＰ２と判断した場合に、ＩＰ電話端末ＩＰＴ１の収容先をＣＰコンテナＣＰ１からＣＰコンテナＣＰ２に変更する。
【００３２】
また、収容先制御部３５０は、収容先変更を必要とするＩＰ電話端末ＩＰＴ１〜ＩＰＴｎの台数が、変更先となるＣＰコンテナＣＰ２の収容可能台数以上存在した場合に、収容先情報テーブル３２０を参照して、変更対象となるＩＰ電話端末ＩＰＴ１〜ＩＰＴｎに割り当てられた優先度が高い順に収容先変更を行う。
【００３３】
図１に戻って、運用支援サーバＣＳＶ３は、ユーザデータベースＤＢに基づいて、仮想化ホストサーバＮ１〜Ｎｐ、電話会議サーバＣＳＶ１及びウェブ会議サーバＣＳＶ２の監視、障害検出、保守、アラーム発報、一括ログ収集、一括データバックアップ、プログラム更新、ＩＰ電話端末のファームウェア更新、ＱＯＳモニタ等を自動的に実行する機能を有する。さらに、自動化のためのインベントリ情報をデータベース管理する機能も有している。
【００３４】
課金管理サーバＣＳＶ４は、ユーザの電話機能の使用量により従量課金する機能を有し、メーカーサイトＭＳからユーザ情報を取得し、ユーザに対して課金処理を行う。
【００３５】
プロビジョニングサーバＣＳＶ５は、メーカーサイトＭＳからユーザが購入したライセンス情報を取得し、購入ライセンス数に応じて通話機能、電話会議機能、ウェブ会議機能のリソースを割り当てる機能を有する。具体的には、通話機能についてはライセンス数に応じた数のＩＰ電話端末（ＩＰＴ）、ＩＰトランク回線を割り当てる。また、ライセンスを取得したユーザに応じて、電話会議サーバ、ウェブ会議サーバの使用可否を設定する。
【００３６】
図４は、プロビジョニングサーバＣＳＶ５に設けられる、ユーザデータベースＤＢである。このユーザデータベースＤＢには、各ユーザごとに割り当てられた個別識別番号（ユーザＩＤ）に対応付けて、ユーザに割り当てられたＩＰアドレス、後述するがユーザの設定リソース（設定可能なリソースも含む）、ユーザに付与された秘密情報としての機器識別番号、認証情報としてのパスワード、ログイン中のＩＰ電話端末ＩＰＴ１，ＩＰＴ２がそれぞれ記憶されている。ここで、設定リソースの例としては、通話機能、ボイスメール機能、緊急通話機能、電話会議機能、ウェブ会議機能等が挙げられる。
【００３７】
また、運用支援サーバＣＳＶ３、課金管理サーバＣＳＶ４及びプロビジョニングサーバＣＳＶ５は、例えば専用線を介してメーカサイトＭＳに接続される。
【００３８】
次に、上記構成における動作について説明する。  
（ユーザシステムの登録）  
まず、ユーザが本第１の実施形態のシステムを利用するためには、ディーラとの契約を行う。契約の内容は、必要な回線数や、付加機能（電話会議機能、ウェブ会議機能等）を使用するかについて、契約を行うことで、ライセンスを受ける。ここで、通常は、回線数や付加機能の有無により、料金が異なる場合が多い。
【００３９】
ディーラは、ユーザとの契約内容に応じて、ユーザサイトＵＳ１を操作し、契約したユーザの登録を行う。
【００４０】
ユーザサイトＵＳ１の操作に対応して、データセンタＤＣ１のプロビジョニングサーバＣＳＶ５が、仮想化ノードのＡｄｍｉｎコンテナを制御して、必要なＣＰコンテナの設定を行う。また、電話会議機能やウェブ会議機能の使用可否の設定も行う。
【００４１】
このような設定が完了することで、ユーザが通話機能、電話会議機能またはウェブ会議機能を使用できるようになる。
【００４２】
（ＣＰコンテナＣＰ１に収容されるＩＰ電話端末ＩＰＴ１とＣＰコンテナＣＰ２に収容されるＩＰ電話端末との通話動作）  
ＣＰコンテナＣＰ１に収容されたＩＰ電話端末ＩＰＴ１にてＣＰコンテナＣＰ２に収容されるＩＰ電話端末への発信操作が行われたとする。そうすると、ＩＰ電話端末ＩＰＴ１は、ＣＰコンテナＣＰ１へ発信要求を送信する。
【００４３】
ＣＰコンテナＣＰ１は、上記発信要求を受信すると、発信要求をＬＡＮ２を介してＣＰコンテナＣＰ２へ送信する。
【００４４】
ＣＰコンテナＣＰ２は、発信要求を受信すると、着信先のＩＰ電話端末の呼び出しを行なう。このとき、着信先のＩＰ電話端末では、着信報知が行われる。
【００４５】
上記着信報知に対し着信先のＩＰ電話端末のユーザが応答操作を行なうと、着信先のＩＰ電話端末は応答メッセージをＣＰコンテナＣＰ２へ送信する。
【００４６】
ＣＰコンテナＣＰ２は、受信した応答メッセージより、着信先をＣＰコンテナＣＰ２に接続した旨を示す情報を応答メッセージに乗せてＣＰコンテナＣＰ１に通知する。
【００４７】
ＣＰコンテナＣＰ１は、応答メッセージ受信後、２００ＯＫメッセージを発信元のＩＰ電話端末ＩＰＴ１へ送信する。すると、ＩＰ電話端末ＩＰＴ１は、ＣＰコンテナＣＰ１に対しＡＣＫを返送する。
【００４８】
ＣＰコンテナＣＰ１は、ＩＰ電話端末ＩＰＴ１からＡＣＫを受信すると、ＣＰコンテナＣＰ２に対しＣＯＮＮ  ＡＣＫを送信する。そして、ＣＰコンテナＣＰ２は、着信先のＩＰ電話端末に対しＡＣＫを送信する。かくして、発信元のＩＰ電話端末ＩＰＴ１と着信先のＩＰ電話端末との間にはＣＰコンテナＣＰ１，ＣＰ２を経由した通信リンクが形成され、以後ＲＴＰパケットの送受信が行われ、通話が可能となる。
【００４９】
（ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎの収容先変更動作）  
まず、ＣＰコンテナＣＰ１は、図示しないタイマにより計時される現在時刻を定期的に確認し端末収容先変更確認日時と一致したことを確認すると、例えばＩＰ電話端末ＩＰＴ１のトラフィック情報テーブル３１０のデータを取得する。
【００５０】
そして、ＣＰコンテナＣＰ１は、取得したデータから、現在の収容先以外の他ノードとの通話回数が閾値以上の値が存在するか判定する。ここで、閾値以上の値が存在した場合、ＣＰコンテナＣＰ１は、該当するＩＰ電話端末の収容先情報テーブル３２０のデータを取得し、取得したデータから、現在のノードの収容日数が閾値以上経過しているか判定する。
【００５１】
ここで、収容日数が閾値以上の場合、ＣＰコンテナＣＰ１は収容先変更回数が閾値以下か判定する。ここで、収容先変更回数が閾値以下の場合、ＣＰコンテナＣＰ１は該当するＩＰ電話端末ＩＰＴ１を収容先変更対象として、同ＩＰ電話端末ＩＰＴ１の内線番号の収容先を他ノードの例えばＣＰコンテナＣＰ３とみなし、ＣＰコンテナＣＰ３向けの収容先変更台数を加算する。
【００５２】
一方、収容先変更回数が閾値を超える場合、ＣＰコンテナＣＰ１はトラフィック情報テーブル３１０中の該当する内線番号の収容先変更回数を「０」に初期化する。
【００５３】
ＣＰコンテナＣＰ１は、収容する全ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎに関してトラフィック情報テーブル３１０のデータ確認が完了すると、収容先変更先となる他ノードのＣＰコンテナＣＰ３に対する端末収容先変更確認要求メッセージを生成し、送信する。
【００５４】
一方、ＣＰコンテナＣＰ１は、他ノードの例えばＣＰコンテナＣＰ２からの端末収容先変更確認応答メッセージを受信すると、同メッセージに設定された収容可能台数とＣＰコンテナＣＰ２への収容先変更台数を比較する。
【００５５】
ここで、ＣＰコンテナＣＰ２の収容可能台数がＣＰコンテナＣＰ２への収容先変更台数より多い場合、ＣＰコンテナＣＰ１は収容先変更対象の全ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎに対して収容先変更要求（収容先：ＣＰコンテナ２）を送信する。
【００５６】
一方、ＣＰコンテナＣＰ２の収容可能台数がＣＰコンテナＣＰ２への収容先変更台数より少ない場合、ＣＰコンテナＣＰ１は収容先情報テーブル３２０から収容先変更対象の全ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎの収容先変更優先度データを取得し、優先度が高い順にＣＰコンテナＣＰ２の収容可能台数分だけ抽出した上で、例えばＩＰ電話端末ＩＰＴ１〜ＩＰＴ９に対して収容先変更要求（収容先：ＣＰコンテナＣＰ２）を送信する。
【００５７】
以上のように上記第１の実施形態によれば、各ユーザサイトＵＳ１〜ＵＳｍに配置される一般のアプライアンス型ＩＰ電話サーバの機能を分割して、クラウド上のデータセンタＤＣ１内の仮想化ホストサーバＮ１〜Ｎｐに割り当てるシステムであって、仮想化ホストサーバＮ１のＣＰコンテナＣＰ１に収容されるＩＰ電話端末ＩＰＴ１とＣＰコンテナＣＰ２に収容されるＩＰ電話端末間の呼接続が確立され、終話するごとに、トラフィック情報テーブル３１０中のＩＰ電話端末ＩＰＴ１の内線番号に対応する通話回数をインクリメントしておき、例えばＩＰ電話端末ＩＰＴ１の通話回数がしきい値を超えている場合に、ＩＰ電話端末ＩＰＴ１の収容先変更に先立ち、収容先の例えばＣＰコンテナＣＰ２に対して収容可能端末数を問い合わせ、ＣＰコンテナＣＰ２が収容可能と判断した場合に、ＩＰ電話端末ＩＰＴ１の収容先をＣＰコンテナＣＰ１からＣＰコンテナＣＰ２に変更するようにしている。
【００５８】
従って、特定のＣＰコンテナへの収容が集中することを回避することができる。
【００５９】
また、上記第１の実施形態によれば、ＩＰ電話端末ＩＰＴ１の収容先のＣＰコンテナＣＰ１を変更する判定条件として、通話回数だけでなく、各内線単位の収容期間や収容先変更回数を判定条件に追加することで、例えば特定のＣＰコンテナＣＰ３との間の収容先変更が頻繁に行われたり、ＣＰコンテナ間の収容先変更がループ状態になり繰り返し行われることを回避することができる。
【００６０】
さらに、上記第１の実施形態によれば、ＣＰコンテナＣＰ１において、収容先変更を必要とするＩＰ電話端末ＩＰＴ１〜ＩＰＴ９の台数が、変更先となるＣＰコンテナＣＰ２の収容可能台数以上存在したとしても、優先度に従って比較的柔軟に収容変更を行うことができる。
【００６１】
（第２の実施形態）  
第２の実施形態は、通信ネットワーク上に呼制御サーバを分散配置し、各呼制御サーバごとにＩＰ電話端末の通話回数をカウントし、収容先変更対象となったＩＰ電話端末の収容先を変更するようにしたものである。
【００６２】
図５は、本第２の実施形態に係るＩＰ電話システムの概略構成図である。
【００６３】
このシステムは、通信ネットワークとして例えばＬＡＮ（Local Area Network）といったプライベート網ＰＮＷ１を有する。プライベート網ＰＮＷ１には、複数の呼制御サーバＳＶ１〜ＳＶｎ（ｎは自然数）が接続されている。また、呼制御サーバＳＶ１〜ＳＶｎには、ＩＰ電話端末Ｔ１１〜Ｔ１ｉ（ｉは自然数），Ｔ２１〜Ｔ２ｍ（ｍは自然数），Ｔ３１〜Ｔ３ｐ（ｐは自然数），Ｔｎ１〜Ｔｎｋ（ｋは自然数）が登録されている。なお、ＩＰ電話端末Ｔ１１〜Ｔ１ｉ，Ｔ２１〜Ｔ２ｍ，Ｔ３１〜Ｔ３ｐ，Ｔｎ１〜Ｔｎｋは、通話処理機能と映像等のメディア情報処理機能とを備えている。
【００６４】
また、呼制御サーバＳＶ１には、ゲートウェイＧＷ１が登録される。ゲートウェイＧＷ１は、公衆網ＮＷ１とプライベート網ＰＮＷ１との間を接続するもので、公衆網ＮＷ１とＩＰ網１との間における通信プロトコル及び信号フォーマットの変換機能を備えている。
【００６５】
また、呼制御サーバＳＶｎには、ゲートウェイＧＷ２が接続される。ゲートウェイＧＷ２は、公衆網ＮＷ２とＩＰ網１との間を接続するもので、公衆網ＮＷ２とプライベート網ＰＮＷ１との間における通信プロトコル及び信号フォーマットの変換機能を備えている。
【００６６】
呼制御サーバＳＶ１〜ＳＶｎは、複数のＩＰ電話端末Ｔ１１〜Ｔ１ｉ，Ｔ２１〜Ｔ２ｍ，Ｔ３１〜Ｔ３ｐ，Ｔｎ１〜Ｔｎｋ間または呼制御サーバＳＶ１〜ＳＶｎ間またはＩＰ電話端末Ｔ１１〜Ｔ１ｉ，Ｔ２１〜Ｔ２ｍ，Ｔ３１〜Ｔ３ｐ，Ｔｎ１〜Ｔｎｋと公衆網ＮＷ１，ＮＷ２との間で、例えばＳＩＰに従ってセッションを確立する交換制御機能を備える。そして、セッション確立後は、発信側と着信側の電話端末間でピアツーピア接続でＲＴＰパケットを送受信することで、音声通信を行なう。
【００６７】
図６は、上記呼制御サーバＳＶ１〜ＳＶｎの構成を示すブロック図である。ここでは、呼制御サーバＳＶ１を代表して説明する。
【００６８】
呼制御サーバＳＶ１は、制御部２１、ノースブリッジ２２、主メモリ２３、サウスブリッジ２６、ＨＤＤ（Hard Disk Drive）２７、マルチドライブ２８、ＬＡＮコントローラ２９、インタフェース部３０、ＰＣカードコントローラ３１、ＢＩＯＳ−ＲＯＭ（Basic Input/Output System ROM）３３、ＥＣ／ＫＢＣ（Embedded Controller/Keyboard Controller）３４、電源コントローラ（ＰＳＣ）３５、電源部３６、インタフェース（Ｉ／Ｆ）３８、Ｉ／Ｏコントローラ４０などを備える。
【００６９】
制御部２１は、（ＣＰＵ：Central Processing Unit）を主体として呼制御サーバＳＶ１全体の制御を司るものであり、主メモリ２３をワークエリアとして使用し、ＨＤＤ２７から主メモリ２３にロードされる、オペレーティングシステム（ＯＳ）２３ａ、ドライバ２３ｂ、交換プログラム２３ｃなどを実行する。  
ノースブリッジ２２は、制御部２１とサウスブリッジ２６との間のブリッジ処理、主メモリ２３の制御などを行う各種コントローラを備えている。  
サウスブリッジ２６は、ハブリンクを介してノースブリッジ２２に接続されており、ＬＰＣ（Low Pin Count）バス上の各種デバイス（ＥＣ／ＫＢＣ３４、Ｉ／Ｏコントローラなど）や、ＰＣＩ（Peripheral Component Interconnect）バス上の各種ＰＣＩデバイス（ＬＡＮコントローラ２９、インタフェース部３０、ＰＣカードコントローラ３１など）や、ＩＤＥ（Integrated Drive Electronics）対応のディスクドライブや、ＵＳＢデバイスなどの制御を行う各種コントローラを備える。
【００７０】
ＨＤＤ２７は、プライマリＩＤＥに対応するデバイスとしてサウスブリッジ２６に接続されており、ＯＳや交換プログラム等の各種プログラム、各種データ２３ｄなどを記憶する内蔵のハードディスクである。マルチドライブ２８は、セカンダリＩＤＥに対応するデバイスとしてサウスブリッジ２６に接続されており、リムーバブルな記録媒体であるＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＣＤ−Ｒ／ＲＷを駆動する。
【００７１】
ＬＡＮコントローラ２９は、ＰＣＩデバイスとしてサウスブリッジ２６に接続されており、有線ＬＡＮの仕様に準拠する通信機能を備え、同じ通信機能を備えた通信装置との間で通信を行うものである。  
インタフェース部３０は、ＰＣＩデバイスとしてサウスブリッジ２６に接続されており、ＩＰ網１の仕様に準拠する通信機能を備え、ＩＰパケットの授受に係わる処理を行う。  
ＰＣカードコントローラ３１は、ＰＣＩデバイスとしてサウスブリッジ２６に接続されており、ＰＣＭＣＩＡ(Personal Computer Memory Card International Association)の仕様に準拠し、各種のＰＣカードを制御するものである。ＢＩＯＳ−ＲＯＭ３３は、ＬＰＣバスに接続されており、電源が投入された際に主にマスタサーバＳＶ１内のハードウェアに対する設定処理などを行うＢＩＯＳ（Basic Input/Output System）を格納している。ＥＣ／ＫＢＣ３４は、ＬＰＣバスに接続されており、電源コントローラ３５の制御などを行う。このＥＣ／ＫＢＣ３４は、組み込みコントローラであるＥＣ（Embedded Controller）とキーボードコントローラとを一体化したものである。
【００７２】
電源コントローラ３５は、Ｉ2Ｃバスを介してＥＣ／ＫＢＣ３４に接続されており、呼制御サーバＳＶ１内の各部に供給する電圧を制御する。電源部３６は駆動電力を生成し、呼制御サーバＳＶ１内の各部に供給する。インタフェース３８は、入力装置等が接続可能で、ＥＣ／ＫＢＣ３４との間の信号のインタフェースを行うものである。Ｉ／Ｏコントローラ４０は、ＬＰＣバスに接続されており、外部とシリアル信号やパラレル信号の入出力制御を行う。
【００７３】
この呼制御サーバＳＶ１においては、制御部２１の制御のもとで、主メモリ２３上に展開した交換プログラム２３ｃがＬＡＮコントローラ２９などと協働して所定の交換処理機能を実現する。呼制御サーバＳＶ１は汎用のコンピュータサーバに交換プログラム２３ｃをロードし、このプログラムを実行させることで電話端末間の交換機能を実現する。呼制御サーバＳＶ１は、汎用コンピュータと同様に、データが記憶された領域が物理的には不連続なメモリ領域であっても、ソフトウェア（プロセスなど）から見て連続になるように見せかける仮想記憶システムを採用する。
【００７４】
ところで、ＨＤＤ２７には、トラフィック情報テーブル２７１と、収容先情報テーブル２７２とが設けられている。
【００７５】
トラフィック情報テーブル２７１は、各ＩＰ電話端末Ｔ１１〜Ｔ１ｉの通話回数を管理するためのテーブルである。トラフィック情報テーブル２７１には、図７に示すように、各ＩＰ電話端末Ｔ１１〜Ｔ１ｉの内線番号と、自ノード（内線間）内の通話回数と、他ノード（呼制御サーバＳＶ２〜ＳＶｎ）との通話回数との対応関係を表すデータが記憶されている。
【００７６】
収容先情報テーブル２７２は、収容先変更対象となるＩＰ電話端末Ｔ１１〜Ｔ１ｉの収容先変更条件を管理するためのテーブルである。収容先情報テーブル２７２には、図８に示すように、各ＩＰ電話端末Ｔ１１〜Ｔ１ｉの内線番号と、収容先変更優先度と、収容開始日時と、収容先変更回数との対応関係を表すデータが記憶されている。
【００７７】
また、制御部２１は、ＩＰ電話制御部２１ａと、呼制御部２１ｂと、ＩＰ専用線制御部２１ｃと、ＩＰトランク制御部２１ｄと、トラフィック制御部２１ｅと、収容先変更判定部２１ｆと、収容先制御部２１ｇとを備えている。
【００７８】
ＩＰ電話制御部２１ａは、各ＩＰ電話端末Ｔ１１〜Ｔ１ｉに対する発着信処理やデジタル信号の転送処理等を行なう。呼制御部２１ｂは、ＩＰ電話制御部２１ａと、ＩＰ専用線制御部２１ｃと、ＩＰトランク制御部２１ｄとの間で通話を行うための呼接続を行う。
【００７９】
ＩＰ専用線制御部２１ｃは、プライベート網ＰＮＷ１との間の呼の確立処理等を行う。ＩＰトランク制御部２１ｄは、ゲートウェイＧＷ１もしくはインターネットとの間の呼の確立処理等を行う。
【００８０】
トラフィック制御部２１ｅは、上記呼制御部２１ｂにより例えばＩＰ電話端末Ｔ１１の終話が検出されるごとに、トラフィック情報テーブル２７１中の自ノード通話回数もしくは他ノード通話回数をインクリメントする。
【００８１】
収容先変更判定部２１ｆは、トラフィック情報テーブル２７１の記憶内容に基づいて、例えばＩＰ電話端末Ｔ１１の他ノードとの通話回数がしきい値を超えているか否かを判定する。
【００８２】
収容先制御部２１ｇは、上記収容先変更判定部２１ｆによる判定結果から、例えばＩＰ電話端末Ｔ１１の他ノードとの通話回数がしきい値（例えば１００回）を超えている場合に、収容先情報テーブル２７２を参照して、ＩＰ電話端末Ｔ１１の呼制御サーバＳＶ１への収容期間がしきい値（例えば１週間）を超え、収容先変更回数がしきい値（２回）以下の場合に、ＩＰ電話端末Ｔ１１の収容先を呼制御サーバＳＶ１から他のノードに変更するべく、収容変更先に対し収容変更の旨のメッセージを送信する。この時、例えば呼制御サーバＳＶ２に対し収容可能端末数を問い合わせ、この問い合わせに対し呼制御サーバＳＶ２と判断した場合に、ＩＰ電話端末Ｔ１１の収容先を呼制御サーバＳＶ１から呼制御サーバＳＶ２に変更する。
【００８３】
また、収容先制御部２１ｇは、収容先変更を必要とするＩＰ電話端末Ｔ１１〜Ｔ１ｉの台数が、変更先となる呼制御サーバＳＶ２の収容可能台数以上存在した場合に、収容先情報テーブル２７２を参照して、変更対象となるＩＰ電話端末Ｔ１１〜Ｔ１ｉに割り当てられた優先度が高い順に収容先変更を行う。
【００８４】
次に上記構成における動作について説明する。  
（ＩＰ電話端末Ｔ１１と自ノードＩＰトランクとの通話動作）  
ここで、上記ＩＰ電話端末Ｔ１１と公衆網ＮＷ１上の外部端末との間で通信リンクを形成する動作について説明する。
【００８５】
呼制御サーバＳＶ１に収容されたＩＰ電話端末Ｔ１１にて公衆網ＮＷ１上の外部端末への発信操作が行われたとする。そうすると、ＩＰ電話端末Ｔ１１は、呼制御サーバＳＶ１へ発信要求（例えばＳＩＰではＩＮＶＩＴＥメッセージ）を送信する。呼制御サーバＳＶ１は、上記発信要求を受信すると、ゲートウェイＧＷ１経由で公衆網ＮＷ１上の外部端末に対しＩＮＶＩＴＥメッセージを送信して呼び出しを行う。
【００８６】
この呼び出しに対し外部端末Ｔ１２のユーザが応答操作を行うと、ゲートウェイＧＷ１は応答メッセージ（２００ＯＫ）を呼制御サーバＳＶ１へ送信する。呼制御サーバＳＶ１は応答メッセージをＩＰ電話端末Ｔ１１に送信し、ＩＰ電話端末Ｔ１１と公衆網ＮＷ１上の外部端末との間で通信リンクを形成する。
【００８７】
図９は、上記ＩＰ電話端末Ｔ１１と公衆網ＮＷ１上の外部端末との通話状態から終話操作をした時の信号シーケンスの例である。
【００８８】
図９において、ＩＰ電話端末Ｔ１１のユーザが自ノードＩＰトランクとなる公衆網ＮＷ１上の外部端末との通話中に終話操作を行うと、ＩＰ電話端末Ｔ１１は、呼制御サーバＳＶ１へ切断要求（例えばＳＩＰのＣＯＮＮメッセージ）を送信する（図９（１））。すると、呼制御サーバＳＶ１内のＩＰ電話制御部２１ａは、切断要求を呼制御部２１ｂに送信する（図９（２））。呼制御部２１ｂは、ＩＰトランク制御部２１ｄに対し復旧指示を送信する（図９（３））。ＩＰトランク制御部２１ｄは、ゲートウェイＧＷ１経由で公衆網ＮＷ１上の外部端末へＢＹＥメッセージを送信し（図９（４））、ゲートウェイＧＷ１から応答メッセージ（２００ＯＫ）が返送された時点で（図９（５））、上記ＩＰ電話端末Ｔ１１と公衆網ＮＷ１上の外部端末との通信リンクを切断する。
【００８９】
一方、呼制御部２１ｂは、トラフィック制御部２１ｅに対してトラフィック制御指示メッセージを送信する（図９（６））。トラフィック制御指示メッセージにはＩＰ電話端末Ｔ１１の内線番号1000と、通話相手情報として自ノードを設定する。同メッセージを受信したトラフィック制御部２１ｅは、トラフィック情報テーブル２７１の内線番号1000に対応する自ノード通話回数を加算する（図９（７））。
【００９０】
（ＩＰ電話端末Ｔ１１とＩＰ電話端末Ｔ２１との通話動作）  
呼制御サーバＳＶ１に収容されたＩＰ電話端末Ｔ１１にて呼制御サーバＳＶ２に収容されるＩＰ電話端末Ｔ２１への発信操作が行われたとする。そうすると、ＩＰ電話端末Ｔ１１は、呼制御サーバＳＶ１へ発信要求（ＩＮＶＩＴＥメッセージ）を送信する。
【００９１】
呼制御サーバＳＶ１は、上記発信要求を受信すると、ＩＰ−ＱＳＩＧで規定されるＳＥＴＵＰメッセージを生成する。呼制御サーバＳＶ１は、ＳＥＴＵＰメッセージをプライベート網ＰＮＷ１を介して呼制御サーバＳＶ２へ送信する。
【００９２】
呼制御サーバＳＶ２は、ＳＥＴＵＰメッセージを受信すると、着信先のＩＰ電話端末Ｔ２１に対しＩＮＶＩＴＥメッセージを送信して呼び出しを行なう。ＩＰ電話端末Ｔ２１は、ＩＮＶＩＴＥメッセージを受信後、着信報知が行われている旨を示す１００Trying及び１８０Ringingを呼制御サーバＳＶ２へ返送する。この着信報知は、鳴音の発生または着信表示により行なわれる。
【００９３】
呼制御サーバＳＶ２は、ＩＰ電話端末Ｔ２１から１００Trying及び１８０Ringingを受信すると、呼制御サーバＳＶ１に対しＳＥＴＵＰメッセージを正しく受信した旨を示すメッセージ（ＣＡＬＬ  ＰＲＯＣ，ＡＬＥＲＴ）を送信する。
【００９４】
呼制御サーバＳＶ１は、呼制御サーバＳＶ２からＣＡＬＬ  ＰＲＯＣメッセージ及びＡＬＥＲＴメッセージを受信すると、発信元のＩＰ電話端末Ｔ１１に対し１００Trying及び１８０Ringingを送信して、ＩＰ電話端末Ｔ２１に対し着信報知が行われている旨を通知する。
【００９５】
上記着信報知に対しＩＰ電話端末Ｔ２１のユーザが応答操作を行なうと、ＩＰ電話端末Ｔ２１は応答メッセージ（２００ＯＫ）を呼制御サーバＳＶ２へ送信する。
【００９６】
呼制御サーバＳＶ２は、受信した応答メッセージ（２００ＯＫ）より、ＩＰ電話端末Ｔ２１を呼制御サーバＳＶ２に接続した旨を示す情報を応答メッセージ（ＣＯＮＮ）に乗せて呼制御サーバＳＶ１に通知する。
【００９７】
呼制御サーバＳＶ１は、ＣＯＮＮメッセージ受信後、２００ＯＫメッセージを発信元のＩＰ電話端末Ｔ１１へ送信する。すると、ＩＰ電話端末Ｔ１１は、呼制御サーバＳＶ１に対しＡＣＫを返送する。
【００９８】
呼制御サーバＳＶ１は、ＩＰ電話端末Ｔ１１からＡＣＫを受信すると、呼制御サーバＳＶ２に対しＣＯＮＮ  ＡＣＫを送信する。そして、呼制御サーバＳＶ２は、ＩＰ電話端末Ｔ２１に対しＡＣＫを送信する。かくして、発信元のＩＰ電話端末Ｔ１１と着信先のＩＰ電話端末Ｔ２１との間には呼制御サーバＳＶ１，ＳＶ２を経由した通信リンクが形成され、以後ＲＴＰパケットの送受信が行われ、通話が可能となる。
【００９９】
図１０は、上記ＩＰ電話端末Ｔ１１とＩＰ電話端末Ｔ２１との通話状態から終話操作をした時の信号シーケンスの例である。
【０１００】
図１０において、ＩＰ電話端末Ｔ１１のユーザがＩＰ電話端末Ｔ２１との通話中に終話操作を行うと、ＩＰ電話端末Ｔ１１は、呼制御サーバＳＶ１へ切断要求（例えばＳＩＰのＣＯＮＮメッセージ）を送信する（図１０（１））。すると、呼制御サーバＳＶ１内のＩＰ電話制御部２１ａは、切断要求を呼制御部２１ｂに送信する（図１０（２））。呼制御部２１ｂは、ＩＰ専用線制御部２１ｃに対し復旧指示を送信する（図１０（３））。ＩＰ専用線制御部２１ｃは、プライベート網ＰＮＷ１経由で呼制御サーバＳＶ２のＩＰ電話端末Ｔ２１へＢＹＥメッセージを送信し（図１０（４））、呼制御サーバＳＶ２から応答メッセージ（２００ＯＫ）が返送された時点で（図１０（５））、上記ＩＰ電話端末Ｔ１１とＩＰ電話端末Ｔ２１との通信リンクを切断する。
【０１０１】
一方、呼制御部２１ｂは、トラフィック制御部２１ｅに対してトラフィック制御指示メッセージを送信する（図１０（６））。トラフィック制御指示メッセージにはＩＰ電話端末Ｔ１１の内線番号1000と、通話相手情報として他ノード(呼制御サーバＳＶ２)を設定する。同メッセージを受信したトラフィック制御部２１ｅは、トラフィック情報テーブル２７１の内線番号1000に対応する他ノード通話回数を加算する（図１０（７））。
【０１０２】
（ＩＰ電話端末Ｔ１１〜Ｔ１ｉの収容先変更動作）  
図１１は、呼制御サーバＳＶ１に収容されたＩＰ電話端末Ｔ１１〜Ｔ１ｉの収容先変更が発生した時の信号シーケンスの例である。
【０１０３】
呼制御サーバＳＶ１は、現在時刻が予め設定した端末収容先変更確認日時と一致して、呼制御サーバＳＶ２に対し、収容可能台数を問い合わせるために端末収容先変更確認要求を送信する（図１１（１））。そうすると呼制御サーバＳＶ１は、端末収容先変更確認要求に対する応答を受信し（図１１（２））、応答に含まれる収容可能台数「Ｘ」を取り出し、ＨＤＤ２７に登録する。続いて、呼制御サーバＳＶ１は、呼制御サーバＳＶ３〜ＳＶｎに対し順次端末収容先変更確認要求を送信する（図１１（３））。そして、呼制御サーバＳＶ１は、端末収容先変更確認要求に対する応答を受信し（図１１（４））、応答に含まれる収容可能台数「Ｙ」を取り出し、ＨＤＤ２７に登録する。
【０１０４】
続いて、呼制御サーバＳＶ１は、収容先変更対象となるＩＰ電話端末Ｔ１１に対し収容先を呼制御サーバＳＶ２に指定した収容先変更要求を通知する（図１１（５））。ＩＰ電話端末Ｔ１１は、呼制御サーバＳＶ１からの収容先変更要求の通知に対し、ＩＰ電話端末Ｔ１１の内線番号（１０００）、収容先変更優先度、収容先変更回数を含む登録要求を呼制御サーバＳＶ２へ送信する（図１１（６））。
【０１０５】
呼制御サーバＳＶ２は、ＩＰ電話端末Ｔ１１からの登録要求を受信すると、登録要求に含まれるＩＰ電話端末Ｔ１１の内線番号（１０００）、収容先変更優先度、収容先変更回数を収容開始日時とともに、収容先情報テーブル２７２に登録し、ＩＰ電話端末Ｔ１１の内線番号（１０００）と、通話回数「０」とをトラフィック情報テーブル２７１に登録する（図１１（７））。
【０１０６】
呼制御サーバＳＶ２は、ＩＰ電話端末Ｔ１１の登録が完了すると、結果「ＯＫ」を含む登録応答がＩＰ電話端末Ｔ１１へ返送される（図１１（８））。ＩＰ電話端末Ｔ１１は、呼制御サーバＳＶ２から登録応答を受信すると、呼制御サーバＳＶ１に対し収容先変更完了のメッセージを送信する（図１１（９））。かくして、呼制御サーバＳＶ１は、ＩＰ電話端末Ｔ１１から収容先変更完了のメッセージを受信すると、トラフィック情報テーブル２７１から内線番号「１０００」のデータを削除し、トラフィック情報テーブル２７１から内線番号「１０００」のデータを削除する（図１１（１０））。
【０１０７】
一方、呼制御サーバＳＶ１は、収容先変更対象となるＩＰ電話端末Ｔ１ｉに対し収容先を呼制御サーバＳＶｎに指定した収容先変更要求を通知する（図１１（１１））。ＩＰ電話端末Ｔ１ｉは、呼制御サーバＳＶ１からの収容先変更要求の通知に対し、ＩＰ電話端末Ｔ１ｉの内線番号、収容先変更優先度、収容先変更回数を含む登録要求を呼制御サーバＳＶｎへ送信する（図１１（１２））。
【０１０８】
呼制御サーバＳＶｎは、ＩＰ電話端末Ｔ１ｉからの登録要求を受信すると、登録要求に含まれるＩＰ電話端末Ｔ１ｉの内線番号、収容先変更優先度、収容先変更回数を収容開始日時とともに、収容先情報テーブル２７２に登録し、ＩＰ電話端末Ｔ１ｉの内線番号と、通話回数「０」とをトラフィック情報テーブル２７１に登録する（図１１（１３））。
【０１０９】
呼制御サーバＳＶｎは、ＩＰ電話端末Ｔ１ｉの登録が完了すると、結果「ＯＫ」を含む登録応答がＩＰ電話端末Ｔ１１へ返送する（図１１（１４））。ＩＰ電話端末Ｔ１ｉは、呼制御サーバＳＶｎから登録応答を受信すると、呼制御サーバＳＶ１に対し収容先変更完了のメッセージを送信する（図１１（１５））。かくして、呼制御サーバＳＶ１は、ＩＰ電話端末Ｔ１ｉから収容先変更完了のメッセージを受信すると、トラフィック情報テーブル２７１から該当する内線番号のデータを削除し、トラフィック情報テーブル２７１から該当する内線番号のデータを削除する（図１１（１６））。
【０１１０】
図１２は、端末収容先変更確認要求を送信する際の制御部２１の制御処理手順を示すフローチャートである。
【０１１１】
まず、制御部２１は、収容先制御部２１ｇで図示しないタイマにより計時される現在時刻を定期的に確認し端末収容先変更確認日時と一致したことを確認すると（ステップＳＴ８ａ）、トラフィック制御部２１ｅから例えばＩＰ電話端末Ｔ１１のトラフィック情報テーブル２７１のデータを取得する（ステップＳＴ８ｂ）。
【０１１２】
そして、制御部２１は、取得したデータから、現在の収容先以外の他ノードとの通話回数が閾値以上の値が存在するか判定する（ステップＳＴ８ｃ）。ここで、閾値以上の値が存在した場合（Ｙｅｓ）、制御部２１は、収容先制御部２１ｇにより該当するＩＰ電話端末の収容先情報テーブル２７２のデータを取得し、取得したデータから、現在のノードの収容日数が閾値以上経過しているか判定する（ステップＳＴ８ｄ）。
【０１１３】
ここで、収容日数が閾値以上の場合（Ｙｅｓ）、制御部２１は収容先変更回数が閾値以下か判定する（ステップＳＴ８ｅ）。ここで、収容先変更回数が閾値以下の場合（Ｙｅｓ）、制御部２１は該当するＩＰ電話端末Ｔ１１を収容先変更対象として、同ＩＰ電話端末Ｔ１１の内線番号「１０００」の収容先を他ノードの呼制御サーバＳＶｎとみなし、呼制御サーバＳＶｎ向けの収容先変更台数を加算する（ステップＳＴ８ｆ）。
【０１１４】
一方、上記ステップＳＴ８ｅにおいて、収容先変更回数が閾値を超える場合（Ｎｏ）、制御部２１はトラフィック情報テーブル２７２中の該当する内線番号「１０００」の収容先変更回数を「０」に初期化する（ステップＳＴ８ｇ）。
【０１１５】
制御部２１は、収容する全ＩＰ電話端末Ｔ１１〜Ｔ１ｉに関してトラフィック情報テーブル２７２のデータ確認が完了すると、ステップＳＴ８ｈからステップＳＴ８ｉに移行して収容先制御部２１ｇにより収容先変更先となる他ノードの呼制御サーバＳＶ３に対する端末収容先変更確認要求メッセージを生成し、ＩＰ専用線制御部２１ｃに対して同メッセージの送信を要求する（ステップＳＴ８ｊ）。
【０１１６】
そして、制御部２１は、他ノードの全呼制御サーバＳＶ２〜ＳＶｎに対する収容先変更内線有無を確認したか否かを判断し（ステップＳＴ８ｋ）、全呼制御サーバＳＶ２〜ＳＶｎに対する確認が完了するまでステップＳＴ８ｉ乃至ステップＳＴ８ｋの処理を繰り返し実行する。
【０１１７】
図１３は、例えばＩＰ電話端末Ｔ１１から収容先変更完了を受信するまでの制御部２１の制御処理手順を示すフローチャートである。
【０１１８】
制御部２１は、ＩＰ専用線制御部２１ｃで他ノードの例えば呼制御サーバＳＶ２からの端末収容先変更確認応答メッセージを受信すると（ステップＳＴ９ａ）、収容先制御部２１ｇにおいて同メッセージに設定された収容可能台数と呼制御サーバＳＶ２への収容先変更台数を比較する（ステップＳＴ９ｂ）。
【０１１９】
ここで、呼制御サーバＳＶ２の収容可能台数が呼制御サーバＳＶ２への収容先変更台数より多い場合（Ｎｏ）、制御部２１は収容先変更対象の全ＩＰ電話端末Ｔ１１〜Ｔ１ｉに対して収容先変更要求（収容先：呼制御サーバＳＶｎ）を送信する（ステップＳＴ９ｃ）。
【０１２０】
一方、呼制御サーバＳＶ２の収容可能台数が呼制御サーバＳＶ２への収容先変更台数より少ない場合（Ｙｅｓ）、制御部２１は収容先情報テーブル２７２から収容先変更対象の全ＩＰ電話端末Ｔ１１〜Ｔ１ｉの収容先変更優先度データを取得し、優先度が高い順に呼制御サーバＳＶ２の収容可能台数分だけ抽出した上で（ステップＳＴ９ｄ）、例えばＩＰ電話端末Ｔ１１〜Ｔ１９に対して収容先変更要求（収容先：呼制御サーバＳＶ２）を送信する。
【０１２１】
以後、制御部２１は、他ノードへの収容先変更が必要な全ＩＰ電話端末Ｔ１１〜Ｔ１ｉに対して収容先変更処理を完了したか否かを判断し（ステップＳＴ９ｅ）、完了するまでステップＳＴ９ｂ乃至ステップＳＴ９ｅの処理を繰り返し実行する。
【０１２２】
以上のように上記第２の実施形態では、呼制御サーバＳＶ１において、呼制御サーバＳＶ１に収容されるＩＰ電話端末Ｔ１１と呼制御サーバＳＶ２に収容されるＩＰ電話端末Ｔ２１間の呼接続が確立され、終話するごとに、トラフィック情報テーブル２７１中のＩＰ電話端末Ｔ１１の内線番号「１０００」に対応する通話回数をインクリメントしておき、例えばＩＰ電話端末Ｔ１１の通話回数がしきい値を超えている場合に、ＩＰ電話端末Ｔ１１の収容先変更に先立ち、収容先の例えば呼制御サーバＳＶ２に対して収容可能端末数を問い合わせ、呼制御サーバＳＶ２が収容可能と判断した場合に、ＩＰ電話端末Ｔ１１の収容先を呼制御サーバＳＶ１から呼制御サーバＳＶ２に変更するようにしている。
【０１２３】
従って、特定のサーバ装置への収容が集中することを回避することができる。
【０１２４】
また、上記第２の実施形態によれば、ＩＰ電話端末Ｔ１１の収容先の呼制御サーバＳＶ１を変更する判定条件として、通話回数だけでなく、各内線単位の収容期間や収容先変更回数を判定条件に追加することで、例えば特定の呼制御サーバＳＶ３との間の収容先変更が頻繁に行われたり、呼制御サーバＳＶ１〜ＳＶｎ間の収容先変更がループ状態になり繰り返し行われることを回避することができる。
【０１２５】
さらに、上記第２の実施形態によれば、呼制御サーバＳＶ１において、収容先変更を必要とするＩＰ電話端末Ｔ１１〜Ｔ１９の台数が、変更先となる呼制御サーバＳＶ２の収容可能台数以上存在したとしても、優先度に従って比較的柔軟に収容変更を行うことができる。
【０１２６】
（その他の実施形態）  
本第１及び第２の実施形態では、収容先制御部がＩＰ専用線制御部を介して他ノードの呼制御サーバに端末収容先変更確認要求メッセージを送信する前に、収容先変更対象のＩＰ電話端末の現在の収容日数や収容先変更回数を確認しているが、他ノードの呼制御サーバからの端末収容先変更確認応答メッセージを受信して、他ノードの呼制御サーバの収容可能台数を取得し、収容先変更対象のＩＰ電話端末の現在の収容日数や収容先変更回数を確認した上で、実際に収容先変更を行うか判断してもよい。
【０１２７】
また、上記各実施形態では、収容先変更を実行する条件として、収容期間、収容変更回数を用いる例について説明したが、他の条件を用いるようにしてもよい。また、通話回数の閾値、収容期間の閾値、収容変更回数の閾値は、保守者によって可変設定されるものでもよい。
【０１２８】
さらに、上記第２の実施形態では、呼制御プロトコルにＳＩＰやＩＰ−ＱＳＩＧを用いる例について説明したが、Ｍｅｇａｃｏを用いるようにしてもよい。
【０１２９】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１３０】
１,２…ＬＡＮ、２１…制御部、２２…ノースブリッジ、２３…主メモリ、２４…ビデオコントローラ、２５…表示部、２６…サウスブリッジ、２７…ＨＤＤ（Hard Disk Drive）、２８…マルチドライブ、２９…ＬＡＮコントローラ、３０…インタフェース部、３１…ＰＣカードコントローラ、３３…ＢＩＯＳ−ＲＯＭ（Basic Input/Output System ROM）、２１ａ…ＩＰ電話制御部、２１ｂ…呼制御部、２１ｃ…ＩＰ専用線制御部、２１ｄ…ＩＰトランク制御部、２１ｅ…トラフィック制御部、２１ｆ，３４０…収容先変更判定部、２１ｇ，３５０…収容先制御部、２７１，３１０…トラフィック情報テーブル、２７２，３２０…収容先情報テーブル、３３０…テーブル更新部、ＤＣ１〜ＤＣｉ…データセンタ、ＭＳ…メーカサイト、ＵＳ１〜ＵＳｍ…ユーザサイト、ＩＰＴ１〜ＩＰＴｎ…ＩＰ電話端末、ＩＮＷ…インターネット、Ｎ１〜Ｎｐ…仮想化ホストサーバ、ＣＳＶ１…電話会議サーバ、ＣＳＶ２…ウェブ会議サーバ、ＣＳＶ３…運用支援サーバ、ＣＳＶ４…課金管理サーバ、ＣＳＶ５…プロビジョニングサーバ、ＤＢ…ユーザデータベース、ＣＰ１〜ＣＰ１２…ＣＰコンテナ、Ａｄｍｉｎ１〜Ａｄｍｉｎ３…Ａｄｍｉｎコンテナ、ＴＣ１…電話会議コンテナ、ＷＣ１…ウェブ会議コンテナ、ＰＮＷ１…プライベート網、Ｔ１１〜Ｔ１ｉ，Ｔ２１〜Ｔ２ｍ，Ｔｎ１〜Ｔｎｋ…ＩＰ電話端末、ＳＶ１〜ＳＶｎ…呼制御サーバ、ＮＷ１，ＮＷ２…公衆網、ＧＷ１，ＧＷ２…ゲートウェイ。
【図１】
2013232812.tif 000003
【図２】
2013232812.tif 000004
【図３】
2013232812.tif 000005
【図４】
2013232812.tif 000006
【図５】
2013232812.tif 000007
【図６】
2013232812.tif 000008
【図７】
2013232812.tif 000009
【図８】
2013232812.tif 000010
【図９】
2013232812.tif 000011
【図１０】
2013232812.tif 000012
【図１１】
2013232812.tif 000013
【図１２】
2013232812.tif 000014
【図１３】
2013232812.tif 000015