(57)【要約】【課題】  従来の電話交換システムにおいては、交換装置のライン回路への給電をカットすることで、輻輳時の発信規制を行っていたが、ネットワークがＩＰ化した現在ではその手法を使用することができず、電話機に対する発信規制を行うことができない。【解決手段】交換装置の交換制御部が輻輳状態に陥った場合に、その輻輳状態を示す情報をＬＡＮ上に接続されたＩＰ電話機に対して送出し、その情報を受信したＩＰ電話機側で発信規制を行うような動作を行わせる。その際に、各ＩＰ電話機に優先度を設けて発信規制することで効果的な運用がはかれる。【選択図】図４
2007124511.tif 000002
【特許請求の範囲】
【請求項１】
電話機をパケット網を介して収容する交換装置において、
前記電話機の呼制御情報を受信し、所望の相手に交換接続する制御部と、
前記制御部の輻輳状態を監視する輻輳監視部と、
前記輻輳監視部が、前記制御部が輻輳状態にあると判断した場合に、前記電話機に輻輳情報を送信する輻輳情報送信部と、
を備えたことを特徴とする交換装置。
【請求項２】
複数の電話機をパケット網を介して収容する交換装置において
前記複数の電話機の呼制御情報を受信し、所望の相手に交換接続する制御部と、
前記制御部の輻輳状態を監視する輻輳監視部と、
前記複数の電話機に対して発着信規制を行う為の優先順位を格納した記憶部と、
前記輻輳監視部が、前記制御部が輻輳状態にあると判断した場合に、前記記憶部に格納された優先順位に従い、所定の電話機に輻輳情報を送信する輻輳情報送信部と、
を備えたことを特徴とする交換装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は電話交換装置における輻輳時の制御技術に関する。
【背景技術】
【０００２】
従来の交換装置における輻輳制御は、ＣＰＵが輻輳状態だと判断した場合に、内線番号に優先順位を持たせ優先順位の低いものに発着信規制する技術が特許文献１に開示されている。
【特許文献１】特開平５−６８０９２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしなら、昨今のネットワーク事情より回線のInternet Protocol（以下ＩＰをいう。）化に伴い、収容する電話機もＩＰ化されてきている。このような状況においては、交換装置よりの輻輳規制（特許文献１に開示）は、単純にライン回路により発着信規制を行えば電話機にそれが伝わるようなものではなくなってきている。
具体的に説明すると、電話機の受話器を上げた際のダイヤルトーン（以下ＤＴという。）、話中時のビジートーン（以下ＢＴという。）等は、従来、交換装置より電話機に対して送出されてきているものだが、ネットワークのＩＰ化の伝送遅延に伴い、電話機自身より発せられるようになってきている。
【０００４】
そのため、ライン回路に発信規制をかけただけでは、電話機に交換装置の輻輳状態が伝達されないのである。従って、本発明は輻輳状態を迅速かつ的確に電話機に伝達する交換装置の提供を目的とする。
【課題を解決するための手段】
【０００５】
上記課題を解決するために、本発明の第１の交換装置は、電話機をパケット網を介して収容し、前記電話機の呼制御情報を受信し、所望の相手に交換接続する制御部と、前記制御部の輻輳状態を監視する輻輳監視部と、前記輻輳監視部が、前記制御部が輻輳状態にあると判断した場合に、前記電話機に輻輳情報を送信する輻輳情報送信部とを備えたことを特徴とする。
【０００６】
また、本発明の第２の交換装置は、複数の電話機をパケット網を介して収容し、前記複数の電話機の呼制御情報を受信し、所望の相手に交換接続する制御部と、前記制御部の輻輳状態を監視する輻輳監視部と、前記複数の電話機に対して発着信規制を行う為の優先順位を格納した記憶部と、前記輻輳監視部が、前記制御部が輻輳状態にあると判断した場合に、前記記憶部に格納された優先順位に従い、所定の電話機に輻輳情報を送信する輻輳情報送信部と、を備えたことを特徴とする。
【発明の効果】
【０００７】
以上のように本発明の第１の交換装置は、電話機をパケット網を介して収容し、前記電話機の呼制御情報を受信し、所望の相手に交換接続する制御部と、前記制御部の輻輳状態を監視する輻輳監視部と、前記輻輳監視部が、前記制御部が輻輳状態にあると判断した場合に、前記電話機に輻輳情報を送信する輻輳情報送信部とを備えたことにより、交換装置の輻輳状態をＩＰ電話機に通知することで、ＩＰ電話機に対する輻輳規制を指示することができ、交換装置に対する不要な再発信操作に応じた呼制御メッセージの送出を抑制することができ、輻輳状態における処理を軽減できる。また、輻輳状態中に不要な再発信操作がなくなるので、輻輳によるサービスの停止からの回復までの時間を短縮することができるようになる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明を実施例１及び実施例２の通信システムを例に説明する。
【実施例１】
【０００９】
図１に本発明に係わる交換装置を用いたシステム構成を示す。
本システムは、ＩＰパケット通信を行う複数の通信端末３１，３２と３３と、複数の通信端末相互間の呼制御を行う交換装置１（以下ＴＭ部という）を有する。複数の通信端末３１，３２，３３のうち、一つはＩＰゲートウェイ３３で、残りはＩＰ電話機である。
集線装置（Concentrator）であるＨＵＢ２には、ＬＡＮ（Local  Area   Network）ケ−ブル６を通じて、ＴＭ部１と、ＴＭ部１との独自のインタフェ−スを持つＩＰ電話機３１，３２，とＩＰゲートウェイ３３が接続されている。ＴＭ部１は、ゲートウェ３３を介してＩＰ網５と接続され、ＩＰ電話機３１、３２は、ＩＰ網に接続されている電話機や通信端末装置を通信・通話が可能となっている。
【００１０】
図２に本発明のＴＭ部１の内部ブロック図を示す。ＴＭ部１内にはＬＡＮやＩＰ網との呼制御を行うＩＰ呼制御部１２（以下ＳＣ部という）と、交換制御を行う交換制御部１１（以下ＣＣ部という）とを備える。
【００１１】
ＣＣ部１１は、ＳＣ部１２から伝達された呼情報を統括し、チャンネルごとの呼状態を管理、着信可否判定等を行う交換制御部１１３を有する。また、ＣＣ部１１には、交換制御部１１３の処理能力を監視し、交換制御部１１３において輻輳状態となっていないかどうかを監視する監視部１１１を有し、更に、呼のサービスに関する設定情報を管理する記憶部１１２とから構成されている。
【００１２】
ＳＣ部１２は、ＣＣ部１１から受け取った呼の交換情報をＩＰパケット化し、通信端末へ伝送する機能と、通信端末からの呼情報をＣＣ部１１へ伝送するＩＰ個制御１２３を有する。
【００１３】
ＩＰ呼制御１２３部の機能としては、通信端末の種類に応じてプロトコル変換を行い、ＣＣ部１２は通信端末の種類を意識することなく制御可能となり、多様なＩＰ通信端末と接続可能な柔軟なインタフェースを提供できるようにしている。
【００１４】
通信端末の種類には、ＳＩＰ（Session Initiation Protocol）を用いたもの、ＩＴＵ−Ｔ  Ｈ．３２３通信プロトコルを用いたもの等があり、また、通信機メーカ各社の独自インタフェースのプロトコルを使用するものがある。
ＳＣ部１２内部には、ＩＰ呼制御部の処理能力を監視し、輻輳が発生していないかを監視するＳＣ監視部１２１と、ＳＣ部１２が管理する通信端末の情報を管理するＳＣ記憶部１２２を備えている。
【００１５】
また、ＴＭ部１にはＳＣ部１２を１２ａ、１２ｂ、１２ｎといった具合に複数搭載可能としている。このようにすることで、ＳＣ部１２の端末接続処理能力に応じて追加を行い、ＴＭ部１全体としての収容端末数を増加させると共に、ユーザーにストレスを与えることなく使用させることが可能になる。また、複数ＳＣ部となった場合にＳＣ部毎に別ネットワークとして運用することも可能となり、ＳＣ部の保守面で障害切り分けなどが行い易くなっている。
【００１６】
次に、図３を用いて、ＴＭ部１の配下のＩＰ電話機間の通信動作を説明する。
システムの構成としてＣＣ部１１はＳＣ部１２を複数管理することが可能で、ＳＣ１２ａ、１２ｂ、・・・・・、１２ｎを搭載している。
【００１７】
通信端末としてＳＣ１２ａには、複数のＩＰ電話機３１ａ〜３１ｎと、ＳＣ１２ｎには、複数のＩＰ電話機３２ａ〜３２ｎが収容されている。
【００１８】
本実施例は、ＳＣ１２ａ部に収容されたＩＰ電話機３１ａとＳＣ１２ｎに収容されたＩＰ電話機３２ａ間が通話を行う場合を例とする。
【００１９】
ＩＰ電話機３１ａが受話器を上げると（オフフック）、その情報は、ＩＰパケット型呼制御メッセージとして送出され、ＳＣ部１２ａ内のＩＰ呼制御部１２３で認識し、ＣＣ部１１へ伝送される。このＳＣ部１２ａへのメッセージ宛先ＩＰアドレスはＳＣ部１２ａであり、発信元ＩＰアドレスはＩＰ電話機３１ａである。
【００２０】
オフフック情報を受信したＣＣ部１１は、ダイヤルトーン出力要求（ＤＴ要求）をＳＣ部１２ａ経由でＩＰ電話機３１ａに送出する。
【００２１】
前記ダイヤルトーン出力要求を受けたＩＰ電話機３１ａは、話者に対してダイヤルトーンを聞かせるためダイヤルトーン（ＤＴ）を生成し受話器から出力する。そして、ダイヤルトーンを受信して、ＴＭ部１に起動がかかったと認識したＩＰ電話機３１ａの話者は、接続するためのダイヤルを入力し、ＩＰ電話機はその入力されたダイヤル情報の送信を開始する。
【００２２】
ＳＣ部１２ａ系由で最初のダイヤルを受信したＣＣ部１１は、ダイヤルトーン停止要求（ＤＴｏｆｆ要求）をＳＣ部１２ａ経由でＩＰ電話機３１ａに送り、ＩＰ電話機３１ａからのダイヤルトーンの出力を停止させる。
【００２３】
最終ダイヤルを受信したＣＣ部１１は、そのダイヤル情報から接続相手先を認識し、ＳＣ１２ｎ内のＩＰ呼制御部１２３へ接続相手先のベルを鳴動させるように指示する。この動作は、ＣＣ部１１内の記憶部１１２に予め登録されている宛先ＩＰアドレスを抽出するもので、前記ダイヤル情報を受信した際にそれに対応するＩＰアドレス情報を抽出し、相手先を呼び出すようにＳＣ部１２へ指示するものである。
【００２４】
指示を受けたＳＣ１２ｎ内のＩＰ個制御部１２３は、ＩＰ電話機３２ａのＩＰアドレス宛にベルの鳴動を要求する。
【００２５】
その要求に従い、ＩＰ電話機３２ａは自身の呼び出しベルを鳴動させる。また、ＣＣ部１１は、ＳＣ１２ａを介してリングバックトーン出力要求（ＲＢＴ要求）をＩＰ電話機３１ａに行い、その指示に従い、リングバックトーンをＩＰ電話機３１ａが出力する。
【００２６】
ここでＩＰ電話機３２ａの話者が受話器を上げると（オフフック）、その情報はＩＰパケット型の呼制御情報としてＳＣ１２ｎへ送信され（宛先ＩＰアドレスはＳＣ１２ｎ、送信元ＩＰアドレスはＩＰ電話機３２ａ）、ＳＣ１２ｎは受信した情報をＣＣ部１１へ伝達する。
【００２７】
それを受けたＣＣ部１１は、ＩＰ電話機間で通話を開始するために、ＩＰ電話機３１ａと３２ａが通話する旨のメッセージをＳＣ１２ａとＳＣ１２ｎへ送信し、その情報を受けたＳＣ１２ａはＩＰ電話機３１ａへ、ＳＣ１２ｎはＩＰ電話機３２ａへと伝達する。この情報により、ＩＰ電話機３１ａと３２ａはベル鳴動やリングバックトーンの出力をやめ、チャンネルオープンの状態となり、通話準備が完了する。この後通話データは、ＴＭ部１を介さずＩＰ電話機３１ａ、３２ａ間をＬＡＮ経由でＩＰパケット音声のみで伝送される。
【００２８】
次に図８と図９を用いて、本システムにおいてＴＭ部１で輻輳が発生した際に、輻輳を軽減する方法を説明する。
【００２９】
例１として、輻輳の重度、軽度の度合い（以下輻輳レベル）に応じて接続を規制する電話機（例えば内線電話機）と、規制しない電話機を定める管理情報を作成する。
この情報は会社等での電話システムにおいての輻輳状態となった場合に、一般従業員の使用する内線電話機は使用を規制するが、会社役員の電話機や重要顧客との対応窓口等に用いる内線電話機等は、優先して使用可能にするというような運用方法を想定している。
図８の例では輻輳時の接続優先度を高める内線電話機として、内線番号１０００（図番号の３１ａ）と内線２０００（図番号の３２ａ）を設定し、その他の内線電話機として内線番号１９９９（図番号の３１ｎ）と内線番号２９９９（図番号の３２ｎ）を設定した事を示している。
【００３０】
ここでは、輻輳状態となった時の接続優先度を高い、低い、の２段階で表現しているが、必要に応じてより詳細に分類しても良い。また、逆に内線電話機毎に接続優先度を設定せずに全内線の接続優先度を等しく設定することで、どの内線から発信された情報なのかを交換機が判断する処理を省略し、交換機の負荷を軽減する運用方法としてもよい。
【００３１】
次にこのような輻輳状態時の接続優先度と交換機の輻輳レベルとを対応させる管理情報を作成する。本発明の交換機の輻輳レベルを決定する方法として、ＣＰＵ使用率や、呼の待ちキューの使用率等を用いる。以下は、ＣＰＵ使用率を用いて説明する（図９）。
【００３２】
輻輳による規制を開始する方法として、輻輳の重度、軽度の度合い（輻輳レベル）に応じて段階的に接続優先度の低い内線電話機から接続を規制する。次に、輻輳レベルの１段階目としてＣＰＵ使用率がＣＰＵ使用率の下限閾値である７０％〜ＣＰＵ使用率上限閾値である８０％となる時間が、規制始動ＣＰＵ占有時間である６０秒以上続く場合は、輻輳レベル１とみなし、輻輳時の接続優先度が低く輻輳レベル１で規制を開始する内線番号１９９９と内線番号２９９９を接続規制の対象とする。
【００３３】
また、輻輳時の接続優先度が高く輻輳レベル２から規制を開始する内線番号１０００と内線番号２０００の内線は、接続の規制を行わない。
【００３４】
また、ＣＰＵ使用率がＣＰＵ使用率下限閾値である８０％〜ＣＰＵ使用率上限閾値である１００％となる時間が規制始動開始ＣＰＵ占有時間である６０秒以上続く場合は、輻輳レベル２とみなし、輻輳レベルが２から規制対象となる内線を規制する。図８の設定では全内線の接続を規制する。このような規制の段階は、例として示した２段階より詳細に区切って管理することも可能である。
【００３５】
次に、現在輻輳レベル２の状態にあるものとして、輻輳規制の解除を行う例を説明する。輻輳レベル２のＣＰＵ使用率下限閾値である８０％を下回る時間が、規制キャンセルＣＰＵ占有時間である６０秒を越えたとき、輻輳レベルを下げて１とみなす。
このとき、輻輳レベル２から規制対象となる内線（内線番号１０００と、内線番号２０００）は規制を解除し、接続可能な状態とする。また、レベル１から規制対象となる内線電話機（内線番号１９９９と内線番号２９９９）は引き続き規制の対象となる。
【００３６】
次の段階として、輻輳レベル１のＣＰＵ使用率下限閾値である７０％を下回る時間が、規制キャンセルＣＰＵ占有時間である６０秒を越えたとき、輻輳レベルを下げて０（輻輳解除）とみなす。輻輳解除の状態では、すべての内線電話機の接続規制を解除し、呼を繋げる事が可能となる。
【００３７】
この輻輳制御の動作シーケンス図４を用いて説明する。
ＣＣ部１１の記憶部１１２には全ての内線電話番号毎に交換制御の輻輳状態時における接続優先度を管理する情報が設定されており、ＳＣ部１２ａのＳＣ記憶部１２２には、ＳＣ１２ａが収容（管理）する内線の接続優先度を管理する情報を有する。
ここでＳＣ１２ａが有する内線の接続優先度の情報は、事前にＣＣ部の記憶部１１２から取得しているものとする。
【００３８】
ＣＣ部１１には、交換制御部１１３を監視する監視部１１１があり、周期的に交換制御部１１３の輻輳レベル（ＣＰＵ使用率）を監視する。交換制御部１１３が輻輳無しの場合（輻輳レベル１の条件に満たない）には、監視部１１２が交換制御部１１３に輻輳無しを通知し、交換制御部１１３は、ＣＣ部１１が管理する全てのＳＣ部１２に輻輳無しを通知する。
【００３９】
この状態でＩＰ電話機３１ａとＩＰ電話機３１ｎがオフフックを行うと、ＳＣ１２ａは輻輳無しの状態を有しているので、両者の情報ともＣＣ部１１へ伝達し、通常の呼接続を行う。オフフック後のシーケンスは図３と同様のため省略する。
ＣＣ部１１の処理が増加し輻輳レベル１の条件を満たした場合は、監視部１１１が輻輳レベル１を交換制御部１１３に通知し、交換制御部１１３は、全てのＳＣ１２に対して輻輳レベル１を通知する。
【００４０】
この状態で、内線番号１０００のＩＰ電話機３１ａがオフフックを行うと、オフフック情報を受信したＳＣ１２ａは、ＳＣ記憶部１２２にある内線番号１０００に設定されている輻輳時の接続優先度を判定し、輻輳レベルが２以上なので規制対象外と判断しＣＣ部１１の交換制御部１１３へ呼情報を送信する。
オフフック情報を受け取った交換制御部１１３は、ＤＴ要求をＩＰ電話機３１ａへ送信する。以降の発信処理は図３の通常の呼制御動作と同じとなるので説明を省略する。
しかしこの状態のときに、内線番号１９９９のＩＰ電話機３１ｎがオフフックを行うと、オフフック情報を受信したＳＣ１２ａは、ＳＣ記憶部１２２にある内線番号１９９９に設定されている輻輳時の接続優先度を判定し、輻輳レベルが１以上なので規制対象と判断し、輻輳ステータス通知をＩＰ電話機３１ｎに通知する。
【００４１】
ＩＰ電話機３１ｎは、輻輳ステータス通知を受け取ると、話者に対してリオーダトーンを聞かせるためリオーダトーンを生成し受話器から出力するか、ＬＣＤ表示可能な場合にはＩＰ電話機に登録してある発信規制中等のメッセージを表示することにより、話者に発信規制中の状態案内を行い以降の発信操作の中止を通知する。
【００４２】
さらに、ＣＣ部１１の処理が増加し輻輳レベル２の条件を満たした場合は、監視部１１１が輻輳レベル２を交換制御部１１３に通知し、交換制御部１１３は、全てのＳＣ１２に対して輻輳レベル２を通知する。
【００４３】
この状態で、内線番号１０００のＩＰ電話機３１ａがオフフックを行うと、オフフック情報を受信したＳＣ１２ａは、ＳＣ記憶部１２２にある内線番号１０００に設定されている接続の優先度を判定し、輻輳レベルが２以上なので規制対象と判断し、輻輳ステータス通知をＩＰ電話機３１ａに通知し、発信を規制する。同様に、内線番号１９９９のＩＰ電話機３１ｎがオフフックを行うと、オフフック情報を受信したＳＣ１２ａは、ＳＣ記憶部１２２にある内線番号１９９９に設定されている接続の優先度を判定し、輻輳レベルが１以上なので規制対象と判断し、輻輳ステータスをＩＰ電話機３１ｎに通知することで、発信を規制する。
【００４４】
次に、ＳＣ部１２のＩＰ呼制御部１２３で処理増大し輻輳状態となった場合の動作シーケンスを図５を用いて説明する。
ＳＣ部１２には、ＩＰ呼制御部１２３を監視するＳＣ監視部１２１があり、周期的にＩＰ呼制御１２３の輻輳レベル（ＣＰＵ使用率）を監視する。ＳＣ監視部１２１はＩＰ呼制御１２３の輻輳無しの場合には、ＩＰ呼制御１２３に輻輳無しを通知する。
【００４５】
この状態でＩＰ電話機３１ａとＩＰ電話機３１ｎがオフフックを行うと、ＳＣ１２ａは輻輳無しの状態であるので、両者の情報ともＣＣ部１１へ伝達し、通常の呼接続を行う。オフフック後のシーケンスは図３の説明の際に行ったため省略する。
【００４６】
ＩＰ呼制御部１２３の処理が増加し輻輳レベル１の条件を満たした場合は、ＳＣ監視部１２１が輻輳レベル１をＩＰ呼制御部１２３に通知する。この状態で、内線番号１０００のＩＰ電話機３１ａがオフフックを行うと、オフフック情報を受信したＳＣ１２ａは、ＳＣ記憶部１２２にある内線番号１０００に設定されている接続の優先度を判定し、輻輳レベルが２以上なので規制対象外と判断しＣＣ部１１へ呼情報を送信する。
【００４７】
オフフック情報を受け取ったＣＣ部１１は、ＤＴ要求をＩＰ電話機３１ａへ送信する。以降の発信処理は通常の呼制御と同じとなるので説明を省略する。
【００４８】
しかしこの状態において内線番号１９９９のＩＰ電話機３１ｎがオフフックを行うと、オフフック情報を受信したＳＣ１２ａは、ＳＣ記憶部１２２にある内線番号１９９９に設定されている接続の優先度を判定し、輻輳レベルが１以上なので規制対象と判断し、輻輳ステータスをＩＰ電話機３１ｎに通知し、発信を規制する。
【００４９】
さらに、ＳＣ部１２の処理が増加し輻輳レベル２の条件を満たした場合は、ＳＣ監視部１２１が輻輳レベル２をＩＰ呼制御部１２３に通知する。この状態で、内線番号１０００のＩＰ電話機３１ａがオフフックを行うと、オフフック情報を受信したＳＣ１２ａは、ＳＣ記憶部１２２にある内線番号１０００に設定されている接続の優先度を判定し、輻輳レベルが２以上なので規制対象と判断し、輻輳ステータスをＩＰ電話機３１ａに通知し、発信を規制する。
【００５０】
同様に、内線番号１９９９のＩＰ電話機３１ｎがオフフックを行うと、オフフック情報を受信したＳＣ１２ａは、ＳＣ記憶部１２２にある内線番号１９９９に設定されている接続の優先度を判定し、輻輳レベルが１以上なので規制対象と判断し、規制ステータスをＩＰ電話機３１ｎに通知することで、発信を規制する。
【００５１】
次に、図６を用いてＴＭ部１の輻輳を軽減するためのＩＰ電話機の機能を説明する。
【００５２】
ＴＭ部１のＣＣ部１１が輻輳レベル１状態にあるとして、監視部１１１が、交換制御部１１３へ輻輳レベル１を通知し、交換制御部１１３はＳＣ１２ａに輻輳レベル１を通知しているものとする。
【００５３】
この状態で、内線番号１９９９のＩＰ電話機３１ｎがオフフックを行うと、オフフックの情報を受け取ったＳＣ１２ａが輻輳レベル１である事を判定し、ＩＰ電話機３１ｎに輻輳ステータス通知を送信する。
【００５４】
輻輳ステータス通知を受信したＩＰ電話機３１ｎは、話者にＴＭ部１が輻輳状態にあり、発信規制中である旨を示すため、ＩＰ電話機で生成したリオーダトーンを聞かせるか、ＬＣＤ表示可能な場合には発信規制中等のメッセージを表示することにより、話者に発信規制中の状態案内を行い発信を中止させる。
【００５５】
また、この際ＩＰ電話機側で再発信規制時間を設け、タイマーにより数秒間発信規制を行う。ＩＰ電話機側で再発信を規制する時間を設けることにより、発信できなかった話者が連続して再発信を試み、加速的にＴＭ部１の負荷が増えることを防止できる。
【００５６】
ＴＭ部１の輻輳状態が解除され、更に、ＩＰ電話機の再発信規制時間の経過により、ＩＰ電話機が発信可能状態になれば、発信を行うことができるようになる。
【実施例２】
【００５７】
実施例１として、ＴＭ部１のＣＣ部１１の負荷を軽減する方法を説明した。次に実施例２として、ＴＭ部１側全体の負荷をより軽減するための実施形態を説明する。
【００５８】
実施例２は、内線電話機毎に接続の優先度を定める点は実施例１と同様であるが、異なる点としてＩＰ電話機が起動時した際にＴＭ部１から、自ＩＰ電話機の接続優先度の情報（接続規制を開始する輻輳レベル）を取得し、その後ＴＭ部１より得られる情報を基に、電話機自身で判断し話者に対して発信規制をかけるようにしたものである。その動作を図７を用いて説明を行うこととする。
【００５９】
ＩＰ電話機３１ａとＩＰ電話機３１ｎは、予めＴＭ部１から各々の電話機に設定されている輻輳レベルを取得しているものとする。
【００６０】
ＣＣ部１１の監視部１１１は、交換制御部１１３の輻輳状態を監視し、輻輳無しと判断した場合は、輻輳無しという情報を交換制御部１１３へ通知する。輻輳無しの情報を受けた交換制御部１１３は全てのＳＣ部１２に伝達する。輻輳無しの情報を受けたＳＣ部１２ａはマルチキャスト通信を用いて収容するＩＰ電話機へ輻輳ステータス通知を行う。（但しこの輻輳ステータス通知には、輻輳レベルの情報が含まれているものとし、この場合は輻輳無しという情報をＩＰ電話機３１ａと３１ｎに通知したものである。）
【００６１】
ＩＰ電話機３１ａと３１ｎは、輻輳無しのメッセージを受信しているため、発信する事が可能となる（オフフック情報をＴＭ部１へ通知する可能）。
【００６２】
次に、ＣＣ部１１の処理が増加し、輻輳レベル１の条件を満たしている場合を説明する。
【００６３】
監視部１１１は、交換制御部１１３の輻輳状態を監視し、輻輳レベル１と判断するため輻輳レベル１という情報を交換制御部１１３へ通知する。
【００６４】
輻輳レベル１の情報を受けた交換制御部１１３は全てのＳＣ部１２に伝達する。ＳＣ部１２ａはマルチキャスト通信を用いて収容するＩＰ電話機３１ａ、３１ｎへ輻輳ステータス通知（輻輳レベル１）を行う。
【００６５】
ＩＰ電話機３１ａと３１ｎは、輻輳レベル１のメッセージを受信すると、事前にＴＭ部１から取得している自電話機の接続を規制開始する輻輳レベルと比較して、接続規制を開始するか否かの判断を行う。
【００６６】
ＩＰ電話機３１ａは輻輳レベル２以上で発信規制対象となるので、発信する事が可能となる。ＩＰ電話機３１ｎは輻輳レベル１以上で発信規制対象となるため、発信規制を行う。発信規制を行っている間は、ＩＰ電話機３１ｎから発信操作（オフフック）を行っても、規制案内をユーザに通知し（実施形態１で説明したリオーダトーンを発生させる方法、又はＬＣＤに発信規制中という表示を行う方法）、オフフック情報をＴＭ部１へ通知しないようにする。
【００６７】
次に輻輳レベル１の状態から、輻輳無しの状態に遷移した場合を説明する。監視部１１１が輻輳無しの情報を交換制御部１１３へ送信し、交換制御部１１３とＳＣ部１２ａを経由して輻輳ステータス通知（輻輳無し）をＩＰ電話機３１ａと３１ｎが受信する。ＩＰ電話機３１ｎは、発信規制状態から輻輳ステータス通知（輻輳無し）を受信したことにより発信可能な状態に移行し、発信する事が可能となる（オフフック情報を交換機へ通知する可能）。
【００６８】
また、この方法では、ＴＭ部１が輻輳状態から輻輳解除の状態に遷移する際に、輻輳解除を伝える輻輳ステータス通知（輻輳無し）のメッセージがネットワークのトラブル等により通知されない場合も考えられる。すると実際はＴＭ部１側の輻輳が回復しているにもかかわらず発信できないという現象が起こる可能性がある。
【００６９】
そこで本発明では、ＩＰ電話機側で、輻輳ステータス通知（輻輳レベル１以上）を受け取った場合、発信規制を解除するタイマーをセットし、タイマーの満了時に発信規制を解除している。これにより、ネットワークトラブル発生時においても輻輳解除への移行が可能となり、輻輳状態のまま電話機が使用不能となることを防止している。
【００７０】
前述では、輻輳レベル１の場合を用いて説明を行ったが、輻輳レベル２の場合でもＩＰ電話機に輻輳レベル２という輻輳ステータスを通知し、ＩＰ電話機側で自電話機に登録されている規制開始する輻輳レベルと比較して発信規制するという処理は同様である。
【００７１】
この実施例２では、輻輳ステータス通知を常にＩＰ電話機に通知するため、ＬＡＮ上のトラフィックが実施例１より増加しやすい。そこで、交換制御部１１３は、監視部１１１から輻輳の情報を受信した際に、前回受信したものと同じものかどうかを判断し、同じ情報であれば適当な間隔で間引いて、ＳＣ部１２に輻輳情報を通知する方法と併用してもよい。例えば１秒毎に監視部１１１が輻輳無しを連続して通知してきた場合は、５秒に１回だけＳＣ部１２に通知する等である。
【図面の簡単な説明】
【００７２】
【図１】本発明の交換装置を用いたシステム構成図である。
【図２】本発明の交換装置の内部ブロック図である。
【図３】本発明におけるＩＰ電話機間の通話シーケンス図である。
【図４】本発明の交換装置（ＣＣ部）の輻輳制御シーケンス図である。
【図５】本発明の交換装置（ＳＣ部）の輻輳制御シーケンス図である。
【図６】本発明の交換装置とＩＰ電話機を用いた輻輳制御シーケンス図である（１）。
【図７】本発明の交換装置とＩＰ電話機を用いた輻輳制御シーケンス図である（２）。
【図８】本発明の交換装置内の電話番号優先度管理テーブルを示す図である。
【図９】本発明の交換装置内の輻輳検出値設定テーブルを示す図である。
【符号の説明】
【００７３】
１：交換機
２：ＨＵＢ
３１，３２：ＩＰ電話機
３３：ＩＰゲートウェイ
４：一般電話機
５：公衆交換網（ＰＳＴＮ）
６：ＬＡＮ
【図１】
2007124511.tif 000003
【図２】
2007124511.tif 000004
【図３】
2007124511.tif 000005
【図４】
2007124511.tif 000006
【図５】
2007124511.tif 000007
【図６】
2007124511.tif 000008
【図７】
2007124511.tif 000009
【図８】
2007124511.tif 000010
【図９】
2007124511.tif 000011