"マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するコンピュータにおけるセッション制御方法であって、複数のプロセスが、各プロセスの処理キューに蓄積されたキューを、順次並列に処理するステップと、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視するステップを備えることを特徴とするセッション制御方法。前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定することを特徴とする請求項1に記載のセッション制御方法。前記輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定することを特徴とする請求項1に記載のセッション制御方法。前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定することを特徴とする請求項1に記載のセッション制御方法。外部から入力された信号を処理するプロセスが輻輳状態の場合、内部から処理がキューイングされるプロセスが処理を拒否する応答信号を出力するステップと、前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップと、前記外部から入力された信号を処理するプロセスおよび前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップをさらに備えることを特徴とする請求項1ないし4のいずれか1項に記載のセッション制御方法。マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するセッション制御サーバであって、処理キューに蓄積されたキューを、順次並列に処理する複数のプロセスを実現する複数の処理部と、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視する輻輳監視部を備えることを特徴とするセッション制御サーバ。前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定することを特徴とする請求項6に記載のセッション制御サーバ。前記輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定することを特徴とする請求項6に記載のセッション制御サーバ。前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定することを特徴とする請求項6に記載のセッション制御サーバ。前記プロセスは、外部から入力された信号を処理する受信処理部と、前記受信処理部から入力された信号を処理する呼制御処理部によって実現され、前記受信処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力し、前記呼制御処理部が輻輳状態の場合、前記受信処理部が処理を拒否する応答信号を出力し、前記受信処理部および前記呼制御処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力することを特徴とする請求項6ないし9のいずれか1項に記載のセッション制御サーバ。しかしながら、マルチコアCPUを搭載したセッション制御サーバにおいて、複数のプロセスに処理を分散させ、シーケンシャルに処理させる場合、各プロセスが一つの信号に対する処理量が異なる場合がある。これにより、一定時間内に処理可能な信号の数も、各プロセスによって異なる場合がある。マルチコアCPU環境では、それぞれのプロセスが同時に並列して処理することができるので、大量の信号を処理することができる。しかし、その1信号の処理に要する時間がプロセスによって異なるため、処理の遅いプロセスのみ処理が滞り、輻輳状態になる場合がある。この場合、一部のプロセスのみ輻輳状態となる。このように一部のプロセスのみ輻輳状態のことを、本実施形態においてプロセス輻輳と称する。このようなプロセス輻輳の状態では、サーバ全体では輻輳状態とは判定されない場合もある。具体的には、プロセス輻輳に陥っているプロセスは、コアを100使用している。しかし、処理の早いプロセスは処理量に余裕があり、その他のプロセス輻輳でないプロセスでは、コアを100使用することはない。従来、サーバのCPUの使用率が閾値を越えた場合に、サーバ輻輳が検出されるので、マルチコアCPUのセッション制御サーバにおいては、すべてのコアの使用率の平均値に基づいてサーバ輻輳が検出されてしまう。従って、プロセス輻輳の状態では、個別のプロセスにおいて輻輳が発生していても、そのほかのプロセスでは輻輳状態ではないため、サーバ輻輳が検出されない場合がある。これにより、呼の集中によりサーバ全体で呼の処理性能が低下しているにもかかわらず、その事象を検出することができない問題がある。従って本発明の目的は、マルチコアを搭載し、複数のプロセスを同時に並列して処理する制御サーバにおいて、適切に輻輳を制御するセッションセッション制御方法およびセッション制御サーバを提供することである。上記課題を解決するために、本発明の第1の特徴は、マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するコンピュータにおけるセッション制御方法に関する。すなわち本発明の第1の特徴に係るセッション制御方法は、複数のプロセスが、各プロセスの処理キューに蓄積されたキューを、順次並列に処理するステップと、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視するステップを備える。ここで、輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。また、外部から入力された信号を処理するプロセスが輻輳状態の場合、内部から処理がキューイングされるプロセスが処理を拒否する応答信号を出力するステップと、内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップと、外部から入力された信号を処理するプロセスおよび前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップをさらに備えても良い。本発明の第2の特徴は、マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するセッション制御サーバに関する。すなわち本発明の第2の特徴に係るセッション制御サーバは、処理キューに蓄積されたキューを、順次並列に処理する複数のプロセスを実現する複数の処理部と、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視する輻輳監視部を備える。ここで、輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。また、プロセスは、外部から入力された信号を処理する受信処理部と、前記受信処理部から入力された信号を処理する呼制御処理部によって実現され、受信処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力し、呼制御処理部が輻輳状態の場合、前記受信処理部が処理を拒否する応答信号を出力し、受信処理部および前記呼制御処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力しても良い。本発明によれば、マルチコアを搭載し、複数のプロセスを同時に並列して処理する制御サーバにおいて、適切に輻輳を制御するセッションセッション制御方法およびセッション制御サーバを提供することができる。次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一または類似の部分には同一または類似の符号を付している。本発明の実施の形態に係るセッション制御サーバ1は、コンピュータに所定の処理を実行するプログラムがインストールされて実現される。セッション制御サーバ1は特に、マルチコアを搭載し、複数のプロセスを同時に並列して処理することのできるコンピュータによって実現される。図1に示すセッション制御サーバ1は、例えば電話システムなどにおいて、外部から入力された発呼信号2から応答信号3を出力する。セッション制御サーバ1は、受信処理部10、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40および輻輳監視部50を備える。受信処理部10、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40および輻輳監視部50は、それぞれプロセスによって実現される。受信処理部10、第1の呼制御処理部20、第2の呼制御処理部30、第3の呼制御処理部40および輻輳監視部50は、それぞれスレッドによって実現されても良い。本実施の形態において、プロセスは、一般的なプロセスとスレッドの意味を含むものとして説明する。ここで、図1に示す例において、セッション制御サーバ1が、3つの呼制御処理部を備える場合について説明するが、呼制御処理部の数は、1つでも4つ以上でも良い。セッション制御サーバ1の複数のプロセスは、各プロセスの処理キューに蓄積されたキューを、順次並列に処理する。受信処理部10は、外部から入力された信号を処理するプロセスを実現する処理部である。受信処理部10は、受信信号保存キュー11を備える。セッション制御サーバ1が発呼信号2を受信すると、受信された発呼信号2は、受信信号保存キュー11に蓄積され、受信処理部10による処理を待機する。受信処理部10は、受信信号保存キュー11から一つずつ呼を取り出して、後続のプロセスのいずれかにキューイングする。ここで図1に示す例において受信処理部10の後続のプロセスは、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40である。いずれのプロセスにキューイングするかは、所定の手順で決定される。受信処理部10から第1の呼制御処理部20にキューイングされた呼は、第1の呼制御処理部20の呼制御処理保存キュー21に蓄積される。第1の呼制御処理部20は、内部から処理がキューイングされるプロセスを実現する処理部である。第1の呼制御処理部20は、呼制御処理保存キュー21から一つずつ呼を取り出して所定の手順で処理し、応答信号3を出力する。同様に、受信処理部10から第2の呼制御処理部30にキューイングされた呼は、第2の呼制御処理部30の呼制御処理保存キュー31に蓄積される。第2の呼制御処理部30は、内部から処理がキューイングされるプロセスを実現する処理部である。第2の呼制御処理部30は、呼制御処理保存キュー31から一つずつ呼を取り出して所定の手順で処理し、応答信号3を出力する。受信処理部10から第3の呼制御処理部40にキューイングされた呼は、第3の呼制御処理部40の呼制御処理保存キュー41に蓄積される。第3の呼制御処理部40は、内部から処理がキューイングされるプロセスを実現する処理部である。第3の呼制御処理部40は、呼制御処理保存キュー41から一つずつ呼を取り出して所定の手順で処理し、応答信号3を出力する。受信処理部10は、受信した呼を、後続のプロセスに引き渡すほか、輻輳により呼を拒否する場合、輻輳状態データ51aを参照して、受信処理部10は、その拒否する応答信号を出力させるプロセスを特定する。ここで呼を拒否するか否かは、呼の優先度、信号種などにより、判断される。受信処理部10が輻輳状態の場合、受信処理部10は、拒否応答信号を出力するプロセスとして、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40のいずれかを特定する。受信処理部10は、特定されたプロセスに、拒否する応答信号を出力させる。第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40のいずれかが輻輳状態の場合、受信処理部10は、拒否応答信号を出力するプロセスとして、受信処理部10自身を特定する。受信処理部10が処理を拒否する応答信号を出力する。受信処理部10、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40のいずれもが輻輳状態の場合、受信処理部10は、拒否応答信号を出力するプロセスとして、受信処理部10自身を特定する。受信処理部10が処理を拒否する応答信号を出力する。輻輳監視部50は、セッション制御サーバ1の監視対象のプロセスについて、各プロセスが輻輳状態であるか否かを周期的に監視し、輻輳状態データ51aとして輻輳状態記憶部51に記憶する。ここで、輻輳監視部50の監視対象プロセスは、受信処理部10、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40の各プロセスである。輻輳監視部50は、セッション制御サーバ1全体の輻輳状態を監視するとともに、これら各プロセスの輻輳状態を監視する。セッション制御サーバ1全体の輻輳状態は、サーバ全体のCPU使用率から判定される。輻輳監視部50が各プロセスの輻輳状態を監視する際、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、輻輳状態であるか否かが判定される。輻輳監視部50が、各プロセスの輻輳状態を監視する方法として、1プロセスのコア使用率を参照する方法、2プロセスの処理キューに蓄積された処理数を参照する方法および3プロセスのコア使用率およびプロセスの処理キューに蓄積された処理数を参照する方法が考えられる。輻輳監視部50は、各プロセスの使用率または/および処理キューに蓄積された処理数を保持し、各プロセスの使用率または/および処理キューに蓄積された処理数が、所定期間閾値を超えた場合に、各プロセスが輻輳状態であると判定する。ここで、所定期間は、1周期でも良い。1の場合、輻輳監視部50は、監視対象のプロセスのコア使用率が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。輻輳監視部50は、各プロセスについて、逐次コアの使用率を算出し、そのコア使用率のログを取得する。2の場合、輻輳監視部50は、監視対象のプロセスの処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。ここで、輻輳監視部50は、各プロセスについて、逐次各プロセスの処理キューに蓄積された処理数のログを取得する。この処理キューは、各プロセスに対応づけられた処理キューである。図1に示す例において、受信処理部10のプロセスについて、処理キューは、受信信号保存キュー11に記憶された受信処理キューである。第1の呼制御処理部20のプロセスについて、処理キューは、呼制御処理保存キュー21に記憶された呼制御処理キューである。第2の呼制御処理部30のプロセスについて、処理キューは、呼制御処理保存キュー31に記憶された呼制御処理キューである。第3の呼制御処理部40のプロセスについて、処理キューは、呼制御処理保存キュー41に記憶された呼制御処理キューである。3の場合、輻輳監視部50は、監視対象のプロセスのコア使用率が、所定期間連続して閾値を超え、かつ、監視対象のプロセスの処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。輻輳監視部50は、各プロセスの使用率および処理キューに蓄積された処理数がともに、所定期間閾値を超えたプロセスを、輻輳状態であると判定する。輻輳監視部50において、1ないし3のいずれかの輻輳監視対象、所定期間および閾値が、予め設定される。その設定に従って、輻輳監視部50は、各プロセスの輻輳状態を監視する。また、輻輳監視部50がいずれの監視対象、所定期間および閾値を採用するかは、運用時間帯や、セッション制御サーバ1の負荷などに応じて、適宜設定されても良い。また、輻輳監視部50は、監視対象のすべてのプロセスについて、1ないし3のうちのいずれか同じ監視対象、所定期間および閾値で輻輳状態を検出しても良い。輻輳監視部50は、各プロセスについて、1ないし3のうちそれぞれ異なる監視対象、所定期間および閾値を予め設定し、その設定された監視対象、所定期間および閾値で各プロセスの輻輳状態を取得しても良い。輻輳監視部50は、各プロセスおよびサーバについて、定期的に輻輳状態を監視し、輻輳状態データ51aを生成し、輻輳状態記憶部51に記憶する。輻輳状態データ51aは、図2に示すように、各プロセスの識別子と、そのプロセスの輻輳状態が関連づけられるとともに、サーバ全体の輻輳状態が含まれている。この輻輳状態は、例えば、各プロセスまたはサーバが、輻輳状態であるか否かのフラグである。輻輳監視部50は、適宜輻輳状態データ51aを更新し、各プロセスおよびサーバの最新の輻輳状態を保持する。この輻輳状態データ51aは、受信処理部10において、輻輳状態のプロセスを特定するとともに、受信した呼を拒否する応答信号を出力させるプロセスを特定するために参照される。図3を参照して、本発明の実施の形態に係る輻輳監視部50において、各プロセスの輻輳を検出する処理を説明する。ステップS101ないしS107の処理は、例えば一定時間おきに、または、何らかのイベントの発生により実行される。図3に示す例においては、監視対象の各プロセスについて、個別に輻輳監視方法が設定されている場合を説明する。ステップS101ないしステップS106の処理は、各プロセスの輻輳状態を特定するプロセスである、図1に示す構成の場合、輻輳監視部50は、受信処理部10、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40の輻輳状態を監視する。従って受信処理部10、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40が、輻輳監視部50の輻輳判定対象となり、これらの各輻輳判定対象について、ステップS101ないしステップS107が繰り返される。ステップS101において、判定対象プロセスごとに設定される輻輳監視方法によって処理が振り分けられる。まず、処理キューに積まれている処理数に応じてプロセスの輻輳を監視する場合、ステップS102に進む。ステップS102において輻輳監視部50は、判定対象プロセスの監視対象である処理キューに積まれている処理数が、所定期間連続して閾値を超えたかを監視する。監視対象が所定期間連続して閾値を超えている場合、ステップS105において、この判定対象プロセスは輻輳状態であると判定し、ステップS107において輻輳監視部50は、その旨を輻輳状態データ51aに更新する。一方監視対象が所定期間連続して閾値を超えていない場合、ステップS106において輻輳監視部50は、この判定対象プロセスは輻輳状態でないと判定し、ステップS107において輻輳監視部50は、その旨を輻輳状態データ51aに更新する。プロセスのコア使用率に応じてプロセスの輻輳を監視する場合、ステップS103に進む。ステップS103において輻輳監視部50は、判定対象プロセスの監視対象であるコア使用率が、所定期間連続して閾値を超えたかを監視する。監視対象が所定期間連続して閾値を超えている場合、ステップS105において、この判定対象プロセスは輻輳状態であると判定し、ステップS107において輻輳監視部50は、その旨を輻輳状態データ51aに更新する。一方監視対象が所定期間連続して閾値を超えていない場合、ステップS106において輻輳監視部50は、この判定対象プロセスは輻輳状態でないと判定し、ステップS107において輻輳監視部50は、その旨を輻輳状態データ51aに更新する。処理キューに積まれている処理数およびプロセスのコア使用率に応じてプロセスの輻輳を監視する場合、ステップS104に進む。ステップS104において輻輳監視部50は、判定対象プロセスの監視対象である処理キューに積まれている処理数とコア使用率がともに、所定期間連続して閾値を超えたかを監視する。これら監視対象が所定期間連続して閾値を超えている場合、ステップS105において、この判定対象プロセスは輻輳状態であると判定し、ステップS107において輻輳監視部50は、その旨を輻輳状態データ51aに更新する。一方これら監視対象が所定期間連続して閾値を超えていない場合、ステップS106において輻輳監視部50は、この判定対象プロセスは輻輳状態でないと判定し、ステップS107において輻輳監視部50は、その旨を輻輳状態データ51aに更新する。輻輳監視部50のすべての判定対象プロセスについてステップS101ないしステップS107が繰り返されると、ステップS108に進み、一定時間スリープする。一定時間経過後、再びステップS101に戻り、輻輳監視部50は、すべての判定対象プロセスについてステップS101ないしステップS107をそれぞれ繰り返す。次に図4を参照して、セッション制御サーバ1において、発呼信号2を受信し、応答信号3を送信する処理を説明する。まずステップS201において受信処理部10は、発呼信号2を受信すると、ステップS202において自身のサーバ,およびサーバ内の複数のプロセスのいずれかが輻輳状態であるか否かを判定する。このとき、受信処理部10は輻輳状態データ51aを参照して、各プロセスおよびサーバの輻輳状態を取得し、輻輳状態のサーバまたはプロセスがあるかを判定する。いずれも輻輳状態でない場合、ステップS206において受信処理部10は、受信した発呼信号2を、後続プロセスである呼制御処理部にキューイングする。ステップS209において呼制御処理部は、キューから呼を取り出して処理し、応答信号3を送信する。一方ステップS202において自身のサーバ,およびサーバ内の複数のプロセスのいずれかが輻輳状態であると判定された場合、ステップS203において、その輻輳状態の発生プロセスに基づいて処理が振り分けられる。ステップS202において外部から入力された信号を処理するプロセスで輻輳状態が発生していると判定された場合、ステップS204に進む。本発明の実施の形態において外部から入力された信号を処理するプロセスは、図1の受信処理部10である。受信処理部10自身が輻輳状態である場合、ステップS204において受信処理部10は、受信した呼を拒否するか否かを判定する。ここで受信処理部10は、呼の優先度、信号種別などにより、この呼の接続を拒否するか否かを判定する。拒否しない場合、ステップS206に進み、ステップS209において呼が処理される。受信した呼を拒否する場合、ステップS207において受信処理部10は、接続拒否を意味する処理を、後続プロセスである呼制御処理部にキューイングする。ステップS210において呼制御処理部は、拒否信号を生成して応答ソケットに書き込み、応答信号3を送信する。一方、ステップS202において内部から処理がキューイングされるプロセスで輻輳状態が発生していると判定された場合、ステップS205に進む。本発明の実施の形態において内部から処理がキューイングされるプロセスは、図1の第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40である。第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40の少なくとも一つ以上が輻輳状態である場合、ステップS205において受信処理部10は、受信した呼を拒否するか否かを判定する。ここで受信処理部10は、呼の優先度、信号種別などにより、この呼の接続を拒否するか否かを判定する。拒否しない場合、ステップS206に進み、ステップS209において呼が処理される。受信した呼を拒否する場合、ステップS208において受信処理部10は、ステップS208において拒否信号を生成して応答ソケットに書き込み、応答信号3を送信する。ここで、外部から入力された信号を処理するプロセスで輻輳状態が発生する場合を図5に示す。この場合、内部から処理がキューイングされるプロセスが、処理を拒否する応答信号を出力する。受信処理部10において輻輳状態が発生しているので、受信処理部10は、拒否信号を送信する処理を、後続の第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40のいずれかにキューイングする。キューイングされた呼制御処理部は、拒否する意味の応答信号3を生成して、出力する。内部から処理がキューイングされるプロセスで輻輳状態が発生する場合を図6に示す。この場合、外部から入力された信号を処理するプロセスが、処理を拒否する応答信号を出力する。第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40のうちの少なくともいずれかで輻輳が発生している場合、受信処理部10は、接続を拒否する意味の応答信号3を生成して、出力する。ここで、外部から入力された信号を処理するプロセスおよび内部から処理がキューイングされるプロセスで、輻輳状態が発生する場合を図7に示す。この場合、外部から入力された信号を処理するプロセスが、処理を拒否する応答信号を出力する。図1に示す例では、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40が並列に処理している。従って、受信処理部10で輻輳が発生するとともに、第1の呼制御処理部20、第2の呼制御処理部30および第3の呼制御処理部40少なくともこのいずれかで輻輳が発生している場合、受信処理部10は、接続を拒否する意味の応答信号3を生成して、出力する。例えば、受信処理部10および第1の呼制御処理部20で輻輳が発生している場合、受信処理部10は、接続を拒否する意味の応答信号3を生成して、出力する。本発明の最良の実施の形態に係るセッション制御サーバ1は、プロセス単位で輻輳を検出することができる。また、プロセス輻輳により発呼信号2を拒否する場合、プロセス輻輳が生じていないプロセスが、その応答信号3を出力する。これにより、輻輳の生じたプロセスの負荷を軽減しつつ、輻輳の生じていない、余裕のあるプロセスが応答信号3を出力することができる。このように本発明の最良の実施の形態に係るセッション制御サーバ1によれば、マルチコアCPUを搭載したコンピュータ上に構築された場合でも、複数プロセスを分散させるとともに、各プロセスの輻輳を制御ことができる。また、従来はサーバ輻輳の状態の場合、発呼信号を受信した後、受信拒否ルートに入って処理されていたが、本発明の最良の実施の形態においては、プロセスの単位で輻輳状態を管理し、プロセスで輻輳が発生した場合、そのほかのプロセスで拒否信号を生成する。これにより、プロセス単位で輻輳が発し得していた場合でも、応答信号の送信速度を向上させ、セッション制御サーバ1全体で信号の意図しない取りこぼしの可能性を低減させることができる。さらにこのように、信号の応答速度を向上させることにより、輻輳が発生しても、その輻輳が解消するまでの時間を短縮することができ、さらには、サービスの停止の可能性や劣化期間を低減することができる。このように本発明の最良の実施の形態に係るセッション制御方法によれば、マルチコアCPUを搭載したコンピュータ上で、並列して大量の処理を可能にしつつ、プロセス単位で輻輳を制御することができるので、良質なセッション制御を提供することができる。その他の実施の形態上記のように、本発明の最良の実施の形態によって記載したが、この開示の一部をなす論述および図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例および運用技術が明らかとなる。本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。従って、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。"